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

Zelda Classic (Viewer)

Zelda Classic:General

• Integrate the agfont library, adding TTF support to ZC.
• Allow editing ag.cfg via GUI/menus, using ZC.'
• Allow reading from allegro.log, or some kind of external file.
  [list]
• If another external file, then ZScript will need to be able to write to it.
• We could probably build this into a TCP/IP communications stack, for strategy games.

General

General::Quest, Save

• Save datum carryover between numbered quests.
• Fix combos that only work on layer 0, to work on higher layers, adding any ZScript components that we may need.
• Improved sideview mode.

General::Flags

• Add Flag (Explosion Trigger ( combos that are triggered by contact with LW_EXPLOSION).
• Add: EWeapon trigger flags.

General::Misc

• Add 2-player, support, and multiple input device support.
• Potentially find a way to solve the need to make fresh saves when changing vars, or arrays.
  
• Add internal version detection, and reporting (when loading/playing a quest).
• Change ffc loading from absolute (all screens, all DMaps at the start of the game), to a pre-emptive loading; else allow reading, and running ffcs on other screens.
• Other ffc changes/improvements.
• Allow 8-bit icons, and improvements to save slot/name entry/display.
• Allow changing some system hardcoded colours, such as shoppe rupee prices, and death animation red flash.
• Push all game save data to another quest file, for sequel support.
  
• Fix large Link hitbox in sideview.
• Global (not screen-based) script-executing objects, like FFCs, but without ffc properties.
• Fix scaling 8-bit tiles/sprites, and such. At present, their colours are ruined when downsized.
• Might need to fix up-sizing 8-bit, too?
  
• Possibly allow higher resolution sprites, via scaling? Can we do this if we double the screen size, and pixel ratio?
• Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.
• Possibly convert counters to be signed longs.
• Make x/y/z coordinates floating point values, so that it is possible to increment/decrement them in fractional units of pixels. Note that they would still be floored when drawn, but it will be possible to store a coordinate value of 10.023, for example, which would be drawn as 10.
• Sideview slope (diagonal movement) combos.
• Add 'Sideview' DMap flag, for sideview quests, so that it is not mandatory to set this on a per-screen basis.
• Add subscreen object 'Equip/Unequip'

External

Quest-template::Gameboy

• Include a Gameboy quest template that includes most, or all of the content belonging to Link's Awakening, and the Oracle games, so that users may build similar quests without the hassle of piecing together all the scripts, graphics, and such.

Quest-template::Z3-Esque

• Something based on Pure, or similar. Possibly a Z3 tileset, with Z3 enemies, items, and bosses?
• This does not mean Z3-Screolling. Don't ask.

Quest-template::RPG

• Could be based on the RPG.zh engine, with a 'Dragon Quest' tileset, items, spells, menus, and the like.

Headers::std.zh

• Expanded std.zh for 2.53 and above.
  
• Includes a config file.
• Includes new functions, and constants.
  
• Includes expanded string,zh, that is now considered part of std.zh proper, and imported with it.
  -->This will not conflict with scripts that import string.zh.
• mem.zh for advanced array handling.
• Possibly linked lists and mock function pointers, until we add those internally.

Docs::ZScript

• Usage docs for ZScript, with examples.
• Usage docs for std.zh and all related files.

Docs::ZScript Parser

• Explains how the parser works.

Docs::Script Tutorials

• Self-explanatory, but we will list what we complete.

Docs::ZQuest Manual

• A big, long, horrific nightmare.
  
• Any volunteers to assist with writing this bastard?

Docs::ZQuest Tutorials

• PDF format.
• Video format, if we have a volunteer to record them.

Tools and Utilities::Editors and Viewers

• String Table Editor
• Palette Editor/Viewer
• Subscreen Designer -> We also need to be able to import subscreens as code.

Tools and Utilities::ZScript

• ZScript IDE -> Bobby Light's Java IDE might be usable as a base?
• ZASM Extractor -> Extracts ZASM from .qst file word table, back into ZASM instructions.

Tools and Utilities::ZLaunch

• Replace ZLaunch with LTMs launcher. or something similar that handles multiple save files.

Tools and Utilities::ROMView

• Fix ROMView, or replace with something new.

Tools and utilities::Misc

• Personal Quest Database, with quest rations, and such, that can be shared.

External::TCP/IP Communications

• Some method of transmitting text over TPC/IP via two Ip addresses on a given port, would allow turn-based strategy quests, and sharing seeds for randomised games, or time-based synchronisation.

22-Feb, 23-Feb,24-Feb : Some additions to the above llist, and other notations.
25-Feb: Expansions, plus 'External' category.
17-Jan-2017 : Updated

We're going to need to start tagging these things as goals for [2.53], [2.54], [2.55], and ['2.60'], along with who is working on each aspect. Note that '2.60' (above) implies that it won't be in 2.53->2/55, but in a later version. It might make it into an earlier release, but we can only plan on it for the future, and not for the immediate future.

Quest Files

Quests:Quest Details

• Allow setting a quest number for serialised quests, that does not require the quest to have a

27-Feb : Added some global values, and object values. By popular request 9and concern), [FONT=Courier New]bool ObeysGravity[/FONT] is now on the list for weapons, and other object types. This one might be a priority for 2.54/2.55

