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

[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.

[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.

[DarkDragon]

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.

[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.