User Tag List

Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 42

Thread: ZScript additions for 2.51.

  1. #11
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by DarkDragon View Post
    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?

  2. #12
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    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.

  3. #13
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    Quote Originally Posted by ZoriaRPG View Post
    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.

  4. #14
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by DarkDragon View Post
    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.

  5. #15
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%

  6. #16
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    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!)

  7. #17
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by DarkDragon View Post
    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_27...-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?

  8. #18
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    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!"

  9. #19
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by DarkDragon View Post
    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.

  10. #20
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    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.)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social