PDA

View Full Version : ZScript additions for 2.51.



Gleeok
12-31-2016, 07:47 AM
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
12-31-2016, 03:17 PM
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
12-31-2016, 08:48 PM
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
01-02-2017, 08:03 PM
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
01-06-2017, 05:26 PM
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
01-06-2017, 05:30 PM
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
01-06-2017, 07:11 PM
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
01-06-2017, 07:32 PM
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
01-06-2017, 08:16 PM
(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
01-07-2017, 01:13 AM
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
01-07-2017, 01:20 AM
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?

DarkDragon
01-07-2017, 01:27 AM
Why, exactly; is this?

As I explained above, everything about a quest is currently self-contained within the .qst file -- except the ZScripts. If people lose the script files, or move to a new computer, or their hard drive fails, or they move on to a different project, and come back years later and want to modify their old quests (upgrade it to the latest features of ZC, or fix some bugs) -- they are screwed. Tilesets, SFX, subscreen layouts, etc etc are all currently stored in a self-contained .qst file. The scripts should be as well.


So unless I'm completely misunderstanding
Maybe? Did you see


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.


It's OK to be worried, and I'm interested in hearing your feedback, but I think much of it is change that sounds a lot scarier than it will actually be in practice.

DarkDragon
01-07-2017, 01:38 AM
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.



(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 (http://www.armageddongames.net/member.php?u=42714) 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?

To be honest, a lot of this sounds like "change is bad because it's change," rather than concrete and actionable concerns.

If the most commonly-used script libraries are bundled with ZC (which I think is a great idea) and are packaged correctly (which they will be, if bundled with ZC) the entire scipting system becomes a lot easier to use for the average quest author. The same goes for a system that allows the quest authors to pull in entire libraries of scripts and headers as a single package.

Finally keep in mind that what I've proposed here in the absolute worst case (because I agree with you that some convenience features are needed for users that edit their scripts in external editors; see my reply above) under this system authors would have to
1. the very first time they start a new quest, for each script library they want to use, click "import," and click on the folder they downloaded from Pure (or wherever) containing the script library they want to use (the same way they import tilesets, SFX, etc).
2. there is no step 2.
I have a hard time believing this will actually cause anybody to walk away, but I'm happy to hear your concerns.

ZoriaRPG
01-07-2017, 01:57 AM
To be honest, a lot of this sounds like "change is bad because it's change," rather than concrete and actionable concerns.

If the most commonly-used script libraries are bundled with ZC (which I think is a great idea) and are packaged correctly (which they will be, if bundled with ZC) the entire scipting system becomes a lot easier to use for the average quest author. The same goes for a system that allows the quest authors to pull in entire libraries of scripts and headers as a single package.

Finally keep in mind that what I've proposed here in the absolute worst case (because I agree with you that some convenience features are needed for users that edit their scripts in external editors; see my reply above) under this system authors would have to
1. the very first time they start a new quest, for each script library they want to use, click "import," and click on the folder they downloaded from Pure (or wherever) containing the script library they want to use (the same way they import tilesets, SFX, etc).
2. there is no step 2.
I have a hard time believing this will actually cause anybody to walk away, but I'm happy to hear your concerns.

The main issue, is that it increases the convenience of the script user, at the expense of the script developer. Given that most script users rely on the same handful of script devcelopers to make everything for them--hell, i should know, given how many scripts i deliver to users regularly--that's a major issue for script developers.

The other issue, is that changing how the directive works, breaks almost every existing script set out there. You just can't do that.

As I said, I don;t objedct to an additional command or directive to handle this. It might even be good to do; but changing the behaviour of the existing directive just seems like the worst way to handle this.

I would much rather include paths, and an include directive, to ease working with headers and libraries, just like in C. That would be something new, and would work with this model, without breaking the existing system. It would also be logical, to most programmers, whilst non-programmers could ignore it.

I also think you are hyper-complicating a problem that doesn't exist. Users aren;t complaining about how headers work. THey aren;t complaining about scripts not being stored with quests, and they don;t complain about needing to download headers and header sets. Most of the time, they flipping get a scripter to do all of their set-up for them, because they flain refuse to figure out how to compile a basic script, and do any basic set-up. at all. So, again here, you are considering the user of the scripts, rather than the people doing all of the work.

I know you have good intentions here, but you;ve been out of the scene for a very long time, and you need to minmgle with the users a bit and find out how things are done these days. I would honestly suggest mingling with the scripter Skype group, tossing ideas around there, and seeing what their reactions are to them. I can tell you for nothing, that FOUR main scripters provide almost all of the stuff used in quests these days, and I'm one of them. Moosh is another, and it's hard enough to get him to drop in here to post a critical bug report. When one of those main scripters looks at this, and would never want to use it, that is a 25% reduction in available scripting generation for the general commumnity, which is a rather large number.

If ZC had thousands of people using this code engine, and a much bigger pool of users, this might be far more practical, but proper include directives, and paths, just seem a better course of action. Hell, I have those on the 2.future planned feature list from a over year ago, and I would not object to them, again, as an addition to how things now work. Anything that expands how things work at present is good. Anything that changes how things work, is not so good,a nd probably unwise. Breaking compatibility with scripts IMO is no different than breaking compatibbility with quests.

DarkDragon
01-07-2017, 01:59 AM
FYI I've created the poll here: http://www.purezc.net/forums/index.php?showtopic=71534

DarkDragon
01-07-2017, 02:04 AM
The main issue, is that it increases the convenience of the script user, at the expense of the script developer.

This is the correct balance though, IMO. Script writers do very valuable work, but at the end of the day, quest players >> quest authors >> everyone else.

Also, I'm not sure where you're getting the idea that I'm out to break all existing scripts. All existing scripts will work fine, with the possible exception that, as a one-time setup, users would need to take old scripts and tell ZQuest about them (like they currently do with tilesets, loose tiles, or anything else). This could be as easy as hitting menu->Import and clicking on the PureZC .zip file containing all of loose script files.

Forcing users to manually "import" quests they want to use, inside a single script buffer, with no support for bundled external script libraries, no support for multiple script files, and no saving of the dependencies inside the .qst, is a crazy setup. It's only this way because ZScript was at first intended as a "quick hack" on top of ZASM, and nobody thought that scripting would take off the way it has, with people using multiple different libraries spanning a ton of external files.

Now that using scripts is more or less expected of a high-quality quest, the user experience should be streamlined, and that includes making it easier to get hold of useful quest libraries (by bundling with ZQ) and making it easier to work with script libraries inside of ZQ. There is a cost to any change, no doubt about it, but I'm really not seeing apocalyptic-level problems here (especially not compared to, say, switching entirely to AngelScript!)

ZoriaRPG
01-07-2017, 02:31 AM
This is the correct balance though, IMO. Script writers do very valuable work, but at the end of the day, quest players >> quest authors >> everyone else.

Also, I'm not sure where you're getting the idea that I'm out to break all existing scripts. All existing scripts will work fine, with the possible exception that, as a one-time setup, users would need to take old scripts and tell ZQuest about them (like they currently do with tilesets, loose tiles, or anything else). This could be as easy as hitting menu->Import and clicking on the PureZC .zip file containing all of loose script files.

Forcing users to manually "import" quests they want to use, inside a single script buffer, with no support for bundled external script libraries, no support for multiple script files, and no saving of the dependencies inside the .qst, is a crazy setup. It's only this way because ZScript was at first intended as a "quick hack" on top of ZASM, and nobody thought that scripting would take off the way it has, with people using multiple different libraries spanning a ton of external files.

Now that using scripts is more or less expected of a high-quality quest, the user experience should be streamlined, and that includes making it easier to get hold of useful quest libraries (by bundling with ZQ) and making it easier to work with script libraries inside of ZQ. There is a cost to any change, no doubt about it, but I'm really not seeing apocalyptic-level problems here (especially not compared to, say, switching entirely to AngelScript!)

Let me ask it to you this way: Why change the way it works at present, rather than adding this as an option to the programme, where the implementation is a decision that is up to the user?

I also think that your opinion on who is more important, in terms of support on scripting engine materials, is sort of unbalanced. If you annoy the people developing scripts, they'll just stop. That has been the steady course of things over the last few years. A large number of users who routinely created scripts for users, just abruptly stopped delivering, because it was too frustrating. That put the burden on the rest of us, and many of us are pretty much tiring of doing it too. If we stop delivering, then scripted quests will start falling off the map, save for wat we do for one-another, or make ourselves. Thus, if you want to ensure that uses are provided with script content, you need to keep the coders happy, as your primary priority.

Scripters already sacrifice a gigantic amount of time to provide the community with these materials. Saying that questmaker support is a higher priority with the script engine, than scripter support, isn;t going to win you any favours.

The other issue, I posted to the Pure poll, and relates to how people use the buffer, in general. I can only think of two users who keep more than one line in the buffer. Everything else, header, script, lists of constants, and otherwise, is called by import. Take a look at how my own library is organised:

http://github.com/ZoriaRPG/Backup_27JAN2016_RPG_zh-Main-Project/

This is not atypical: Grayswandir does precisely the same thing with his library sets.

In that set, the library files, functions, constants, and each component, is separated into an individual '.zlib' file, or '.zs' file, and called by importing one master 'RPG.zh' file from anywhere. Users do not only import headers. They import flipping everything using that directive.

Why not just add imort paths and a new directive? What is the actual loss in doing it that way?

DarkDragon
01-07-2017, 03:24 AM
It is a common misconception that more options == better. This is almost never the case, actually. In fact, adding more options often degrades the quality of a program, as it makes the program harder to use, harder to maintain, and harder to learn.

If a feature is broken, the answer is to fix it, not to have side-by-side well-designed and broken features. Of course, the cost of asking users to change how they use the broken feature must be assessed.

And to those not numbed to it, the ZScript library import system is broken. Imagine if new users were told that this was the procedure for importing tiles: "Download some tiles from the internet. Close ZQuest, open up Photoshop, and copy-paste all of the tile images together into one giant image. Be sure to get the order of the tiles just right, and the alignment! Otherwise things won't work and you will get a mountain of cryptic errors. Ok, now open up ZQuest. Go to a text command line and enter the following line: import_tile 'mytiles.png.' Don't forget to make a backup of this png and keep it with your quest, otherwise next time you open up your quest, nothing will work. Ok, that's it. Isn't that easy? And people say ZQuest is difficult to learn and use. Pshaw!"

ZoriaRPG
01-07-2017, 03:49 AM
It is a common misconception that more options == better. This is almost never the case, actually. In fact, adding more options often degrades the quality of a program, as it makes the program harder to use, harder to maintain, and harder to learn.

If a feature is broken, the answer is to fix it, not to have side-by-side well-designed and broken features. Of course, the cost of asking users to change how they use the broken feature must be assessed.

And to those not numbed to it, the ZScript library import system is broken. Imagine if new users were told that this was the procedure for importing tiles: "Download some tiles from the internet. Close ZQuest, open up Photoshop, and copy-paste all of the tile images together into one giant image. Be sure to get the order of the tiles just right, and the alignment! Otherwise things won't work and you will get a mountain of cryptic errors. Ok, now open up ZQuest. Go to a text command line and enter the following line: import_tile 'mytiles.png.' Don't forget to make a backup of this png and keep it with your quest, otherwise next time you open up your quest, nothing will work. Ok, that's it. Isn't that easy? And people say ZQuest is difficult to learn and use. Pshaw!"

Unfortunately, this is a case where everyone is not only 'numb' to it, but they expect it to work this way. It's a convenience, and a convention, that they are accustomed to having at their disposal.

Quite frankly, the present process for importing tiles is far more broken. Really, go try to explain how to import 8-bit tiles, set up level palettes to display them, and assign palette slots to anyone.

As a user, I would certainly prefer to have both options. It may not always be better, but it certainly can be a benefit.

DarkDragon
01-07-2017, 03:51 AM
Unfortunately, this is a case where everyone is not only 'numb' to it, but they expect it to work this way. It's a convenience, and a convention, that they are accustomed to having at their disposal.

I suppose if this is actually the case, the poll at PZC will bear it out. (And here "everyone" means quest authors, of course.)

DarkDragon
01-07-2017, 04:00 AM
Quite frankly, the present process for importing tiles is far more broken. Really, go try to explain how to import 8-bit tiles, set up level palettes to display them, and assign palette slots to anyone.

If you have ideas for how to improve it, start a new thread, and let's fix it!

SUCCESSOR
01-07-2017, 04:03 AM
I think the changes you are talking about will be a great improvement. I hate how it works now. Leaving something broken because a few find it convenient is silly.

ZoriaRPG
01-07-2017, 04:17 AM
If you have ideas for how to improve it, start a new thread, and let's fix it!

Feh. What it needs is some automated way to read the palette of the image that the user is ripping, and automatically store it, so that the imported tiles come out in some semblance of the original image.

Try doing it yourself, see if you can even remember how to do it, and you'll see what I mean.

I should note, as an anecdote, that the way you described ripping tiles is not far from how Solarus works. You list all the files with your tile sheets in a text document, then the programme reads them.


I suppose if this is actually the case, the poll at PZC will bear it out. (And here "everyone" means quest authors, of course.)

Clarify: Does this also mean that you are discounting the input from scripters?

The bottom line for me, is that if as you say, that you do not intend to break how it works now (ref: [...] 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 [...] ), that I do not object to adding in additional functionality.

I think that the very nature of import is somewhat broken. That isn't a standard directive, which is why I think an include directive would be welcome. I also think that stuff like IFDEF would be beneficial, as would any way to mask duplicate functions. If you're going to add in include-ish stuff, you should consider extern, and header to global class dereferencing in the process.

DarkDragon
01-07-2017, 04:25 AM
Clarify: Does this also mean that you are discounting the input from scripters?
No, of course not. What I mean is that the change is intended to be a positive for quest authors, and a slight burden to script authors. If instead it is a negative for quest authors (or a big burden to scripters) then it is a bad idea.



I think that the very nature of import is somewhat broken. That isn't a standard directive, which is why I think an include directive would be welcome. I also think that stuff like IFDEF would be beneficial, as would any way to mask duplicate functions. If you're going to add in include-ish stuff, you should consider extern, and header to global class dereferencing in the process.
I'm not against the idea, but I don't have a crystallized picture yet of how to deal with namespaces and symbol collision issues in a way that is functional and useful. I'd be happy to hear your ideas if you've thought about this (in a new thread, please!)

ywkls
01-07-2017, 04:39 AM
And to those not numbed to it, the ZScript library import system is broken. Imagine if new users were told that this was the procedure for importing tiles: "Download some tiles from the internet. Close ZQuest, open up Photoshop, and copy-paste all of the tile images together into one giant image. Be sure to get the order of the tiles just right, and the alignment! Otherwise things won't work and you will get a mountain of cryptic errors. Ok, now open up ZQuest. Go to a text command line and enter the following line: import_tile 'mytiles.png.' Don't forget to make a backup of this png and keep it with your quest, otherwise next time you open up your quest, nothing will work. Ok, that's it. Isn't that easy? And people say ZQuest is difficult to learn and use. Pshaw!"

When you put it that way, it does sound broken.


Unfortunately, this is a case where everyone is not only 'numb' to it, but they expect it to work this way. It's a convenience, and a convention, that they are accustomed to having at their disposal.

[...]

As a user, I would certainly prefer to have both options. It may not always be better, but it certainly can be a benefit.

I'd hate to have to start from square one, learning how to do something that at the moment is relatively simple to me.
I agree that having the option to do it one way or the other would probably be something everyone could agree on.

Gleeok
01-07-2017, 06:39 AM
... walls of text ...
This argument is stupid. I cannot believe there is so much text devoted to this argument. /drop the mic
..


I once created puzzle.qst. It had a few different puzzle games in it for fun; tetris, 16 puzzle, and a color block game. I lost the script files to it so I could never update it to 2.50. Instead it's in some really old alpha version like 3xx.

I was also creating another quest at the time "Dungeon Impossible 2" which was a working procedurally generated 8x8 Rubik's Cube where you controlled 2 Links at the same time and had to shift rooms in order to proceed. It would have been the most ridiculous mind-fucking daunting zc quest ever and it would have made LoH look like Six Flags. This was on the same computer as puzzle.qst, and so it is no more.

So, what am I getting at? Well, my main points...

-While making a quest I would of preferred to store all the scripts inside the quest file so long as it would be as convenient recompiling as just the "normal" standard way of writing "import myshiz.h" once and then just clicking the big red button every time I update it.

-As a previous avid scripter I would of preferred if the compiler was separate from ZQuest so I wouldn't have to keep ZQuest open all the time to tweak scripts and could just do it in ZC. This is the main reason I moved on to c++, because iteration time in ZC with scripting is damn slow. With c++ it takes 2 seconds to recompile, load assets, open an OpenGL window, etc.; with ZC you have to practice to get good at it, but then it still takes like 30 seconds.

-When releasing a quest I would prefer to have the option of storing an unmodified text copy in the quest file or not. While 1 MB (arguments sake) is not that much, a quest is not designed to have people open them up and extract things or recompile scripts.


PS: Why is everyone so keen on arguing with DD? It's a valid point. He probably could of wrote the code in the time it took to respond here so many times.

PPS: For the record, the angelscript system would do (would of done) all of the above.

Mitsukara
01-07-2017, 11:19 AM
I just posted a wall of text about this on Dark Dragon's related PureZC thread (http://www.purezc.net/forums/index.php?showtopic=71534#entry1013263), rambling about my own position on the subject, so now I'm going to try to break character and phrase a more succinct summary of the issue here instead:

People make quests in ZC for fun, because they cannot profit off of it (if that stops being a thing let me know, 'cause I'm dirt poor). Un-learning and re-learning how to do things you already knew how to do, is usually not fun.

Anything that overturns and replaces existing basic usage of ZScript will alienate existing scripters, and probably cause backwards compatability problems that are more difficult to implement than the (debatable?) convenience that might be gained by the changes.

If you go even further and drop backwards compatabiliy, you create an even bigger rift by doing so, and are effectively making a separate derivative engine, rather than something that would be consistently accepted as an improved update of the previous engine.

If, however, you keep supporting the old way of doing things, and focus instead on:
- Expanding the existing features/bypassing old limtations within the same setup,
- Adding alternative side-by-side setups that coexist with the previous setup so that the user can use either one,
- and bugfixing the existing features,
then you don't cause such divisiveness, because you're expanding the same product instead of trying to replace it.

ZC's community is small-ish, even on PureZC where most of the community goes. I understand wanting to grow that community, but making it harder for the existing core users to keep doing stuff would likely do more harm than good in terms of keeping a following. It also risks a situation where some people would wind up developing in 2.50.2 and ignoring your newer versions.

TL;DR: Adding stuff is great, but be very careful what you remove. Chances are very high that some people were actually using it, even if you think it's useless, cruft-y, or a kludge. If, however, you decide you don't care what they think, then you must at least accept that you may lose some users, and that you will almost certainly cause weird version usage rifts. : (

(I think maybe I failed on the succinctness, sorry.)

ywkls
01-07-2017, 11:52 AM
This argument is stupid. I cannot believe there is so much text devoted to this argument. /drop the mic
..


I once created puzzle.qst. It had a few different puzzle games in it for fun; tetris, 16 puzzle, and a color block game. I lost the script files to it so I could never update it to 2.50. Instead it's in some really old alpha version like 3xx.

I was also creating another quest at the time "Dungeon Impossible 2" which was a working procedurally generated 8x8 Rubik's Cube where you controlled 2 Links at the same time and had to shift rooms in order to proceed. It would have been the most ridiculous mind-fucking daunting zc quest ever and it would have made LoH look like Six Flags. This was on the same computer as puzzle.qst, and so it is no more.



I've actually had something like this happen to me too (though not with a scripted project) so I understand the difficulty.



-As a previous avid scripter I would of preferred if the compiler was separate from ZQuest so I wouldn't have to keep ZQuest open all the time to tweak scripts and could just do it in ZC. This is the main reason I moved on to c++, because iteration time in ZC with scripting is damn slow. With c++ it takes 2 seconds to recompile, load assets, open an OpenGL window, etc.; with ZC you have to practice to get good at it, but then it still takes like 30 seconds.


This is a valid point. Especially since the time to compile ZScript seems to get exponentially longer, the bigger your script file is. Having the compiler be separate from ZC in a way that it can choose what .qst file to send stuff to sounds like a solution everyone can support.



PS: Why is everyone so keen on arguing with DD? It's a valid point. He probably could of wrote the code in the time it took to respond here so many times.

PPS: For the record, the angelscript system would do (would of done) all of the above


After what he posted on PureZC, I understand it a bit better and most of my objections have been allayed.

DarkDragon
01-07-2017, 06:08 PM
PS: Why is everyone so keen on arguing with DD? It's a valid point. He probably could of wrote the code in the time it took to respond here so many times.

It's fine. At least people are posting more :) I guess I'm just lucky I didn't post a plan to change the color of the ZC icon (http://bikeshed.com/).

Mitsukara
01-07-2017, 09:43 PM
Oh, you can make the ZC icon hot pink, that's fine!

Gleeok
01-08-2017, 12:18 AM
What are you crazy?! Everyone knows the correct color for an icon is lime green.

Chris Miller
01-08-2017, 02:44 AM
Ecru is where it's at.

ZoriaRPG
01-08-2017, 04:26 AM
It's fine. At least people are posting more :) I guess I'm just lucky I didn't post a plan to change the color of the ZC icon (http://bikeshed.com/).

Rats, when I edited this to quote Gleeok, it ate my response.

I believe it was: The sad, or funny thing, is that we are likely to be forced to change the icon for the GPL releases.

I know I had something else in that response, but now I've forgotten what it was.



So, what am I getting at? Well, my main points...

(1) -While making a quest I would of preferred to store all the scripts inside the quest file so long as it would be as convenient recompiling as just the "normal" standard way of writing "import myshiz.h" once and then just clicking the big red button every time I update it.

(2) -As a previous avid scripter I would of preferred if the compiler was separate from ZQuest so I wouldn't have to keep ZQuest open all the time to tweak scripts and could just do it in ZC. This is the main reason I moved on to c++, because iteration time in ZC with scripting is damn slow. With c++ it takes 2 seconds to recompile, load assets, open an OpenGL window, etc.; with ZC you have to practice to get good at it, but then it still takes like 30 seconds.

(3) -When releasing a quest I would prefer to have the option of storing an unmodified text copy in the quest file or not. While 1 MB (arguments sake) is not that much, a quest is not designed to have people open them up and extract things or recompile scripts.

(4) PS: Why is everyone so keen on arguing with DD? It's a valid point. He probably could of wrote the code in the time it took to respond here so many times.

(5) PPS: For the record, the angelscript system would do (would of done) all of the above.
(numbering, mine)

For the sake of sanity, I'll respond to each paragraph, and point, first numbering them.

(1) I don't disagree with the idea, or the premise; merely with the implementation replacing the present import method. I would like to see this added, as a new directive. The idea of breaking how it now works, is not pretty. If the system somehow supported how it works now, and did this new stuff, that would also work, and I doubt anyone would complain, but look at the reactions, which are effectively as I predicted thus far.

That said, this is not the only way of handling storing scripts with the quest, if archival preservation is the most important factor. If header organisation is the key element, I think that an includes path and standard C include directives would work better. That way, the user can determine what headers each script would use, and those would be processed when that script is processed; which would require rewriting the compiler to do passes per script, and likely cause havoc with how global declarations are handled.

I've been down that road.

(2) Oh yes. That would be lovely, but as yet, it does not exist. A script debugger and a complete set of IDE kit would be fantastic. I that wish you could find the IDE that you made years ago, so that we could work with it.

(3) I agree. If we implement this in any regard, it needs to be an option, even if it is the default option.

(4) Well, when people are more keen on arguing that something is unwise, a bad idea, or are passionate about their dislike of it, than on seeing it implemented; then it is an indication that the idea needs revision, prior to implementation.

(5) True, however as I understand, the AS would be rn through a JIT compiler, and would not need the user to precompile it, just to test it, or check for errors. Presumably, it would have also included a more robust dev environment, to find syntactical (or logical, or other) issues, and correct them prior to running a quest. This is vastly different from the compiler halting from one bad keystroke, and needing to manually load files into the buffer on every fix-- an action that takes longer for the user to perform than the compiling itself.

In the end, it comes down to breaking script compatibility, as far as I'm concerned. That must be avoided at all costs. If we can avoid that, and we can implement a system that allows reading the files externally, I don;t care how they are embedded. I would however, worry about the number of scripts involved. How many buffers are you going to allocate? What if the user has 2,500 scripts? 500 header files? At present, that is not an issue. They can compile as many as they wish, as long as they all fit into the main buffer string at the end of the day.

Moreover, if you create a slot system, with one slot per file or one slot per script, then you artificially limit the number of single files involved. Flidd, my own engine uses hundreds of separate files. Because the packfile needs to know in advance how many slots are being saved, or read, a dynamic system isn't really feasible, and a static system would need to allocate a tremendous number of buffers, and could still fall short and be unable to load existing materials.

Then, you need some kind of datatype association. Using a filename extension is not the right way to handle this. I , and several other users do not use .z and .zh exclusively. In fact, .z is a horrible extension, as it is a filetype association with ZLIB compression. Thus, headers and scripts would need a token to identify what they are, and what slot type to occupy.

That could even be the cleanest way to handle this:
Use one generic buffer for any file imported that lacks a categorisation token. If a file has a token <ZHEADER>, load it into a header buffer, or if it has a token <ZSCRIPT>, load it to a script buffer. That way, you retain the present import capability, and expand it to allow using the additional buffers. The parser has the capability to read tokens like thse, and shift modes for any of its internal operations, or directives. You can separately define how import "filename" works if the parser finds specific tokens.

Gleeok
01-08-2017, 07:53 AM
Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

-DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
-ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
-See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

That's my 2 cents.

[edit]
I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).

ZoriaRPG
01-08-2017, 12:31 PM
Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

-DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
-ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
-See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

That's my 2 cents.

[edit]
I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).

No exclusion, certainly, but how would you instruct the parser as to what to store in each buffer? It needs some way to segregate headers, and scripts, to do what DD is suggesting.

I'm not even keen on disabling it by default. I can think of three separate ways to handle adding this feature without in any way impacting the existing operation of the import directive. ( I've separately posted all three in the thread.)

Thus far, a few suers have also asked for simultaneous support, and I don't know of any reason that we couldn't simultaneously support both modes of this. This allows users to adapt to, and shift to the new paradigm, without the fear of any older scripts ever breaking from the change. It also permits the most stubborn users to fall back on the present import method. Deprecating it slowly wouldn't really work, because that's the same outcome as disabling it now, and the user will always find old scripts that they want to use, which may rely on the old operation.

There are still users, right now, downloading, and using scripts from 2007-8. ... You know how fun it is to support that nonsense.

We can't support converting existing scripts from a dev end.

Beyond that, if a user mixes and matches scripts that work with the standard 2.5 import scheme, and new scripts, say, that come out after we did something like this that are designed to use this scheme, those would not get along together if the option is a boolean setting of new/old import method.

OTOH, If you use a parser directive token, or if you used a different directive token than import, then you can shift modes on the fly... That's another compelling reason to simultaneously support both, as otherwise you will create script incompatibility due to users mixing syntax generations, which would be bad. (-Cue Harold Ramis impression).

DarkDragon
01-08-2017, 03:09 PM
Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

-DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
-ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
-See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

That's my 2 cents.

[edit]
I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).

