EntityClassAttributes

[greebo]

I've looked into this issue report http://bugs.angua.at/view.php?id=443 which deals with some editor_* properties not showing up.

 

The problem in this particular case (atdm:mover_door) is that the editor_bool trigger_on_open is encountered after the actual trigger_on_open.

 

...
"frob_action_script"		"frob_door"
"trigger_on_open"			"1"
"trigger_on_close"			"0"

"editor_bool trigger_on_open"		"If set to 1, blah."
"editor_bool trigger_on_close"		"If set to 1, blah."
...

 

DarkRadiant eclass manager parses this definition and inserts the first trigger_on_open, the second editor_bool trigger_on_open is ignored as it is already existing in the map.

 

I'd say we need to change the way the editor_* stuff is handled so that they are explicitly tagged as editor_* spawnargs. OrbWeaver, I think it was you who wrote that part - is there anything that needs to be considered, any problems you wanted to tackle with this approach? I don't want to rush in changing the current design without making sure that it's safe.

[greebo]

After thinking about this a bit more and reading through the code, I believe the current EntityAttribute system doesn't need to be changed, rather the way it's used by the EntityInspector's AddProperty dialog.

 

The confusion as described in the issue report seems to arise from the fact that "trigger_on_open" actually is defined on the entity in the inherited properties, hence DarkRadiant thinks it doesn't need to be listed in the "Add Property" dialog.

 

I assume that users do want to add such a property to the entity, even though it is already inherited in the entityDef?

 

Independently of this, the parser needs to be adapted a bit to read in the attribute type from the "editor_*" spawnargs, even if a "proper" spawnarg is already set.

[OrbWeaver]

It's a long time since I wrote that code so my memory is very hazy, but your assessment sounds pretty accurate to me. What I'm not sure about is whether there is currently a distinction between "inherited" actual properties from the entity def, and "inherited" properties from "editor_var blah" properties on the entity def.

[greebo]

What I'm not sure about is whether there is currently a distinction between "inherited" actual properties from the entity def, and "inherited" properties from "editor_var blah" properties on the entity def.

We do have information about whether an EntityClassAttribute is inherited or not. However, we can't make use of this in this particular case, because we're adding properties to the Entity itself, and via Entity::getKeyValue we have no information about whether the returned value was inherited from an entityDef or coming directly from the entity itself.

 

If the spawnarg was inherited, it should be listed, but if there is already such a spawnarg on the entity itself, it should be omitted in the AddProperty treeview.

 

The quick and dirty solution would be to always list properties, regardless of whether they exist or not on the entity.

 

The safer code would be to find out about the inheritance status of the returned keyvalue. I'll have to investigate this.

[greebo]

I can think of two quick ways to solve this problem:

 

Implement a method bool Entity::isInherited(const std::string& key) which checks the status on a case-by-case basis, or add an optional parameter to getKeyValue, which can prevent the Doom3Entity object from querying the eclass if the requested spawnarg wasn't found.