Jump to content
The Dark Mod Forums
Sign in to follow this  
SneaksieDave

Some entity properties not listed; which and why

Recommended Posts

@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 )

Share this post


Link to post
Share on other sites
@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! :blush:

 

- 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...)


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :laugh:

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.

Share this post


Link to post
Share on other sites
One other thing: I admit you are confusing the heck outta me with this :laugh:

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'.

Share this post


Link to post
Share on other sites
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'.

Share this post


Link to post
Share on other sites
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 :)


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Which entity were you looking at, an ordinary light?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :laugh: 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.

Share this post


Link to post
Share on other sites
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. :laugh: 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 :)


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

 

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


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...