kdau on 11/7/2013 at 03:26
Quote Posted by Sliptip
Question about KDToolSight
I'm using a default tool sight on the CustomHUD object. I decided to change the tool sight for one of my projectiles, however the projectile has other projectiles that inherit from it. I notice they don't inherit the tool sight image from the parent, but rather from the CustomHUD. Would it be possible to change that? It's a really minor (and easily circumventable) thing but it felt kind of "off" from the way most things inherit in Dromed.
Ah yes, Design Note parameters are an inheritance nightmare. I really wish we had a better system. The CustomHUD object is only consulted if a parameter is missing from the Design Note inherited by an object. However, Design Note inheritance is all or nothing. If an archetype or concrete object has any Design Note at all, it won't inherit any Design Note parameters from its parent archetype(s). The only solution is to copy the ancestors' parameters onto the descendants. For example, you might have a tree like this:
Code:
MyGenericType (-6003) Design Note: foo=2
|- MyIntermediateType (-6011) Design Note: foo=2; bar=-7 ("inherit" MyGenericType's foo parameter and add bar)
| |- MySpecificType (-6027) Design Note: foo=4; bar=-7; baz=6.5 (override foo, add baz, but "inherit" bar)
| \- MyConcreteObject (322) (no Design Note; inherited from MyIntermediateType)
\- MyOtherType (-6015) (no Design Note; inherited from MyGenericType)
\- MyOtherConcrete (485) Design Note: foo=2; baz=11.0 (if any parameters need to be set on a concrete object, still have to include all ancestors' parameters)
OTOH, if you don't have any Design Note on the child archetype and the parent archetype's parameters are being ignored anyway, that would be a bug.
Quote Posted by Sliptip
Do you think it would be possible in the future to offset the tool sight graphic?
I knew I was forgetting something in the positioning code! Parameters tool_sight_offset_x and tool_sight_offset_y will be added in the next version (along with equivalents for KDStatMeter).
Sliptip on 11/7/2013 at 10:10
Oh my mistake then! :eek:
My child objects all have their own design notes. That would explain why they weren't inheriting.
EDIT: I just noticed that the tool sight disappears when I pick up more of the same projectile. I've got a container that when frobbed gives the player the item specified by the contains link. I'll do some testing with this when I get home from work tonight to give you more specifi info!
EDIT 2: More specifically, if I pick up more projectiles the tool sight does not appear. If I'm using one of the pre-made tool sights, I can switch to another inventory item, then switch back and it will appear. If I'm using a .png file of my own design, I am unable to get it back.
kdau on 12/7/2013 at 00:58
Quote Posted by Sliptip
EDIT: I just noticed that the tool sight disappears when I pick up more of the same projectile. I've got a container that when frobbed gives the player the item specified by the contains link. I'll do some testing with this when I get home from work tonight to give you more specifi info!
EDIT 2: More specifically, if I pick up more projectiles the tool sight does not appear. If I'm using one of the pre-made tool sights, I can switch to another inventory item, then switch back and it will appear. If I'm using a .png file of my own design, I am unable to get it back.
Well, that's interesting. It turns out that, when an object is cloned (such as when a stackable is combined or pulled off the stack), the scripts on it aren't <ins>always</ins> started afresh or sent the usual messages. The engine may just <del>copy the scripts' data wholesale</del><ins>create new instances by surpise</ins>. :weird: (It's not a NewDark thing; the HUD feature is just revealing a design flaw in the original Dark code.)
Edit: technical clarification for posterity: Sometimes the engine does properly start new script instances; other times it doesn't bother. In either case, the HUD bitmap system reuses handles for requests for the same path, so a garbage collection wrapper is needed to avoid early freeing.
In this case, both copies of the projectile then hold a pointer to the
same loaded copy of the image. When one of them is destroyed, it deletes the image copy, so then the other one can't use it.
This won't be fixed in 0.3.0 (coming momentarily), but for 0.5.0 I'll write a managed pointer that keeps the images alive.
Sliptip on 12/7/2013 at 01:08
Ok good I'm glad you know what it's doing :laff:
I was trying to compile more useful data to report, but the more I thought I had it figured out, the more I wrong I was. . .
kdau on 12/7/2013 at 01:21
Announcing version 0.3.0, now with 99% fewer crashes (hopefully)! See the first post for details.
Quote Posted by Sliptip
Ok good I'm glad
you know what it's doing :laff:
I was trying to compile more useful data to report, but the more I thought I had it figured out, the more I wrong I was. . .
Yeah, without seeing the data on the scripts themselves, something like this looks nonsensical. Don't worry, you're not in Neverland quite yet. :)
Sliptip on 12/7/2013 at 03:53
Everything seems to be working now - thanks for the update!
fibanocci on 12/7/2013 at 06:34
Yes. it's working very well :thumb:
Ricebug on 12/7/2013 at 11:33
Isn't it amazing that a game approaching its 15th birthday is still going strong? And much of it is due to folks like Le Corbeau, kdau, Telliamed, Nameless Voice, and other math pukes who keep coming up with tools and improvements to Garrett's world.
I've been doinking around with level design and mods since Boulderdash put out its editor. DooM, Quake, etc...the mod communities within those games all had a few folks who could crank out tools to make the process easier. I've known a few who were hired by the same companies who made the games. I feel fortunate to have these guys in our midst, keeping Thief alive.
seventyfour on 13/7/2013 at 16:30
Wow, this is great news. I've been playing around with the scripts and havn't found any problems so far. :thumb:
On a lighter note, now we finally have an intuitive way to indicate how many whole deer legs Garrett manages to stuff himself with.
Chewing is overrated.
<param name="movie" value="//www.youtube.com/v/Xt2aMPw5-WE?hl=sv_SE&version=3&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="//www.youtube.com/v/Xt2aMPw5-WE?hl=sv_SE&version=3&rel=0" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>
kdau on 13/7/2013 at 17:37
Update on the disappearing bitmap issue: it has indeed been fixed for version 0.5.0. As part of that fix, the KDCustomHUD script will no longer be needed (or exist). (It will still be possible to set parameter defaults on an object named CustomHUD, but no extra script will be involved.)
Quote Posted by Ricebug
Isn't it amazing that a game approaching its 15th birthday is still going strong? And much of it is due to folks like Le Corbeau, kdau, Telliamed, Nameless Voice, and other math pukes who keep coming up with tools and improvements to Garrett's world.
I've been doinking around with level design and mods since Boulderdash put out its editor. DooM, Quake, etc...the mod communities within those games all had a few folks who could crank out tools to make the process easier. I've known a few who were hired by the same companies who made the games. I feel fortunate to have these guys in our midst, keeping Thief alive.
Aww, thanks for the kind words. :) I'm not sure I really belong on that list, but I'm glad to do what I can.
Quote Posted by seventyfour
Wow, this is great news. I've been playing around with the scripts and havn't found any problems so far. :thumb:
On a lighter note, now we finally have an intuitive way to indicate how many whole deer legs Garrett manages to stuff himself with.
Chewing is overrated.
This is the best use of KDStatMeter that one could possibly conceive of. :laff::thumb: Would you mind if I linked to that video in future versions of the documentation?
