Jump to content
The Dark Mod Forums

Some entity properties not listed; which and why


Recommended Posts

I have added another small improvement to the GUI.

 

* the script devel/inspect.pl now searches the desciptions for texts like 'SpawnArgName' and converts them to a marker ("S(SpawnArgName)"), which is in turn used by the GUI to create HTML links out of them.

 

Here is a screenshot, shoing the description for "anim" linking automatically to "num_anims":

 

post-144-1232399781_thumb.png

 

So how do you add these links in the def files? Easy, whenever you mention a spawnarg, just enclose it in single quotes. I did choose that format because a lot of the references are already this way :)

 

Example: http://www.bloodgate.com/mirrors/tdm/pub/doc/#spawnarg-anim

 

This also works in the lists that show spawnargs as well as the search results, thus allowing easier cross-referencing.

 

Enjoy!

"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

Link to post
Share on other sites
  • Replies 249
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

@Tels, greebo: More questions upon trying to still get this going. I better type them out quick before I forget!

 

1. Playing around with atdm:lamp_desk. I added a test field to it, with a test value; it showed up in DR when I clicked show inherited properties. Okay (I guess?). I added a second test field/value to atdm:static_light_unlit_base. Similarly, it showed up for the lamp under inherited properties. Okay.

 

First question that comes to mind is, not that this is a problem, but why does it only show up there, but not as a property one can add from the Add Property dialog? Maybe this is just the way it should work and I'm thinking from the other direction. Anyway it's no big deal, the user can still see it. It's just confusing that, if they go to Add Properties, they don't see it as an option. Maybe there should be a 'show inherited' on that page as well.

 

So I went deeper. I tried the same with func_static. Took a look at atdm:entity_base and added a test field. This did not show up, in anything, though I expected it to show for everything (it is the base entity afterall). This could just be my misunderstanding. But if a property cannot be added and shown this way, how can it?

 

2. What does the "Inherited" column imply, for example here: http://bloodgate.com/mirrors/tdm/pub/doc/i...-atdm:lamp_desk

 

It says for frobable, Inherited = "No". But clearly it is. And in DR, showing inherited properties shows frobably for this object. Which is correct?

 

3. This one gets back to the main point, possibly already answered in part by #1 above. Again for the desk lamp: the frobable description states, "It will use the default distance unless frob_distance is set with a different value." Okay. But uh, frob_distance isn't shown. Not on the site, not in the editor. I looked in tdm_frobable.def, which appears to be the place where that property is described, ( "editor_int frob_distance" "Specifes the distance when the frob highlight should become active. This setting will override the default frob distance." ) So it IS documented, but does NOT show up. The main point. What must be done?

 

If anyone at all understands what I'm asking here, for the sake of my sanity, please give me an example that demonstrates this (the main issue: a property that is (or not, but can be fixed) documented, being displayed as a property that can be added via the editor UI) working. Maybe I'll try to use logs to figure out Flanders' recent changes and see if I can determine from those.

Link to post
Share on other sites
@Tels, greebo: More questions upon trying to still get this going. I better type them out quick before I forget!

 

2. What does the "Inherited" column imply, for example here: http://bloodgate.com/mirrors/tdm/pub/doc/i...-atdm:lamp_desk

 

It says for frobable, Inherited = "No". But clearly it is. And in DR, showing inherited properties shows frobably for this object. Which is correct?

 

Ah, this is a bug I stumbled over and then forgot and couldn't remember. The column should show wether "frobable" is set on that particular entity as a spawnarg, or if that entity just gets the inherited value.

 

The list appears to be correct (frobable is directly set on atdm:lamp_desk), but also incomplete. For instance

 

noclipmodel 0

 

is set func_static, so atdm:lamp_desk should inherit it. I have a look whats up with my code.

 