Sounds very reasonable to me.

ZoriaRPG
01-08-2017, 04:42 PM
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.


List as of now: http://pastebin.com/BgGn38TD

There're clearly going to be things in there that won't go into the ZC core, or may need to be modified first; and other things remain to be completed, but that is the present state of additions in 2.future.

DarkDragon
01-08-2017, 05:04 PM
The ones that I use the most often are stdExtra.zh (by MoscowModder) and ffcscript.zh, ghost.zh and tango.zh (by Saffith).


I have PMed MoscowModder asking for permission.

Are there any others? For instance, Moosh's FFC script has a lot of high ratings at Pure. Are there enemies or items that are very widely used (Pegasus Boots?)

ywkls
01-08-2017, 08:15 PM
I have PMed MoscowModder asking for permission.

Are there any others? For instance, Moosh's FFC script has a lot of high ratings at Pure. Are there enemies or items that are very widely used (Pegasus Boots?)

If you want some suggestions for other commonly used individual scripts, there are quite a few available. (And many most players expect to see in a quest these days.)

Here's a few samples.

Item Pickup Message (http://www.purezc.net/index.php?page=scripts&id=72)- Probably the most basic of basic scripts, but something not built into ZC.

Item Bundle Pickup Script (http://www.purezc.net/index.php?page=scripts&id=17)- Lets you pick up more than one item at once.

I don't know how easy Moosh's NPC script is to use, to be honest. I wrote one myself, but it's just a slight rewrite of scripts that others have submitted.

The only working Pegasus Boots script I know of is here (http://www.purezc.net/index.php?page=scripts&id=159). It was created for me by special request and is mostly free of bugs. (You can get Link to face the wrong direction while using them, which leads to some odd graphical errors.)

A couple of fairly easy scripts to apply to enemies are the Ball and Chain (http://www.purezc.net/index.php?page=scripts&id=33) and the Big Enemy (http://www.purezc.net/index.php?page=scripts&id=115) scripts. (I should note that Big Enemy is the way to do things only if a scripter doesn't know how to use ghost.zh.)

The database at PureZC has a wide variety of enemy scripts. I'd suggest you download the relevant example quests and try them out. Some may require rewrites to match the behaviors of the original foes, though.

There is also the Enemy of the Month contest at PureZC, which has had a lot of unique foes show up over the course of its lifetime. These have videos of the enemies in action and should still have quests available to download to try them out. (Some links may have expired, but generally; the authors of those scripts are still around.)

There's also some scripts that aren't int PureZC's script database, but which are generally available. For example, the Moving Platforms and Hole/Lava scripts by Mero/Tamamo are available at PureZC, but many people have had trouble getting them to work.

I know ZoriaRPG has a fixed version floating around somewhere (I think Tamamo does too, but I'm not sure); but there are others which are similar and easier to implement and not in the database. (The alternates were a Moving Platform script by Moosh and a Hole/Lava script by MoscowModder that was a modification of an existing script which he'd forgotten he'd posted when I mentioned it a while back.)

There are also some that let you make a trading sequence, not in the database. This (http://www.purezc.net/forums/index.php?showtopic=65488&hl=) is one.

I'm sure that there are more examples, but that's all I could come up with for now.

DarkDragon
01-08-2017, 08:18 PM
Thanks! That's very helpful.
By the way, do you know how I can get in touch with Mero and aaa2? They are apparently banned on Pure...

ywkls
01-08-2017, 08:42 PM
Thanks! That's very helpful.
By the way, do you know how I can get in touch with Mero and aaa2? They are apparently banned on Pure...

Mero is Tamamo here on AGN. I don't know about aaa2, that's before my time. What script did they write?

(Also, there are several useful scripts that I've written, but I hesitate to promote them for inclusion with new quest packages.)

ZoriaRPG
01-09-2017, 01:47 PM
Thanks! That's very helpful.
By the way, do you know how I can get in touch with Mero and aaa2? They are apparently banned on Pure...

It seems that you want to provide Preloaded Scripted Quest Templates. If so, I have already been working on that, and it's on the 2.future plan list. Many of the components for that are done, and those that are unfinished are either partially done, or shouldn't be terribly hard to complete. There was never any consensus on this though.

What I effectively wanted to provide, were a preloaded Gameboy type scripted quest pack, and a Z3-esque preloaded scripted quest pack, so that the user could load one of those, and just place everything using the editor, without needing to worry about adding scripts unless they later want to expand it.