Some entity properties not listed; which and why

[SneaksieDave 39]

@Tels: Looks like it's still got a couple of issues. Taking a look at worldspawn:

 

- Both tables still use the old mouseover for Inherited (not "Whether the spawnarg is documented on this entity", though, is that column necessary with the new Defined column?)

 

- The mouseover for Description in the second table is currently column shifted, showing the intended mouseover for Defined

 

- One other minor thing which might be by design but I thought I'd mention: if you bring up a spawnarg that is defined and only used on e.g. worldspawn (something like the shopitem ones), when you follow the link, it tries to show the list of ents where the spawnarg appears, but either since it is worldspawn, or maybe because it's only on this entity, it doesn't show up, and the table/list is empty. ( http://bloodgate.com/mirrors/tdm/pub/doc/i...shopitem_1_cost )

[Tels 268]

@Tels: Looks like it's still got a couple of issues. Taking a look at worldspawn:

 

- Both tables still use the old mouseover for Inherited (not "Whether the spawnarg is documented on this entity", though, is that column necessary with the new Defined column?)

 

As for "nec." yeah maybe not, but I thought it wouldn't hurt. But maybe it just takes up too much space?

 

As for the other things, I forgot to upload the new tdm.js file to bloodgat.com - oops sorry!

 

- One other minor thing which might be by design but I thought I'd mention: if you bring up a spawnarg that is defined and only used on e.g. worldspawn (something like the shopitem ones), when you follow the link, it tries to show the list of ents where the spawnarg appears, but either since it is worldspawn, or maybe because it's only on this entity, it doesn't show up, and the table/list is empty. ( http://bloodgate.com/mirrors/tdm/pub/doc/i...shopitem_1_cost )

 

That is by design, the spawnargs are "defined" on worldspawn, but not used. When you look at a single spawnarg, though, only the *used* spawnargs are shown.

 

Since "shopitem_1_cost is never set on any entity in our def files (don't confuse this with map files, which basically inherit all our def files and then add entities and spawnargs too), there is nothing to show or see.

 

(I know this is confusing, but id software designed it so...)

[Flanders 12]

I've added descriptions for inv_droppable, inv_name, inv_icon to entityDef atdm:moveable_base. I need to add 'target' for my custom moveable but I suspect this ought to be on all target entities. They seem to inherit from atdm:entity_base so I don't know if it should go on there or not.

Those spawnargs are already documented somewhere in the def files as you can see if you search for them on the bloodgate documentation. Possibly they are documented at the wrong places so they don't show up for all entities that use it. Or your custom moveable entity should inherit from another base class like item_base were the three spawnargs should probably be documented. We don't want double descriptions for the same spawnargs.

 

If I search bloodgate for atdm:entity_base it doesn't actually tell me which file it is in (the original.) That might be useful as a local internal file search gives me 36 files but which is the original.

It's in tdm_base.def.

[SneaksieDave 39]

That is by design, the spawnargs are "defined" on worldspawn, but not used. When you look at a single spawnarg, though, only the *used* spawnargs are shown.

Ahh ok that makes sense. I think.

 

One other thing: I admit you are confusing the heck outta me with this

Top table, column: Inherited

Description: "Whether the spawnarg is documented on this entity."

 

Bottom table, column: Inherited

Description: "Is the spawnarg documentation inherited?"

 

Why the different descriptions, can they be the same? Confusing.

 

Really like the Defined column, btw; very useful.

[Flanders 12]

One other thing: I admit you are confusing the heck outta me with this

Top table, column: Inherited

Description: "Whether the spawnarg is documented on this entity."

 

Bottom table, column: Inherited

Description: "Is the spawnarg documentation inherited?"

 

Why the different descriptions, can they be the same? Confusing.

Yeah, I think the top one should be something like 'Whether this spawnarg is inherited from a parent entity'.

[SneaksieDave 39]