02-March:

Add: TriggerSecret(int secret)
Add: Flag (Explosion Trigger ( combos that are triggered by contact with LW_EXPLOSION).
Add: EWeapon trigger flags.

04-March: Added External:Tools and Utilities category, above..

16-March :

Added list entries for the following to the main categories, above:

• Add [FONT=Courier New]Until()[/FONT] and [FONT=Courier New]Unless() [/FONT]expressions. -ZoriaRPG/grayswandir
• Allow creating user-defined bitmaps with user-defined IDs at specific sizes.
• Allow saving user bitmaps directly in the quest file.
• Allow editing ag.cfg via GUI/menus, using ZC.
• Fix ROMView, or replace with something new.
• Replace ZLaunch with LTMs launcher. or something similar that handles multiple save files.
• Add Repeat(int iterations) loop type. -grayswandir

17-March:

• Add method of reading system time, and date.
  [list]
• This would allow setting time, or events in a quest, based on real-time events.

• If another external file, then ZScript will need to be able to write to it.
• We could probably build this into a TCP/IP communications stack, for strategy games.

• Some method of transmitting text over TPC/IP via two Ip addresses on a given port, would allow turn-based strategy quests, and sharing seeds for randomised games, or time-based synchronisation.

Happy Spring!

21-March:

• Add [FONT=Courier New]PrintToLog(char str)[/FONT] to ZScript.
  [list]
• This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.

22-March:

• Add 'load' directive to load a quest with a specified file name into the present save slot, and change the assigned quest when loading that slot.
  [list]
• This is for serialised quests spanning multiple quest files.

Quest Files

Quests:Quest Details

• Allow setting a quest number for serialised quests, that does not require the quest to have a

Editor::Rules & Quest Settings

• Add duplicate point to set Link movement and related attributes rules in QRs panel, in addition to the Link->Graphics panel.
• Expand the amount of the text field for quest details in header.
• Add 'Quest credits' to quest header.
• Enable visibility of 'Quest Number', rather than needing to press a special key to view, and set it.

I suppose I need to go over all this at some point...

Increase the script buffer from ~18MB to MAX_LONG in bytes.

Increase other operational pointers for datatype objects from 255 to *.

Add some lexer symbols, such as [FONT=Courier New]?[/FONT] (question-mark) to be used in function names, such as [FONT=Courier New]?InAir[/FONT]()

Add AngelScript style [FONT=Courier New]and[/FONT] token, and [FONT=Courier New]or[/FONT] token.
Add [FONT=Courier New]Until()[/FONT] and [FONT=Courier New]Unless() [/FONT]expressions.
Add Repeat(int iterations) loop type.

Add function pointers.

Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.

Allow reading most internal variables, including enemy timers, and whatnot.

This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

Set/change quest rules by script.

Add [FONT=Courier New]PrintToLog(char str)[/FONT] to ZScript.

• This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.

Increase Screen->D[] regs to 256.

Allow saving user bitmaps directly in the quest file.

Add Link->SetItemA/B internally, instead of the std.zh pressDirand subscreen madness. This will set an item to A/B directly. It should have a param 'bool force' that sets it even if Link doesn't have it.

Allow 8-bit icons, and improvements to save slot/name entry/display.

Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.

I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.

Saffith wrote:I suppose I need to go over all this at some point...

Well, we started making a plan out of this in January, but better late than never; eh?

The buffer is just a std::string. Any limit on it is from that class, and it may vary by platform. Not that it's all that hard to replace, probably.

I suppose we'll find out when we try to do it.

Before I get too deep into this, I feel it important to note that I'm not quite on most of these topics yet. Of the list, there are only two things that I wanted to get into 2.55, which per our versioning plan, would be six months to a year following 2.53/2.54; and that is intended to be the first truly new ZC 2.x release out of our plans.

Dimentio did some npc stuff, and might have done some ZQ string control code madness that I personally want no part of, as Ikd rather not support YAL in ZC with SCCs to do ZScript stuff, which is what he was attempting to do.

When is 255 not enough? That's a significant design consideration for an extremely rare case.

Actually, it's usually weapons that can easily exceed this, but there are some abstract applications for these objects, too. I think we tagged this as 2.6.

/quote]
Why? There's no way to fit that into existing naming standards, it would make it impossible to implement the ternary operator (not that I expect that to happen anyway), and there isn't any obvious benefit.
[/quote]

