SneaksieDave 40 Posted February 16, 2009 Author Report Share Posted February 16, 2009 @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 ) Quote Link to post Share on other sites
Tels 279 Posted February 16, 2009 Report Share Posted February 16, 2009 @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...) Quote "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
Flanders 12 Posted February 16, 2009 Report Share Posted February 16, 2009 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. Quote Link to post Share on other sites
SneaksieDave 40 Posted February 17, 2009 Author Report Share Posted February 17, 2009 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: InheritedDescription: "Whether the spawnarg is documented on this entity." Bottom table, column: InheritedDescription: "Is the spawnarg documentation inherited?" Why the different descriptions, can they be the same? Confusing. Really like the Defined column, btw; very useful. Quote Link to post Share on other sites
Flanders 12 Posted February 17, 2009 Report Share Posted February 17, 2009 One other thing: I admit you are confusing the heck outta me with this Top table, column: InheritedDescription: "Whether the spawnarg is documented on this entity." Bottom table, column: InheritedDescription: "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'. Quote Link to post Share on other sites
SneaksieDave 40 Posted February 17, 2009 Author Report Share Posted February 17, 2009 Will that flip the result? Also though, unless they can't, let's have the columns agree at least. Quote Link to post Share on other sites
Flanders 12 Posted February 17, 2009 Report Share Posted February 17, 2009 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'. Quote Link to post Share on other sites
Tels 279 Posted February 17, 2009 Report Share Posted February 17, 2009 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 Quote "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
SneaksieDave 40 Posted February 20, 2009 Author Report Share Posted February 20, 2009 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. Quote Link to post Share on other sites
greebo 103 Posted February 20, 2009 Report Share Posted February 20, 2009 Which entity were you looking at, an ordinary light? Quote Link to post Share on other sites
Flanders 12 Posted February 20, 2009 Report Share Posted February 20, 2009 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. Quote Link to post Share on other sites
greebo 103 Posted February 20, 2009 Report Share Posted February 20, 2009 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? Quote Link to post Share on other sites
SneaksieDave 40 Posted February 20, 2009 Author Report Share Posted February 20, 2009 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. Quote Link to post Share on other sites
Flanders 12 Posted February 21, 2009 Report Share Posted February 21, 2009 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. Quote Link to post Share on other sites
Tels 279 Posted February 22, 2009 Report Share Posted February 22, 2009 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). Quote "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
SneaksieDave 40 Posted February 22, 2009 Author Report Share Posted February 22, 2009 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? Quote Link to post Share on other sites
greebo 103 Posted February 22, 2009 Report Share Posted February 22, 2009 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. Quote Link to post Share on other sites
SneaksieDave 40 Posted February 22, 2009 Author Report Share Posted February 22, 2009 Okay done: http://bugs.angua.at/view.php?id=1662 Quote Link to post Share on other sites
greebo 103 Posted March 3, 2009 Report Share Posted March 3, 2009 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_baseSo, 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. Quote Link to post Share on other sites
SneaksieDave 40 Posted March 3, 2009 Author Report Share Posted March 3, 2009 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. Quote Link to post Share on other sites
greebo 103 Posted March 3, 2009 Report Share Posted March 3, 2009 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. Quote Link to post Share on other sites
SneaksieDave 40 Posted March 3, 2009 Author Report Share Posted March 3, 2009 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. Quote Link to post Share on other sites
Tels 279 Posted March 3, 2009 Report Share Posted March 3, 2009 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 Quote "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
SneaksieDave 40 Posted March 3, 2009 Author Report Share Posted March 3, 2009 Okay opened 2 4 U: http://bugs.angua.at/view.php?id=1671http://bugs.angua.at/view.php?id=1672 Quote Link to post Share on other sites
Tels 279 Posted July 25, 2009 Report Share Posted July 25, 2009 Okay opened 2 4 U: http://bugs.angua.at/view.php?id=1671http://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 Quote "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
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.