Calling convention for Actions (advanced scripting analysis)

[ailinon]

Calling convention for Actions (advanced scripting analysis)

I've been wondering - analysing it from the basics of programming. I come from C/C#/Java/Lua/VB background, so I think I should be pretty fluent by now.AssignCommand(oNPC,ActionSomething(parameters));This should, logically, generate an object of type 'action' and assign it to the NPC, placing it in its action queue or something. This should, then, also work written as:action aDoit = ActionBelch();AssignCommand(oShrek,aDoit);AssignCommand(oFiona,aDoit);... as this would assign identical actions to two NPCs - but no, Action* functions return... voids! Here comes the stump in a more profound manner:AssignCommand(oFiona,DelayCommand(1.0,ActionSpeakString("Oh golly!")));Or, even simplerelayCommand(1.0,PrintString("Hello, I'm your friendly debug log."));Why does AssignCommand happily accept a void parameter? Why does DelayCommand gladly receive a void returned from PrintString? Do these commands use some weird interpreted syntax, instead of proper function-returning-a-value convention now?Any experienced programmers on board..?-- Sinus

 

[Gamewidow]

because it is not doing type-checking ? ... sure, it would be nice if it did ... i don't know if this is part of the language definition or if they just didn't bother/notice when putting D'Jinni togetherUpdate plugging nwn AssignCommand into google seems to suggest this function is working as specified. it's still pretty weird ... so ok, not type-checking, just a strange way to pass around arguments

 

[ailinon]

It bothers me to hell and back how a function can not do type-checking of its arguments, yet still run what it received. And, note, it - being technically correct - receives nothing! PrintString, for example, doesn't return anything - and yet it's a valid argument for DelayCommand...Why I'm poring over it so much is simple: I was imagining a simple "action chooser" function, working - in a C/NWNscript hybrid form - like thiselayCommand(1.0,MyActionChooser(OBJECT_SELF));...function MyActionChooser(object oObject) { if (IsCivilized(oObject)) return ActionCough(); else return ActionBelch();}I'd be glad if I could be sure that my function is ran before the one second delay starts, and at that point it decides the action to be performed later. With a proper type-compliant scheme (including passing around pointers or delegates) this would be fairly easy to do - with something hybrid, that Aurora seems to run on, I end up doing massive guesswork and "hope methods" and wondering how it all holds together... if it does at all.-- Sinus

 

[vaernus]

From our understanding, it seems as if every function is overridden to accept any parameter and either parse out useless garbage, or not even allow a function to compile. In the case of AssignCommand and DelayCommand, they are very multipurpose tools to control exactly when something runs, and whom it runs on.However, we've seen exactly the same problem where it tends to run straight through an entire script rather than line by line. Therefore allowing a DelayCommand action to effectively run after other code when it was intended to run before. Now we have found a few ways to cheat the system and force a script (or rather a procedure) to follow our order.One way is to use ExecuteScript inside of a DelayCommand. If properly spread out, and Djinni only required results behind the scene, it tends to be effective. This would require code blocks and separate scripts to accomplish.Another is using fake cutscenes. They take an OnEndCutscene script if applicable and force the script to run only after the cutscene is finished. Setting up a blank 1 second cutscene would force order into the scripts.All tend to be workarounds though.

 

[ailinon]

Although these workarounds are definitely creative and noteworthy, they seem like the opposite of what I'm trying to accomplish.I need a way to "store" actions to be performed, in order to create an action queue of my own. There doesn't seem to be a way to "wrap" a function call, the way DelayCommand or AssignCommand apparently does, and feed it into several DelayCommands one after another... A sad thing, really, as it seems to prove that NWNscript is not a real programming language at all, just a "script that got improved and improved over time", like mIRC script, in which each function has its own calling convention and syntax...Okay, tinkering on.-- Sinus