ZScript additions for 2.51.

[Gleeok]

This consists primarily of two things: Additions to the core ZScript bindings and interface, and additions or removals of library functions (eg; std.zh). I know there are also other popular .zh files since 2.50 was released: std_extra.zh, weapons.zh, etc.; are any of these worth adding (whole or piecemeal) directly into the 'std' library for the next release? Suggestions are also welcome.


@ZoriaRPG - Would you mind giving us a brief summary list of the new ZScript functions you guys have added that you would like us to include into 2.51? This should also save some back and forth time in case some things needs to be discussed or modified. I'd like to put all of these changes in before anything else, if you don't mind.

[DarkDragon]

I know there are also other popular .zh files since 2.50 was released: std_extra.zh, weapons.zh, etc.; are any of these worth adding (whole or piecemeal) directly into the 'std' library for the next release?

This is an excellent idea. There are many user-created scripts that are extremely commonly used (item pickup messages; handling of NPCs, etc) that we coudl include (with permission) as a standard bundle.

EDIT: One concern I have about the way we current handle .zh files: they are imported at ZScript compile time, not at quest creation time. So for instance suppose a quest uses weapons.zh in ZQ 2.50, and then the quest author loads her quest in ZQ 2.70 and tries to recompile her scripts. Should she expect to have to deal with backwards incompatibilities that have arisen in weapons.zh since 2.50? Or should she expect her scripts to still compile as-is?

[Gleeok]

Yes, exactly. Anything removed, say, would have to be moved to a "std_legacy.zh," and any major additions should get a separate .zh file (Like string.zh does for example).

[DarkDragon]

Yes, exactly. Anything removed, say, would have to be moved to a "std_legacy.zh," and any major additions should get a separate .zh file (Like string.zh does for example).

How about something like this? It balances between keeping .qst files self-contained and safe from changes to the script headers in the future, without breaking ZScripts stored in old .qsts *too* badly:

1. Instead of a single script buffer, quests store a list of scripts and script headers, and their contents. Users can import/export the scripts and headers from/to files.
2. The ZScript compiler then compiles all scripts, but the "import" command will pull script headers only from those that have been imported into the quest.
3. If the script headers change in a future version of ZC, quests created on earlier versions will keep using their own old version of the script header, stored inside the quest file. The quest author can update the headers by importing the new version into their quest and recompiling (at which point, they are responsible for fixing any ZScript errors that occur due to changing the header version.)
4. Old quests from 2.50 and earlier, when loaded into ZQ, have their buffer contents saved to a "myscript.z" script, and have std.zh automatically included as an imported header. If the script buffer "import"s any other headers, the author will have to import the header into their quest manually before they can compile their scripts again.
5. The game play of old quests whose scripts have already been compiled into ZASM is completely unaffected.

[ZoriaRPG]

How about something like this? It balances between keeping .qst files self-contained and safe from changes to the script headers in the future, without breaking ZScripts stored in old .qsts *too* badly:

1. Instead of a single script buffer, quests store a list of scripts and script headers, and their contents. Users can import/export the scripts and headers from/to files.
2. The ZScript compiler then compiles all scripts, but the "import" command will pull script headers only from those that have been imported into the quest.
3. If the script headers change in a future version of ZC, quests created on earlier versions will keep using their own old version of the script header, stored inside the quest file. The quest author can update the headers by importing the new version into their quest and recompiling (at which point, they are responsible for fixing any ZScript errors that occur due to changing the header version.)
4. Old quests from 2.50 and earlier, when loaded into ZQ, have their buffer contents saved to a "myscript.z" script, and have std.zh automatically included as an imported header. If the script buffer "import"s any other headers, the author will have to import the header into their quest manually before they can compile their scripts again.
5. The game play of old quests whose scripts have already been compiled into ZASM is completely unaffected.

(Emphasis, mine.)
I do not like this. I would much rather add an include directive to the parser to do this in the future, and maintain the existing import directive. Most scripters use the import directive as an easy way to handle editing script files extermally, and do not want to manually load them. That's pretty much the entire point.

People do not solely use import for headers, nor do they want to manually load headers. That just sounds like an awfulw way to handle this, and it would exponentially increase the amount of work involved with script and quest development. Have you ever looked at some of the massive 'library' like heades out there, that import other headers, with those importing their own?

Changing how import works, would break the majority of scripts used in quests over the last ten years, and many of the released scripts sets. Plus, how will you handle cross-association of values and calls? I would think that the parser rewrites just to do this outweigh any advantage it might represent at present.

I do like the idea of an include directive, to store scripts in separate buffers, as a new option, but not using import to do it.

Another thing to note here, is that headers also commonly contain scripts, not just global functions and declarations, so storing header datum separately from script datum, when both are related, is somehow a bad idea.

[ywkls]

