ZScript additions for 2.51.

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?

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?

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

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.

Gleeok wrote: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.

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.

DarkDragon wrote: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 [FONT=Courier New]import [/FONT]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.

DarkDragon wrote: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.

ZoriaRPG wrote:(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 [FONT=Courier New]import [/FONT]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?

ZoriaRPG wrote:(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 [FONT=Courier New]import [/FONT]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.

DarkDragon wrote: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.

DarkDragon wrote: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 [MENTION=42714]Gleeok[/MENTION] 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?

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

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.

ZoriaRPG wrote: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 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.

DarkDragon wrote: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. [MENTION=59858]Moosh[/MENTION] 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.

FYI I've created the poll here: http://www.purezc.net/forums/index.php?showtopic=71534

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

DarkDragon wrote: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: [MENTION=42509]Grayswandir[/MENTION] 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?

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!"

DarkDragon wrote: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.

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

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.

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.

DarkDragon wrote: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.

DarkDragon wrote: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.

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

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 wrote:

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.

ZoriaRPG wrote: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.

... walls of text ...

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.

I just posted a wall of text about this on Dark Dragon's related PureZC thread, 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.)

Gleeok wrote: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.

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.

Oh, you can make the ZC icon hot pink, that's fine!