Message system discussion

[DarkDragon]

AngelScript will use a messaging system, and ZScript may switch to using one as well, depending on if it seems like the effort is worth it (i.e., if it looks like AngelScript will take a while to get up and running).

This thread is to discuss how scripts will work in the messaging system, and to hash out the details of this system.

First, a quick overview. Instead of scripts with run() methods, in the future scripts will have a collection of message handlers/callbacks. Here is an initial, very minimal set of proposed messages that more or less replicate current ZScript functionality. Ultimately, many more message types could be supported (feel free to suggest):

Every script type
OnCreate -- called when the object to which the FFC is associated is first created (at the beginning of the game for global scripts; when Link enters the screen for screen and ffc scripts, etc)
OnDestroy -- called when the object to which the FFC is associated is destroyed (when Link leaves the screen for screen and ffc scripts, etc)
EveryFrame -- called at the beginning of each frame (immediately preceding when current scripts that called WaitFrame() execute)
OnDraw -- called at the end of each frame (immediately preceding when current scripts that called WaitDraw() execute)

Item scripts
OnPickedUp -- called when an instance of the item is picked up
OnUsed -- called when the item is used from the inventory

...

Once a callback starts to run, its execution context exists independently of the execution of any other of the script's callbacks. Waitframe() suspends execution until the start of the next frame, WaitDraw() until the end of the current frame, etc. So, for example, if a candle script has an OnUsed callback that creates fire and animates it for several iterations, if Link uses the candle item a second time, a second and completely independent instance of the OnUsed callback starts to run (and can spawn and control its own fire weapon, etc.)

It seems like every script should have control over what messages it is listening for, and which ones it is ignoring (so for instance, a blue candle script could disable OnUsed until Link leaves the screen after the first time it is used, etc.)

Instead of using Misc[] for storing local state, each script will have its own set of local variables, declared within the script, and shared by all instances of all running callbacks of that script.

Old Script Compatibility

If messages are implemented into ZScript, ensuring compatibility of old scripts seems straightforward. Each old global and ffc script (script that includes a Run() method and no callbacks) gets a default OnCreate callback that calls Run(), and a default OnDestroy callback that calls Quit(). Each old item pickup script gets an OnPickedUp that calls Run(), and item use scripts gets OnUsed() callbacks that call Run().

[ZoriaRPG]

AngelScript will use a messaging system, and ZScript may switch to using one as well, depending on if it seems like the effort is worth it (i.e., if it looks like AngelScript will take a while to get up and running).

This thread is to discuss how scripts will work in the messaging system, and to hash out the details of this system.

First, a quick overview. Instead of scripts with run() methods, in the future scripts will have a collection of message handlers/callbacks. Here is an initial, very minimal set of proposed messages that more or less replicate current ZScript functionality. Ultimately, many more message types could be supported (feel free to suggest):

Every script type
OnCreate -- called when the object to which the FFC is associated is first created (at the beginning of the game for global scripts; when Link enters the screen for screen and ffc scripts, etc)
OnDestroy -- called when the object to which the FFC is associated is destroyed (when Link leaves the screen for screen and ffc scripts, etc)
EveryFrame -- called at the beginning of each frame (immediately preceding when current scripts that called WaitFrame() execute)
OnDraw -- called at the end of each frame (immediately preceding when current scripts that called WaitDraw() execute)

Item scripts
OnPickedUp -- called when an instance of the item is picked up
OnUsed -- called when the item is used from the inventory

...

Once a callback starts to run, its execution context exists independently of the execution of any other of the script's callbacks. Waitframe() suspends execution until the start of the next frame, WaitDraw() until the end of the current frame, etc. So, for example, if a candle script has an OnUsed callback that creates fire and animates it for several iterations, if Link uses the candle item a second time, a second and completely independent instance of the OnUsed callback starts to run (and can spawn and control its own fire weapon, etc.)

It seems like every script should have control over what messages it is listening for, and which ones it is ignoring (so for instance, a blue candle script could disable OnUsed until Link leaves the screen after the first time it is used, etc.)

Instead of using Misc[] for storing local state, each script will have its own set of local variables, declared within the script, and shared by all instances of all running callbacks of that script.

Old Script Compatibility

If messages are implemented into ZScript, ensuring compatibility of old scripts seems straightforward. Each old global and ffc script (script that includes a Run() method and no callbacks) gets a default OnCreate callback that calls Run(), and a default OnDestroy callback that calls Quit(). Each old item pickup script gets an OnPickedUp that calls Run(), and item use scripts gets OnUsed() callbacks that call Run().

->Misc[] support does need to continue, so that mixing scripts does not pose problems. That is, a newer script needs to know how to read/write to ->Misc[] of an object generated by an older script.

Or do you not mean the Misc[] array for the pointer objects? Really, it's wise to retain that, as part of the object class, as the object can remain extant after the script exits, which is where those values have always been useful. Cutting that is going to be another 'huge problem', and I don't see how it would be a technical issue, given that it is a variable of the object class and not inherent tot he script that generated it.

Did you mean something else?

Another issue, is that if the same local vars are shared across all running instances, that this would not seem to work properly given the present types of implementation. For example, an ffc script that controls an npc, may have ten (or 32) running instances, each [I]needing[I] its own local variables and/or arrays. If this is not what you meant here, please clarify.

[DarkDragon]

Misc will still work. But there will also be script local variables you can use instead, for data you want to share between callbacks.

Another issue, is that if the same local vars are shared across all running instances

Hold on, I'm not sure what you mean by "running instances" here.