Will that flip the result? Also though, unless they can't, let's have the columns agree at least.

[Flanders 12]

Will that flip the result? Also though, unless they can't, let's have the columns agree at least.

Yes, the description as it is now is not just vague, it's wrong too . If these explanations are used they are almost similar and correct I think.

 

top: 'Whether this spawnarg is inherited from a parent entity'.

bottom: 'Whether this spawnarg description is inherited from a parent entity'.

[Tels 268]

Yes, the description as it is now is not just vague, it's wrong too . If these explanations are used they are almost similar and correct I think.

 

top: 'Whether this spawnarg is inherited from a parent entity'.

bottom: 'Whether this spawnarg description is inherited from a parent entity'.

 

I can change them easily enough, but not today Please remind me

[SneaksieDave 39]

I guess this falls on the DarkRadiant side of the issue: Why do some properties' help/docs not show up (either under help icons, or during mouseover) in DR? For instance, light_radius or noshadows. Both of these are documented, both show up on the bloodgate docs; neither have help info in DR.

[greebo 29]

Which entity were you looking at, an ordinary light?

[Flanders 12]

Greebo, this seems to be only for the spawnargs in the basic, lights, model etc folders when you add a property, not in the top folder that is specific for the entity.

[greebo 29]

Greebo, this seems to be only for the spawnargs in the basic, lights, model etc folders when you add a property, not in the top folder that is specific for the entity.

Pardon me, I'm not sure I understand? Sneaksie is talking about the help icons, isn't he? How are the "basic" and "lights" folders related to that?

[SneaksieDave 39]

Both the help icons and/or the mouseover for tooltip functionality.

 

Yes, just create a normal light. Mouseover origin (or break, or health, etc), and it gives the popup help. But mouseover light_radius, and it doesn't give any information. However this property is documented. To add even more confusion, noshadows does give info for a light, but not for a func_static.

[Flanders 12]

Pardon me, I'm not sure I understand? Sneaksie is talking about the help icons, isn't he? How are the "basic" and "lights" folders related to that?

O was it only about the help icons, sorry. I noticed that not all spawnarg descriptions were showing up in those folders I mentioned. If you create a light and want to give it noshadows in the add property menu the descriptions shows up in the top folder that is specific for the entity but not in the "light" folder under "basic". Perhaps related to what SneaksieDave said.

[Tels 268]

O was it only about the help icons, sorry. I noticed that not all spawnarg descriptions were showing up in those folders I mentioned. If you create a light and want to give it noshadows in the add property menu the descriptions shows up in the top folder that is specific for the entity but not in the "light" folder under "basic". Perhaps related to what SneaksieDave said.

 

I think thats related to the way that the "basic" folders are somewhere hardcoded in an XML file. (It is a small list of "useful" spawnargs).

 

