20 replies to this topic

[DarkDragon]

Currently in ZQuest, the process for including third-party assets (tilesets, sound effects, etc) works like this:

 - You download the tileset, etc. from the PureZC database;

 - Inside your quest, you "import" the desired assert.

 

Once imported, the assert is embedded inside the .qst file. This means that you can copy the .qst file to another computer, re-download it from the QDB if you want to revise the quest later, etc. and all of the assets are self-contained.

 

The two exceptions are large music files (excluded for space reasons) and ZScripts. The process for including third-party scripts is currently

- You download the scripts from the PureZC database;

- Inside your quest, you create a script buffer and "import" all of the scripts you want to use;

- The ZScript compiler reads the external scripts from your hard drive when you go to compile the scripts.

 

In particular, the libraries are *not* embedded inside your .qst. This means that if you move the .qst to a new computer, lose track of the script files you used before, upgrade the scripts to a new version, etc. it is possible that your .qst gets into a state where the scripts no longer work.

 

 

I've been thinking about solutions for this, and my proposal is to harmonize ZScripts with the way other assets are handled. Instead of creating a script and writing "import foo.zh" you would download the ZScript library from the database, and then tell ZQuest that your quest uses that library. The library code is then read into the .qst file and embedded there, and persists even if you move the .qst file or accidentally delete/change the downloaded script libraries.

 

I've been told this change could be negative/disruptive, so wanted to gather your opinion. Assume that the details are worked out so that

 - it is still easy to edit your own scripts using an external text editor, and have those changes reflected in your quest;

 - there is a way to upgrade imported ZScript libraries to newer versions, if the library author releases a fix/upgrade;

 - it is still possible to use all of the scripts currently in the QDB (there may be ~5 minute setup cost (total) getting existing scripts imported into your existing quest). New scripts created after this change would be bundled up into single-file libraries (like tilesets are bundles of tiles) and importable with a single click.

 

Thanks!

-DD

Edited by DarkDragon, 07 January 2017 - 12:58 AM.

[Timelord]

One thing that is not clear here, is what would occur when a script file was set up like this, which is typical.

 

Entrire contents of buffer:

import "myscripts.z"

myscripts.z text file contents:

import "std.zh"
import "ghost.zh"
import "weapons.z" //contains its own imports, and many scripts
import "ghosted_npcs.z"
import "animations.z" //scripts plus library functions
import "music_ffcs.z"
//and a long list of others.

That is the trend. I can only think of two users who keep all of their script contents in the buffer. Both of them import headers, but most users import headers, and scripts, and the files that they call also import other files.

Edited by ZoriaRPG, 07 January 2017 - 01:17 AM.

[DarkDragon]

You should think of it like importing sound effects, or loose tiles. For each script library you want to include, you download it from the QDB, then inside ZQuest, click on menu->Import and then click on the file you downloaded. This is a one-time setup cost when you start a new quest. ZQuest compiles all libraries you imported, and you can go straight to assigning scripts to slots.

 

If you have a standard bundle of libraries that you want to use in several different quests, you could create your own "bundle" library that contains all of these, and then just import that "bundle" library once into all of your quests (like you can assemble loose tiles into a tileset). I'm not sure this is the best workflow, though (I'd think it's better to cherry-pick the high-level libraries that you need on a per-quest basis, rather than including absolutely everything, since ZScript will have to compile everything you import, just like the current functionality.)

Edited by DarkDragon, 07 January 2017 - 01:30 AM.

[ywkls]

You should think of it like importing sound effects, or loose tiles. For each script library you want to include, you download it from the QDB, then inside ZQuest, click on menu->Import and then click on the file you downloaded. This is a one-time setup cost when you start a new quest. ZQuest compiles all libraries you imported, and you can go straight to assigning scripts to slots.

 

If you have a standard bundle of libraries that you want to use in several different quests, you could create your own "bundle" library that contains all of these, and then just import that "bundle" library once into all of your quests (like you can assemble loose tiles into a tileset). I'm not sure this is the best workflow, though (I'd think it's better to cherry-pick the high-level libraries that you need on a per-quest basis, rather than including absolutely everything, since ZScript will have to compile everything you import, just like the current functionality.)

 

Okay, I think I understand what you're getting at now a little better than before.

 

