View Issue Details

IDProjectCategoryView StatusLast Update
0000594DarkRadiantMap Editingpublic08.07.2017 18:54
ReporterSneaksieDave Assigned To 
Status acknowledgedResolutionopen 
Product Version0.9.5 
Summary0000594: Destruction of brush data for unknown classname?
DescriptionAt least, I *think* that's what's going on -- I'm not at all sure.
I believe this is related to 572 ( ) and possibly a duplicate of it. I have yet to confirm the behavior of that one, but as the behavior shown in this issue exists in the latest snapshot, I am guessing it is still a problem.

A map of mine has/had a brick wall in it, where you could remove the bricks (doesn't work too great, but I hadn't revisited it for a better method yet). They are of type moveable_base_brick. I believe this was recently re-org'd into the "/doom3 junk" folder. However, it still exists, and browsing to and assigning that classname does not fix the problem. Attached are two maps -- "fromDE" (saved from doom edit) and "fromDR" (saved from darkradiant) versions of the same wall and bricks. Until recently (I'm guessing before the reorg above) this worked fine. I've gone back as far as DR .92, and it still doesn't show properly, so it seems that the reorg is to blame for at least part of this (though I'm not sure which part). However, it is established that DR is discarding/screwing up the brush info. That's how it relates to 572; it gives the same type of behavior with the dummy brush and _default texture.

1. Open "fromDE" in DoomEdit. Note that each of the bricks does have a brush (blue on my setup). It also has a big black box, which I assume is a problem somewhere resulting from the reorg (??)

2. Open "fromDR" in DoomEdit. The brushes are not shown.

3. Open both in your text editor of choice. Note that each of the bricks in fromDE has detailed brush info: believable coords and textures grouped under "//primitive 0". In the fromDR version, by contrast, the bricks have zeros and small values (0.125) and _default textures, grouped under "// dummy brush 0" (as is the case with 0000572; this also brings a memory of broken windows I had where the func_door became mover_door. I'm guessing this isn't fixed afterall?).

4. Open fromDE in DarkRadiant, and then save it as something else.

5. Open that new file in DarkRadiant or your text editor. The brick brush information from the fromDE file that was in "primitive" has become "dummy" and changed to that of the fromDR file. The information was stripped out or damaged at least. I don't know why, but I'm guessing that perhaps DR isn't handling a classname which has been reorg'd still?

Note though, even that doesn't completely explain it, because I've tried setting up the classname properly, and nothing changes, it stays broken. Very confusing.

Image showing the same file (fromDE) opened in DE and DR. Note the missing bricks in the DR shot:

Version 0.96 snapshot, I can't change the version listbox above.
TagsNo tags attached.


03.03.2008 22:10


maps.rar (2,655 bytes)


04.03.2008 15:55

reporter   ~0001082

Last edited: 04.03.2008 16:08

I've confirmed that moveable_base_brick is fine in TDM (big ugly black boxes appear in both editors, and serve no useful purpose, but that's beside the point and possibly due to defs, I don't know). I guess this confirms that the problem is in fact within DR.

Edit: Furthermore, if I change (in notepad) all of the moveable_base_bricks in the map to func_statics, then DR loads it fine, and shows all of the brush information properly. DR definitely does not like whatever is different about that class type or its path or folder or...

As soon as I change (in DR) the func_static back into moveable_base_brick, the brush disappears. I hope/assume this makes determination easier.

Another edit! Further discovery: If I change one of the func_statics back to moveable_base_brick, using the classname browser to search for "doom 3 junk/moveable_base_brick", the entity breaks in DR (as seen in this entry). If, however, I change it to a moveable_base_brick by *typing that name into the classname field*, it works! So it seems for the second part of this at least (the renaming from within the editor), the classname browser is at fault.

One more edit: the above is true, UNTIL I reload the map in DR again. Now, my properly working moveable_base_brick is in fact broken again. ?! I'm trying to determine what's going on with diffs.



04.03.2008 16:27

reporter   ~0001083

Last edited: 04.03.2008 16:33

Okay let me summarize what I've just done, to get away from the confusing garble above.

1. took the working brick map (fromDE) and made three copies of it.
2. for copy 1, I changed the bricks to func_static, and confirmed that it worked.
3. for copy 2, I changed the bricks back to moveable_base_brick via the classname browser. This broke them in DR immediately, and in TDM, they don't work.
4. for copy 3, I changed (func_statics) back to moveable_base_brick by typing the name into the classname field, NOT browsing. This did not break them in DR (yet), and upon saving this out, it worked in TDM!
5. however, when I reload copy 3 in DR, the bricks are back at square one, broken in DR. If I save this out, they don't work in TDM.

SO. It appears from the outside that the following things are happening:

1. DR doesn't like that entity's (and all others like it in whatever way) path or definition or something else. As a result it doesn't display/handle the brush properly on load.

2. DR also does not save this entity properly (obviously it cannot if it's broken on load or change).

3. The classname browser applies changes immediately, while typing in new classnames does not. They act differently, at least, that's for sure. Furthermore, as seen in 3 and 4 above, the classname browser is doing something (destroying/modifying, "primitive" -> "dummy") to the brush info for an entity it doesn't handle.

I think that's it?

It appears that definition changes to moveable_base_brick during reorg merely exposed this problem. It is highly recommended that whatever is wrong with moveable_base_brick definition NOT be fixed until after this problem is addressed in DR, otherwise there will be no means to verify the fix is successful and thus safe to use.



04.03.2008 19:53

administrator   ~0001084

Ok, thanks for putting so much effort in narrowing this down. I'll look into it sometime, but I can't make any promises at this point.

Issue History

Date Modified Username Field Change
03.03.2008 22:10 SneaksieDave New Issue
03.03.2008 22:10 SneaksieDave File Added: maps.rar
04.03.2008 06:34 greebo Status new => acknowledged
04.03.2008 15:55 SneaksieDave Note Added: 0001082
04.03.2008 15:58 SneaksieDave Note Edited: 0001082
04.03.2008 16:00 SneaksieDave Note Edited: 0001082
04.03.2008 16:04 SneaksieDave Note Edited: 0001082
04.03.2008 16:08 SneaksieDave Note Edited: 0001082
04.03.2008 16:27 SneaksieDave Note Added: 0001083
04.03.2008 16:30 SneaksieDave Note Edited: 0001083
04.03.2008 16:33 SneaksieDave Note Edited: 0001083
04.03.2008 19:53 greebo Note Added: 0001084
08.07.2017 18:54 nbohr1more Relationship added related to 0004557
08.07.2017 18:55 nbohr1more Relationship deleted related to 0004557