ZScript additions for 2.51.

[ZoriaRPG]

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

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

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

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

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

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

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

(Emphasis, mine)

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

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

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

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

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

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

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

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