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

Some entity properties not listed; which and why

Recommended Posts

Variations of this issue have come up a number of times (at least twice by me) so I apologize in advance to all reading for bringing this up again. As you know, the forum search function leaves some things to be desired; hopefully this thread is named in a manner that makes finding it in the future easier.

 

What this is not about: the known issue of why some properties have no descriptions in DarkRadiant.

Solution: they need descriptions added in editor_var fields in def files.

 

What this is about: an issue that came up for DarkRadiant a couple of times, and was fixed for troublesome cases. But it seems like we're not over the wall yet. Perhaps it is not a DR issue at all though, and instead is another case of lacking documentation.

 

The problem: the Add Property dialog does not present to users all valid properties for a given entity.

 

Example: atdm:mover_door

lock_pins

lock_picktype

frob_peer

 

None of these are listed as selectable properties in the Add Property dialog nor even listed as inherited, and these are only three properties (there are definitely more) grabbed at random on a single entity type of many, noticed because I was putting a chest prefab to use. As such, this is probably the rule instead of the exception. How many other properties exist on other entities which are not displayed to the user? In the example of frob_peer, it is a very general property which should be listed for anything frobable, but it is not. Basically, how can we expect mappers to know about these properties, and thus the abilities designed into TDM, if they don't even know they exist? These can't all be memorized or gleaned from a wiki page every time they're needed.

 

If this is in fact a DR issue of displaying properties (inherited or not), is a fix possible? If it is not about DR, where is this documentation located? Searches of all text files in TDM's folders have not revealed a definitive answer (some are kept in defs, others are not), so I'm guessing that it is compiled into the DLL in many cases.

 

Most importantly though: even if we don't have wonderfully written descriptions for every property, we at least have to give users a complete list of which properties exist for them to use, and I would think that should be programmatically possible. We should be careful not to make the same mistakes id made, prompting us to complain that they didn't give us enough information on how to use their engine.

Share this post


Link to post
Share on other sites
Is this related to this issue? http://bugs.angua.at/view.php?id=443

 

Unsure. However, there is also this bug, which gets marked as resolved (but I am still unsure and think it isn't really resolved):

 

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

 

Basically, except the very first entry in the "Add property" dialog list, the entries are hardcoded in the doom3.xml file. Which is bad, because it misses a lot and also is not synced to whatever changes are in the def files.

 

But ignoring this for a moment, the reason that "frob_peer" is not listed for a atdm:mover_door is simple that the base class, "atdm:frobable_base", does not define:

 

"editor_var frob_peer" "fooo"

 

If one adds this, the property shows in the proper dialog. :)

 

I can easily add to devel/inspect.pl a switch that lists all defined spawnargs for a given base that do not have a corrosponding "editor_FOO" set. This way we can then whittle down this list by adding the proper descriptions, and thus also make them available in the "Add property" dialog.

 

So, basically all we need to do is add the proper "editor_foo" descriptions.

 

Btw, greebo, is there an equivalent of "editor_entitity" ? It seems all entity arguments are described simple as "var" or "string", meaning DR does not know that the argument has to be a valid entity name.


"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

Progress:

 

Added "frob_peer" to atdm:frobable_base, and fixed the "editor_displayFolder" in atdm:mover_door.


"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
Progress:

 

Added "frob_peer" to atdm:frobable_base, and fixed the "editor_displayFolder" in atdm:mover_door.

 

Btw, the relevant bug report would be this:

 

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

 

Here is another gem:

 

def/tdm_mover_base.def: "editor_string pickable"				"Format: N N N. See the description for the lock state."
def/tdm_mover_base.def: "pickable"							  "1"
def/tdm_mover_button.def:	   "pickable"									  "0"
def/tdm_mover_doors.def:		"pickable"									  "1"
def/tdm_mover_doors.def:		"editor_bool pickable"						  "If set to 1, is pickable by the player"

 

Description fixed in SVN now.


"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
Btw, greebo, is there an equivalent of "editor_entitity" ? It seems all entity arguments are described simple as "var" or "string", meaning DR does not know that the argument has to be a valid entity name.

No, I don't think there is an "entity" equivalent. Don't know how useful this would actually be, but it can definitely be added.

Share this post


Link to post
Share on other sites
No, I don't think there is an "entity" equivalent. Don't know how useful this would actually be, but it can definitely be added.

 

I found this:

 

	"editor_argType1"	   "e" // Entity
"editor_argDesc1"	   "The target entity that should be removed"
"editor_argTitle1"	  "Target"

"editor_argString"	  "Remove entity <b>[arg1]</b> from the game."

 

But I am not sure how that works or what it does.

 

@greebo: When you use "Add property" in DR, and select for instance "Links", you see that it lists "bind" and "target" with a little "green arrow" symbol, denoting that the value is an entity. AFAIKS this is not possible from the def files yet.


"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 found this:

 

	"editor_argType1"	   "e" // Entity
