Xaleros Yesterday at 9:18 AMI uh, found out something interesting about maps with the brushwork deletedIt actually does not delete the brushes, it just sets the bDeleteMe variable to true so that if you were to rebuild it, it would delete thembut they are actually still stored in the level itselfso it reverse that, literally all you have to do is go through the level, switch all of those variables to 0 instead of 1and then the brushes are restored

So there's your fix for stripped maps. Anyone want to make an automated script for this? It's time we restored a bunch of maps.

"You damn kids, back in my time we made the items, maps and games ourselves with an unwieldy engine using counter-intuitive crash-prone tools and we liked it so much we built communities around this which nowadays look like cults because they're quasi-parallel societies based on the same old games." -Hellkeeper

Yay, challenge accepted... but I cannot be sure if exist any brush in Editor with bDeleteMe because I can iterate and recover them or consolecommand-ing them, but I did not get any response. GarbageCollector did its job somehow ?

Edit:Yeah, a sample: MH-Egyptica - opening map in NotePad++ exported as t3d and then as UNR. I was looking for string "Brush" - I found... Movers. Did I miss something ?Edit2: If map without any Brush is smaller, how can I be sure that they are still in Level ? 300K contest maps have small size and one of them has a 400 k version with brushes inside. 100Kb removed by stripping brushes ? How do am I supposed to recover this data and where is it stored (compressed ???) ? Myths from discord ? April fools in January ?EDIT3:

Trumph wrote:Fake news...

It's called CTF-300k-FrozenFrag and BSP one it's called CTF-300k-FrozenFrag_bsp. Size is definitely saying that some content from this Level is GONE - NONE. 297kb < 457kb - I need to know the Voodoo Magic turning 297 kb into 457 kb by simply setting up some value from 1 to 0

Chamberly wrote:So that's why maps were still able to play regardless... Neat!

I think that has nothing to do with the Brushes in a map. The brushes are needed to build a bsp tree (with UnrealED), and the game engine only used this tree when running this map. That's why brushes can be removed from a map while the map is still playable.

I also don't believe that deleted brushes can be recovered after the map has been saved. As Sector said the file size of a map is smaller (about 25% at one example here) if you delete the brushes and store the map so there is significant missing something.

"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

Xaleros Yesterday at 9:18 AMI uh, found out something interesting about maps with the brushwork deletedIt actually does not delete the brushes, it just sets the bDeleteMe variable to true so that if you were to rebuild it, it would delete thembut they are actually still stored in the level itselfso it reverse that, literally all you have to do is go through the level, switch all of those variables to 0 instead of 1and then the brushes are restored

So there's your fix for stripped maps. Anyone want to make an automated script for this? It's time we restored a bunch of maps.