Separately: do y'all have a list of recommended .zh files to include in future ZC releases? Obviously, we'd have to get permission from each script author, but it would be helpful to start compiling a "short list" of widely-used/popular .zhs.

The ones that I use the most often are stdExtra.zh (by MoscowModder) and ffcscript.zh, ghost.zh and tango.zh (by Saffith). These are also the libraries that I see most other scripters using frequently. Importing their various files one at a time would be a lot of work, though; especially since things like ghost.zh and tango.zh have dozens of files included.

(Emphasis, mine.)
I do not like this. I would much rather add an include directive to the parser to do this in the future, and maintain the existing import directive. Most scripters use the import directive as an easy way to handle editing script files extermally, and do not want to manually load them. That's pretty much the entire point.

Some of the libraries in question can have dozens of lengthy files. Usually, this is done for the purposes of keeping things organized so that they can be readily edited. Personally, I can't keep track of where a certain function is in my own script header, much less somebody else's.

People do not solely use import for headers, nor do they want to manually load headers. That just sounds like an awfulw way to handle this, and it would exponentially increase the amount of work involved with script and quest development. Have you ever looked at some of the massive 'library' like heades out there, that import other headers, with those importing their own?

I've actually moved more towards the format DarkDragon suggested earlier, of myscript.z (although in my case, it's usually myquest.z) because it's easier to find and edit errors that way. But having to load each of the headers I have does sound like it would take a lot of time. Unless I'm misunderstanding somehow?

[DarkDragon]

(Emphasis, mine.)
I do not like this. I would much rather add an include directive to the parser to do this in the future, and maintain the existing import directive. Most scripters use the import directive as an easy way to handle editing script files extermally, and do not want to manually load them. That's pretty much the entire point.

People do not solely use import for headers, nor do they want to manually load headers. That just sounds like an awfulw way to handle this, and it would exponentially increase the amount of work involved with script and quest development. Have you ever looked at some of the massive 'library' like heades out there, that import other headers, with those importing their own?

Changing how import works, would break the majority of scripts used in quests over the last ten years, and many of the released scripts sets. Plus, how will you handle cross-association of values and calls? I would think that the parser rewrites just to do this outweigh any advantage it might represent at present.

I do like the idea of an include directive, to store scripts in separate buffers, as a new option, but not using import to do it.

Another thing to note here, is that headers also commonly contain scripts, not just global functions and declarations, so storing header datum separately from script datum, when both are related, is somehow a bad idea.

The problem right now is that .qst file scripts cannot be recompiled at all if the quest author somehow deletes the wrong extra file from their computer (or upgrades to a new version.) If as you say, people are including files without even being aware of what files are involved, the situation is even more dire than I thought, since they might switch to a new computer, etc. and have no idea what external script packages, and what version of those script packages, are needed to get everything compiling again.

I'm happy to discuss quality-of-life features, but the ZScript ecosystem moving forward needs to include a solution to the above problem. "Import" reading files directly from disk is toast.

Features that sound like they would be useful, from your comments:
- A button that refreshes all scripts and headers used in a quest, if files with the same name are found in the file system;
- A way for library authors to bundle together multiple headers/scripts.

The changes may well require ZScript library authors to repackage their scripts, in order for them to be as easy to use as possible by other people in the future. I don't see the problem with this. A little pain now is worth a clean and easy way of bundling scripts into external libraries, making .qsts self-contained, and making it easy for quest authors to pick-and-choose libraries and quests to include in their own quests.

[ywkls]

The problem right now is that .qst file scripts cannot be recompiled at all if the quest author somehow deletes the wrong extra file from their computer (or upgrades to a new version.).

I don't know about anyone else, but what I do is keep a separate file for every script I write or plan to use some day in a separate folder labeled scripts, forever.

As for new versions, generally speaking; those don't come out very often and when they do; the person who wrote them usually knows enough to write the new one where it won't conflict with the old (or tells you what the conflicts/changes might be, so you can make sure everything you have works still).

If as you say, people are including files without even being aware of what files are involved, the situation is even more dire than I thought, since they might switch to a new computer, etc. and have no idea what external script packages, and what version of those script packages, are needed to get everything compiling again.

I personally use a lot of scripts without understanding all of their intricacies. That's mostly because I don't have the time to read and comprehend every line of code for 14 separate files that total over 160 KB of data.

I may be alone in this, but I've switched to a new computer once in the last decade. During that time, I was a member of the ZC community for 2 and a half years. And since I became active, most of the popular headers have received maybe one update each.

It's been my experience, though; that if you're using scripts regularly... you already know which ones you need to do a particular thing. So I'm not sure why anyone would be confused about what scripts they needed to import.

I'm happy to discuss quality-of-life features, but the ZScript ecosystem moving forward needs to include a solution to the above problem. "Import" reading files directly from disk is toast.

Why, exactly; is this?

As it stands now, importing each separate file every time you compile would be a heinous amount of work. Especially for those who keep every script in separate files.