The termary operator [FONT=Courier New]?:[/FONT] should be able to coexist. The way I was setting this up, the identifiers required that the ? was a leading, or trailing character, and I can put in an exception for STATEMENT ? EXPRESSION : EXPRESSION, or IDENTIFIER ASSIGN STATEMENT ? EXPRESSION;, or I believe that I can. This, and some of the other things to do with tokens, will come down to experimentation. If what I do works, I'll keep it. If not, I'll cut it, and cut my losses.

I know those aren't quite right, but ai'm flat out of steam at present.

In any event, ? by itself can be distinguished from ?[aA-zZ] or whatever identifier tokens you fancy. The key component is that the ? must be the first, or last char in the token. I could probably add a ternary token too, just to test if they are compatible.

Okay, I guess? Again, I don't see much benefit. It'll create more reserved words, and "repeat" in particular is likely to be used in existing scripts.

Some of us just like these expressions. That comes from a language diversity, I expect, but they are useful in some readability aspects. Grayswandir requested a basic repeat statement, I think, and I'd like a do-until expression simply for clarity.

In these cases, I look at is a more of a kwhy notk situation. Repeat is just a shorthand for loop, and thus a shorter way of doing that. I've never seen it used in a script, though that doesn't make it impossible. In any case, our decision on this is that there may be small ZScript changes that require updating a minority of scripts, so unless we did something with sweeping impact--which is in the alloeed scope of 2.65 under our definition--it can stand.

It's not the first time this has happened, and even [MENTION=42714]Gleeok[/MENTION] suggested replacing existing functions with new functions that use the same name, but with more params. I wasn't in favour of that, as that has a high risk factor in breaking existing scripts.

That's going to be seriously limited without fundamentally changing how scripts work. Functions aren't shared among compiled scripts, so a pointer passed from one script to another would become invalid.

This one isn't my idea at all, and I wouldn't want to be the one to implemt it.

UID behavior has already changed in a way that would break compatibility.

Please explain, and give further details on what this is supposed to mean.

This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.

This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

That was sort of the implied direction for making these vars part of the npc class itself.

Similar deal, plus there are several issues with it already. Lots of rules wouldn't take effect if set while the game was already running. We'd either have to rewrite a lot of stuff to address that, or just accept that it would be inconsistent and unpredictable.

Probably both, with incremental shifts towards full compatibility. Not as if there isn't already an arms' length list of inconsistent behaviour in ZScript, such as NULL values.

That would require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.

The point of this one, is to make it possible to do TraceS() without using a pointer to an existing string: TraceStr("This is what we're doing" ). Of course, how to store that string is another matter, but doing anything with char isn't happening soon.

That would increase memory usage by 134,912 bytes per map. And every byte of that is save data, which means load and save times for even small quests would be drastically increased. To take one example, the save data for Isle of Rebirth is currently about 2.24 MB; with this change, it would become 20.18 MB. And that vast majority of that would be totally unused.
If you come up with a way to do this that allows the memory to be allocated on demand and not saved unless it's used, it might be okay. Simply increasing the number wihtout changing its behavior would be unacceptable.

What is the specific memory footprint for a single index? When I do the math here, I'm coming up with a different value? (131072 Bytes).

I had not considered that this was another area where zc memory management was so broken. So, sure, if we made huge array sizes for screen datum, we'd need to compress out unused stuff and load it more dynamically.

It would still be nice to pop these up a bit, perhaps make it a size of 20, and make all the class->Misc[] arrays a size of 32. How bad is memory (RAM) handling for those? Probably the same issue, only it is based on object count.

