Askave.map Crashes Dr With Assertion Failure [closed]

[OrbWeaver]

Loading askave.map from the latest CVS crashes DarkRadiant with the following assertion:

 

darkradiant: libs/traverselib.h:275: virtual void TraversableNode::insert(scene::Node&): Assertion `m_node == 0' failed.

 

A quick text search does not reveal any CVS-related corruption or merge indicators. The map loading code needs to be considerably improved, at the very least it needs to say which entity caused the crash and the line in the .map file if possible.

[OrbWeaver]

Seems to be on the first primitive in the worldspawn.

 

Unusually the worldspawn has a name in this map:

 

"classname" "worldspawn"
"name" "askave_hidden_door_1"
"hide" "0"

 

Perhaps DarkRadiant is unable to deal with these properties.

[OrbWeaver]

Confirmed. Editing out these extra properties causes the map to load successfully.

 

This looks like a bug, if Doom 3 can cope with worldspawn properties then so should DR.

 

EDIT: It seems to be specifically the "name" property that causes the crash, other properties seem to be OK.

[OrbWeaver]

The problem seems to be that the worldspawn Doom3Group is being considered a model (func_static) because the "model" key (which is unset) differs from the "name" key.

 

I have corrected this by adding a separate exclusion for "worldspawn" in Doom3Group::updateIsModel() which solves the worldspawn issue, but now there is another problem with the entity named "trigger_hurt_2" which contains both child brushes and has a model key equal to the name key.

 

EDIT: Never mind, got it the wrong way round. Model == name means NOT a model entity.

[OrbWeaver]

Fixed in rev 376

[sparhawk]

Does this mean that you can also set key/value pairs on worldspawn? How do you read that? Would be interesting to use this for global parameters.

[OrbWeaver]

This is certainly possible in DarkRadiant, you can edit the worldspawn like any other entity by selecting a brush. I assume that Doom 3 must support it as well hence the keyvalues appearing in ascottk's map.

 

I also think that this would be a good way of storing global state; it might even be possible to use "editor_xyz" keys to store editor-specific state such as the last part of the map you were viewing in the editor.

[sparhawk]

Maybe not the map, but you could set where the camera was last oriented and such things.

[ascottk]

I thought this map might come in handy some day Which reminds me I need to update that thing . . .