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

[DarkDragon]

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.

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.

[Saffith]

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.

Yes, that's the plan, though the details are still pretty uncertain. I like AngelScript specifically for of its C++-like syntax. It's similar to ZScript, which should make for an easier transition for the mostly amateur scripting community, and it's easy to adapt the existing code for anything we want to move out of the engine.

[ZoriaRPG]

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_2...h-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.