ZScript additions for 2.51.

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

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

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

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

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

[ZoriaRPG]

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.

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

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

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

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

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

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

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

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

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

(numbering, mine)

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

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

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

I've been down that road.

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

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

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

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

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

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

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

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

[Mitsukara]

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

[Gleeok]

What are you crazy?! Everyone knows the correct color for an icon is lime green.

[Chris Miller]

Ecru is where it's at.

[Gleeok]

Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

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

That's my 2 cents.

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