Jump to content

Photo

Script Message System Discussion


  • Please log in to reply
15 replies to this topic

#1 Gleeok

Gleeok

    It's dangerous to dough alone, bake this.

  • Members
  • Real Name:Pillsbury
  • Location:Magical Land of Dough

Posted 24 January 2017 - 05:04 AM

[Gleeok] The jist of all this is something akin to "How can scripting be improved in ZC 2.6 to make scripts easier to do what you want them to do and not how you workaround what they can't do to get it to sorta do what you wanted to do in the first place." ..if that makes sense. Basically, you may ignore the technical details if you like and just get to demanding new core script features, so be sure to write lots of exclams!!! :P


Copy-paste from AGN: http://www.armageddo...stem-discussion


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


  • Avaro likes this

#2 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 January 2017 - 06:28 AM

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

 

Note to users: This will be automated and invisible. You will not need to edit scripts to implement this.



#3 Avaro

Avaro

    o_o

  • Members
  • Real Name:Robin
  • Location:Germany

Posted 24 January 2017 - 11:37 AM

This sounds great, but I hope its easy enough to fully understand too. xd I'll need some examples if this gets implemented for sure. Also does this mean item scripts can run longer than 1 frame? Also, FFCs do get destroyed when you leave the screen? Does that happen when leaving the screen by ANY means, including warps and F6 continue?

 

On a completely unrelated note, is angelscript still planned for the future?


Edited by Avataro, 24 January 2017 - 11:40 AM.


#4 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 January 2017 - 05:14 PM

This sounds great, but I hope its easy enough to fully understand too. xd I'll need some examples if this gets implemented for sure. Also does this mean item scripts can run longer than 1 frame? Also, FFCs do get destroyed when you leave the screen? Does that happen when leaving the screen by ANY means, including warps and F6 continue?

 

On a completely unrelated note, is angelscript still planned for the future?

 

It should allow item scripts to continue running, and it's a system we hope to implement for weapon scripts, npc scripts, screen scripts, and the like, in the future.

 

There is still debate/uncertainty on AS, or any other script engine model; and Gleeok is testing out a compatibility model at present.



#5 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 24 January 2017 - 06:13 PM

This sounds great, but I hope its easy enough to fully understand too. xd I'll need some examples if this gets implemented for sure. Also does this mean item scripts can run longer than 1 frame? Also, FFCs do get destroyed when you leave the screen? Does that happen when leaving the screen by ANY means, including warps and F6 continue?

 

On a completely unrelated note, is angelscript still planned for the future?

 

New things are always confusing until they are not. Whatever new scripting changes are made, I, and probably a few others will readily help the community understand how to adapt to those changes and for new users to comprehend them. How exactly such things will work is hypothetical right now. Someone else could tell you how FFC objects behave internally, because I have no idea...

 

AngelScript is being discussed and I think it is likely as a good deal of work has been done with it and it will greatly benefit ZC.



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 January 2017 - 06:22 PM

New things are always confusing until they are not. Whatever new scripting changes are made, I, and probably a few others will readily help the community understand how to adapt to those changes and for new users to comprehend them. How exactly such things will work is hypothetical right now. Someone else could tell you how FFC objects behave internally, because I have no idea...

 

AngelScript is being discussed and I think it is likely as a good deal of work has been done with it and it will greatly benefit ZC.

 

I shall do likewise, and I may do a video series to detail some of the changes. I am already planning that for parser changes, so that users know how to use some of the goodies.

 

I don't yet know how ffc behaviour may change. At present they work as follows:

 

When a quest is loaded, every ffc in the quest, is loaded into RAM. Even if it has a blank combo, no script, and default attributes, and you are not on its screen, it is loaded into memory. This is madness, because ffc values are only accessible when you are on the screen with that ffc, and it is the reason why we don't want to expand the number of them per screen.

 

A sizable amount of the RAM usage by ZC is purely for ffcs. It's madness.

 

32 bits per ffc variable, plus bits for each of their flags, and a word for their combo; plus the memory footprint of their combo, even if it is blank, multiplied by the number of screens on a map including blank screens) multiplied by the number of maps in a game, all as global memory.

 

This more than anything else is what bloats quest file size and game RAM usage.

 

Another issue is that ffcs aren't even their own object class at present. They essentially look like this, in reference:

 

TheMaps[num_maps][num_screens][32].variable

 

When you visit a screen, the index at which operating ffcs are referenced is offset to the map*screen value. FFC combos, and scripts, and movement only run when their map*screen index matches the map*screen index of the current screen, but they are always in memory.

 

Changing this would be a benefit in general, although we need to ensure that they still run when the screen is drawn.

 

Another issue is that their drawing sequence has no method of doing draws in sync with other screen drawing. This change would fix that, by giving them OnDraw().