Edit: That opens up an interesting question. Let's assume entity A defines FOO, and B inherits from A and C inherits from B. Does C then also inherit the setting for "FOO" from A? I think so, but I am not sure actually. In any case it looks like my GUI only shows things inherited from B, and ignores anything further up.

 

As for the other quesions, I annot answer them as I haven't looked into DR actually. Maybe greebo can do this better?

"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

Link to post
Share on other sites
1. Playing around with atdm:lamp_desk. I added a test field to it, with a test value; it showed up in DR when I clicked show inherited properties. Okay (I guess?). I added a second test field/value to atdm:static_light_unlit_base. Similarly, it showed up for the lamp under inherited properties. Okay.

What do you mean by "added a test field"? I need to know that before I can relate to the rest of your post.

Link to post
Share on other sites
So I went deeper. I tried the same with func_static. Took a look at atdm:entity_base and added a test field. This did not show up, in anything, though I expected it to show for everything (it is the base entity afterall). This could just be my misunderstanding. But if a property cannot be added and shown this way, how can it?
Strange, this should work. :mellow: Did you restart your DarkRadiant after adding the test field?

 

2. What does the "Inherited" column imply, for example here: http://bloodgate.com/mirrors/tdm/pub/doc/i...-atdm:lamp_desk

 

It says for frobable, Inherited = "No". But clearly it is. And in DR, showing inherited properties shows frobably for this object. Which is correct?

The problem is possibly the definition of "inherited" here. For DarkRadiant, every key that is set in the def and not in the editor (regardless if it is set in the def of the entity itself or somewhere up the inheritance chain) is inherited.

The key "frobable" is set on the def of the lamp itself, so if you would see it from the entity's def's point of view, it is not inherited from somewhere up the inheritance chain. This is probably what Tels' list shows.

 

3. This one gets back to the main point, possibly already answered in part by #1 above. Again for the desk lamp: the frobable description states, "It will use the default distance unless frob_distance is set with a different value." Okay. But uh, frob_distance isn't shown. Not on the site, not in the editor. I looked in tdm_frobable.def, which appears to be the place where that property is described, ( "editor_int frob_distance" "Specifes the distance when the frob highlight should become active. This setting will override the default frob distance." ) So it IS documented, but does NOT show up. The main point. What must be done?
The problem here is that the lamp does not inherit from frobable_base. It inherits from static_light_unlit_base, which inherits from func_static, which inherits from entity_base. So all the properties listed in frobable_base are not available. Maybe we should shove it in between entity_base and func_static (or set the properties directly on the base class, most entities can be frobable anyway.)
Link to post
Share on other sites
Ah, this is a bug I stumbled over and then forgot and couldn't remember. The column should show wether "frobable" is set on that particular entity as a spawnarg, or if that entity just gets the inherited value.

 

That is fixed now, the code didn't even take into account ineritance. Now it travels along the inheritance chain and adds every spawnarg it hasn't seen set. (Hence the slightly unsorted order).

 

