editor_setKeyValue support

[greebo]

I added support for a new kind of editor_ spawarg to DarkRadiant, which allows an entityDef to specifiy a ste of keyvalues which are set on the actual entity after creation. This was a response to this request http://bugs.angua.at/view.php?id=1306, to make func_emitters easier to use.

 

This is the section on the entityDef:

"editor_setKeyValue model"  "-" // the key value to be set when this entity is created

 

The entity will carry a "model" spawnarg right after it will have been created. It's possible to define multiple editor_setKeyValue spawnargs, just add an index to them like this "editor_setKeyValue1".

 

This will be active with the next DarkRadiant release.

 

This also makes me think, whether we should have a wiki article describing these editor_* spawnargs? Anybody up to that?

[Tels]

I added support for a new kind of editor_ spawarg to DarkRadiant, which allows an entityDef to specifiy a ste of keyvalues which are set on the actual entity after creation. This was a response to this request http://bugs.angua.at/view.php?id=1306, to make func_emitters easier to use.

 

This is the section on the entityDef:

"editor_setKeyValue model"  "-" // the key value to be set when this entity is created

 

The entity will carry a "model" spawnarg right after it will have been created. It's possible to define multiple editor_setKeyValue spawnargs, just add an index to them like this "editor_setKeyValue1".

 

I am not sure in which circumstances this is used. Is this sort of a "default value" for spawnargs for entities that are created in uh the editor? In the game?

 

Also, how does this differ from spawnargs with default values?

 

And last but not least how does this tie in with my planned support for def files specifying spawnargs to be set on entities that are def_attached at runtime?

 

This will be active with the next DarkRadiant release.

 

This also makes me think, whether we should have a wiki article describing these editor_* spawnargs? Anybody up to that?

 

The wiki is good for adding images to descriptions and so on, but it absolutely sucks for creating spawnarg articles because the titles get uppercased, underscores get to spaces (so "foo_blah" ends up as "Foo blah") and you can't crosslink and list them unless you do it manually. Which is quite a lot of effort and would double the amount of work to do (document in the def file and wiki).

 

So my plan was to improve the documentation of spawnargs in the def file and improve the doc-generator script we already have and then only have wiki articles for selected groups of spawnars (like the one we have for clipmodels).

[Fidcal]

I don't really understand this. You mean if I create a func_emitter in DR it will have a default spawnarg 'model' already? I would ask why not just add the spawnarg 'model' to the func_emitter def? Ah! I see that's what Tels is also asking. So do you mean it adds the spawnarg and value to whatever is emitted?

[greebo]

I don't really understand this. You mean if I create a func_emitter in DR it will have a default spawnarg 'model' already? I would ask why not just add the spawnarg 'model' to the func_emitter def?

No, this is not the point here. If we want a default value, then we can of course set the "model" key on the entityDef and call it done of course.

 

The issue is more one of usability - the inherited "model" spawnarg would not be displayed in DarkRadiant's EntityInspector unless you specifically say so, and even then it's some kind of buried in the grey list of inherited spawnargs.

 

The method above allows for auto-adding a "model" spawnarg to the actual entity (not the def, the map entity), such that the process of selecting the particle is facilitated:

 

- RMB > Create Entity

- Choose func_emitter (this auto-adds the "model" spawnarg)

- Select the "model" spawnarg and hit "Choose Particle".

 

What is saved is that the user doesn't need to browse through the list of inherited values (or the one in the "Add Property" dialog) to select the "model" key. It's right there after creation.

 

Just try it out in the next release, you'll see it then.

[Fidcal]

I understand now. Mainly for cases where you'd (almost) always want to set the spawnarg value but it won't show by default so you'd have to add it. Maybe the door handle entity would always need bind for example.

[Tels]

Just try it out in the next release, you'll see it then.

 

Ah okay, this makes sense. Basically it solves a problem I wasn't aware we had

 

Edit: Good work!

[Fidcal]

I'm getting lots of Dark Radiant console errors like this...

 

[eclassmgr] AttributeSuffixComparator: cannot compare 'editor_setKeyValue density' with 'editor_setKeyValue bouncyness' at position 18: invalid integer.

 

Not sure why it's comparing density with bouncyness but maybe they have to be in the exact order of their counterparts? Or maybe each one individually must immediately follow its equivalent?

 

I'll document these editors vars eventually - on my todo.

[greebo]

I'm getting lots of Dark Radiant console errors like this...

 

[eclassmgr] AttributeSuffixComparator: cannot compare 'editor_setKeyValue density' with 'editor_setKeyValue bouncyness' at position 18: invalid integer.

This error is harmless. This is issued by the getAttributeList() method when trying to sort a list of spawnargs matching a given prefix. It tries to do this by converting the suffix to integers, but actually it shouldn't emit an error when this fails. If you report that on the tracker, it will be gone in the next release.

[OrbWeaver]

One potential way to improve usability further would be to pop up a subsidiary dialog when an entity with editor_setKeyValue spawnargs is created, with a list of the "recommended" spawnargs and a PropertyEditor panel where each one could be set. This would make it very clear to the user that they need to set certain values to make the entity behave correctly, as well as highlighting functionality that they might not have been aware of.

[greebo]

Yes, this sounds like a userfriendly approach. We would need to find a way to store this meta-information somewhere though, probably to additional editor_* spawnargs.

[OrbWeaver]

I'm not sure there is any additional required information, is there?

 

You have

 

"editor_setKeyValue model" "blah"

 

so DR can display "model" in its list of "Recommended keyvalues", look it up in its already-existing list of known keys, and choose the ModelPropertyEditor to edit the value.

[greebo]

I figured there would be a dialog with multiple keyvalues to fill in (as you suggested) - but I guess you're still right anyway, as the editor_setKeyValue spawnargs are there in the first place - DarkRadiant just needs to find all of them.

[Tels]

I figured there would be a dialog with multiple keyvalues to fill in (as you suggested) - but I guess you're still right anyway, as the editor_setKeyValue spawnargs are there in the first place - DarkRadiant just needs to find all of them.

 

A new dialog/GUI for setting "set ... " spawnargs would also be nice. DR could figure out which attachement points exist and what their names are and what the spawnclass of that entity is, so the user can simple choose the spawnarg/attachement point name. I can do mockups and pseudo-code and put it on the tracker if you wish.

[greebo]

You can report it, but currently I get sick when thinking about coding another GUI. GTK is so tiresome.