Work In Progress Uncategorized

[Raap]

4 minutes ago, jonwil said:

I just added a feature to Mammoth so it will read these per-map sky settings. The old Westwood editor is going away in the near future since Mammoth is nearly feature complete (the main remaining thing on the to-do list is fixing all the bugs in our reverse engineered clone of the vis generation algorithm) and definitely couldn't have this stuff added in any case.

When you change the ini you will just need to reload the map and it will read your changed sky colors.

As for the dependencies, Mammoth makes it trivial to add the ini file as a dependency of the map (that will get automatically exported into the map mix file). The dependency information is then stored in the .lvl file and travels with that.

You solved most of the VIS and pathfinding problems? Nice work then, I can finally uninstall Level Edit and leave it back in 1977 where it was created.

Reading the ini's sounds good. Next step is a UI that can write them, right?

As for dependencies, can you explain this? It isn't being exported by default - the ini is in the project editor cache folder. Had to do the preset dependencies work-around to make it export.

Edited July 14, 2018 by Raap

[jonwil]

Right now what we have is a reverse engineered clone of the pathfind generation that is (at least assuming there are no bugs left) producing valid correct usable output that matches the output of the original Westwood code in all the places that matter. And we have the same thing for the vis generation but its full of bugs that we are still in the process of fixing and is 100% not usable as of right now (to the point where using it guaranteed to produce bad output assuming it doesn't crash first).

Note that pathfinding in Mammoth can't be canceled in the way it can with Leveledit so you will need enough pathfind blocking objects to ensure it is able to complete without running out of memory.

We haven't really made any improvements to the pathfinding or vis generation yet (well there is one improvement in that if you proxy in a ladder transition object, it will now get proper action portals and bots will use that ladder). What happens in terms of improvements to that stuff will depend on what Neijwiert (the genius who did most of the work around pathfinding) ends up implementing.

As for a UI that can edit the sky colors, that's not as easy as it sounds unfortunately. Maybe in the future I will look into it but right now the priority is to get all the things done that need to be done before we can completly drop LevelEdit for good.

In terms of dependencies, what you need to do is to open Mammoth (assuming the version you are using is new enough) then open your level and choose "edit-include files". Anything you add to the list in there will be included in the mix file automatically when you use "export to mix" or "run game" or whatever). The list itself is stored in the .lvl file.

[Raap]

Ah so that's what the include option does. After you mentioned the dependencies stuff in your previous post I noticed it but didn't know what the purpose of it was (I'm probably still conditioned into ignoring half the options from LE, given that most did nothing useful).

Anyhow, sounds like Neijwiert is quite an asset!

Edited July 14, 2018 by Raap

[Raap]

Hooray for experimental things!

Added periodic dust storms that blow into the map from afar (dev note: I solved the problem of animated effects no longer rendering when the origin point is not within view, so this effect will now always appear).

Late Edit: I made some alterations, such as raising the fog brightness. I kept the old screenshot above to allow for comparisons.

Edited July 15, 2018 by Raap

[moonsense715]

3 hours ago, Raap said:

(dev note: I solved the problem of animated effects no longer rendering when the origin point is not within view, so this effect will now always appear).

How did you do that? I have lots of these problems

[Raap]

15 hours ago, moonsense715 said:

How did you do that? I have lots of these problems

Same way to fix anything in W3D: Use a bigger hammer.

 

Because I know where this animation is located to play within the world, I've added visible-but-under-terrain boxes in a 360 radius (hidden meshes do NOT work for this), as well as one in the middle of the level. This ensures that no matter where your camera turns, you will always be rendering the animation.

This cannot be applied to emitters, only to 3DS-created animations. It also is most reliably used for static environmental effects and nothing dynamic that could spawn animations at odd rotations (else you'd get floating boxes in the air).

Not a perfect silver bullet solution to all animation issues but it certainly works for me here.

 

Edit: I updated my previous post with an updated image alongside the old one. If anyone has an opinion on which looks better, let me know.

Edited July 15, 2018 by Raap