Just as an example, one script file for a quest I'm currently testing imports over 40 separate files. Right now, the compiler automatically scans all those files and then loads the scripts into slots (if slots are already selected) or lets you do that (or change the order).

So unless I'm completely misunderstanding, I can't imagine that loading each file one at a time every time would be an improvement.

[ZoriaRPG]

The problem right now is that .qst file scripts cannot be recompiled at all if the quest author somehow deletes the wrong extra file from their computer (or upgrades to a new version.) If as you say, people are including files without even being aware of what files are involved, the situation is even more dire than I thought, since they might switch to a new computer, etc. and have no idea what external script packages, and what version of those script packages, are needed to get everything compiling again.

I'm happy to discuss quality-of-life features, but the ZScript ecosystem moving forward needs to include a solution to the above problem. "Import" reading files directly from disk is toast.

Congratulations: You've found the easiest way for the few remaining scripters to just walk away. You can't just change something fundamental like this, particularly when the entire community has been not only using the import directive like this for years, but that it was the advised way of handling multiple scripts; and I believe that even other developers advised this. The common scripters won't use import this way. They may not even update, because of it.

You simply cannot change a prime aspect of how the script system works without some very deep thought. There isn't even a need to do it, to preserve scripts. you can copy the resulting post-import buffer into a string and store it with the quest, with an 'Extract' button to copy it back to a file. I was going to do that anyway. You can also save scripts into buffers without changing this option, and you can add alternatives, and slowly mirate people over to a new system.

At the least, a system like this would need a dedicated API and an external compiler that sopported bugesting scripts fast, and easily.

Features that sound like they would be useful, from your comments:
- A button that refreshes all scripts and headers used in a quest, if files with the same name are found in the file system;
- A way for library authors to bundle together multiple headers/scripts.

The changes may well require ZScript library authors to repackage their scripts, in order for them to be as easy to use as possible by other people in the future. I don't see the problem with this. A little pain now is worth a clean and easy way of bundling scripts into external libraries, making .qsts self-contained, and making it easy for quest authors to pick-and-choose libraries and quests to include in their own quests.

(Emphasis, mine)

Again, no-one will repackage their scripts. The userbase can't even be bothered to fix script bugs as it is. More than half of the script authors aren't even around to do it any longer anyway. Script authors just do not care if users in the future will be able to use their stuff eaily. They care if they can easily use it, and if the intended user can do so. The majority of scripts are not created for general-user application.

Go post this on Pure. Ask the scripter community for a show of hands as to how many would repackage, how many will just not update, and how many will adapt. I think you'll find that this kind of new feature suggestion will be out in the wind with the tumbleweed. Just last week you complained that the Allegro developers want people to recode their programmes to fit their new API (ag5) and didn't make it compatible with Allegro 4. This is no different, and just as absurd, if not more absurd, given that there are about twenty people using the script engine regularly, and out of them, maybe one or two wouldn't care; and the rest wouldn't upgrade.

This effectively deprecates all ZScript code for 2.5. I won't support it, I won't advoocate it, and I wouldn't develop for it.

Given that there is a general desire to replace ZScript in the future, this is just madness. Wait for the new script engine, and then handle that however you want. Don't ruin the experience for the present users now, just to satisfy your wishes that a script file shouldn't be lost because a user is too foolish to keep a backup somewhere. The programme, and its authors should not tbe the ones accountable for users archiving their content, nor should that burden be placed on the scripting commumity, who at large have no need for this.

If you want to do this sort of thing as a user-settable option--flex supports different compiler modes, and this could be an optional mode--that's fine. I doubt many people will use it, but you cannot shift the paradigm now: It's far too late in the game to add new players. This is in effect, no different than breaking scripts by changing the number of parameters for a function, which neither I, nor @Gleeok support doing, and it is in fact, worse, as 99.5% of scripts use this feature, versus a small chance of a function refusing to compile.

Before you ask for links, or evidence, go post this on Pure. I don't really care if this forum isn't seeing any responses. The only time that people outside the four of us post here, is if I link something in Skype. Unfortunately, Pure is where you will get your real feedback.

In fact, that's a good point: If users are too lazy to read or post here, do you seriously think they are going to adapt to this kind of change?

P.S. FWIT, this would also mean, for me, going over 8MB of code, for one quest and rewriting it to fit the changes. I'd sooner publish the quest with its own ZC build as a standalone file. That's less work, and more reasonable than this kind of change. How much money do you want to wager than the consensus of the scripting community agrees?

[ZoriaRPG]

It would probably be a good idea to individually go over the additions that I, and that the script group members have proposed for std.zh.

I suppose including the other headers is workable, but I dread a conflict if they are imported by default. What I've been doing, is bundling the popular headers in the package with ZC, so that the user needn't download them, but they aren't imported by default.

I also had a mind to slit std_functions.zh into separate files, based on function category, to make reading through it easier.