"editor_argDesc1"	   "The target entity that should be removed"
"editor_argTitle1"	  "Target"

"editor_argString"	  "Remove entity <b>[arg1]</b> from the game."

 

But I am not sure how that works or what it does.

These are coming from the response effects definitions and are completely unrelated to the EntityInspector. It's only used by the Stim/Response Editor.

 

@greebo: When you use "Add property" in DR, and select for instance "Links", you see that it lists "bind" and "target" with a little "green arrow" symbol, denoting that the value is an entity. AFAIKS this is not possible from the def files yet.

That's defined in doom3.game:

<property name="bind" category="Links" type="entity" />

Share this post


Link to post
Share on other sites
That's defined in doom3.game:

<property name="bind" category="Links" type="entity" />

 

Yep, but doom3.game is from DR, not from the DEF files, where "editor_entity" doesn't work (yet :)


"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
Yep, but doom3.game is from DR, not from the DEF files, where "editor_entity" doesn't work (yet :)

Erm, yes?

 

DarkRadiant's EntityInspector still can interpret the doom3.game stuff and knows that the given key is an entity (it will display the right dropdown box).

 

I know that it's completely unrelated to the DEF files - what did you want to know?

Share this post


Link to post
Share on other sites
Erm, yes?

 

DarkRadiant's EntityInspector still can interpret the doom3.game stuff and knows that the given key is an entity (it will display the right dropdown box).

 

yes. I know that :)

 

I know that it's completely unrelated to the DEF files - what did you want to know?

 

Why:

 

* this is only possible in doom3.game and not in DEF (I know the answer, so this is a rhetorical question :ü

* why these values are hardcoded in doom3.game, anyway. They shouldn't, as these things might not even make sense in combination of whatever DEF files the editor currently uses. Plus, they get out of sync (e.g. you have to maintain DEF files and the doom3.game file)

 

:)


"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 can only guess, but I think this has its root in the way the EntityInspector was initially setup.

 

@OrbWeaver: What was the initial intention when you set it up this way? I assume it has to do with the icon display in the property dialogs?

Share this post


Link to post
Share on other sites
Is this related to this issue? http://bugs.angua.at/view.php?id=443

Yes, that sounds like it touches the same problem. It was hard to approach/describe this separate from the other symptoms we saw a long time ago, which led to the introduction of the blue folder and other fixes, and were addressed. This however has seemed to linger and reveal itself from time to time so I wanted to pin it down once and for all.

So, basically all we need to do is add the proper "editor_foo" descriptions.

Does this mean it's a human task, as opposed to programmatic? Because if so, not only is that a lot of work, but it will ultimately lead to omissions yet again. I know I'm stating the obvious, but I want to explicitly say it anyway: It's not just a handful of objects to be found by human inspection -- they're everywhere. I imagine it is quite possible that every entity is not displaying all of its relevant (or possible) properties.

Share this post


Link to post
Share on other sites
Does this mean it's a human task, as opposed to programmatic? Because if so, not only is that a lot of work, but it will ultimately lead to omissions yet again. I know I'm stating the obvious, but I want to explicitly say it anyway: It's not just a handful of objects to be found by human inspection -- they're everywhere. I imagine it is quite possible that every entity is not displaying all of its relevant (or possible) properties.

 

Well, it has to be a "human" task, because no computer can yet figure what text to add to the option "foo_bar_baz" :)

 

However, my idea was to give the script "devel/inspect.pl" (which already exists) the ability to figure out which spawnargs are set on an entity (it already does this part), but which do not have a corrosponding "editor_var" description. (this part is not implemented yet).

 

Once the script can do this, you could run it and get a report on which descriptions are missing.

 

Then we can work down this list and add them one by one.


