kdau on 17/7/2013 at 19:08
Quote Posted by Sliptip
I will test these out tonight. One question though - what's the transmute link for?
I'm not sure what the original purpose was, but the (
http://dromed.whoopdedo.org/public_scripts/transmogrify) Transmogrify script in Public Scripts uses it to create new crystals and such, identifying what object should be added to inventory instead of the one picked up. By checking the link, KDRenewable can work correctly with custom crystals and the like.
Sliptip on 17/7/2013 at 19:29
Ah ok, that actually sounds like it could be really useful.
Sliptip on 17/7/2013 at 23:03
Testing: KDRenewable & KDToolSight
I just checked out the scripts and everything seems to work fine except: The robots I had spawn using the KDRenewable don't seem to be able to move and are non-physical. They are aware of me though and shoot at me when I cross their path.
R Soul on 17/7/2013 at 23:09
That's not a bug:
"The new instance is created without a physics model or velocity, so the marker should be positioned and rotated appropriately for the object being created."
That's probably to stop arrows falling if they're created.
KDToolSight:
If I have any tool sight object selected (scouting orb, flashbomb etc) when the scouting orb is activated, the sight remains on screen. Would it be possible to detect whether or not the player is looking through the orb and remove the sight?
kdau on 18/7/2013 at 00:06
Quote Posted by Sliptip
The robots I had spawn using the KDRenewable don't seem to be able to move and are non-physical. They are aware of me though and shoot at me when I cross their path.
Quote Posted by R Soul
That's not a bug:
"The new instance is created without a physics model or velocity, so the marker should be positioned and rotated appropriately for the object being created."
That's probably to stop arrows falling if they're created.
Indeed, that is behavior copied from the original RenewableResource, which was only ever meant for (inanimate) inventory items. Keep in mind that the threshold count is never used for a non-inventory item, since the script only counts copies in inventory, not the world. So a new instance spawns if and only if the previous spawned instance is destroyed. Robots work here because they have Corpse links and are replaced when slain; other AIs wouldn't.
That being said, there's no reason why KDRenewable shouldn't optionally do more. I'll change the script to allow AIs to keep their physics, and any other objects if so configured. I'll also have it optionally ignore slain objects. The next step would be to optionally consider the object count in the world (instead of/along with inventory), but that would be a bit more complicated.
Quote Posted by R Soul
KDToolSight:
If I have any tool sight object selected (scouting orb, flashbomb etc) when the scouting orb is activated, the sight remains on screen. Would it be possible to detect whether or not the player is looking through the orb and remove the sight?
That bothered me too. After an extensive search, I didn't find any way of determining whether/when a camera is attached: there are no property or link changes on the player or the orb, and the camera script service doesn't have any status functions (only attach and detach commands). One option would be to deselect the current inventory object whenever an orb is thrown, which I could add to KDToolSight, to be enabled by a parameter.
The Watcher on 18/7/2013 at 14:25
Quote Posted by Sliptip
I just checked out the scripts and everything seems to work fine except: The robots I had spawn using the KDRenewable don't seem to be able to move and are non-physical. They are aware of me though and shoot at me when I cross their path.
Well, FWIW I've been working towards a replacement for the FireShadowEcology script that can be used for generic AI respawning and population control (with optional per-spawned AI respawn suppression depending on kill method). Dunno if it would be more preferable for you to use that, or for kdau to modify KDRenewable, or what.
LarryG on 18/7/2013 at 16:47
I've been thinking about RenewableResource script, and one enhancement that I would like to see is around the quantity specification.
Quote:
The data of the link is the maximum number of created objects that can be in the player's inventory.
What I'm thinking is that it would be better to tie the qty to a qvar who's name is in the data for the link. That way you can vary the amounts dynamically, but most specifically vary them by difficulty. I suppose, but have not tested, that you could setup three links and use Difficulty > Remove Properties to remove two of the links on Sim. Even if that would work, it just seems to me that hard coding the value in the Data for the link is pretty inflexible.
Updated qvar scripts where the action varies by difficulty would be great too.
Which also brings up the idea of more difficulty-centric scripting. Why not provide for different script behaviors based on difficulty in the scripting framework so that all scripts could inherit that capability?
What do you think?
kdau on 18/7/2013 at 18:17
Quote Posted by The Watcher
Well, FWIW I've been working towards a replacement for the FireShadowEcology script that can be used for generic AI respawning and population control (with optional per-spawned AI respawn suppression depending on kill method). Dunno if it would be more preferable for you to use that, or for kdau to modify KDRenewable, or what.
Cool, that sounds like a much more fitting solution. I think having separate scripts handle the inventory-object and AI cases is a wise idea, too. I'll leave KDRenewable as is for now.
Quote Posted by LarryG
What I'm thinking is that it would be better to tie the qty to a qvar who's name is in the data for the link. That way you can vary the amounts dynamically, but most specifically vary them by difficulty. I suppose, but have not tested, that you could setup three links and use Difficulty > Remove Properties to remove two of the links on Sim. Even if that would work, it just seems to me that hard coding the value in the Data for the link is pretty inflexible.
Indeed, it's inflexible and not quite a standard use of the Data field. I have to keep that as an option for backwards compatibility, but adding another option would be welcome.
My concern with using a qvar here, though, is that we'd be transferring object-level data to a world-level data store (that only handles integers). For all their inheritance problems, Design Note parameters have the advantage of being clearly associated with one object (and supporting a range of data types). I've actually been writing all my scripts to respond to changes in their DN parameters, even though there's no way for authors to change them yet. If there were a TrapSetParam (like TrapSetQVar) that rewrote DN parameters, and a renewable_threshold parameter on KDRenewable, would you consider that a workable solution? It would certainly cover more ground from a coding perspective.
Quote:
Updated qvar scripts where the action varies by difficulty would be great too.
Hmm. I imagine a syntax like the one below in Trap\Quest Var. Is this what you had in mind? I suppose the simplicity of not needing multiple difficulty-destroyed trap objects is worth the extra syntax complexity.
Code:
[0]=1:evil_creatures;[1]=4:evil_creatures;[2]=9:evil_creatures
Quote:
Which also brings up the idea of more difficulty-centric scripting. Why not provide for different script behaviors based on difficulty in the scripting framework so that all scripts could inherit that capability?
It would be nice, certainly. All scripts can trivially read the difficulty qvar once it's set. The main issue is how to apply that to choosing different behaviors. Qvars and DN parameters can feasibly have difficulty numbers tacked on their ends, but (given the idea above) they could have a less-error-prone way of being adjusted. Other properties and links don't have any generic way of specifying the difficulty adjustments.
The other concern is generalizability: there are now five custom OSMs in circulation, and we all share the core of our codebase and various interface principles (like the DN syntax). I wouldn't want to create confusion by being inconsistent. Even in the case of a hypothetical TrapSetParam (as above), I'd need to rely on the other OSMs never caching (directly or indirectly) the values of DN parameters. I suppose the first step is for me to investigate whether they do; please stay tuned.
LarryG on 18/7/2013 at 18:33
Your ideas sound fine. I'm not wedded to a qvar for RenewableResource. And with the design note approach you can always assign the dn variable to a qvar if you want to.
I guess I don't see how what you put into your framework would affect any other osm. Certainly from a usability standpoint, having all the same general principles and ways for specifying parameters to the scripts should be as consistent across osms. That makes sense. But I don't see how enhancing the framework for your osm would be an issue. NV significantly expanded on the tnhscript framework for his design notes. This would just be a similar expansion for difficulty, no?
The Watcher on 18/7/2013 at 19:11
Quote Posted by kdau
Hmm. I imagine a syntax like the one below in Trap\Quest Var. Is this what you had in mind? I suppose the simplicity of not needing multiple difficulty-destroyed trap objects is worth the extra syntax complexity.
Code:
[0]=1:evil_creatures;[1]=4:evil_creatures;[2]=9:evil_creatures
That's pretty manky syntax though, in my opinion anyway. I'd honestly lean more towards a more conventional array access style syntax:
Code:
evil_creatures[0]=1;evil_creatures[1]=4;evil_creatures[2]=9
With some work, that could even do things like
Code:
evil_creatures[0,1]=1;evil_creatures[1]=9
And these two would be equivalent:
Code:
evil_creatures[0,1,2]=3;
evil_creatures=3;
Actually, now I think about it, I'll probably just go ahead and implement that anyway, should be easy enough to make any design note option difficulty-sensitive that way.