Or in other words, that page shows ALL spawnargs in EFFECT at the currently shown entity, and details wether that spawnarg is set directly on that entity or inherited from another one. (it doesn't show yet from where)

"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

Link to post
Share on other sites
Ah, this is a bug I stumbled over and then forgot and couldn't remember. The column should show wether "frobable" is set on that particular entity as a spawnarg, or if that entity just gets the inherited value.

Oh, so "no" doesn't mean not inherited, but that the value is no? Yeah that's confusing.

 

What do you mean by "added a test field"?

In the definition file, I added:

"testfield1" "testvalue1"

 

for the sake of a new nonsense property that is 'documented', to see if it then appears for the children.

 

Did you restart your DarkRadiant after adding the test field?

Yep, I restart DR after each change.

 

Not to sound like a broken record, but I still have a very unsure feeling that everyone here knows something I don't; that I don't "get it," that maybe what I'm requesting isn't at all possible (or very near to impossible), or that I'm not comprehending the way this type of thing works. So we (I) might just be stumbling on a big misunderstanding as opposed to limited functionality.

 

I'll try to keep searching for a good example to either prove or disprove concept. @Flanders, thanks I'm checking out your thread now.

Link to post
Share on other sites

Wait, I'm not sure my frobable_base example above isn't appropriate afterall. If I look in the def itself:

 

---

entityDef atdm:frobable_base

...

"editor_int frob_distance" "Specifes the distance when the frob highlight should become active. This setting will override the default frob distance."

---

 

And then compare it to the doc site:

 

http://bloodgate.com/mirrors/tdm/pub/doc/i...m:frobable_base

 

They don't match up. frobable_base has frob_distance defined right in it (as opposed to inherited) and yet it isn't displayed on the page. In fact, several fields are missing, and I can't put rhyme or reason to it. Of course, we're not looking for a manual fix here but the reason why; if my first stab at it finds this many things missing, something's wrong (or misunderstood).

 

(For the moment this is just about the doc site, not DR; trying to tackle this one thing at a time)

Link to post
Share on other sites

The light has finally shined. :) (This is for the DR side of things, separate from web docs above)

 

I modified my local tdm_base and tdm_conversation def files. To entity_base, I added a "grandparent_property" field, with some description. To conversation_info, I added a "parent_property" field, with some description. Finally, I created a conversation_info2, inherited from conversation_info, and added a "child_property" field, with some description. Happily, when I created a conversation_info2 in DarkRadiant, all three fields showed up in the Add Properties dialog. Whew. :D So barring further yet-not-understoods, I guess this is finally proof of concept.

 

A question, and an issue:

 

1. Probably just a matter of my lack of understanding but: why do the inherited properties show up in the Add Property dialog, but do not show up when I select Show Inherited Properties checkbox? In fact, for a conversation_info, after selecting to Show Inherited Properties, I only see 6 fields in total, and yet inheriting from entity_base provides quite a few. Are they handled differently, things like editor_mins, etc? Or maybe I'm way off and not thinking about this correctly.

 

2. Possible bug in DR: If I remove the description from the "grandparent_property" field, all fields inherited from entity_base disappear from the DarkRadiant "blue folder", the folder specifically for that entity. Easily reproducable. Add the property description, and all entity_base fields return.

Link to post
Share on other sites
Wait, I'm not sure my frobable_base example above isn't appropriate afterall. If I look in the def itself:

 

---

entityDef atdm:frobable_base

...

"editor_int frob_distance" "Specifes the distance when the frob highlight should become active. This setting will override the default frob distance."

---

 

And then compare it to the doc site:

 

http://bloodgate.com/mirrors/tdm/pub/doc/i...m:frobable_base

 

They don't match up. frobable_base has frob_distance defined right in it (as opposed to inherited)

 

NO it hasn't!

 

You are confusing things again :)

 

There are three things an entity can have:

 

* a spawnarg directly _set_ e.g. "frob_distance" "12"

* a spawnarg inherited e.g. "inherit" "blah" where blah has "frob_distance" "12" _set_ directly

* a documentation for a spawnarg

 

The web doc shows only the first two cases when you look at an entity. :) (Formerly it only had the first variant, I fixed that yesterday)

 

I guess I should add a "spawnargs documented here", too.

 

Sorry for the confusion :)

"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

Link to post
Share on other sites
The light has finally shined. :) (This is for the DR side of things, separate from web docs above)

 

I modified my local tdm_base and tdm_conversation def files. To entity_base, I added a "grandparent_property" field, with some description. To conversation_info, I added a "parent_property" field, with some description. Finally, I created a conversation_info2, inherited from conversation_info, and added a "child_property" field, with some description. Happily, when I created a conversation_info2 in DarkRadiant, all three fields showed up in the Add Properties dialog. Whew. :D So barring further yet-not-understoods, I guess this is finally proof of concept.

 

A question, and an issue:

 