If you have multiple FFCs on the screen, and all have been assigned the same script, each script behaves completely independently. Other than the fact that they happen to have the same code, the only thing they share are the global variables.

Each script can have script member variables that act exactly like C++ member variables. For one FFC, each callback can read and write member variables that are also visible to other callbacks (of the same FFC only).

Then of course each callback has its function local variables, which are unique to each execution of the callback.

[Gleeok]

Hold on ZoriaRPG, let me translate the OP really quick using the state of the art tool transintercommunicomputron-2000:

**working**
...

BZZTFFTT....
...

Computron-2000 ready to translate this is my robot voice BZZT WHIRR.

Greetings primitive human scum. No one use the beta-suggestion forum to help improve scripting in ZC. Why you all do this? We like to improve scripting it make easy things to do that are hard as current. Please help suggest ways to improve our base turret firing system to protect from Pigeon raids. Pigeons eat our milkshakes, this is bad. We can send message to you so you can intercept via script to stop future bird poop attacks. What system do you like to use? We can transmit coordinates directly to your scripts. In future, we poop on birds from below. Is great justice for ZC in 2.6 to poop on birds from below.

Err.. Looks like it's got some kinks in it still... I can never get the blasted thing to work right. :/

[ZoriaRPG]

Misc will still work. But there will also be script local variables you can use instead, for data you want to share between callbacks.



Hold on, I'm not sure what you mean by "running instances" here.

If you have multiple FFCs on the screen, and all have been assigned the same script, each script behaves completely independently. Other than the fact that they happen to have the same code, the only thing they share are the global variables.

Each script can have script member variables that act exactly like C++ member variables. For one FFC, each callback can read and write member variables that are also visible to other callbacks (of the same FFC only).

Then of course each callback has its function local variables, which are unique to each execution of the callback.

I primarily wanted to clarify, and ensure that was true. Your post sounded like you want to deprecate ptr->Misc[], which doesn't make sense because those values are independent of any script that sets them.

Hold on ZoriaRPG, let me translate the OP really quick using the state of the art tool transintercommunicomputron-2000:

**working**
...

BZZTFFTT....
...

Computron-2000 ready to translate this is my robot voice BZZT WHIRR.



Err.. Looks like it's got some kinks in it still... I can never get the blasted thing to work right. :/

[/choking to death laughing]

You win Gleeok. The AGN 'Funnies Bastard' award, goes to you. :)

[Gleeok]

I guess no one has any concrete ideas?

For the time being I'll just do these:

~OnUpdate()
~OnDraw()
~OnPigeonRaid()

The tricky one is going to get Link right at some point. Perhaps we might try and come up with a spec for how Link would work if scripters want to have control over various Link stuff.

[DarkDragon]

This is a good idea. When I get some spare time I'll take a look at the code and come up with a proposal.

For items, weapons, enemies, etc I think it's best to add a very minimal set of callbacks to the existing hard-coded enemies, and then add in a special "scriptable enemy" etc that has a full and large set of callbacks.

[Gleeok]

Callbacks are in for stateful scripts (ie.; scripts with persistent stack space). For global callbacks these should be declared global procedures by scripts. I can add any procedure to call these on the script side easily, just need to spec the desired arguments and return values and then add them to ZC first.

There's a slight annoyance with classes though: Script classes cannot inherit from application classes, so for example a scripted npc with an npc property can't do 'this.X = 0', but instead '(this.)npc.X = 0', which is weird. This requires an extra layer of a scripted base class to define these properties and get them from the engine... I *think*. The problem is we are short of people, especially with Saffith leaving. I wouldn't be surprised if npcs have to wait one version... :/ Unlimited screen scripts, map scripts, global scripts, and various callbacks might be enough for an initial release, which isn't so bad I guess.

One nice thing is the memory usage isn't too bad. Compiling and updating 2048 global scripts -each script uses only a few kb.

[ZoriaRPG]

I guess no one has any concrete ideas?

For the time being I'll just do these:

~OnUpdate()
~OnDraw()
~OnPigeonRaid()

The tricky one is going to get Link right at some point. Perhaps we might try and come up with a spec for how Link would work if scripters want to have control over various Link stuff.

I missed this one. The first thing that we need to do in this regard, is refactor how some aspects of the Link class work. If you don;t want to allow writing to sprites, then we need to rework sprites,a nd read them from an ffscript class of some kind, as a default, and if those are not set, use the engine sprites. Likewise, the detection of Link and map flags, combo solidity, eweapons, and npcs, need to work in the same way, calculating his hitbox from his x, y, hitsize, and hitoffsets. The present implementation is scattered around, uses some dfunctons that are very hard to read, and is just generally terrible.

I'm a bit tired of making adjustments back and forth between files. A general, hitbox function per class would be best, for calculating hits. Perhaps even a hitbox class that can be applied to any game object? That would solve many issues.

Are we good to go for messages in the zscript parser for now?

[Saffith]

There's a slight annoyance with classes though: Script classes cannot inherit from application classes, so for example a scripted npc with an npc property can't do 'this.X = 0', but instead '(this.)npc.X = 0', which is weird.

You can use virtual properties to work around that.

fix X
{
    get const { return npc.X; }
    set { npc.X=value; }
}

That also has the advantage that the handle can be made private in the base class, so you can't accidentally point it to another enemy.
One minor issue what that is that you can't use increment and decrement operators on virtual properties. I think it should be possible to add them, though, if you don't mind messing around with AS's code a bit. They were deliberately removed, and I forget the reason, but I think it had to do with multithreading issues that aren't relevant to ZC.