Again, as long as you can do it on demand rather than saving all bitmaps for every quest.

Naturally, it would need to be something that is added to a save file only after the bitmaps are first generated in a playthrough. The new functions to create bitmap space might help there.

This sounds like the same thing as making Link->Equipment writable. That was the case in 2.50 until build 1187 or so, but it was disabled because it was too buggy and basically unfixable. I don't know the details of that, though.

Are the old (non-public) ZC dev boards from 2.11/2.5 still archived? It would be extremely useful to be able to read them, to find out what has been tried, and know the pitfalls. I only know that the intent was to be able to set/get any value.

Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.

I'll need to look at how icons are drawn, but if you only allow a single 8-bit icon, or four 4-bit, it could work.

They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.

Why do the unsigned values roll at 32768? Is there any valid reason not to change them to the fixed type? Hell, I'd like to make signed fixed counters available.

I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.

None of claimed it would be easy, and pretty much, the understanding is that if we make 2.5x stuff, we're stuck supporting it. Either way, it's all stuff we'd like to do, but not something we swear we'll be able to pull off, and it's part of a four-year overall plan, with one release a year, as the general model.

It's hard to say what on the list will prove possible on a per-version basis, or if itks even possible, until we write it, and test it. We aren't trying to strongarm you into doing any of this, at all. Really, we aren't looking to burden you with this; but we do appreciate being able to consult with you from time to time, as needed, to ask technical questions, as long as you don't mind doing that, while you do the things that you want to accomplish.

Now...I've worked a 22-hour shift, and been awake for 30+ hours, so I'm siging off, to pass out.

The termary operator [FONT=Courier New]?:[/FONT] should be able to coexist. The way I was setting this up, the identifiers required that the ? was a leading, or trailing character, and I can put in an exception for STATEMENT ? EXPRESSION : EXPRESSION, or IDENTIFIER ASSIGN STATEMENT ? EXPRESSION;, or I believe that I can. This, and some of the other things to do with tokens, will come down to experimentation. If what I do works, I'll keep it. If not, I'll cut it, and cut my losses.

In these cases, I look at is a more of a kwhy notk situation. Repeat is just a shorthand for loop, and thus a shorter way of doing that. I've never seen it used in a script, though that doesn't make it impossible. In any case, our decision on this is that there may be small ZScript changes that require updating a minority of scripts, so unless we did something with sweeping impact--which is in the alloeed scope of 2.65 under our definition--it can stand.

Please explain, and give further details on what this is supposed to mean.

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.

Probably both, with incremental shifts towards full compatibility. Not as if there isn't already an arms' length list of inconsistent behaviour in ZScript, such as NULL values.

The point of this one, is to make it possible to do TraceS() without using a pointer to an existing string: TraceStr("This is what we're doing" ). Of course, how to store that string is another matter, but doing anything with char isn't happening soon.

What is the specific memory footprint for a single index? When I do the math here, I'm coming up with a different value? (131072 Bytes).

It would still be nice to pop these up a bit, perhaps make it a size of 20, and make all the class->Misc[] arrays a size of 32. How bad is memory (RAM) handling for those? Probably the same issue, only it is based on object count.

Are the old (non-public) ZC dev boards from 2.11/2.5 still archived? It would be extremely useful to be able to read them, to find out what has been tried, and know the pitfalls. I only know that the intent was to be able to set/get any value.

I'll need to look at how icons are drawn, but if you only allow a single 8-bit icon, or four 4-bit, it could work.

Why do the unsigned values roll at 32768? Is there any valid reason not to change them to the fixed type? Hell, I'd like to make signed fixed counters available.

[MENTION=38582]Saffith[/MENTION]
He's talking about the counters, if you trace values to allegro they are signed and rolled for some reason.
In otherwords the internal does not match allegro log.

Saffith wrote:
It's just too problematic. Quest rules were't made to be changed mid-game. I can't imagine how many bugs would result from it, beyond some of them simply not doing anything at all. Also, it'd make it harder to replace quest rules with superior options later on.
Quest rules don't make for a good scripting interface, anyway. If you put some rules one might reasonably want to change behind meaningful interfaces (e.g. Link->DiagonalMovement, Game->ContinueHealth), that should be okay. Even if the ZASM it compiles to is just SETQUESTRULE, that's less of an issue.