Some of the concerns that I have are actually related to the file size issue that you mentions earlier. Some of the scripts for quests that now exist are inordinately large. (I know of one that's over 100,000 lines of code.) So, wouldn't have the script embedded with the quest increase the file size by whatever amount of information is stored in that script file?

 

 

One thing that is not clear here, is what would occur when a script file was set up like this, which is typical.

 

Entrire contents of buffer:

import "myscripts.z"

myscripts.z text file contents:

import "std.zh"
import "ghost.zh"
import "weapons.z" //contains its own imports, and many scripts
import "ghosted_npcs.z"
import "animations.z" //scripts plus library functions
import "music_ffcs.z"
//and a long list of others.

That is the trend. I can only think of two users who keep all of their script contents in the buffer. Both of them import headers, but most users import headers, and scripts, and the files that they call also import other files.

 

I completely agree with this. Although in my case, I generally do store all my scripts in one file, but when going to the buffer I just type import "myscripts.z" or whatever. However, many of the general users utilize the format ZoriaRPG refers to.

 

 

 - it is still easy to edit your own scripts using an external text editor, and have those changes reflected in your quest;

 - there is a way to upgrade imported ZScript libraries to newer versions, if the library author releases a fix/upgrade;

 - it is still possible to use all of the scripts currently in the QDB (there may be ~5 minute setup cost (total) getting existing scripts imported into your existing quest). New scripts created after this change would be bundled up into single-file libraries (like tilesets are bundles of tiles) and importable with a single click.

 

So, would this mean that scripts imported with this method would automatically update if those files were changed?

Another concern is actually related to the way that Music and SFX are embedded, since there is currently no way to export them if you want to. Having a way to export your scripts would be essential.

 

A problem I can foresee with this is that a lot of script authors may not necessarily want to have their scripts available for general use. (Which the ability to export any imported scripts would open up.) The primary reason for this is often the fact that their scripts are hardcoded, the setup process is incredibly complex or they don't feel like explaining for the billionth time how to do something that they find incredibly simple.

 

I used to respond more often to script requests myself, but I found the endless garbled requests off-putting at times and just laughable at others. I tend to respond these days whenever there is a script that I feel that I might use one day.

[Timelord]

 

A problem I can foresee with this is that a lot of script authors may not necessarily want to have their scripts available for general use. (Which the ability to export any imported scripts would open up.) The primary reason for this is often the fact that their scripts are hardcoded, the setup process is incredibly complex or they don't feel like explaining for the billionth time how to do something that they find incredibly simple.

 

I used to respond more often to script requests myself, but I found the endless garbled requests off-putting at times and just laughable at others. I tend to respond these days whenever there is a script that I feel that I might use one day.

 

There's also that point. Many scripters, although I do not agree with them, like to keep all of their code private/secret. Some go out of their way to ensure that it cannot be recovered, or read by the user. It's a point that I hadn't even considered, because I release everything to the public.

 

I also think this should be in scripting discussion, not general ZC.

 

That sums up my feeling on script requets, too. I typically fulfill requests now, if they are short, clear, and don't need me to nursemaid them; if they seem something I'd use; or if the substance of the request interests me.

 

Even the simplest stuff though, the user almost always wants, needsm or demands that I set it up for them; or after they try to set it up and fail, they come to beg me to do it. I don't mean compiling it...I mean the most basic set-up. Only a few questmakers that I can name never do this, and they are the ones that would also never need to ask. The bottom line is that the typical user may have no use for this type of feature.

 

I worry that existing scripts that expect to read files from disc, will break, and that it will hinder script development, if you can't simply recompile all changes to file son-disc with one button press. If it requires rewriting scripts, I do not expect that many, if any, scripters will want to, or bother doing, the required changes.

 

Scripts that exist now, that rely on importing from disc, will break; no-one will update them, and it will only creae even more user confusion when they follow the directions and the directrions become wrong by this change.

 

These are serious issues that necessitate a valid plan, to circumvent, and avoid.

Edited by ZoriaRPG, 07 January 2017 - 02:10 AM.

[DarkDragon]

Some of the concerns that I have are actually related to the file size issue that you mentions earlier. Some of the scripts for quests that now exist are inordinately large. (I know of one that's over 100,000 lines of code.) So, wouldn't have the script embedded with the quest increase the file size by whatever amount of information is stored in that script file?

 

Good question. If the average line length is about a dozen characters, that's about 1 MB of extra size. Quests currently run from about 5-20 MB so it is a nontrivial increase in size. It might make sense to compress the text within the .qst using zlib if it becomes large (and come to think of it, this might make sense for the compiled ZASM too.)

 

I completely agree with this. Although in my case, I generally do store all my scripts in one file, but when going to the buffer I just type import "myscripts.z" or whatever. However, many of the general users utilize the format ZoriaRPG refers to.

My feeling is that this mode of working with scripts should be supported, but discouraged, with authors in the future encouraged to cherry-pick the libraries they want to include (just as currently, you don't throw every loose tile you've ever downloaded into a giant tileset, but rather group commonly-used tiles into thematic tilesets like Pure, plus some extra quest-specific loose tiles.)

 

since there is currently no way to export them if you want to. Having a way to export your scripts would be essential.

I could not agree more! In fact, if you post an issue on GitHub asking for support for exporting SFX, I will get around to it (eventually ).

 

A problem I can foresee with this is that a lot of script authors may not necessarily want to have their scripts available for general use.

Oof. I honestly am not sure how I feel about this issue. Back in the day, when we were discussing opening the ZC source, there was a *lot* of angst about the fact that quest encryption was effectively going to be disabled. Authors were very concerned about others "stealing" their work, or copying a quest, making tiny changes, and re-releasing it as their own; but in the end the source was opened anyway and (as far as I know) there have not been many cases of these kinds of shenanigans.

 

One solution, if authors really do not want to let others see their scrips, is to compile the ZScript into ZASM, delete all ZScripts from the quest, and then publish the stripped quest. (Of course, they are then out of luck if they themselves ever lose access to their original, unstripped quest...)

I also think this should be in scripting discussion, not general ZC.

 

I want the poll here, where end-users of scripts see it, and not just script developers.

[ywkls]

There's also that point. Many scripters, although I do not agree with them, like to keep all of their code private/secret. Some go out of their way to ensure that it cannot be recovered, or read by the user. It's a point that I hadn't even considered, because I release everything to the public.

 

I also think this should be in scripting discussion, not general ZC.

 

That sums up my feeling on script requets, too. I typically fulfill requests now, if they are short, clear, and don't need me to nursemaid them; if they seem something I'd use; or if the substance of the request interests me.

 

Exactly. I generally make mine open and will provide them if asked. I also occasionally submit things to the database here. There are some things, though; which are simply beyond the average user; like 600 KB of scripts or more which runs a specialized engine that does things ZC was never meant to do.

 

And there are plenty of others which scripters get tired of doing, like combining global scripts or fixing scripts that are years old and probably shouldn't still be used anyways. (Like the moving platform and hole/lava scripts by Mero/Tamamo, which though broken are still the most requested scripts to be fixed.)

 

Also, on requests; the more work I would have to do... the less likely I am to respond. I've offered my help freely to quests makers at least twice, but even then; they'd occasionally ask for things that I'd have to admit were beyond my ability.

 

I don't mind doing requests, but since most users can't even get separate portions of a global script to work together properly; I'm not sure that this would make this easier for them.

Edited by ywkls, 07 January 2017 - 02:12 AM.

[Timelord]

Good question. If the average line length is about a dozen characters, that's about 1 MB of extra size. Quests currently run from about 5-20 MB so it is a nontrivial increase in size. It might make sense to compress the text within the .qst using zlib if it becomes large (and come to think of it, this might make sense for the compiled ZASM too.)

 

 

My feeling is that this mode of working with scripts should be supported, but discouraged, with authors in the future encouraged to cherry-pick the libraries they want to include (just as currently, you don't throw every loose tile you've ever downloaded into a giant tileset, but rather group commonly-used tiles into thematic tilesets like Pure, plus some extra quest-specific loose tiles.)

 

 

I could not agree more! In fact, if you post an issue on GitHub asking for support for exporting SFX, I will get around to it (eventually ).

 

 

 

Oof. I honestly am not sure how I feel about this issue. Back in the day, when we were discussing opening the ZC source, there was a *lot* of angst about the fact that quest encryption was effectively going to be disabled. Authors were very concerned about others "stealing" their work, or copying a quest, making tiny changes, and re-releasing it as their own; but in the end the source was opened anyway and (as far as I know) there have not been many cases of these kinds of shenanigans.

 

One solution, if authors really do not want to let others see their scrips, is to compile the ZScript into ZASM, delete all ZScripts from the quest, and then publish the stripped quest. (Of course, they are then out of luck if they themselves ever lose access to their original, unstripped quest...)

 

 

 

I want the poll here, where end-users of scripts see it, and not just script developers.

 

DD, most of the scripters only read the scripting forum regularly. At the least, it needs a cross link.

 

Edit: Cross-linked.

 

P.S. I also think that the notion of 'stealing scripts' is absurd, but some people do want to hide easter eggs and such. I advise them, to do what you advised, if they are that serious about it. Compile the ZASM, and assign the ZASM to a slot. I've even (rarely) made ZASM-specific code files for a few select users to do bizarre things that the ordinary ZScript syntax doesn't facilitate.

Edited by ZoriaRPG, 07 January 2017 - 02:21 AM.

[ywkls]

My feeling is that this mode of working with scripts should be supported, but discouraged, with authors in the future encouraged to cherry-pick the libraries they want to include (just as currently, you don't throw every loose tile you've ever downloaded into a giant tileset, but rather group commonly-used tiles into thematic tilesets like Pure, plus some extra quest-specific loose tiles.)

 
I usually try to discourage this sort of thing myself, since I find it easier to detect bugs if I'm using one file.
 
The problem is that many of the things which quest authors want to do aren't supported by any one script header. Instead, they gather scripts from all sorts of places. These may be requests posted in the forums here, PMs, old script topics, or files generously provided to them by others.
 
Another problem is that since they have so many varied sources, the scripts in question are often not designed to work together. Getting them to do so is yet another hurdle.
 
The third problem is that the scripts that they're using may work, but be so out of date or undocumented that the scripters today can't really help them figure out how to get them to function.
 

I could not agree more! In fact, if you post an issue on GitHub asking for support for exporting SFX, I will get around to it (eventually  )

 
Exactly how would I do that? I've never used GitHub.
 

Oof. I honestly am not sure how I feel about this issue. Back in the day, when we were discussing opening the ZC source, there was a *lot* of angst about the fact that quest encryption was effectively going to be disabled. Authors were very concerned about others "stealing" their work, or copying a quest, making tiny changes, and re-releasing it as their own; but in the end the source was opened anyway and (as far as I know) there have not been many cases of these kinds of shenanigans.
 
One solution, if authors really do not want to let others see their scrips, is to compile the ZScript into ZASM, delete all ZScripts from the quest, and then publish the stripped quest. (Of course, they are then out of luck if they themselves ever lose access to their original, unstripped quest...)

I generally feel like ZoriaRPG and don't restrict any of my scripts.
However, there are some things that I know for sure the average user wouldn't be able to comprehend easily. (In some cases, I wrote it and I still don't entirely understand it.) 

 

I've shared this topic with the scripting Skype group which ZoriaRPG started a while back, so they'll know it exists.

[DarkDragon]

Head here: https://github.com/A...aClassic/issues

[ywkls]

Like so?

Spoiler

https://github.com/A...assic/issues/40

[Timelord]

 [...] since I find it easier to detect bugs if I'm using one file.
 

 

That's pretty subjective. You also read faster than Clark Kent, whilst most of us find it far easier to manage large sets of small files, instead of one large one. You should have a look at the ZC source, and tell me how much sense it makes as one huge file. Back int he day, that is how we were forced and required to maintain code. Thank goodness that it is not longer mandatory.

 

I honestly have no idea how you do this.

Edited by ZoriaRPG, 07 January 2017 - 03:22 AM.

[ywkls]

That's pretty subjective. You also read faster than Clark Kent, whilst most of us find it far easier to manage large sets of small files, instead of one large one. You should have a look at the ZC source, and tell me how much sense it makes as one huge file. Back int he day, that is how we were forced and required to maintain code. Thank goodness that it is not longer mandatory.
 
I honestly have no idea how you do this.

 
So,,, I'm super-script-man? (Insert your own joke here.)
 
In all seriousness, yes; I do read faster than most people I know.
 
I may look at the ZC Source, now that someone has finally gotten it to compile.
 
Also, for those concerned with this... the topic which spawned this one.
 
http://www.armageddo...itions-for-2-51

 

I'm linking this so people who come across this poll here will know why this came up in the first place.

 

I feel as if I should respond to that thread on AGN again, though... since it doesn't feel right doing so here. You're making me participate there more, so I guess that's good?

[Deedee]

My concerns lie, not with quest building... but with script testing. See, it's already annoying enough to make an entire quest file just to test it, but having to import each header, subscript, etc... manually, is more work and less speed, for the gain of regaining loss. I have no problems with having a way to regain your scripts... But they should either A: have their own encoding/password, to prevent people from learning of the existence of the scripts (have it be like the cheat code menu, only the "option" shows up even if you don't have any encoded stuff. This allows people to hide the existence of stuff like superbosses and bonus dungeons in quests where they don't want that knowledge revealed. And yes, people do this), B: be optional (I recommend this the most), so people can use the current, faster way instead of being limited to manually importing each, and/or C: save the entire script once you import it into ZQuest so that it's still regainable, but does not sacrifice the current way of doing so while being automatic (this, again, should require it's own password).

​What this proposed change is, is basically removing the faster way of doing things, because scripters apparently can't save their script and back them up (if up the quest, what's to say they can't back up the quest itself?  Are they that unorganized?). And there is nothing stopping a person from simply rewriting or redownloading the scripts again. Quest backups exist. I'm not against this "new way", I think it could be great and easier for the casual user. However, I am against removing the old way, just because people can't back their stuff up. I'd like the faster way that doesn't take 5 minutes to set up to remain, since inconveniences like that discourage my creative/testing process.

[Mitsukara]

EDIT: I wrote another shorter post in the debate about this same subject over on AGN, going straight for the overall design philosophy issues, whereas the post below deals more with my personal experience.

 

Currently, a quest file does retain the behaviors of a compiled script within the actual .qst file; quest makers don't need to include the script files with the quest when they distribute it, just the .qst file, and it will keep all the scripted behaviors from when the creator last compiled them. So it seems like the data IS being stored in the .qst file, but probably encrypted somehow, in a way where it can't export the stuff that it's already compiled, only what it stores in the buffer.

 

For my quest, I made a very long global that goes in the buffer, but it seperately imports each FFC script and item script, of which there's somewhere around 100. If I had to manually re-import those every time I needed to test, I wouldn't have gotten anywhere.

 

An actual functionality problem I've also noticed is that if a global script is too long (my global is a bit over 8000 lines long, and it's right under the line to cause this problem)- is using too many ZASM commands I think? Basically, if I put in too many things for it to do- then the quest will freeze. However, things that are imported as FFC scripts and Item scripts have no impact on this length; whereas things that are imported as functions, or things that are stored directly in the global in the buffer, DO cause this problem.

 

But aside from that issue, just in general, I don't think what you're proposing sounds very convenient or all that backwards-compatability friendly (for scripters, that is), unfortunately. Instead, I would advocate for some other means of being able to export the already-compiled zscript code from a quest, since it's obviously storing the information in some format in order to keep using it. If possible, this would also still allow quest makers to keep their scripts secret if they so desired, by passwording the quest (although technically I think there was some way to crack passwords, I never really looked into that).

 

Personally, I already give away all my scripts (I included them all in a 'support pack' file you can download next to my quest, along with the music, a goofy instruction manual I put together, and so on), so concealing the scripts isn't a big deal for me... but I do think that needing to manually import everything, or needing to keep everything in the buffer, would really suck, and cause problems for many scripters. More problems than it would solve. : (

 

More generally regarding major facelifts to ZScript functionality: I think expanding the existing capabiilties would be great, and I think adding extra options would be great, and bugfixing is almost always good; but with anything that overturns basic stuff about how users script, and disables them from doing it the way they've been doing it... I think that risks alienating the (kinda smallish) core of people who've learned to write ZScript, without necessarily attracting any more new people than before to the project. These users don't have the existential need to adapt to arbitrary changes the way a professional programmer might, nor the profit incentive to do so... people write zscript stuff for fun, as a hobby, and the more they have to un-learn and re-learn to accomplish the same stuff, the less fun it gets, and the less they might get done.

 

For minor stuff like weird bugs that stop working, that's fine- I don't object to needing to put a different map number for SetComboSolid in future ZC versions because the old number was one off from how everything else is formatted, which was a recent bugfix- but I'd advise a lot of caution about completely replacing basic behaviors of ZScript. Personally, the growth I'd rather see in ZC is mostly expanding the existing capabilities of ZScript and the ZQuest editor. I would also be open to seeing new options for how to do things, so long as such additions can coexist with the old ways, rather than replacing them.

 

For some context, I don't say this as someone who's been scripting for all that long- I didn't even start really learning ZScript until 2014. I've only made one quest in this that I've actually finished. But it would knock the wind out of my sails to start over to try to make anything else, rather than being able to build off of what I already know how to do... I'm a lot less inclined to make another quest if it would mean starting from scratch. (In such a case I might even consider building a quest in 2.50.2 and ignoring new versions, if it was the only way to utilize my existing familiarity.)

 

TL;DR: I would be okay with this if it were available as a separate option alongside the old way of doing it, but I'm not happy about the notion of removing the old way.

Edited by Mitsukara, 07 January 2017 - 10:30 AM.