Jump to content
The Dark Mod Forums

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 )

Link to comment
Share on other sites

  • Replies 249
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

@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

Link to comment
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.

Link to comment
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.

Link to comment
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'.

Link to comment
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'.

Link to comment
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

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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.

Link to comment
Share on other sites

  • 2 weeks later...
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
Share on other sites

  • 4 months later...

 

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

Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...