ZScript additions for 2.51.

[DarkDragon]

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]

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]

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]

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]

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]

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

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

[ywkls]

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]

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.

[Mitsukara]

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