ZC [2.future] Development Plans [To-Do]

Quote:

---

I need to know if @DarkDragon is still thinking of doing buffers per script, or something like that, first. That, or multiple buffers. If you need JWin help, let me know.

---

I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.

Quote:

---

Originally Posted by DarkDragon

I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.

---

I was just sorta copying/emulating how ZScript does it. If you're talking about storing scripts inside of quest files I hadn't planned that until ver.2 since run-time compiling is higher priority.

Quote:

---

Originally Posted by Gleeok

I was just sorta copying/emulating how ZScript does it. If you're talking about storing scripts inside of quest files I hadn't planned that until ver.2 since run-time compiling is higher priority.

---

Quote:

---

Originally Posted by DarkDragon

I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.

---

Fair enough mates. For the present, I may write a routine to parse the output of the fuill buffer with all imports in-line to a separate buffer, and save it with the quest, with an option to extract it to a file, and an option to output it to a file at compile time. That should not disrupt anything and can be expanded in the future. It would be a pretty useful utility in any case. I think I will make it the default, and compulsory behaviour. If people absolutely want to hide code, they will need to work to do it. The entire argument of [i]needing'[/i[ to hide it, is asinine, IMO.

I also still plan to add an 'Export ZASM' option at some point, to get scripts as assembly to reuse, should the master files ever be lost. (Note, that I mean raw ZASM as a file, not some kind of disassembly--pretty much the opposite of the 'Import ZASM' options.

I forgot to add this during me last overhaul:

Zelda Classic (Viewer)

Zelda Classic:General

• Integrate the agfont library, adding TTF support to ZC.

It seems viable, and falls into the 'would be nice' for 2.55, 'almost certainly' for 2.60, and 'mandatory' for 2.65.

THis has many upsides, including the following:

• ZC GUI fonts will be scaled smoothly. No more jagged edges or distortions from scaling the window to any arbitrary size.
• Higher legibility on large (high-resolution_ displays.
• Easier to allow the user to set an interface font.
• Better internal code editor, and listers.
• In-quest ZStrings, and ZScript/AScript strings could use any font, and any size, cleanly.
• The user can add fonts to a quest.

The proof is in the pudding, though.

I just want to say good luck to the devs. I hope ZC will stay great and become even greater. Just having read the OP so far, that's one heck of a list. Most of the stuff would be too good to be true. I have no idea what the state of the future of ZC is in right now though.

Has there been any progress on the 2-player input and 2-player support in any recent builds?

Quote:

---

Originally Posted by Downloader

Has there been any progress on the 2-player input and 2-player support in any recent builds?

---

It is now possible to write a scripted system where different keyboard keys can be mapped to two or more player inputs, but as yet there is no P2 controller built-in. It is still part of the plan for canonical ZC.

[2.future] itself is dead, though. We have integrated most of the plan here into 2.55 and beyond.

Please see: To-Do List, on OpenZC.org