Edited by ZoriaRPG, 24 January 2017 - 06:36 PM.


#7 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 24 January 2017 - 07:11 PM

When a quest is loaded, every ffc in the quest, is loaded into RAM.

Good lord...

 

This, Ladies and Gentlemen, is why Zscript needs to go!

 

ZoriaRPG, trying to message you but you can't receive anymore PMs. Where can I get a hold of you?


Edited by SUCCESSOR, 24 January 2017 - 07:31 PM.


#8 Quanta

Quanta

    King of Thieves

  • Members
  • Real Name:Willem
  • Location:Earth

Posted 24 January 2017 - 08:00 PM

Is there actually a point for having ffcs stored constantly in ram?



#9 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 January 2017 - 08:22 PM

Good lord...

 

This, Ladies and Gentlemen, is why Zscript needs to go!

 

ZoriaRPG, trying to message you but you can't receive anymore PMs. Where can I get a hold of you?

 

Do you use Skype? If not, you can always send a PM to me on AGN.

 

The ffcs issue has nothing to do with ZScript. Even if you changed script engines, the problem would remain. It's how they were implemented, and the issue that most of the older devs didn't even attempt any sort of memory management. Changing them is problematic because of how old quests expect them to work, and I do not know what the plan is in this regard.

 

(We briefly discussed adding more ffcs as dynamic objects, created by the user on demand, although screen, weapon, and npc scripts would reduce the need for this.)

 

 

Is there actually a point for having ffcs stored constantly in ram?

 

Poor future planning. Quests at the time didn't typically use many maps, and they were originally only intended to be combo objects, not script components. There are in fact, source comments complaining about them not having their own class.

 

It was probably the easiest way to implement, and reference them, at the time.


Edited by ZoriaRPG, 24 January 2017 - 08:26 PM.


#10 Gleeok

Gleeok

    It's dangerous to dough alone, bake this.

  • Members
  • Real Name:Pillsbury
  • Location:Magical Land of Dough

Posted 24 January 2017 - 08:46 PM

RE: How much memory does ZScript use? Load up a quest in 2.10, and then the same quest in 2.50 and compare.

This was just sort of inherited from the old beta-18 days. I've already made plenty of jokes about it so there's no need to make more. It's low priority, but if some people want to help fix bugs or test it (ZQuest...yuck) I can "fit it," and by that I mean lower RAM to next to 0 but everything will crash or not work properly. It's fun to fix non-issues.

#11 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 24 January 2017 - 11:22 PM


The ffcs issue has nothing to do with ZScript. Even if you changed script engines, the problem would remain.

You know, I should really stop thinking of FFCs as nothing but script vessels. It's hard as it's all I have ever used them for.



#12 Quanta

Quanta

    King of Thieves

  • Members
  • Real Name:Willem
  • Location:Earth

Posted 25 January 2017 - 12:38 AM

You know, I should really stop thinking of FFCs as nothing but script vessels. It's hard as it's all I have everused them for.

You have never made moving spike traps or anything like that?

 

Anyway, I like the idea of having trigger script types instead of the global, ffc and item types.

Why is it called angelscript?



#13 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 25 January 2017 - 01:32 AM

You have never made moving spike traps or anything like that?

 

Anyway, I like the idea of having trigger script types instead of the global, ffc and item types.

Why is it called angelscript?

 

AngelScript is an entirely different script engine, that has been proposed as a possible replacement for ZScript in the future.



#14 DarkDragon

DarkDragon

    Junior

  • ZC Developers

Posted 25 January 2017 - 11:36 AM


When a quest is loaded, every ffc in the quest, is loaded into RAM.

 

This is not actually a problem. Everything in a .qst is loaded into memory when you start playing it (music, tilesets, etc). There is no support for streaming parts of a .qst from disk as you play, nor is there any need, since even the largest quests have size in the MBs, while computer memory on modern machines is in the GBs.

 

The actual problem Gleeok and ZoriaRPG are alluding to is that the current quest format reserves space for all FFCs, on all screens, even if there are no actual FFCs being used on that screen.



#15 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 27 January 2017 - 11:18 AM

I was thinking about it the wrong way. I thought Zoria meant every single FFC was instantiated when the quest loaded.

Aren't there a great many things in zc that take up memory whether or not they are used? Maps for instance.

You know for awhile now I've wanted to dig into ZC code but keep putting it off. Its like standing at the edge of a cliff with water beneath. You know you can jump, you've seen your friends doing it. But you get that anxiety about actually doing it. Zc code seems kind of like that. Only don't jump too close as there are jagged rocks there... And not out too far! An under current might pull you down.... and don't thrash about a lot there are piranhas.... and don't accidently swallow the water it has e coli...

Edited by SUCCESSOR, 27 January 2017 - 11:22 AM.

  • Anthus likes this


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users