1. Probably just a matter of my lack of understanding but: why do the inherited properties show up in the Add Property dialog, but do not show up when I select Show Inherited Properties checkbox? In fact, for a conversation_info, after selecting to Show Inherited Properties, I only see 6 fields in total, and yet inheriting from entity_base provides quite a few. Are they handled differently, things like editor_mins, etc? Or maybe I'm way off and not thinking about this correctly.

So, just to be sure I understand what you mean, you did the following?

 

in entity_base

"editor_var grandparent_property" "Some description"

in conversation_info

"editor_var parent_property" "Some other description here"

and in conversation_info2

"editor_var child_property" "And even more description"

 

As you said, this gives you the descriptions in the blue "add property" dialog.

 

To see it in the inherited properties, you have to set an actual value to the property in the def (doesn't matter if it is in entity_base, or conversation_info or conversation_info2), like

"grandparent_property" "1"

 

2. Possible bug in DR: If I remove the description from the "grandparent_property" field, all fields inherited from entity_base disappear from the DarkRadiant "blue folder", the folder specifically for that entity. Easily reproducable. Add the property description, and all entity_base fields return.
This is strange and probably a bug. So all you did was removing the line

"editor_var grandparent_property" "Some description" ?

Maybe you left a typo in there?

Link to post
Share on other sites
Tels, there are these strange editor_copy's showing up in the documentation.

http://bloodgate.com/mirrors/tdm/pub/doc/i...tdm:loot_amulet

I think it happens for spawnargs that have a value set for it on itself and one of it's parents. Do these editor_copy's have a purpose or can they be removed?

 

As far as I know, these spawnargs tell the editor that when it copies the entity, it should also copy all the entities (or the spawnargs) pointed to by these spawnargs. But I am not sure if that isn't the case anyway, when you copy an entity?

 

Interestingly enough, the source for DR does not contain the string "editor_copy" at all. Greebo, do you know what these are for?

"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

Link to post
Share on other sites

@Tels: What is this, if not documentation right there (in tdm_frobable.def)

 

entityDef atdm:frobable_base

{

...

"editor_int frob_distance" "Specifes the distance when the frob highlight should become active. This setting will override the default frob distance."

...

}

 

Am I misunderstanding? It's not a value, and it's not an inheritance, so it must be the third choice, the documentation. That is not shown on the site (I think?), and would be a huge help in a wysiwyg sense.

 

@angua:

So, just to be sure I understand what you mean, you did the following?

Yep, and thanks for the clarification on showing inherited props; I will check it out. :)

 

This is strange and probably a bug. So all you did was removing the line

"editor_var grandparent_property" "Some description" ?

Maybe you left a typo in there?

What I did was change:

"editor_var grandparent_property" "Some description"

to:

"editor_var grandparent_property"

 

So I removed the description part. This seemed to break the blue folder for that inheritance. I will track it, if you are able to confirm?

Link to post
Share on other sites
What I did was change:

"editor_var grandparent_property" "Some description"

to:

"editor_var grandparent_property"

 

So I removed the description part. This seemed to break the blue folder for that inheritance. I will track it, if you are able to confirm?

By removing the entire right-hand string you produced an invalid entityDef. A spawnarg always consists of two strings:

 

"key" "value"

 

If you want to have an empty description, you need to set it up like this:

 

"key" ""

 

or remove the entire line.

Link to post
Share on other sites
Tels, can you make the script understand editor_sound and editor_vector descriptions?

 

It already understands "editor_snd".

 

Edit: Does "editor_sound" also work? "editor_sound" is used nowhere in our def files. I added editor_vector, but could not commit, since sparhawks server seems to be unreachable.

 

For future reference, line 99 in devel/inspect.pl contains the regexp that matches these special editor variables:

 

my $qr_editor = qr/^x-editor_(var|bool|int|float|model|string|gui|
color|material|snd|vector)_/;

 

Adding something should be easy :)

"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

