kdau on 18/7/2013 at 19:31
Quote Posted by The Watcher
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.
Quote:
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 :eww:).
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.
LarryG on 18/7/2013 at 19:41
For qvar assignment via Trap>Quest Var the syntax is manky, but we are stuck with it:
Quote:
=3:thingy will set the value of
thingy to
3I assumed that kdau was talking about expanding the Trap>Quest Var syntax for difficulty, not design notes.
Edit: oops, kdau beat me to it.
The Watcher on 18/7/2013 at 20:24
Quote Posted by kdau
My syntax idea was for quest variables
Ah, right. I can brain, really. Sometimes.
Quote Posted by kdau
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 :eww:).
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 Posted by kdau
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.
R Soul on 21/7/2013 at 14:30
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.
kdau on 22/7/2013 at 19:09
Quote Posted by R Soul
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 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.
kdau on 25/7/2013 at 18:19
Quote Posted by Albert
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.
Quote:
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. :erg:
fibanocci on 16/8/2013 at 20:06
The downloadlink in the first post is broken. Please upload it again :)
fibanocci on 16/8/2013 at 20:47
Thanks :thumb:
Daraan on 16/8/2013 at 22:30
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:cheeky:
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.
