OldUnreal (Engine)

Context:
I have been working on a map lately (CTF-Blice), for UT99, which I would like to finish for the 20th anniversary of the game, as a bonus map for the community contest/map pack going on at ut99.org.

This map is fairly complex in terms of BSP (mostly on the amount of geometry), so to surprise of no one, the BSP builds end up with high node counts.

I had everything under control however, since when using the optimized BSP build (Build All button) the node count was reduced in around 30%, meaning that although I was near the node count with a normal BSP build (Build BSP button), with an optimized build the node count went down to around 45k-50k, which was a good enough margin for what is still left to do in the map (which isn't that much).

However, UEd2.0 caught me off-guard on the fact that it seems to do a normal BSP build first, and only afterwards it optimizes the cuts and the overall tree in the end, meaning that in the first build step the node count ends up going beyond the limit, and triggering a crash, despite the fact that in the end the node count would actually be below the limit.

Upon exposing this fact, and essentially announcing the map being canceled (since I had no way to finish it), papercoffee and Dr.Flay told me that I could use UEd2.1 for UT99 maps, and perhaps be able to finish the map with it, provided I did the right configuration steps (Unreal.ini file paths + ported Botpack package).

From there, to my own delight, I was able to open the map in UEd2.1 without issues, as well building everything.
Other issues I had with the map (namely lighting bugs) were also fixed, so that was another big plus.


Problem:
However, upon building the BSP, I found out a critical issue with the BSP builder itself, an issue that UEd2.0 does not have: it seems that UEd2.1 is unable to do an optimized build of the BSP.

In other words, there is no difference between using Build BSP or Build All with the optimized settings.
There's also no difference whatsoever regardless of the values I set up in the BSP sliders, meaning that it seems that the optimization step is not working at all.

This results in 2 problems:

1. The final node count exceeds the 65k limit imposed by UT99/UEd2.0, meaning that it becomes unusable there.

2. I make heavy use of semi-solids: I use them whenever there's no reason to use a solid.
However, when using semi-solids, they often have an occlusion bug when doing a normal BSP build, where semi-solid surfaces occlusion is inverted (are not rendered when in view, and vice-versa), which is completely fixed by doing an optimized BSP build, that takes longer to process, but fixes most BSP issues and lowers the node count in the end.


However, there's a perceived process difference between Build BSP and Build All in UEd2.1: with Build All the geometry optimization steps do appear and take some time to process, unlike Build BSP, so the processes seem to be triggered, but it also seems that unlike UEd2.0 they run before the normal BSP build step, so I wonder if this bug isn't simply the order of processes having been swapped, and thus the optimization steps are not optimizing anything since there's nothing yet to optimize, or if they are optimizing the previous BSP build instead (hence taking some time).

Therefore, my question is: is this a known problem, and has it been already fixed somehow?


For reference, this is the map I am mentioning:
https://ut99.org/viewtopic.php?f=5&t=13 ... 45#p114713
https://ut99.org/viewtopic.php?f=5&t=13 ... 60#p115149

If you perhaps need this map to be able to reproduce the problem, let me know and I will PM you the latest version of this map. [smiley=smiley.gif]

Any news about this?

It's fine if this is already a known or confirmed bug waiting to be fixed eventually, I just need to know if anyone is able to reproduce this and if I am not doing anything wrong on my end.

Sorry, I've not been able to do very much in the last time, so I missed this here.

It's been a while I've working on that, but I am pretty sure optimization was working. I can give you access to current 227j though, so you can give it a try there and if not working there too we can have a look what's up?

No problem.

I just want to make sure that, if there's a bug, at least it goes to the todo list, especially with anth and maybe a few others now in the development cycle.

So yeah, that sounds good, if you give me access to it I will test this out and give feedback.

Looking at the code it seams to simply be doing it in wrong order (BSP->Gemetry->Lighting->Paths).
Try Build all but disable Geometry step.

Thank you for looking into this.

I just tried what you suggested, and it worked.
The number of nodes were reduced to 44k, and thus I was able to open it in UnrealEd 2.0 and run it in UT99 without any issues whatsoever.

So I assume that, for the time being, until this gets fixed in a future UnrealEd release, all I have to do is to do a normal BSP build whenever I change the geometry, and then do a Build All without the geometry step.

Thank you, this may be good enough for now for me to finally finish my map (although it's not that great of a map, but I would like to finish it nonetheless).