EDIT: I wrote another shorter post in the debate about this same subject over on AGN, going straight for the overall design philosophy issues, whereas the post below deals more with my personal experience.
Currently, a quest file does retain the behaviors of a compiled script within the actual .qst file; quest makers don't need to include the script files with the quest when they distribute it, just the .qst file, and it will keep all the scripted behaviors from when the creator last compiled them. So it seems like the data IS being stored in the .qst file, but probably encrypted somehow, in a way where it can't export the stuff that it's already compiled, only what it stores in the buffer.
For my quest, I made a very long global that goes in the buffer, but it seperately imports each FFC script and item script, of which there's somewhere around 100. If I had to manually re-import those every time I needed to test, I wouldn't have gotten anywhere.
An actual functionality problem I've also noticed is that if a global script is too long (my global is a bit over 8000 lines long, and it's right under the line to cause this problem)- is using too many ZASM commands I think? Basically, if I put in too many things for it to do- then the quest will freeze. However, things that are imported as FFC scripts and Item scripts have no impact on this length; whereas things that are imported as functions, or things that are stored directly in the global in the buffer, DO cause this problem.
But aside from that issue, just in general, I don't think what you're proposing sounds very convenient or all that backwards-compatability friendly (for scripters, that is), unfortunately. Instead, I would advocate for some other means of being able to export the already-compiled zscript code from a quest, since it's obviously storing the information in some format in order to keep using it. If possible, this would also still allow quest makers to keep their scripts secret if they so desired, by passwording the quest (although technically I think there was some way to crack passwords, I never really looked into that).
Personally, I already give away all my scripts (I included them all in a 'support pack' file you can download next to my quest, along with the music, a goofy instruction manual I put together, and so on), so concealing the scripts isn't a big deal for me... but I do think that needing to manually import everything, or needing to keep everything in the buffer, would really suck, and cause problems for many scripters. More problems than it would solve. : (
More generally regarding major facelifts to ZScript functionality: I think expanding the existing capabiilties would be great, and I think adding extra options would be great, and bugfixing is almost always good; but with anything that overturns basic stuff about how users script, and disables them from doing it the way they've been doing it... I think that risks alienating the (kinda smallish) core of people who've learned to write ZScript, without necessarily attracting any more new people than before to the project. These users don't have the existential need to adapt to arbitrary changes the way a professional programmer might, nor the profit incentive to do so... people write zscript stuff for fun, as a hobby, and the more they have to un-learn and re-learn to accomplish the same stuff, the less fun it gets, and the less they might get done.
For minor stuff like weird bugs that stop working, that's fine- I don't object to needing to put a different map number for SetComboSolid in future ZC versions because the old number was one off from how everything else is formatted, which was a recent bugfix- but I'd advise a lot of caution about completely replacing basic behaviors of ZScript. Personally, the growth I'd rather see in ZC is mostly expanding the existing capabilities of ZScript and the ZQuest editor. I would also be open to seeing new options for how to do things, so long as such additions can coexist with the old ways, rather than replacing them.
For some context, I don't say this as someone who's been scripting for all that long- I didn't even start really learning ZScript until 2014. I've only made one quest in this that I've actually finished. But it would knock the wind out of my sails to start over to try to make anything else, rather than being able to build off of what I already know how to do... I'm a lot less inclined to make another quest if it would mean starting from scratch. (In such a case I might even consider building a quest in 2.50.2 and ignoring new versions, if it was the only way to utilize my existing familiarity.)
TL;DR: I would be okay with this if it were available as a separate option alongside the old way of doing it, but I'm not happy about the notion of removing the old way.
Edited by Mitsukara, 07 January 2017 - 10:30 AM.