TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 113

Thread: KDScript 0.7.0 (2013-09-01): new script module, now with tutorials

  1. #51
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by Sliptip View Post
    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 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.

  2. #52
    Member
    Registered: May 2002
    Location: Toronto
    Ah ok, that actually sounds like it could be really useful.

  3. #53
    Member
    Registered: May 2002
    Location: Toronto
    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.

  4. #54
    Member
    Registered: Jan 2001
    Location: Pushing my luck with Dromed
    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?

  5. #55
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by Sliptip View Post
    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 Originally Posted by R Soul View Post
    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 Originally Posted by R Soul View Post
    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.

  6. #56
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    Quote Originally Posted by Sliptip View Post
    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.

  7. #57
    Member
    Registered: Aug 2007
    Location: LosAngeles: Between Amusements
    I've been thinking about RenewableResource script, and one enhancement that I would like to see is around the quantity specification.
    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?

  8. #58
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by The Watcher View Post
    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 Originally Posted by LarryG View Post
    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.

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

  9. #59
    Member
    Registered: Aug 2007
    Location: LosAngeles: Between Amusements
    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?

  10. #60
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    Quote Originally Posted by kdau View Post
    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.

  11. #61
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by The Watcher View Post
    That's pretty manky syntax though, in my opinion anyway. I'd honestly lean more towards a more conventional array access style syntax:
    (CLIP)
    My syntax idea was for quest variables (trying to fit in the existing TrapSetQVar syntax), not for Design Note params. I guess I was imagining the option of conditionals based on tracking non-difficulty qvars (e.g. [guards_alerted>5]=3:goal_state_4, no need for a trap/trig pair), but maybe that's overambitious.

    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.
    For DN params, I'm good with the array-index style if you are, but a proper implementation will be tricky. Looking at ScriptLib, the setter functions would have to be rethought, and the getter functions currently each have redundant copies of the name-matching code (and use the hideous plain-C str* function family ).

    What are your thoughts on DN parameters being changed mid-mission? If that's not at odds with how you (and Telliamed and NV) use them, it would be a more flexible option that wouldn't disrupt the existing syntax.

  12. #62
    Member
    Registered: Aug 2007
    Location: LosAngeles: Between Amusements
    For qvar assignment via Trap>Quest Var the syntax is manky, but we are stuck with it:

    =3:thingy will set the value of thingy to 3
    I assumed that kdau was talking about expanding the Trap>Quest Var syntax for difficulty, not design notes.

    Edit: oops, kdau beat me to it.

  13. #63
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    Quote Originally Posted by kdau View Post
    My syntax idea was for quest variables
    Ah, right. I can brain, really. Sometimes.

    Quote Originally Posted by kdau View Post
    For DN params, I'm good with the array-index style if you are, but a proper implementation will be tricky. Looking at ScriptLib, the setter functions would have to be rethought, and the getter functions currently each have redundant copies of the name-matching code (and use the hideous plain-C str* function family ).
    Well, the getters at least will be easy enough for me: I've all but replaced them in my code, and I've got it set up so that all I currently have is a single place that calls GetParamString (well, I also call GetParamBool, but the writing is on the wall for that one, too). I haven't gone near the setters, though; not had any need to, really.

    Although my code still uses the char * stuff for many things, I have been pondering switching it to std::string or maybe bstring. Maybe if I replace GetParamString I'll just go ahead and fix all that.

    Quote Originally Posted by kdau View Post
    What are your thoughts on DN parameters being changed mid-mission?
    I'd be very cautious of it. I only have a couple of released scripts right now, and it'd make no difference to one of them (every time it is triggered it reads settings out of the DN for simplicity). The other potentially sets up qvar subscriptions when handling BeginScript, so it'd need to also register to be notified of property changes and update the qvar subscription if needed. Which I could do - but only with caution, I wonder whether there may be any performance implications from it. Don't know without testing, I guess. I'm pretty sure several Public Scripts scripts would not work properly: they set things up in BeginScript and do not read the DH again, no idea about NV's stuff.

  14. #64
    Member
    Registered: Jan 2001
    Location: Pushing my luck with Dromed
    Would it be possible to create scripts that set or remove properties?

    The 'set' script could read parameters that define the name of the property, and an optional 'agent' object to copy the values from.

  15. #65
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by R Soul View Post
    Would it be possible to create scripts that set or remove properties?

    The 'set' script could read parameters that define the name of the property, and an optional 'agent' object to copy the values from.
    Copying and removing properties should be safe and effective, yes, as well as instantiating properties with their default (inherited) values. I'm in the midst of a code overhaul ATM, but I'll add it to the list next to "set qvar with fancy conditionals" and "set Design Note param (for select scripts only)".

    The only dangerous bit would be the one you didn't ask about, setting a property to a parameter-coded value instead of copying it. In case anyone wants that option, please heed NV's warning about NVRandomPropertyTrap, which would apply doubly to this:
    Quote Originally Posted by NVScript.html
    Warning: attempting to use this to put the wrong type of data into a property will probably result in a crash, e.g. putting a string (via the prefix option) into a numeric property.

  16. #66
    Member
    Registered: Aug 2012
    Location: Seattle
    Quote Originally Posted by Albert View Post
    A bit of an aside, but SS2 could benefit from the custom HUD scripting. Unless that's already possible?
    My understanding is that there was limited HUD access in the script services for pre-NewDark SS2 (OldShock?), but nothing like what's available now. I'm not sure whether allobjs.osm (or any custom module) ever exposed that to FM authors, though.

    Course, the script would need to be made to work with SS2 ND, I imagine.
    Yes, there are a number of differences between Thief's and Shock's versions of the engine. The "NewShock" custom HUD is even more featureful than the NewDark one, offering e.g. object icons, variable fonts and cursors, and some interactivity. The problem is that I've never even played SS2, much less know anything about its internal structure. Someone with that background would have to write those scripts, whether forking from mine or starting from scratch.

  17. #67
    Member
    Registered: Dec 2002
    The downloadlink in the first post is broken. Please upload it again

  18. #68
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    http://www.bogadocious.com/thief/kda...ript-0.5.0.zip appears to be the correct address now.

  19. #69
    Member
    Registered: Dec 2002
    Thanks

  20. #70
    Member
    Registered: Jan 2012
    Location: Gèrmany
    Thanks for bumping up and more thanks to the creator. Nice Nice nice. Maybe I should check the topics I missed during my absent time.

    I was aware that NewDark supports custom HUD elements and stuff but not that we already have a script for these things. Your script will be very usefull for me. I had to do workarounds or drop ideas with NewDark some problems could be solved but not to the degree how I wanted it. but you made my day. Especially the fog manipulation a dream came true

    Only thing that I'm missing is a more simple HUD overlay trap that when turned on displayed a defined bitmap with x,y offset.

    Just an idea but maybe you want to consider it: If you adjust for example values like stat_meter_width or stat_meter_height so that they use a defined percentage of the screen instead of a fixed pixel width that would have the advantage that it looks nearly the same for all resolutions. I experienced such a problem a longer time ago in an old indie game I got a new monitor and then it looked kinda messed up. Also I think there could be problems with this method when mappers make their HUD for nicely for widescreen but with none widescreen monitors there will be overlaps or the screen is just to tiny.

  21. #71
    Member
    Registered: Aug 2012
    Location: Seattle
    Thanks for noticing and relocating! Ricebug is still getting settled at his new host. I have updated the first post accordingly.

    General news: I've been working on some background stuff for the module that will make it much easier for me to add more in the future. It won't affect FM authors too much, but it will include true inheritance of Design Note parameters and improved color interpolation (e.g. in fog transitions). Version 0.7.0 is still coming, but will have mostly small additions to existing scripts. Version 0.9.0 will follow with the other scripts previously discussed. Then I'll be shifting gears to work on my own long-delayed mission for a while, while making small updates to KDScript as needed. Remember: please let me know if you enter beta testing on a mission using KDScript, both so that I can help if needed and so that I can take the "beta" label off KDScript itself!

    Quote Originally Posted by Daraan View Post
    Only thing that I'm missing is a more simple HUD overlay trap that when turned on displayed a defined bitmap with x,y offset.
    Hmm. I should just be able to create a simplified version of KDStatMeter that does that. I'll add it to the future list.

    Quote Originally Posted by Daraan View Post
    Just an idea but maybe you want to consider it: If you adjust for example values like stat_meter_width or stat_meter_height so that they use a defined percentage of the screen instead of a fixed pixel width that would have the advantage that it looks nearly the same for all resolutions. I experienced such a problem a longer time ago in an old indie game I got a new monitor and then it looked kinda messed up. Also I think there could be problems with this method when mappers make their HUD for nicely for widescreen but with none widescreen monitors there will be overlaps or the screen is just to tiny.
    There is an option d3d_disp_scaled_2d_overlay in cam_ext.cfg that scales the HUD based on the resolution. I haven't experimented with it enough, actually, so I'll do that. The option is disabled by default, but an FM should be able to include it in a custom dark.cfg. If that's not a good enough option, it wouldn't be too much trouble to start taking percentages in stat_meter_width et al.

  22. #72
    Member
    Registered: Aug 2012
    Location: Seattle
    I'm pleased to announce version 0.7.0. As noted above, the changes here are mostly behind the scenes, but I would appreciate anyone who is using the module to test this version and confirm that nothing has become broken. KDScript now has a web site with an online version of the documentation, including a new "Quick Start" section with step-by-step tutorials. The specific changes in this version are as follows:

    • The module now requires the new support library ThiefLib.osl instead of DH2.osl.
    • KDCarried: The pickable pocket count will now be reduced just after sim, but only when a Contains-linked object has inert_until_dropped=true.
    • KDCarrier: The AI will now send messages just after the beginning of the knockout or death sequence, instead of at the end; thanks to The Watcher for suggesting the technique used.
    • KDJunkTool: The tool's player arm model, if any, will now be displayed while it is carried. Any previously selected weapon will now be reselected when tool is dropped.
    • KDQuestArrow: The arrow can now be optionally limited to a certain range of distance from the player.
    • KDRenewable: The threshold and frequency are now preferably specified in parameters, though backwards compatibility has been kept. Created objects' physics models can now be optionally left intact.
    • KDSubtitledVO: Align the start time of the sound and subtitle more precisely.
    • KDToolSight: A stack of tool sight objects can now be optionally deselected when one is thrown. (This is intended for scouting orbs.)
    • KDTrapWeather: The radius, opacity, brightness, and wind speed/direction of the precipitation can now be changed as well.
    • All KDScript Design Note parameters are now individually inheritable.
    • As such, HUD element scripts no longer check an object named CustomHUD for their parameters; instead, set those default parameter values on a sufficiently high-level archetype.
    • All KDScript Design Note parameters can now vary by difficulty (see the documentation).
    • All color transitions and gradients are now calculated more smoothly (in the CIE L*a*b* color space).
    • Fog and weather transitions now offer a range of curves other than linear (as in Public Scripts' TrapPhantom).
    • The entire module has been rebuilt on top of my new ThiefLib wrapper library. While major changes have been noted above, there may be other minor differences in behavior from previous versions.
    Last edited by kdau; 1st Sep 2013 at 13:53. Reason: clarify scope of DN changes

  23. #73
    Member
    Registered: Aug 2007
    Location: LosAngeles: Between Amusements

  24. #74
    Member
    Registered: Dec 2012
    I really like this script. Since I saw the mission changer in you chess game, I want to be able to do this, too. And now I can! Thank you!

    I played the version 0.7.0. These are the differences, I noticed (to 0.5.0):
    - The aristo woman stands in the air (only an adjustment thing, I think).
    - The purse now drops earlier; that is better, I think.
    - The new moss arrows are appearing faster. And the quest arrow appears, if you are nearer. (Just mention this for the sake of completeness.)
    So, everything works fine for me.

  25. #75
    Member
    Registered: Dec 2002
    It's working just fine (win xp)

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •