View Issue Details

IDProjectCategoryView StatusLast Update
0000572DarkRadiantMap Editingpublic12.12.2008 15:59
ReporterSneaksieDave Assigned ToSneaksieDave  
Status closedResolutionfixed 
Product Version0.9.4 
Fixed in Version0.9.9 
Summary0000572: Object with changed classname suffers frobbing changes
DescriptionAt first, I thought changing classname was breaking doors completely, but it turns out this is actually more benign (though still pretty serious).

1. Create a new MODEL of a door (e.g., architecture - doors - ones with hinges)
2. Change a brush somewhere (to force D3 to rebuild the BSP), save the map and look at it in TDM.
3. Back in DR, change the classname of the model to be one of the TDM doors (e.g., darkmod - movers - again, ones with hinges). This is perhaps stretching the example, as the user could simply choose one of these in the first place, but it is for the sake of demonstrating the problem. The behavior is assumed possible for any or all such classname changes.
4. Change a brush again, save/build the map, and try the door. Works great.
5. Back in DR, close and re-open your map. The first thing I note is that now the door is orange, the default color. Hmm. Perhaps this is okay.
6. Change a brush somewhere, save it, and build/launch in TDM again.

Now, to open the door successfully, you must frob down in the lower left corner of it. Note also, you can walk right through (or rather up, and through) the door!

I did a windiff of before and after the change and reloading of the map. The changed version has a "dummy" brush added, with "_default" texture, which seems to be stealing the frob and bounding box of the door model. Whether this happens for a reason or not I don't know, but it has bad results in-game. I also came across this several months ago, but somehow it corrected itself (was the dummy brush deleted??) and I didn't understand what was going on enough to report it. With the steps above it is fully reproducable.

Version is 0.9.5 Jan 12, I can't change the listbox above.
TagsNo tags attached.




17.02.2008 20:22

administrator   ~0001054

Can you try to reproduce this with a newer snapshot build here. I recently fixed 0000571 and I think this is resolved now too.

03.03.2008 22:37


test.rar (4,523 bytes)


03.03.2008 22:39

reporter   ~0001080

I tried this out with the current 0.96 snapshot, and I still get the problem. Attached is a rar of the exact map produced from going through the steps. In TDM, one must look downward to frob it, and can step up/over the dummy brush assigned to the door.


04.03.2008 06:31

administrator   ~0001081

I will look into it again then.


09.12.2008 15:48

administrator   ~0002215

Dummy brushes have been disabled since the Saint Lucia release - please revisit this bug.


12.12.2008 15:59

reporter   ~0002233

Okay, this checks out now. It is assumed if dummy brushes make a return (weren't they for DoomEd compatibility?) this will again resurface...

Issue History

Date Modified Username Field Change
10.02.2008 20:57 SneaksieDave New Issue
17.02.2008 20:22 greebo Note Added: 0001054
17.02.2008 20:22 greebo Assigned To => SneaksieDave
17.02.2008 20:22 greebo Status new => feedback
03.03.2008 22:37 SneaksieDave File Added: test.rar
03.03.2008 22:39 SneaksieDave Note Added: 0001080
03.03.2008 22:39 SneaksieDave Status feedback => assigned
03.03.2008 22:39 SneaksieDave Assigned To SneaksieDave =>
03.03.2008 22:40 SneaksieDave Assigned To => greebo
03.03.2008 22:40 SneaksieDave Status assigned => feedback
04.03.2008 06:31 greebo Status feedback => assigned
04.03.2008 06:31 greebo Note Added: 0001081
09.12.2008 15:48 greebo Note Added: 0002215
09.12.2008 15:48 greebo Assigned To greebo => SneaksieDave
09.12.2008 15:48 greebo Status assigned => feedback
12.12.2008 15:59 SneaksieDave Note Added: 0002233
12.12.2008 15:59 SneaksieDave Status feedback => closed
12.12.2008 15:59 SneaksieDave Resolution open => fixed
12.12.2008 15:59 SneaksieDave Fixed in Version => 0.9.9