Link to post
Share on other sites
  • 2 weeks later...

Update to the JS GUI:

 

Apart from a few minor tweaks and fixes, the big news is that now each display for one entity shows all the defined (but not actually set) spawnargs, too:

 

Example: (scroll down)

 

http://www.bloodgate.com/mirrors/tdm/pub/d...:absence_marker

 

Enjoy :)

"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

Link to post
Share on other sites
That's good. But do all those documented spawnargs have a meaning for this entity?

 

How should I know? :)

 

Do all those spawnargs inherited from entity_base 'work' on atdm:absence_marker?

 

How should I know? Or for that matter, how should the GUI know? :)

 

The GUI just shows what is defined in the def files. If that is wrong, some human needs to fix it. The computer can't do that automatically for you. Sorry, but the GUI is the best I can do with automatism :)

 

The technical explanation is that the spawnarg documentation and the real-existing-and-used-by C++ or script code spawnargs are two completely unrelated lists. You can document non-existing spawnargs, and the code can use un-documented (or even un-used in the def files!) spawnargs.

 

I don't like that, but that's just the way id software designed it.

"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

Link to post
Share on other sites

Thing is I don't know either. Before this addition it actually didn't matter if you would put a description in entity_base if it only applied to a certain group of entities and not to all entities. The description would only show up in the documentation if an entity has that spawnarg.

 

Does it matter if a spawnarg description shows up for an entity if it doesn't 'work' for that entity? I guess it does, but I don't know exactly which spawnargs apply to which entities. Before I could just look at the documentation and add descriptions for the undocumented spawnargs that I saw on an entity in the documentation. Now it looks like only coders how have a understanding of which spawnargs 'work' for which entities can add the descriptions in the right places.

Link to post
Share on other sites
Thing is I don't know either. Before this addition it actually didn't matter if you would put a description in entity_base if it only applied to a certain group of entities and not to all entities. The description would only show up in the documentation if an entity has that spawnarg.

 

Edit: Putting descriptions for spawnargs into entity_base should only be done for spawnargs that are REALLY working of every entity. If it f.i. only works for moveables, the description needs to go into atdm:moveable_base. End of Edit.

 

That still works as before, you can just ignore the "second" table on one entity and pretend you don't see it :)

 

As for "knowing", no-one really knows, not even coders, because:

 

A: you would need to actually look up a spawnarg in the C+ code or script code to see if it is supported for the entity in question. (I do not now how we could ever automate that, really. It might work for script code, but see point B:)

B: The mapper can always change two important things for an entity after placing it in a map:

 

* The spawnclass. Changing that for instance from "idMoveable" to "idLight" completely changes the valid spawnargs (invalid spawnargs are simply ignored)

* The scriptobject. Changing that will change the underlying code used from script/ and will also change what spawnargs are used. F.i. changing the light script object to one for moveables (just an example I don't know if we have one) will make f.i. "model_lit" etc. no longer working.

 

Does it matter if a spawnarg description shows up for an entity if it doesn't 'work' for that entity? I guess it does, but I don't know exactly which spawnargs apply to which entities. Before I could just look at the documentation and add descriptions for the undocumented spawnargs that I saw on an entity in the documentation. Now it looks like only coders how have a understanding of which spawnargs 'work' for which entities can add the descriptions in the right places.

 

See above.

 

As for "what works and what not", it is unfortunately "our" work to identify this and set the documentations accordingly. Since id left if in a really half-complete and messy state, and TDM added tons of (partly undocumented) spawnargs, we now have a big mess, and I don't see any way out of it except cleaning it up bit by bit.

 

Note that before the online GUI, we had the same mess, just that nobody knew which spawnarg applied where or when and people did go by with a very small subset of spawnargs. Of course, a lot of them are much more important and common than some others, but still, eventually a mapper wants to look up and use everything.

 

I am sorry that I cannot be of more help.

"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

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.


×
×
  • Create New...