And how would you do that when all the data you have is BSP? You can't open it in Notepad. The best solution would be to make some weird sort of UnrealEd plugin that iterates on every brush actor and set that variable, but even then, I have my doubts. Sektor has a valid point (how rare!), and I'm sure the brushes are indeed deleted (in most striped maps, anyway), and the only reason the map playable is that it has BSP leftovers (its geometry hasn't been rebuilt).

Moreover, if a map author doesn't want a derivate of any of his work to be published, we need to respect it. It's pretty much the same as breaking the terms of a license that disallows derivate work, except there is no license, and I'm pretty sure it would be much more difficult to be taken to court for that.

Why would you need all the vertices of brushes if you can have less than half usually in an entire map? Why keeping a brush which of most vertices are stuck in another brush? Or keeping the vertices of a subtracted brush. I believe the brushes get converted into Level when you build them, indeed when you build a brush and move the brush somewhere else the built brush is still there until you rebuild.

There is no flag called bDeleteMe in UT99. There is in ut 2003/4. I believe this is for something else (it only occurs once).

Using 300k FrozenFrag as an example - the CSG brush data is gone gone gone. When you delete the csg brushes and save, the data is gone.If the map was built, then there is still the compiled data, of course. The 2d viewports don't lie - they use csg brush data to draw lines. 3d views used the compiled data (we refer to as "bsp"). So you can still see things in these views.

Most you can do to recover a brushless map for editing is this:surround the whole thing with a giant cube builder brush and then de-intersect. subtract the brush and order to first. rebuild.tada! of course only works with simple maps - I think (correct me if i'm wrong, but you only have about 500 surfaces per brush before it blows up in UED ... some such thing

If the single brush is not TOO BIG then you could subtract this and add or subtract some extra brushes from it. Lots of chances for HOMs though...

Another example: Not 100% sure, but this one smells like it was "recovered" and then edited (Thornsv3)There were tons of these back in the day...

Between Funky and Frag I think that pretty much sums up things nicely in a way I've never really thought of. Funky is right that when the map is built the brushes convert to level. That's the key thing to remember. Once those brushes get converted they really aren't needed any longer. You can delete all of them and everything is fine as long as you don't rebuild. Frag's example of encompassing the level in a brush works because the level data is still there, just not the individual brush data.

I now think of brushes in a map as a list of instructions for the compiler. Once the instructions are followed you don't really need to leave them in. It also logically follows that you can't de-engineer the map back into the component brushes because a lot of that data is lost in the compiling. Overlapping brushes, intersecting areas, all that would no longer be necessary information. The engine doesn't need any more data than the resulting shape after the brushes are applied. Really this is just designing something like a chair in editor but just on a larger scale.

Damn, that feels good to finally understand. Thank you guys. Now it's settled: there will never be a way to recover stripped maps. Some data is simply not retrievable.

"You damn kids, back in my time we made the items, maps and games ourselves with an unwieldy engine using counter-intuitive crash-prone tools and we liked it so much we built communities around this which nowadays look like cults because they're quasi-parallel societies based on the same old games." -Hellkeeper

There's in fact a very simple way to know if the brushes are still there or not, rather than assuming they aren't just because the file size is smaller (which could happen for other non-obvious reasons, such as some editor-specific cleanup): open one of those maps in UTPT and check if there are any brushes.

I never checked it myself, so I am not sure what you will find there, but it will become clear as crystal which is the case once you do.No need to make potentially false assumptions (not saying the brushes are there, everything indicates they aren't, but you have to open the map and see the binary contents with UTPT for example to be 100% sure).

Feralidragon wrote:There's in fact a very simple way to know if the brushes are still there or not, rather than assuming they aren't just because the file size is smaller (which could happen for other non-obvious reasons, such as some editor-specific cleanup): open one of those maps in UTPT and check if there are any brushes.

I never checked it myself, so I am not sure what you will find there, but it will become clear as crystal which is the case once you do.No need to make potentially false assumptions (not saying the brushes are there, everything indicates they aren't, but you have to open the map and see the binary contents with UTPT for example to be 100% sure).

Surely exporting to T3D won't export any brush except for the active one.

Many games turn their static objects into one or a few unified objects, especially for those games that had to fit in a small storage like PS1 games, it's like baking in Blender.

Do not use Menu>Brush>Export but Menu>File>Export to export the complete map.

Feralidragon wrote:a very simple way [...]: open one of those maps in UTPT and check if there are any brushes.

My first guess is that UTPT reads the name table only. My second is there may be differences between the name table and the data content of a package. I stumbled over that while I was coding a program that reads a package and tries to detect duplicate Actors. The name table is clean in this case, but I guess that UnrealEd reads the content and therefore shows Actors with duplicate (or even multiple names).

See for example "Miniammo2" from map MH-Dark-Laws{fix}.unr in UTPD and UnrealEd.

Last edited by Barbie on Wed Jan 16, 2019 5:51 pm, edited 1 time in total.

"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

PrinceOfFunky wrote:Why would you need all the vertices of brushes if you can have less than half usually in an entire map? Why keeping a brush which of most vertices are stuck in another brush? Or keeping the vertices of a subtracted brush. I believe the brushes get converted into Level when you build them, indeed when you build a brush and move the brush somewhere else the built brush is still there until you rebuild.

ya true - this reminds me of some thoughtful things. It is not too hard to imagine what the compiler is doing with brush data in order to process the "bsp-tree". I actual have/had (engineering) documents how these algorithms work.

Abstractly, the business of lining vertices up all neat and tidy on the uu grid otherwise it's a disaster is a bit silly. That's just humans being tidy.

It's all 3D math using double-precision numbers, rounding (at some depth/tolerance) and triangles with normals so the compiler knows which face is in space, or the void. Basically the compiler/algorithm only cares about the faces in the space side of normals, ignoring the void. So really, additive csg brushes that exist in or extend into the void is basically IGNORED by the complier. Of course the exposed part is used in calculations.

There's more to it obviously, like occlusion (data to support what to render to the camera (FOV / POV), collision, lightmapping blah blah). Lots of room for ERRORS - resulting in things like hommies, holes, invisible "walls", black blotches etc.

Some guys, knowing this, would consciously throw mud in the face of the so-called "guru" mappers (in the editor, of cource). A favorite example of mine is Blito3 and his map "Island of the skull devils". Open it in the editor and have a look. Hilarious! And it works - of course it does Now try and find HOMs. Good luck - i don't believe you'll find any. Now open CTF-Tuesday (by you know who) not hard to find HOMs in that one, as I recall.