IMO this hard-coded way should be removed, it can only get out of sync with the other def files, and it seems it is also an alternative code-path (which doesn't show icons and so on in tooltips).

[SneaksieDave 39]

These past few posts have quickly become quite confusing (for me at least) so I will just ask: should I create a tracker entry, or is it not yet established what the source of the problem is?

[greebo 29]

These past few posts have quickly become quite confusing (for me at least) so I will just ask: should I create a tracker entry, or is it not yet established what the source of the problem is?

I haven't had time to look into this specific issue yet - I'm currently busy in other DarkRadiant areas, but you can go ahead and create a tracker entry. I will close that entry, if it turns out to be a non-DarkRadiant issue.

[SneaksieDave 39]

Okay done: http://bugs.angua.at/view.php?id=1662

[greebo 29]

Yes, just create a normal light. Mouseover origin (or break, or health, etc), and it gives the popup help. But mouseover light_radius, and it doesn't give any information. However this property is documented. To add even more confusion, noshadows does give info for a light, but not for a func_static.

In response to this report here: http://bugs.angua.at/view.php?id=1662

 

I could look into this today, and the issue is that the variable "light_radius" is not documented for the entityDef light.

 

In fact it is first documented for the entity atdm:light_base, but the hierarchy is like this:

 

atdm:entity_base
 light
 atdm:light_base

So, the light entityDef doesn't know about the editor_var light_radius, because it's neither defined on it nor inherited from any base class. It only occurs further down the hierarchy.

 

To fix this, the light_radius variable needs to be moved upwards in the hierarchy, or the light entityDef needs to inherit from atdm:light_base (which has to be double- and triple-checked, because it's a potentially dangerous change).

 

At any rate, I can say it's not a DarkRadiant issue, so I'll close the report.

[SneaksieDave 39]

Can DR be forced to show the descriptions regardless of which class might 'own' it (like a single table of descriptions)? The concern is that it might affect many things, e.g.:

mouseover light_radius, and it doesn't give any information... To add even more confusion, noshadows does give info for a light, but not for a func_static.

etc. There are more examples. I guess this was one of the main issues in nailing down the problem since the start.

[greebo 29]

No, this would not be correct, as the code behind the entity class defines the meaning of each spawnarg. It's possible that this is the exception of the rule, but there might be spawnargs which have different meanings on different entityclasses.

 

Of course, one can argue that things like "health" for instance has a similar meaning for all entity classes it might be defined on:

 

"editor_int health" "Determines how much damage this entity can take before it breaks or dies."

 

but imagine you want to give some additional information about health on AI classes:

 

"editor_int health" "Determines how much damage this entity can take before it breaks or dies. If an AI's health drops below a certain threshold, it might decide to flee."

 

and later one somebody decideds to introduce health for models:

 

"editor_int health" "Determines how much damage this entity can take before it breaks or dies. If an AI's health drops below a certain threshold, it might decide to flee. Model entities might swap their visual mesh when their health hits 0."

 

etc. etc. You see my point, i guess. You'd sacrifice some flexibility and clarity.

 

On top of that, you run the risk of delivering wrong information to mappers, if some other entity defines a description to a spawnarg of the same name but with a completely different meaning. Wrong information is even worse than no information.

 

No, DarkRadiant should definitely not show documentation of spawnargs defined on seemingly unrelated entityDefs.

 

If entityDefs are related to each other, this has to be reflected by proper inheritance, that's how the system is meant to be used.

[SneaksieDave 39]

Ah okay, I think I get it. I'm also using DR's entity tree to look down the inheritances. So it looks like we inserted atdm:entity_base between id's base and light. Why, I don't know and won't ask; it's most likely beyond my understanding. But I think I get your meaning. It would probably require a lot of risky changes for little benefit. Hopefully it doesn't affect too many things, but either way users will survive.

[Tels 268]

Ah okay, I think I get it. I'm also using DR's entity tree to look down the inheritances. So it looks like we inserted atdm:entity_base between id's base and light. Why, I don't know and won't ask; it's most likely beyond my understanding. But I think I get your meaning. It would probably require a lot of risky changes for little benefit. Hopefully it doesn't affect too many things, but either way users will survive.

 

I already had looked into changing the entity hirarchy for the lights, but this was a bit too complicated for a 5minute change. Please open a tracker entity and I will look into it this weekend

 

Also, please open a tracker entity for the JS GUI that says something along the lines of

 

"If multiple definitions for one spawnarg are documented, the GUI currently only shows one. It should show all of them in a list"

 

(Sorry, not enough time to do them myself today

[SneaksieDave 39]

Okay opened 2 4 U:

http://bugs.angua.at/view.php?id=1671

http://bugs.angua.at/view.php?id=1672

[Tels 268]

Okay opened 2 4 U:

http://bugs.angua.at/view.php?id=1671

http://bugs.angua.at/view.php?id=1672

 

Fixed #1671 by moving the editor_vars up to "light". Changing the hirarchy was a bit to dangerous for me