Objects Disappearing

[OrbWeaver]

I have identified the "disappearing object" behaviour that some people have reported. By creating a map in DR with a single atdm:moveable_torch1, I get a map file containing this entity:

 

// entity 1
{
"classname" "atdm:moveable_torch1"
"name" "atdm_moveable_torch1_3"
"origin" "-80 168 0"
}

 

Which causes the torch to disappear when opened in DoomEdit although it loads fine when reopened in DarkRadiant.

 

Creating an identical map in DoomEdit produces the following:

 

// entity 1
{
"classname" "atdm:moveable_torch1"
"name" "atdm:moveable_torch1_1"
"origin" "16 16 0"
// primitive 0
{
brushDef3
{
 ( 0 0 -1 0 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 0 1 -8 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 -1 0 -16 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 1 0 0 -16 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 1 0 -16 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( -1 0 0 -16 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
}
}
}

 

Note the existence of a dummy brush, which is the cube you see in the 2D windows (although the 3D window shows the proper torch model). It seems a bit bizarre to me, but maybe DoomEdit requires this dummy brush to be written to the map file in order to load and display the entity?

[greebo]

Is it possible, that the colon-underscore-replacement does cause any troubles? Maybe DoomEdit is relying on the name of the Entity as well?

 

It's unlikely as one could change the name to something arbitrary by using the entity name, but it would be worth a check.

[OrbWeaver]

I did try deleting the brush primitive from the .map file and reloading in DoomEdit, and it still disappeared, so I don't think the entity name is the problem.

[greebo]

So what could be solution for this? Should DR automatically turn every entity into a brush-based one by adding this dummy-brush?

 

As long as DoomEdit is still required to achieve some mapping goals this should assure the portability of the maps, but we can dump this as soon as DoomEdit becomes obsolete.

[OrbWeaver]

So what could be solution for this? Should DR automatically turn every entity into a brush-based one by adding this dummy-brush?

 

Assuming this is the fix, we can add the dummy brush at map save. The brushes are automatically discarded by DarkRadiant when it is loaded again.

 

As long as DoomEdit is still required to achieve some mapping goals this should assure the portability of the maps, but we can dump this as soon as DoomEdit becomes obsolete.

 

Agreed, I propose an option in the .game file to specify whether this is necessary or not.

[SneaksieDave]

This is giving me major déjà vu. I could swear we came across something like this before. Maybe dealing with lights and ... or non-light entities bound to lights. Or grouping or linking. Or something.

 

Yeah, that's probably zero help.

[OrbWeaver]

This is giving me major déjà vu. I could swear we came across something like this before. Maybe dealing with lights and ... or non-light entities bound to lights. Or grouping or linking. Or something.

 

Are you referring to a problem in the past with DarkRadiant, or with DoomEdit?

 

In DoomEdit you cannot have an object-light entitydef that displays both a lightvolume and a model, even though you can create such an entity manually in the editor. Is this what you are thinking of?

[SneaksieDave]

Yeah it was DoomEd. And that's possibly/probably it...

[OrbWeaver]

Yeah it was DoomEd. And that's possibly/probably it...

 

Notice that if you place a atdm:moveable_torch1 in DarkRadiant it looks like a torch (because that is what its model is set to) whereas if you place it in DoomEdit it appears as a 16x16x16 brush.

 

The problem here is that DoomEdit requires that brush to be written into the mapfile, otherwise it cannot display the entity at all. What a crock.

[OrbWeaver]

Now FIXED.

 

I will put out a 0.7.1 bugfix release this weekend.

[SneaksieDave]

Does this raise any question of either of the following:

 

1. DoomEd ever not being able to open a map created in DR due to this, or this type of thing?

2. A map created in DR, but opened and re-saved in DoomEd, suddenly would have problems in DR?

3. How will DR handle this brush, if originally created in DoomEd? Prune it off, or leave it alone without issue?

 

I realize the goal is to have everyone using DR (and that's well under way) but at least the option to use either should remain, I think.

[OrbWeaver]

1. DoomEd ever not being able to open a map created in DR due to this, or this type of thing?

 

The latest fix was to avoid precisely this situation. It is actually what I would consider a bug in DoomEdit, but DarkRadiant now has workaround code to handle this.

 

2. A map created in DR, but opened and re-saved in DoomEd, suddenly will have problems in DR?

 

This would never have been a problem.

 

3. How will DR handle this brush, if originally created in DoomEd? Prune it off, or leave it alone without issue?

 

DarkRadiant will discard the brush when loading the map, and re-insert it when the map is saved if the compatibility option is set.

[OrbWeaver]

Unfortunately this isn't as fixed as I thought it was. It appears that the maps saved with this workaround cannot be opened again in DarkRadiant for some reason. Hopefully this will be fixed soon so a new release can be made, but no guarantees.

[greebo]

Should we somehow "mark" these dummy brushes, so that DR can automatically strip these brushes on load via a boost::regex?

[OrbWeaver]

I am losing confidence that dummy brushes are indeed the answer. I just did a test -- loading and saving askave.map corrupts the file (so DR cannot load it) if the dummy brushes are added, but works OK if they are not added. Furthermore, the original file contains loads of entities that do not have dummy brushes at all.

 

It seems that further investigation will be required to determine exactly when dummy brushes are needed and when they are not (maybe something to do with whether the entityclass has a "fixedSize").

[Ishtvan]

No one has mentioned the difference in the "origin" key for the two examples. Was this just because the entity was not placed in the same exact place in the DR and DE tests, or is that origin getting set to a different value even though it's being placed in the same place?

 

Also, could the brush in this case be related to the collision model of the torch? Some moveables have had their CM generated via a brush and then exported to CM. After that point you shoudln't need the brush you used to generate the CM anymore (assuming the object is defined in a def somewhere and the CM has been exported), but maybe the editor has to put it back for moveables that have been set up that way, so that the CM can be displayed in the editor. I don't think so, but it's possible.

[sparhawk]

I am losing confidence that dummy brushes are indeed the answer. I just did a test -- loading and saving askave.map corrupts the file (so DR cannot load it) if the dummy brushes are added, but works OK if they are not added. Furthermore, the original file contains loads of entities that do not have dummy brushes at all.

 

It seems that further investigation will be required to determine exactly when dummy brushes are needed and when they are not (maybe something to do with whether the entityclass has a "fixedSize").

 

Maybe it has something to do with the collision box? I'musing DoomEdit and I placed a plank into the map and was a bit surprised that I could resize the brush. It gave me the impression that it treated the brush as the collision box. However when I manually replaced the modelname in the map, the brush suddenly stayed the size I had adjusted it before and was no longer resizable. Mabye that is a hint to give you an idea where to look for? Actually I found it quite convenient to be able to adjust the collision brush in the editor. If possible that would be a good feature to have.

 

Maybe the brush is used if the model doesn't specify a CM and if both are there it gets confused? Just speculation from my observation, I haven't really analyzed it more deeply.

 

Edit: LOL, Ishtvan beat me to that idea.

[OrbWeaver]

Just to clarify, dummy brushes do solve the disappearing objects problem, but adding dummy brushes indiscriminately causes problems when the map is loaded (in particular, a func_static with a model must NOT also have child brushes).

 

Intuition tells me that this has something to do with the fixedSize property of entity classes (a Radiant-internal attribute, I don't think it can be set in the DEF file). Perhaps adding dummy brushes to fixedSize entities, based on the size information in editor_mins and editor_maxs spawnargs, is the answer.

[Ishtvan]

Maybe it has something to do with the collision box? I'musing DoomEdit and I placed a plank into the map and was a bit surprised that I could resize the brush. It gave me the impression that it treated the brush as the collision box. However when I manually replaced the modelname in the map, the brush suddenly stayed the size I had adjusted it before and was no longer resizable. Mabye that is a hint to give you an idea where to look for? Actually I found it quite convenient to be able to adjust the collision brush in the editor. If possible that would be a good feature to have.

 

Maybe the brush is used if the model doesn't specify a CM and if both are there it gets confused? Just speculation from my observation, I haven't really analyzed it more deeply.

 

Edit: LOL, Ishtvan beat me to that idea.

 

Hmm, that is interesting. We know that it saves the brush to a CM file when you use a brush as a CM, but I have no idea how it re-imports that into the map when you place the moveable with a brush-CM. Maybe this dummy brush you get is how it imports in the CM for moveables that originally had the CM defined by a brush? I dunno. I think Spar and I are thinking about this because the entity shown in the example was a moveable with a brush-defined CM. Do you know if it happens with other entity classes with CM's that are not defined by brushes? (Like func_statics or moveables with the CM defined in the model file rather than a brush.. I think the ammo_* arrow moveables are set up that way).

[OrbWeaver]

I'm fairly sure the dummy brushes are not CMs. If you try placing a atdm:moveable_torch1 in DoomEdit you can see that it is represented by a square brush, while in DarkRadiant is displays correctly as a torch. It seems that Doom 3 requires this brush for certain entities that are not lights or func_statics (or other resizable entities), perhaps because it has no way of displaying entities that don't have some kind of "child" (e.g. model or brushes).

[Ishtvan]

Looking at the files for moveable_torch1 specifically, I noticed that it does NOT have a CM defined by a brush anyway, it's in the model file. So I guess we can forget that idea.

 

Out of curiosity, does the same thing happen with atdm:moveable_candle1 and candle2? I'm wondering if it's something bad in that specific torch moveable?

 

Getting back to your theory OrbWeaver, all the things that inherit from moveable_base seem to have the following set:

"editor_mins"						"?"
"editor_maxs"						"?"
"editor_rotatable"					"1"

 

Don't know if that helps or not.

[OrbWeaver]

Well the fix is in 0.7.1, so hopefully it will soon be clear whether it was the right solution or not.