"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
Ugh. :( I'd hoped it was a simple matter of looking up all inherited (or whatever problem is causing them to be omitted) properties programmatically. Doh.

 

Well, what do you mean by "programmatically"? My script doesn't use magic ;)

 

Edit: In any event, even if you look them up, there is still the basic issue that some human needs to go and add the help texts. I don't see any way around this unless you start talking about magic fairies writing them :D


"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

That a program would be able to list relevant properties per entity all inclusive, none missed by human error. The concern is that there may be thousands of instances. If frob_peer doesn't show up for frobables, and lock_picktype doesn't show up for doors, what else might there be, for every entity? We need a foolproof method that gets them all, without doubt (like a program). That's what I mean by it the task being done programmatically. But now I suspect we're going back and forth about a non-issue.

 

Ultimately, I'm more concerned that we at least see all variables that are relevant per entity, and less so about the actual descriptions.

Share this post


Link to post
Share on other sites
@OrbWeaver: What was the initial intention when you set it up this way? I assume it has to do with the icon display in the property dialogs?

 

Yeah, when I wrote this I was unaware of the whole editor_var thing, so I added this as a means to specify property types in lieu of just presenting a list of text strings to be edited manually.

 

If they are causing problems then they can be removed, although personally I think that having a known set of common properties that doesn't depend on correct setup of DEF files as an additional option is an advantage, not a disadvantage.

Share this post


Link to post
Share on other sites
That a program would be able to list relevant properties per entity all inclusive, none missed by human error. The concern is that there may be thousands of instances. If frob_peer doesn't show up for frobables, and lock_picktype doesn't show up for doors, what else might there be, for every entity? We need a foolproof method that gets them all, without doubt (like a program). That's what I mean by it the task being done programmatically. But now I suspect we're going back and forth about a non-issue.

 

Ultimately, I'm more concerned that we at least see all variables that are relevant per entity, and less so about the actual descriptions.

 

The point is that even if you see the properties that you *could* add, they still miss the description.

 

While I agree that it would be useful to at least know the spawnarg is there, this still doesn't fully solve the issue so we have to go all the way to fix the descriptions.


"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 certainly value the descriptions; however if they cannot be done (e.g., if there are thousands of them) it shouldn't derail the effort to get properties listed (even with placeholder descriptions of "-"), at least. I guess that goes without saying though.

Share this post


Link to post
Share on other sites
I certainly value the descriptions; however if they cannot be done (e.g., if there are thousands of them) it shouldn't derail the effort to get properties listed (even with placeholder descriptions of "-"), at least. I guess that goes without saying though.

 

It can't be "thousands" because we only have barely over 1000 unique spawnargs :)

 

Here is a preliminary report:

 

Spawnarg report:
 Unique spawnargs seen: 1072 (editor: 29, non-editor: 1043)

 

The list of "editor_" spawnargs, with the number they appear with another suffix (which, in turn means, so many variables are documented):

 

$VAR2 = {

'editor_caption' => 1,

'editor_copy' => 2,

'editor_gui' => 3,

'editor_int' => 1,

'editor_maxs' => 1,

'editor_model' => 6,

'editor_float' => 14,

'editor_var' => 298,

'editor_light' => 1,

'editor_argtype' => 1,

'editor_mover' => 1,

'editor_argdesc' => 1,

'editor_usage' => 3,

'editor_mat' => 2,

'editor_snd' => 12,

'editor_argstring' => 1,

'editor_material' => 3,

'editor_displayfolder' => 1,

'editor_mins' => 1,

'editor_entity' => 1,

'editor_color' => 3,

'editor_bool' => 59,

'editor_argoptional' => 1,

'editor_argtitle' => 1,

'editor_ragdoll' => 1,

'editor_showangle' => 1,

'editor_rotatable' => 1,

'editor_combatnode' => 1,

'editor_string' => 1

};

 

My gut feeling thus says there are 600 spawnargs without descriptions, but my code might be slightly wrong, as this sounds way too many.

 

Edit: Clarify and made some things bold.


"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

Due to technical limitations the graph attributes could not contain digits,so I replaced them with "_" (underscore). This had the side-effect for turning "dialog1" and "dialog2" both into "dialog_", and thus the report of the spawnargs was slightly off (albeit more realistic, because you don't need different descriptions for "dialog1" and "dialog2").

 

Anywhere, the report now reads:

 

Spawnarg report:
 Unique spawnargs seen: 1371 (editor: 55, non-editor: 1316)

 

My code does not yet produce a list of args without description, that's on my TODO now :)


"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
It can't be "thousands" because we only have barely over 1000 unique spawnargs.
(e.g., if there are thousands of them)

;)

 

Does the estimated count include all the ones from id/Doom?

Share this post


Link to post
Share on other sites
;)

 

Does the estimated count include all the ones from id/Doom?

 

(Ignore my lack of subtleties in English please :)

 

The count was produced by running over all the files in def like so:

 

perl devel/inspect.pl --report=spawnargs def/

 

That means it only contains TDM definitions as the ones that are "hidden" inside the D3 base.pak are not taken into account.

 

However, there is one file, called def/d3_junk.def which contains a few hundred D3 moveables, so there might be a few spawnargs from D3 that are not used in TDM.

 

Otherwise, it contains everything in actual use by TDM. Please note that the count is somewhat inflated, as it counts now "foo" and "foo1" as separate spawnargs. (The first count disregarded these).

 

If you run the report like I wrote above, it currently also prints out all spawnargs it find, the list is... quite impressive.


"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
Ignore my lack of subtleties in English please

Ah, I often even forget, because all of you guys speak such perfect English. I've always wondered what it's like to be fully bilingual (and I seem to always get involved with bilingual women for some reason... hm, maybe I should move to Europe), but I don't think I'll ever know.

 

Well crap. I assume we would need the id ones, too... but if they're already packed up, can their definitions be affected without repacking everything? Perhaps a sort of addendum def to the existing packed files? That was actually 50% of my concern, and probably 75% of what I run into in general mapping use -- undocumented id properties. :(

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