Honestly, if people want to do a rewrite as ZC v3.x, backward compatibility is going to take a hit one way or another. I was originally in favour of continuing 2.xx development, and allowing a rewrite (3.0) to be clean, possibly working on platform stability in future 2.x updates, and working out some way to make a 2.x quest 'player' in the 3.0 engine, that handles all these quirks directly through new, clean code.
The alternative is a big case statement that reads the quest header, and does A if it's 3.x, or B if it's 2.x, for just about everything.
There's no reason that 2.x has to die for this to work, and there's no reason to abandon the community using 2.x to allow a rewrite. I don't really think tha tthe userbase has ever really been consulted on any of this, and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.
An important factor, is that ZC is no longer the only game in town. I'm unsure if
@
DarkDragon
has looked at the Solarus engine. IMO, that is the right direction for ZC3. Every object in Solarus is scripted... If you went that route,
and you had easy to use attribute editors so that scripting is not a mandatory requirement to use the flipping thing (note that Solarus does not yet do that, but it's on
@
Christopho
' s plan), you would have something that can hold up to the test of time.
You could even allow stock Z1 style questmaking, by setting the bitmap scrolling areas to one-screen regions, and adding a scripted subscreen bar. ...but the reality is, that ZC3 should be something that keeps up with the other gamemaking engines, instead of the arcane and antiquated methodologies that it employs at present, and in so doing that, you pretty much relegate old quest compatibility to a side-programme. Other utilities do this. Hell, Apple did it when they came out with OSX, running older programmes in a VM that sort of invisibly ran in the background.
That might be the thing to do, for 2.5 compatibility in the future: Some kind of invisible background process that runs the quest on top of the new engine.
All this not withstanding, in my ehttp://armageddongames.net/showthread.php?97486-ZC-2-future-Development-Plans-To-Do&p=912319#post912319w3stimate, we're five to six years away from such a thing being viable. In the interim, I choose to work with 2.50, adding things that people want, fixing what can be fixed, and trying to smooth out some ruffles. I have yet to see any kind of plan for a rewrite, or ZC3, that I feel is viable; nor have I seen the kind of staffing or dedication it would take to accomplish it. We realistically would need ten or more core developers, and a suite of contributors, or it'll take 12 years, like Solarus, or pretty much 2.5.
We do however, have people willing to work on 2.55, and 2.60. It's possible to keep this thing alive using these resources, while we develop a plan for the future. If you actually need a list of references on why not routinely updating something kills it, I can provide that: History is a good teacher here. Without working on 2.55 and 2.6 as continuations of 2.50--even if that means biting it, and continuing to work on a dinosaur API with a zany assembler that has its own C-type interpreter,--ZC is pretty much a dead duck, as the present userbase will die out, and no new userbase will exist to supplant it.
You also have to take the contributors, and new developers that you can gain, and avoid thwarting ever ambition that they may have, isolating them, and turning them away in the process. I know that
@
Tamamo
pretty much abandoned ZC Dev because everything she wanted to do was rejected; and while I was not in favour of some of it, the same thing is happening with the three of us that are willing to work on this beastie.