Well, right. I was indeed going to add two levels of an interface to it. One that stores the QR values in an array, to modify, and another that uses ZScript hooks. i wasn't planning to make it fully direct. In fact, what i wanted to do was change the way they work, so tat we don;t run out of space, by storing each rule value in an index. Might be wasteful, but unless you want a second flagset...

I was not going to try to do raw Setter/Getter stuff for those. Sorry if that wasn't clear.

I did write some Setter/Getter stuff for things like bool Throttle. Not sure if you would want more abstraction for that stuff. (It's mostly Getter functions anyway.)

That other stuff for the most part, isn't a priority. I think expanding the misc indices for game objects (*weapon, nnc, and so forth) would be prudent, as using two or three headers now makes it easy to have issues with overlaps.

Insofar as stuff like ? as an icentifier, I did indeed add a list of exceptions that check for it. THe way I wrote it, the ? needed to be at the head of an identifier, with no spaces. also have qualms about mandatory spacing styles though, which came up when i wanted to add * to identifiers. WHile that would be nice, it's not necessary. I agree. I did write most of the support code to make it work, but I don't want to cause conflicts. '?' was less of an issue as we don;t use it anywhere else. You're probably right in any event, and maybe I'll add ternary to the parser when I feel like having me brains turn to pudding.

Comment blocks may be done now though, and case-switch is partially done. Not sure how long it'll be before I get back to that one, which I feel would be extremely useful, and compatible with whatever later interface you want. I should note that adding Repeat and Do-Until to AS should be easy, but neither of those have the same priority as case-switch and COMMENTBLOCK.

I also want to make illegal SINGLECHARs such as [FONT=Courier New]`[/FONT] halt the compiler though. I did other things with the parser, but now I'm starting to forget what they were. I might eventually break down and make 2D arrays, but it's low on my agenda, and has a high sanity cost. I'll note here that I don;t really have huge issues comprehending flex, and there are many useful docs and tutorials, many of which I've read specifically for this reason.

I sort of want to make either a BAISC or COBOL language interface for ZASM, just for fun. I seem to recall someone trying to do that in the past, back in 2005-6, before I dropped off the map.

Last, I do have to disagree about who is using ZScript at an advanced enough level to make use of some of these things. We have a decent little (private) side community on Skype who all do some pretty advanced things on a regular basis, and I try not to underestimate the needs/desires of users, present, or new. We've had people sign up, and jump right in with no qualms, only to b*tch about things not existing. I tend to field a lot of stuff for/from users on ZScript support, so I pretty much see a lot more than most when it comes to both desires, and capability of users.

Our side community is meant for people who do advanced stuff though, but we have something like seventeen active participants who are in the chat nearly every day, and more are joining at sporadic intervals. We'd be happy to have you in chat too, but I know that you don't use IM.

Leave quest rules out of ZASM... That is one thing you do not want to tinker with [MENTION=42228]ZoriaRPG[/MENTION]

I should just make things like 4/8-way movement a game variable in general. Not even a quest rule in the first place, but it's the most common request for a rule that can be changed.

One piece of advice: for each of the suggestions, include a paragraph justifying why there is a need for that feature (and even better, links to forum topics by quest authors demonstrating that need). For example I see many items in the list that could be implemented, and be somewhat useful in some situation, but don't seem worth the time or added code complexity to implement unless there is a demonstrated need by quest authors, like octal support, function pointers, global arrays of object pointers, etc.

I also cannot endorse Saffith's comment above enough:

This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.
This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

DarkDragon wrote:I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

DarkDragon wrote:One piece of advice: for each of the suggestions, include a paragraph justifying why there is a need for that feature (and even better, links to forum topics by quest authors demonstrating that need). For example I see many items in the list that could be implemented, and be somewhat useful in some situation, but don't seem worth the time or added code complexity to implement unless there is a demonstrated need by quest authors, like octal support, function pointers, global arrays of object pointers, etc.

I also cannot endorse Saffith's comment above enough:

One of the big mistakes we made in the time between 2.10 and 2.50 is adding many new features without fully thinking through what the consequences would be for future backwards compatibility and for future ports and rewrites.

I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

So, a bit of backstory. When ZC was first released as source, a trio of us pretty much wanted to work on 2.xx, keeping ZScript, as the userbase that we represent has a huge investment in it. We had some chats with Gleeok, and the original plan was that ZC3 would go with AngelScript, and that we'd be in charge of making new 2.xx releases, hence the 2.future tag.

The to-do list was pretty much something that all of us constructed, each with our own priorities, but who knows what would end up in there.

A lot of things on the list should probably make it in, and the most common requests are support for all the weapon types, npc scripts that run like ffcs, support for comment blocks in the parser, global pointers--when you see some of the things we're doing with the language, you'll understand--more control over Link (hitbox, sprites, tiles), and such.

Some of the things were more esoteric. Grayswandir is the one who wants function pointers, for example. We all pretty much want some things like switch-case, and more functions to handle internal ZC things, that should have been in there in 2.5, like GetDMapScreenDoor(), and expanded drawing.

There's always a realism limitation of course, but we do some pretty advanced stuff that is often hindered by limitations. ... and the group that we represent is pretty much the core of the ZScripting community. Typical users don't honestly even comprehend basic scripts, much less complex engines that run on top of ZC.

After a lot of back and forth bicker, the AngelScript plan was put on hold, and we all pretty much agreed to work on 2.54, 2.55, and 2.60 retaining ZScript. By 2.60, we could potentially introduce AngelScript, but I felt that would end up being a 2.65 thing, still supporting ZScript fully, and initially introducing AS so that users could start learning it, with AS being dominant in ZC3. I was hoping to do one major release per year, until ZC3 is ready, too. One main issue that I see, is that the userbase is dwindling, from stagnation.

The best way to attract new users, and keep existing ones, is to keep the programme fresh, so that they can explore new avenues of design. There hasn't been muc of a change since the 2.5 betas, so for the past six years or more, ZC has remained about the same, with few new capabilities. This has caused people to migrate to other tools that are more regularly updated, and if we wait until everything is done, instead of doing incremental new versions, there won't be anyone left to use what we create.

This happened in the 2.5 release era as well. People left the community because it took so long to produce 2.5, and some of them are only now returning, but these are few. The majority of new members want to do 'out of the box' things, and they rely on the scripting community to provide them.

For the most part, nearly none of these scripters had any interest in AS, in moving to something different, or in losing compatibility. Some of these engines are in excess of 100,000 lines of ZScript code, and porting them just isn't a realistic option.

If you want to see just how much can be done with your language, you should try this:

http://timelord.insomnia247.nl/zc/ZeldYs.qst - Moosh is working on this.

..and see...

https://github.com/ZoriaRPG/Backup_27JAN2016_RPG_zh-Main-Project
and
http://pastebin.com/0QrXNm3M - Grayswandir's LISP.zh implementation; he wants function pointers for things like this.

My focus has primarily been adding more script drawing, and adding more getter/setter functions, to do things that are either literally, or practically impossible. The GetDMapScreenDoor() example above is a good one, as there is no realistic way to read Screen->Door remotely. Most of the base functions could use a way to get/set them remotely, which is pretty straightforward, from what I can tell after ploughing through the ffscript code for untold hours.

As things stand, I'm working on a plan to submit, and discuss with the other devs, so that we aren't going in cross directions, and I'm hoping to compile and complete that in January. My time of late has been drained away by petty legal concerns, and my work, which at present has be very far away from home, and my office. (I'm out in the remote wilderness, typing this.)

Another major issue that I see as crucial, is that most users are on Pure, and all of these discussions occur on AGN. While it would be fantastic if they all joined here, realistically that just won't happen. I've tried to motivate people to sign up and participate here, and the common response is 'Why not just make a Dev forum on Pure for us?'.

I'll reiterate that, as it's important: We can't really get user input when we discuss this here, and the userbase is elsewhere. We need a Dev board on Pure.

From what I understand, the Pure staff are reluctant to add one, because AGN staff didn't want it in the past, but now that it's open sourced, we need to remove those objections, and allow a Dev board, with a bug reports board, there. Most of the bugs that we miss are ignored because users don't report them, and they don't report them because they can't do it on PZC.

Other than all of that, I have been (slowly) working on an improved docs set, that in the end, will become a comprehensive PDF. I would like to do the same for ZQuest, and I would also like to work on the Wiki, but there have been some roadblocks.

I would like to ask, while you are here, if it would be possible to move, or mirror the Wiki from Shardstorm to AGN, or to a server with a faster data path. I've had many user complaints that it takes forever to load, and this also makes editing it quite a tedious task. I'd also like to update the Wiki software at some point, to add in modern Wiki markup, as it's running a version that doesn't even properly support referencing. ...but all that is best discussed on its own.

In essence, while all of these other languages are fantastic on the surface, they don't have much appeal to the people actually using the programme. It is far better to plan out a slow migration, and allow users to gradually adapt to the changes. That's my tuppence worth.

I know nothing about any of this, incidentally.

I'm one of the ones who agrees that the change to AngelScript shouldn't be instantaneous. Immediately introducing a new language and then forcing people to ditch ZScript if they want the new changes isn't really a good plan, considering scripters are pretty much keeping ZC alive at this point. Hell, if 2.50 didn't have ZScript, I think ZC would be dead by now. I do think a new, better language would be great at some point, so long as we let people get used to it, allow them the time to learn it, and the like.

Truth be told, I think ZC needs a major rewrite. Looking through the code is almost like taking a tour through an archeological site, and frankly, all these variables whose purpose is not clear can go to hell. :P

If it's possible to add Angelsript at whatever pace you want, without dropping support for ZScript, I think that would be fine. But if you drop support for zscript, even if you replace it with a similar language, you are still disenfranchising some of the most active creators. (I wouldn't count myself as such a person, as I'm in the 'disappeared in the 2.10 days and only recently resurfaced' category, but, for my own position in the matter: I've pretty much completed my first full quest, by heavily relying on ZScript. I would not be eager to learn a different language right away; if I'm going to do that kind of thing, I would go off and learn something I can make programs in myself. But I am already working on ideas for a sequel... that rely on my knowledge of zscript to actually function.) Part of what might also happen if ZScript is dropped too hastily, is that many people will simply use 2.5.2 instead of the new version, which undermines the points of your hard work.

So basically, I'd totally be in favor of adding a new language, and even okay with you developing that language while not really expanding ZScript- as long as compatability for ZScript isn't dropped. I think that would be a terrible mistake. Just look at how many of the most popular quests rely on ZScript, you know?

As far as ideas for new features... I'm pretty sure it's already been discussed here, but I still think that splitting up the NPC Script weapon defenses into 10 parts (a separate defense setting for each of the ten LW_SCRIPTs) would be an excellent addition to the enemy editor, because it would make the separate script weapon types more useful, and much more likely to be used. Needing to script a workaround to constantly change NPCD_SCRIPT is silly, and many users don't even bother, or, as I did, encounter bugs in the course of trying to set it up properly. I also think that added the ten EW_SCRIPT weapon types to the default weapons you can set an enemy to have would be a good idea, because this enables users to easily put together enemies in the editor- without ghost- that use new weapon types that they can script global effects for. Lastly, I think one other enhancement the enemy editor could use, that would improve casual usage, is better built-in adjustments for enemy sizes- basically just a means to type in their tile width, tile height, hit width, hit height, draw X offset, and draw Y offset; those are admittedly pretty easy to set with scripts, but I think you'd get non-scripter users potentially making more interesting bosses this way. I don't know if any of these suggestions are really necessary, but they'd be extremely convenient, and reduce the barriers of confusion for those learning the program.

Regarding setting up a dev forum on PureZC... I'm not a terribly active forumgoer myself at either place, but I do think that would greatly expand your user feedback, since this place is definitely sort of a ghost town by comparison (I must admit I only saw this thread because someone else pointed me at it). Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

In any case, I also want to say that 2.50 was an excellent improvement over 2.10. The ability to script new items and enemies is singlehandedly what made me interested again- finally I can have my Cane of Somaria and so many other neat things I wished for as a teenager. Thank you very much for making ZScript in the first place. Also... 2.50 in general, especially 2.5.2, are far, far less buggy and vastly more stable than the old 2.10 or various 1.92 versions. I've experienced almost no crashes myself, on Windows 7, except for when I did silly things like misusing a while loop when I was learning to script.

I look forward to seeing new developments for ZC, and thank you all for your hard work : )

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).

The ZScript discussion reminds of Houdini, a Blender-like 3D modeling tool that is commonly used in the special effects industry. For many years Houdini was highly scriptable using a DSL called "hscript" with its own syntax and parser, etc. This worked well for a while, but was a barrier to entry for new users and also somewhat of a pain to use since hscript lacked many of the advanced features and conveniences of mainstream scripting languages. At some point SideFX, the company behind Houdini, decided to switch from Hscript to Python. Houdini still supports hscript, but outside of legacy files and assets nobody really uses it anymore.

I imagine the most painless way to move away from ZScript to something like AngelScript would be to use a similar strategy. For a while, both ZScript and AngelScript are fully supported. Fully-scripted items and enemies are slowly introduced that coexist side-by-side with the old hard-coded ones, but new quests created in ZQ use the new enemies by default, and these new features only work with AngelScript. Old quests still play, but authors using ZQuest are increasingly incentivized to switch to the new system.

Another major issue that I see as crucial, is that most users are on Pure, and all of these discussions occur on AGN. While it would be fantastic if they all joined here, realistically that just won't happen. I've tried to motivate people to sign up and participate here, and the common response is 'Why not just make a Dev forum on Pure for us?'.

I'll reiterate that, as it's important: We can't really get user input when we discuss this here, and the userbase is elsewhere. We need a Dev board on Pure.

From what I understand, the Pure staff are reluctant to add one, because AGN staff didn't want it in the past, but now that it's open sourced, we need to remove those objections, and allow a Dev board, with a bug reports board, there. Most of the bugs that we miss are ignored because users don't report them, and they don't report them because they can't do it on PZC.

I guess that's something to discuss with the folks at Pure. I don't know anything about this and don't particularly care to wade in, though I have to say I'm surprised to see that the drama and bickering between the sites continues in 2016 when it seems both sites struggle to get more than a dozen posts per day.

Presumably y'all have set up a core group of developers charged with curating the official repository and binaries. Hopefully you're on the same page about both the short and long-term development goals of the project, and have some centralized place to discuss this. But communication with the community can happen anywhere and in multiple places simultaneously. How to best handle users submitting feature request, pull requests, bug reports etc. is for you (the ZC developers) to decide. Both sites should be making facilitation of ZC development their unequivocal top priority. On the AGN side I can try to help relay any requests or concerns to War Lord (though I know I'm not necessarily much easier to get a hold of than War Lord himself... 😞) and my understanding is that Gleeok and Saffith have pull at PureZC.

I would like to ask, while you are here, if it would be possible to move, or mirror the Wiki from Shardstorm to AGN, or to a server with a faster data path. I've had many user complaints that it takes forever to load, and this also makes editing it quite a tedious task. I'd also like to update the Wiki software at some point, to add in modern Wiki markup, as it's running a version that doesn't even properly support referencing. ...but all that is best discussed on its own.

Agreed; War Lord and I are already coordinating on doing this.

In essence, while all of these other languages are fantastic on the surface, they don't have much appeal to the people actually using the programme. It is far better to plan out a slow migration, and allow users to gradually adapt to the changes. That's my tuppence worth.

From what I'm seeing in this thread, it seems everybody is on board with gradual change.

Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

Yes, this is a perennial problem. The current ZC lead developer should have access to zeldaclassic.com, but should not be expected to have the time or skills to keep the site maintained. The site needs a webmaster who is competent and active, which is a lot to ask. War Lord is currently working on fixing the site in the short term, so if you know somebody who might fit the bill in the long term, please do encourage them to contact War Lord.

There were no plans to remove ZScript immediately from ZC. This is also a practical approach; there's simply too much work to be done first. If the day comes when we have the luxury to either deprecate or rip out ZScript entirely, then it's not going to be a breaking news story by any stretch. The amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all). This includes both the end-user scripts and the ease-of-use of working with scripting from within the codebase itself. That said, I personally don't have problem with leaving ZScript intact until the last, if for no other reason than removing it would be at the bottom of my list of fun things to do to spend my time.

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work.

(More comedically, I'm picturing someone trying to make some sort of 2.5.2 virtual machine in Angelscript, though... XD )

How to run Zeldaclassic.com is pretty much your guys' call, but.... what might be more reliable, is instead of having a single webmaster that can edit the site, if you instead had a handful of key staff members all have access- such as Saffith, who posted 2.5.2- so that once a new version is done, then they don't have to get in touch with somebody less active to update it. A very small group of the most trusted developers all having Zeldaclassic.com update privileges, sort of like a shared dropbox kinda deal, basically.

the amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all).

I don't suppose Angelscript can mess with screen scrolling behavior and built in Active Subscreens, can it?

Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

Saffith wrote:Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

DarkDragon wrote:Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

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 [MENTION=1]DarkDragon[/MENTION] 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 [MENTION=61144]Christopho[/MENTION] ' 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 [MENTION=56506]Tamamo[/MENTION] 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.

Saffith wrote:To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).