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

DarkDragon 30 Nov 2016, 06:05

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.

I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.

However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.

ZoriaRPG 30 Nov 2016, 06:45

DarkDragon wrote:I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.
However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.

You should certainly have a look: http://www.solarus-games.org -- The default quest is rather impressive, and the quests made to date are shaping up nicely. it uses Lua, and TBH, my main complaint is that you need to manually configure absolutely everything with Lua scripts, at present. The map design tools are outstanding though, and it runs in the Z3 style.

It's also open source, and [MENTION=61144]Christopho[/MENTION] has no qualms discussing it in depth, should you want to inquire.

ZoriaRPG 30 Nov 2016, 09:56

Moosh wrote:So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.

Unfortunately, only time will tell. AFAIK, the present plan doesn't call for ZScript deprecation for a jolly long time. I'm mostly uncertain if it's even plausible to do such a major rewrite, and not break the universe in the process. We have so many compatibility rules as things stand, that implementing all of them in a rewrite is simply...madness.

The hope is that when ZC3 is a thing, and a new language is implemented, quests with ZASM tables will still work, most of the time.

It won't be the 'next version' though. Somewhere down the line, certainly, but not next. That, and I may be mad enough to continue supporting 2.xx stuff after it is officially deprecated. We'll see in a few years how much steam I've left.

Saffith 30 Nov 2016, 18:35

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

I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

ZoriaRPG wrote: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 disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

We do however, have people willing to work on 2.55, and 2.60.

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

Moosh wrote:So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.

We just can't say at this point. I think updating a quest would mean removing all ZScripts and updating enemies, items, etc. to the new versions, but maybe not.

DarkDragon 30 Nov 2016, 18:57

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

In particular, are there developers that are willing to focus on fixing bugs, and refactoring code, rather than cram in more new features?

Debugging and maintenance is extremely unglamorous work, but is what ZC needs right now (and has needed since 2.12, to be honest).

ZoriaRPG 30 Nov 2016, 23:10

Saffith wrote:I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

I certainly wouldn't. I'm not even sure what benefot thee would be to that conversion, to be frank. Changing from the present fixed format would sure break everything though, which is why I haven't been in favour of suggestions to do anything of the sort. I had an idea for allowing fixeds in the script lanuage, but I pretty much abandoned that after i determined just how obscene it would be to implement, versus its usefulness.

I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

I don't disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... 😛

It comes up in chat, every single time this topic is broached.

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

That's valid, certainly. I fret that any attempt to clean it up is likely to (initially) do more harm, than good, as well...but there are really three options, as I see things:

1. People work together on the individual, incremental updates; you take what you can get.
2. You end up with a core version, several forks, and community splintering that the present minimal userbase cannot maintain.
3. You have a stalled project, that goes nowhere for years.

We seem mostly to be in mode 3, from that list.

Saffith 01 Dec 2016, 00:21

ZoriaRPG wrote:I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

First I've heard of it. I was doing that, and it seemed to be working fine, but then we stopped doing that. Maybe for a reason, but I don't even know anymore.

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

I don't know what any part of that means.

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... 😛

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

Gleeok 01 Dec 2016, 07:43

DarkDragon wrote:In particular, are there developers that are willing to focus on fixing bugs, and refactoring code, rather than cram in more new features?
Debugging and maintenance is extremely unglamorous work, but is what ZC needs right now (and has needed since 2.12, to be honest).

I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. 😊 In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. 😊

The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.

DarkDragon 01 Dec 2016, 08:38

Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

ZoriaRPG 01 Dec 2016, 10:02

Gleeok wrote:I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. 😊 In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. 😊
The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.

(Emphasis, mine.)

Bah? I have win10 installed, and I've tested ZC and ZQuest, encountering no such issues. It must be either a video driver conflict, or some kind of malware in that case?!.

Neither ZC, nor ZQuest seem to run differently on Win10, than they did on Win7, on this hardware.

Saffith wrote:First I've heard of it. I was doing that, and it seemed to be working fine, but then we stopped doing that. Maybe for a reason, but I don't even know anymore.
I don't know what any part of that means.

I think you had implied in the past that something I had done didn't have proper abstraction? I just want to make certain that setter/getter functions that return something like bool throttleFPS aren't a problem.

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

Oh, I have. I can't even get people to sign in here, that have accounts to make flipping bug reports. They send them to me, over Skype, and ask me to file them. 😞

This is precisely why I've been pushing for bug and dev forums on Pure, as pretty much everyone who could be discussing these things, getting involved, and reporting issues is over there. ---->

I don't actually enjoy relaying everyone else's concerns, you know; nor being left to defend their interests solely. They should just stop being lazy, and sign up, or sign in here, but you know, that isn't going to happen. I'm sort of tired of being the gopher for every complaint, problem, and general issue, too. For my own purposes, I an always crank out a version of ZC that does what I need it to do, and not worry about it.

Frankly, assuring people that everything they made isn't going to abruptly break in the very next ZC version shouldn't be my full-time job.

DarkDragon wrote:Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

2.50 stability is assuredly, highly praised, and regarded. I remember the fun of 2.10 crashing randomly, if I wanted to view the space-bar-map, or 2.5 betas eating save files. things like that are why I abandoned ZC for a few years, particularly when it seemed as if future dev (then) was going no-where.

Incidentally, this is why I fear things being stagnant, now; as I know people tend to leave when they feel as if nothing new is forthcoming. I certainly did, in 2006/7.

Gleeok 01 Dec 2016, 10:32

[Thread Hijacking In Progress]

ZoriaRPG wrote:I think you had implied in the past that something I had done didn't have proper abstraction? I just want to make certain that setter/getter functions that return something like bool throttleFPS aren't a problem.

Ooh boy, oh boy. A discussion about getters/setters and abstraction layers! Quick, post the offending code. We've got to figure this out immediately! :P

This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:
[spoiler]
No. Not sarcasm. Haha. Fooled you.
[/spoiler]

[/Thread Hijacking In Progress]

Mitsukara 01 Dec 2016, 12:51

(I apologize that this following post got rambly.)

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

In support of Zoria, I myself was saying "Wait, if quests that use ZScript stop working in new versions, you're going to lose a ton of your userbase" and "Oh, well, at least people can develop in 2.5.2 instead of the new version, solely for the benefit of continuing to use ZScript". At the same time, I like the potential of what you're describing for new versions, so I think that's a decent sounding compromise, but it is a compromise, because ZScript is the lifeblood of many of the most popular ZC Quests these days.

And you very likely will get some people who don't learn angelscript even though they were avid zscripters, even with that, so I think it's also worthwhile to keep that alive, and to allow people to still play older beloved quests (In The Lost Kingdom of the Banana Blood God, Isle of Rebirth, and so on) in newer versions.

So to reiterate: I'm on board with trying a 'keep supporting quests made with zscript, but don't allow newer versions to compile it because there's this other similar thing you can use instead that's better' approach. It's just that it's a tricky balance to strike.

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

I definitely see how you'd want a small, devoted team- otherwise things do get confusing and messy. I think that can be a pretty good idea here. But regarding your example... I can definitely believe it's a mess to work on behind the scenes, but 2.50 came out much more stable than 2.10 from all my experiences as a user, and...

In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. 😊

Yes, this exact thing. 2.50/2.50.1/2.50.2 are the most stable versions of ZC I remember since 1.00 back in 2000.

What I'm trying to say here is that you've already done a fantastic job debugging ZC from what it used to be. There's things I could imagine being improved, but a lot of those are weirdness rooted deeper in the engine- the odd color limitation system and bad translucent colors, the Zelda 1 scrolling/screen size limits, the Zelda 1 subscreen, and so on. Or stuff that can be worked around easily, like how NPCT_WALKER enemies behave poorly in sideview. 2.50 (and the subsequent, even more stable versions) are so great they brought me back to quest development after many years of disinterest, so don't disregard the quality of your own teamwork/accomplishments, here. : )

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

*raises hand* Dimentio, I, and Moosh all came when Zoria told us we should weigh in. But that's only a small portion of that chat, and leaves out people like Evan who made Isle of Rebirth, Grayswandir, ywkls, and several other major scripters. To say nothing of the sheer scope of the PureZC forums proper...

I don't post very much in either forum. By posting as many times as I have in this thread this week, I think I'm actually exceeding the numer of posts I've made on PureZC in the past month, outside of my own private bugtesting thread for my own quest project. I have nothing against either community in their present forms (though I will say AGN was poorly managed when I was a teenager and a younger adult, many years ago; but I didn't go to PureZC very much then, either, and I spent most of 2007-2015 not posting on either forum at all).

I don't see the communities as bickering or rivaling at all anymore... I see AGN as being a quiet place with a few oldbies who like to hang out, and the staff talking about dev topics amongst themselves.

But PureZC, while slightly slow at times, is a much more active ZC community than AGN. Look at their front page updates for stuff that's been added to the database and updates on quest projects; contrast ZeldaClassic.com's cobweb-filled database. Look at youtube let's plays (MeleeWizard, TeamUDF, Pixcalibur123, SCKnuckles, and the list goes on)... which community is more likely to get mentioned, and where more LPers are announcing their videos/streams. Look at the fact that mere unfinished projects can get a lot of comments and followers. Just a couple of months ago they had a successful expo, and I heard the previous year had a bigger one.

This stuff just doesn't happen at AGN; comparatively there's very little for ZC users to do here besides trying to talk to the staff. There's some posts, but look how many of them are either the same very few people, or extremely old threads... the Quest Developers Excahnge subforum, with the mission statement "Trade tiles, midis, maps, palettes, anything related to quest building in ZC"- it hasn't had a post in over a year, almost a year and a half. PureZC's database has had tile submissions and stuff like that in the past few days, and they keep coming.

It's not about 'the communities fighting'; from what I can see those fights are old, dusty, and, I suspect, mostly over. The aftermath is that AGN retains the actual staff and ownership, but PureZC retains the actual majority of the userbase, and that's just how it works these days. If you want to get the userbase's opinion, you have to seek them out where they actually go, not discard the majority userbase as "secondhand" for going to the more active community instead of the ghost town. That's just... marketing.

You also have to realize that a lot of users might not even realize AGN is where the devs go; you have to realize that people aren't sure who the developers are (...heck, when I posted here asking about a list of everybody known to have been part of ZC's staff, I barely got any replies, with very little info on the subject). And even then, between inactivity, social awkwardness, and not thinking of it, a lot of users are extremely unlikely to look you up over here.

I'm glad that you're all here again and that you're trying to rekindle things, and I'm glad War Lord is updating ZeldaClassic.com- without you guys 2.50 wouldn't have even happened, and without War Lord 1.00 might not've saw the light of day. We also owe a lot to Phantom Menace and DarkNation (may he rest in peace). However, for making these big strategic decisions about the future, I really think you should also post some kind of thread at PureZC about it (that is, discuss it at both forums), or get more of their own staff involved and let them set up a forum for that, or something- I'm certain you would get more feedback from actual users that way, instead of just staff members and less than a handful of people that Zoria personally succeeded at dragging over here. : (

To try to wrap up my ramblings on a more positive note, though, I am very excited for the possibility of new developments in ZC. I always like having more options; I got into ZC again because I could finally make a quest with a ton of items, thanks to the 2.50 updates. : )

Saffith 01 Dec 2016, 15:28

ZoriaRPG wrote:I think you had implied in the past that something I had done didn't have proper abstraction? I just want to make certain that setter/getter functions that return something like bool throttleFPS aren't a problem.

That was regarding quest rules specifically. A lot of the other stuff is just exposing internal state for no reason.
https://github.com/ArmageddonGames/ZeldaClassic/pull/29/commits/eff465097589d28aba7df8e8dbf100e0a95b2d49

+	case GAMEPAUSED:
+		ret=Paused?10000:0;
+		break;
+
+	case GAMESHOWFPS:
+		ret=ShowFPS?10000:0;
+		break;
+
+	case GAMESHOWPAL:
+		ret=Showpal?10000:0;
+		break;
+
+	//case GAMENOCLICKFREEZE:
+	  //      ret=disableClickToFreeze?10000:0;
+	    //    break;
+
+	case GAMECLICKFREEZE2:
+		ret=ClickToFreeze?10000:0;
+		break;
+
+	case GAMEPLAYING:
+		ret=Playing?10000:0;
+		break;
+
+	case GAMEDEBUG:
+		ret=__debug?10000:0;
+		break;
+
+	case GAMEDEBUGON:
+		ret=debug_enabled?10000:0;
+		break;
+
+	case GAMEDEBUGON:
+		ret=debug_enabled?10000:0;
+		break;
+
+	case PRESSF12:
+		ret=debug_enabled?10000:0;
+		break;
+
+	case PRESSF11:
+		ret=F11?10000:0;
+		break;
+
+	case PRESSF5:
+		ret=F5?10000:0;
+		break;
+
+	case PRESSFI:
+		ret=keyI?10000:0;
+		break;
+
+	case PRESSFQ:
+		ret=keyQ?10000:0;
+		break;

I defy you to explain how any of that is useful. Or why access to a variable created just for scripts was removed in favor of the one it overrides.

Mitsukara wrote:In support of Zoria, I myself was saying "Wait, if quests that use ZScript stop working in new versions, you're going to lose a ton of your userbase" and "Oh, well, at least people can develop in 2.5.2 instead of the new version, solely for the benefit of continuing to use ZScript".

See, that's the thing. I feel like a lot of opposition to stuff in general is from people who don't fully understand things, and we can't sort it out without talking directly.

Honestly, the whole reason I said anything publicly about AngelScript in the first place was that I anticipated the concerns and wanted to deal with them as soon as possible. But the reaction seemed largely positive, and I thought the misunderstandings were cleared up pretty easily, so now I wonder if everyone forgot or if it was never really settled in the first place.

ZoriaRPG 01 Dec 2016, 15:32

Gleeok wrote:[Thread Hijacking In Progress]
Ooh boy, oh boy. A discussion about getters/setters and abstraction layers! Quick, post the offending code. We've got to figure this out immediately! :P
This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:
[spoiler]
No. Not sarcasm. Haha. Fooled you.
[/spoiler]
[/Thread Hijacking In Progress]

I did them the same way that the other interface getters work:

[spoiler]

case GAMETHROTTLE: ret=Throttlefps?10000:0; break; case GAMEPAUSED: ret=Paused?10000:0; break; case GAMEPLAYING: ret=Playing?10000:0; break; case GAMEHEARTBEEP: ret=heart_beep?10000:0; break; case ONCONVEY: ret=is_on_conveyor?10000:0; break; case ACTTIMEDWARP: ret=activated_timed_warp?10000:0; break; case GOFAST: ret=gofast?10000:0; break; case GETZCVERSION: ret=zcversion*10000; break;

{ "getVersion", ScriptParser::TYPE_FLOAT, GETTER, GETZCVERSION, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getGoFast", ScriptParser::TYPE_BOOL, GETTER, GOFAST, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getActTimedWarp", ScriptParser::TYPE_BOOL, GETTER, ACTTIMEDWARP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getHeartbeep", ScriptParser::TYPE_BOOL, GETTER, GAMEHEARTBEEP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getCapFPS", ScriptParser::TYPE_BOOL, GETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "setCapFPS", ScriptParser::TYPE_VOID, SETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getPaused", ScriptParser::TYPE_BOOL, GETTER, GAMEPAUSED, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getShowFPS", ScriptParser::TYPE_BOOL, GETTER, GAMESHOWFPS, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "setHasPlayed", ScriptParser::TYPE_VOID, SETTER, GAMEHASPLAYED, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },

[/spoiler]

I had to cut out some to get that to fit, such as GetPressF4.

Most of those that I cut are probably useless, but I just shoved all the interface vars in there when I did a few of them, so that I would never have to do them again. If for some reason anyone wants to add an intermediate register, that's fine, but in these cases, I think it's pretty pointless.

I may have lost the file with Set/GetDMapScreenDoor, Set/GetScreenDoor, Set/getScreenState, Set/etDMapScreenState, and a lot of other general purpose getters and setters for that sort of thing, that otherwise work exactly as GetScreenD, SetScreenD, GetDMapScreenD, SetDMapScreenD, and so forth; that would take all of an hour to write up again. I should have it archived, but I don't know where... It was on the drive that fried, and it'd be faster to rewrite it, than to find it on the servers.

ywkls 01 Dec 2016, 16:44

Mitsukara wrote:(I apologize that this following post got rambly.)
*raises hand* Dimentio, I, and Moosh all came when Zoria told us we should weigh in. But that's only a small portion of that chat, and leaves out people like Evan who made Isle of Rebirth, Grayswandir, ywkls, and several other major scripters. To say nothing of the sheer scope of the PureZC forums proper...

Thanks for the vote of confidence on my scripting skills, Mitsukara. As for why I don't post here, I think you explained it rather succinctly with the following quote.

But PureZC, while slightly slow at times, is a much more active ZC community than AGN. Look at their front page updates for stuff that's been added to the database and updates on quest projects; contrast ZeldaClassic.com's cobweb-filled database. Look at youtube let's plays (MeleeWizard, TeamUDF, Pixcalibur123, SCKnuckles, and the list goes on)... which community is more likely to get mentioned, and where more LPers are announcing their videos/streams. Look at the fact that mere unfinished projects can get a lot of comments and followers. Just a couple of months ago they had a successful expo, and I heard the previous year had a bigger one.
This stuff just doesn't happen at AGN; comparatively there's very little for ZC users to do here besides trying to talk to the staff. There's some posts, but look how many of them are either the same very few people, or extremely old threads... the Quest Developers Excahnge subforum, with the mission statement "Trade tiles, midis, maps, palettes, anything related to quest building in ZC"- it hasn't had a post in over a year, almost a year and a half. PureZC's database has had tile submissions and stuff like that in the past few days, and they keep coming.
It's not about 'the communities fighting'; from what I can see those fights are old, dusty, and, I suspect, mostly over. The aftermath is that AGN retains the actual staff and ownership, but PureZC retains the actual majority of the userbase, and that's just how it works these days. If you want to get the userbase's opinion, you have to seek them out where they actually go, not discard the majority userbase as "secondhand" for going to the more active community instead of the ghost town. That's just... marketing.

I don't post for most of these reasons. There's very little activity here. I do post bugs, occasionally; when I find them. But, otherwise; I rely on PureZC.

So, let me see if I can summarize my opinion on the future development of ZC...

A slow transition between the current scripting language and anything else (such as ZScript) seems to be the best solution to that particular quandary.

Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.

Regarding the objectives outlines towards the beginning of this thread...
I'll make a separate post for that.

ywkls 01 Dec 2016, 16:54

[spoiler]

ZoriaRPG wrote:Zelda Classic (Viewer)
General

General::Quest, Save
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
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.
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.
Fix large Link hitbox in sideview.
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?
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 condiered 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.

[/spoiler]

From this post, these are the things I most understand and have seen the need for their creation. (Or have been forced to create odd scripted workaround to do.)
If anyone needs an explanation why on something, I can provide one.

ywkls 01 Dec 2016, 17:13

[spoiler]

ZoriaRPG wrote:This is a separate topic, detailing things that we plan to do, or that we would like to do/add into 2.xx in the future. users are welcome to respond to this, but we'd like to keep feature requests, and bug reports in their own threads.
Note that while this is a list of what we would like to accomplish, there is absolutely no guarantee that we will do all of what you see here!
ZScript
ZScript::Lexer, Parser, Stack
Expand the number of gd registers to a large amount.
Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.
Add some mathematical things, and logical operators.
Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.
Increase the script buffer from ~18MB to MAX_LONG in bytes.
Add 2D and 3D arrays.
Increase array operational pointers from 4096 to *.
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 custom defined datastructs.
Add a few additional types for variables.
Fix error messages to be more useful.
Detect some common errors, such as reading an invalid pointer ( e.g. [FONT=Courier New]LoadNPC(0) [/FONT]) during compilation.
Add new typedefs that would be useful.
Add octal NUMBERS
Expand IDENTIFIER to cover more (useful) symbols.
Add user-defined pointers.
Add user-defined objects.
Add new types, especially those used by AngelScript.
Add compile-time option to 'Export ZScript Code as AngelScript.
--> This would work as 'Export ZScript code to ZASM' does now, and would create a file with the code as AngelScript. This is a 2.60 or 2.65 goal.
Add 'Cross-Compile to AngelScript' output option.
Add token defs for standard var declarations in both cases.
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.

[/list]
ZScript::Global
Add returns to detect if a screen is a dungeon, or other type, based on its DMap.
Read any DMap value.
Pretty much make any value read/write.
Add Subscreen namespace,and allow easy subscreen construction.
Allow datatype typecasting for objects.
Fix problem reading the pointer of a boolean array.
Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.
Add functions to directly modify the palette, or tiles on a pixel-basis, or colour basis, including reading tiles for a colour value.
Add internal global array series as easy to use defaults.
Internalised Remove()
Allow setting an array size with numeric literal equations (e.g. 14+16) or constants.
Allow loading any LSet or ESP, or CSet pal, into a normal CSet pal, or changing CSet values by script.
Allow reading most internal variables, including enemy timers, and whatnot.
Return engine properties as boolean flags; or make returna for uncapped(), and MenuOpen(), and CheatMenu().
Return ZQuest version in which a quest was created as a global int.
Add method of reading system time, and date.
[list]
This would allow setting time, or events in a quest, based on real-time events.

[*]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.

[/LIST]

ZScript::itemdata
Add all editor values, including Attributes[10], and ensure that all item data resources, and itemdata resources cross over, including Sound, Cost, Level, and so forth.
itemdata values at present don't include about 80% of item attributes.
e.g. The values for a Peril Ring, only allow modifying its Power, but not its min_hearts. We can solve this by ensuring that all attributes are available (read/write, while we're at it).
Allow custom itemclass definitions, and arguments via Attributes[10]
Make all values read/write.

ZScript:Objects
Get UIDS of all objects.
Use UIDs as references.
Store the script id that spawns a weapon, ffc or npc with it.
Add a NoRemove boolean to all objects, so that if they are off-screen, they are not removed when this is set.
All object types should have 'bool ObeysGravity'.
ZScript::*weapon
Allow easy crossing of all itemdata values. This is to allow making a weapon by reading the itemdata values of any existing item, or npcdata (see below).
Correct bomb and flag interaction with wLitBomb and wBOOM for scripted explosions, possibly adding LW_EXPLOSION as its own weapon type.
Add bool ObeysGravity to all weapons.
ZScript::npc
Add Defences[] for all ten script types.
Ensure that all values are r/w.
Allow creation of custom npc classes (with attributes defined by script).
Add npc weapon attributes to match all values available to *weapon, so that the user may set them.
This includes, for example., npc->WeaponSound, npc->WeaponPower, npc->WeaponSprite, and the like.
Make all values r/w.
Give components of a segmented enemy unique flags, and allow access to them individually.
Add user-defined movement styles.
Replace(npc n) to change one npc for another, without needing to silently kill one, and spawn another.
Add ->Invincible attribute. Read to see if an npc is invincible, or set true to make it invincible.
ZScript::npcdata
We plan to add this, to operate as itemdata for nocs, so that you can read npc values without creating them, and waiting for them to spawn.
Dynamically modify main npc attributes, such as walk type.
ZScript::Link
Add [FONT=Courier New]Walkspeed [/FONT]attribute as a variable.
Make all values r/w
Add Link->Extend, so that all the Link hitbox, and drawoffset, and similar things work.
Allow setting Link->Tile
Allow pre-waitdraw adjustments to Link variables that do not work at present.
Make all values r/w.
Add shield block flags to cover all script types.
Add some ->Action types
Add Z3 sword class.
Add a flagset to indicate button presses, and inputs.
Add ->Invincible attribute. Read to see if Link is invincible, or set true to make him invincible.
ZScript::Screen
Increase Screen->D[] regs to 256.
Add function to SetScreenBoundary() s that scrolling occurs when the player passes its event horizon, instead of the default screen edge. This would allow for different screen sizes.
Display passive subscreen, set by flag, or script.
Read/set any screen flag by script.
Read npc lists from any screen in the game.
Add TriggerSecret(int specific_secret) -- This will require making secrets into a flagset on the ZScript side.
ZScript::Script Drawing
Add additional routines for bitmap handling, including translucent rendering to screen.
Increase bitmap area to a very large size (possibly for advanced panning, or scrolling)
Add missing drawing functions, such as Polygon() and Polygon3d()
Allow setting a bitmap as a texture to a drawn object.
Allow creating user-defined bitmaps with user-defined IDs at specific sizes.
Allow saving user bitmaps directly in the quest file.
ZScript::ffc
Complete solidity flag, and allow it to be used with multiple types.
Add solidity bounds as variables.
ZQuest Editor

Editor::Enemies
Add editor flags for various npc options, including invisibility (by type) and reveal invis (by item).
Add block flags by specific script type.
Add death sprite, and other death effects.
Move hardcoded enemy effects to user-defined attributes.
Add 'Invisible', 'Cloaked', Item Class Reveals Insivible [ field ], Item Reveals Invisible [ field ], Itemclass Reveals Cloaked [ field ], Item reveals cloaked [ field ] to the ditor.
--> This would allow the user to specify if an enemy is cloaked, or invisible, and set up a specific item, or itemclass to reveal them.
Add 'Lens Reveals Invisible', 'Lens Reveals Cloaked', 'Amulet Reveals Invisible', and 'Amulet Reveals Cloaked' to each enemy as checkboxes. These work in addition to the specified classes, and items (above).
Add 'Splits into enemy (ID, number of enemies) on hit', Splits into (enemy ID, number of enemies) fields to every enemy.
Add all ten script defence types as individual settings.
->Generic 'Script' would continue to work for any type.
Add 'Split' as a defence outcome. This means that the enemy will split into its defined split variety when hurt by the specified weapon type.
Add 'Whistle' defence type. Make Digdogger's Whislte Defence 'Split'
Add combo type 'Sideview Ladder'
Add combo type 'Pit (Damage)' with different heart damage values and falling LTMs. This should make a sound, set LA_FALLING, and send Link back to the spot at which he entered the screen.
Add combo type 'Lava/Fire' with damage values. This should make a sound and send Link back to the spot at which he entered the screen.
Add Link->Action LA_ONFIRE
Add Link->Action LA_FALLING
Add Link Variable FireDamage
Fix LA_SPINNING so that it does the spin animation on demand.
Fix LA_CHARGING so that it always displays a charging animation.
Add Link var ChargingItem so that we can set what item Link is holding out.
Maybe ChargingSprite?
Add Link->Useitem(int itm). This will use an item even of it isn't in an A/B slot.
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.
Add Link->EquippedItems. When gaining an item, this is set true by default, but can be disabled/enabled without needing to set owning the item to false to temp orarily disable it, or allow equip menus/subscreens.
Add Link variable FireDuration. This should be reduced by 1 per frame, internally.
Add Link->Input and Link->Press flagsets.
Editor::Items
Add 'Can Pick up Items [ field: list item numbers, separated by commas ]' to allow the item to pick up anything listed that it touches.
Add 'Deliver items picked up on contact' and 'deliver items picked up when weapon returns to Link' as options for delivery.
Allow setting the Misc Attributes for generic class items as [ text fields ] instead of greyed out pulldowns.

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.
Editor::Other
Add flag editor.
Add font editor.
Enhance subscreen editor to support multiple pages, and other action types (equip/unequip)
Add option to use specific script object (weapon, or otherwise) in editor options that use them.
Allow setting any pulldown value to a custom value (with field for entry). For example, npc and item values.
Add additional user-defined flags, for use with flag editor.
Add SCCs for more robust options, and to complete some partially-implemented things.
Allow more than 8 script args for editor panes.
Display passive subscreen as a separate option from show subscreen in editor pane.
Allow setting subscreen display by DMap, instead of by specific screen.
Allow any screen flag to be set for all screens on a given DMap from one editor pane.
Add quest templates, with pre-loaded tiles, scripts (enemy, bods, engine, items), for 'Z3-esque', Gameboy-esque', and 'RPG'.
--> These could probably use a *.cgf file to set that, and whatnot, that is read into a buffer. We could then present it in its own GUI window, where a user may toggle settings, and when a user changes (and commits) anything, ZQ would automatically (and silently) recompile using the .cgf file through an import directive in the main buffer.
--> pretty much, when the user saves changes, the save is written to the *.cfg file, and then the main buffer (with a call to [FONT=Courier New]import "questtemplate*.cfg[/FONT]" is recompiled, and all slots automatically reassigned, without displaying any of the manual parts of compiling.
--> This is so that the user never needs to look at the scripts directly.
--> Essentially a new 'Classic/Z1' quest would be what we use now, but the other options would load a quest template with all of the things needed to make that style of quest, pre-configured.

[/spoiler]

I can't think of any reason why most scripters wouldn't want most of the things on this list. As for whether we'll actually get them... that's an entirely different kettle of fish.

ZoriaRPG admits to that and I think that this topic has gotten away from "how can we improve ZC realistically in a time frame that isn't so long where a lot of people lose interest."

My own specific most wanted would be the improvements for Scripted weapons types both in enemy and Link defense, easy adjustment to Link's appearance via script, read and writing flags like Dmap, Screen and other things which aren't currently accessible and improvements to gd registers and script buffer size.

I've lost track of the weird workarounds I've had to do in order to accomplish many of the things on this list (and the other one) and having the ability to control them via script would have definitely made it easier.

Saffith 01 Dec 2016, 19:24

ywkls wrote:Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.

Nothing like that. Everything may be converted to scripts, but they'll all be loaded up by default and placed much like they are now. Anyone who doesn't want to mess with script stuff won't have to. That's not going to change.

ywkls wrote:ZoriaRPG admits to that and I think that this topic has gotten away from "how can we improve ZC realistically in a time frame that isn't so long where a lot of people lose interest."

Realistically is the problematic bit. We can come up with all sorts of ideas, but making even small changes is often difficult, and doing so without breaking existing quests or making future support harder isn't always possible.

ZoriaRPG 01 Dec 2016, 20:13

ywkls wrote:Thanks for the vote of confidence on my scripting skills, Mitsukara. As for why I don't post here, I think you explained it rather succinctly with the following quote.
A slow transition between the current scripting language and anything else (such as ZScript) seems to be the best solution to that particular quandary.
Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.
Regarding the objectives outlines towards the beginning of this thread...
I'll make a separate post for that.

Pretty much, even Solarus will eventually have some way of interfacing with the object scripts via GUI. [MENTION=61144]Christopho[/MENTION] has stated that's part of his goal with the editors.

The basic idea, is that instead of an npc, or an item, hardcoded in the engine, it has a 'built-in' script, that controls it. The user may modify that, or use it as-is; and instead of the editor changing values that affect how its internal coding works, an editor pane will set script attributes.

As I mentioned, I had an idea on how to do this (using ZScript), for npc scripts; disabling the hard-coded behaviour, and using something similar to how an ffc script works, save that they are only loaded when an npc is in use, per npc. The idea what that the 'NPC Type' selector in the enemy editor would have up to N script slots, and selecting one of those would disable any internal behaviour, and run that script to control the npc. I can't say how practical that would have been, or if anyone else would even have approved it, but it could be workable.

Effectively, it would be similar to how item scripts are selected from the item editor, and run when the item is used, save that it would persist until the npc is removed, and its pointer invalidated.

Gleeok 02 Dec 2016, 01:49

ZoriaRPG wrote:I did them the same way that the other interface getters work:

[spoiler]

case GAMETHROTTLE: ret=Throttlefps?10000:0; break; case GAMEPAUSED: ret=Paused?10000:0; break; case GAMEPLAYING: ret=Playing?10000:0; break; case GAMEHEARTBEEP: ret=heart_beep?10000:0; break; case ONCONVEY: ret=is_on_conveyor?10000:0; break; case ACTTIMEDWARP: ret=activated_timed_warp?10000:0; break; case GOFAST: ret=gofast?10000:0; break; case GETZCVERSION: ret=zcversion*10000; break;

{ "getVersion", ScriptParser::TYPE_FLOAT, GETTER, GETZCVERSION, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getGoFast", ScriptParser::TYPE_BOOL, GETTER, GOFAST, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getActTimedWarp", ScriptParser::TYPE_BOOL, GETTER, ACTTIMEDWARP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getHeartbeep", ScriptParser::TYPE_BOOL, GETTER, GAMEHEARTBEEP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getCapFPS", ScriptParser::TYPE_BOOL, GETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "setCapFPS", ScriptParser::TYPE_VOID, SETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getPaused", ScriptParser::TYPE_BOOL, GETTER, GAMEPAUSED, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getShowFPS", ScriptParser::TYPE_BOOL, GETTER, GAMESHOWFPS, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "setHasPlayed", ScriptParser::TYPE_VOID, SETTER, GAMEHASPLAYED, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },

[/spoiler]

I had to cut out some to get that to fit, such as GetPressF4.

Most of those that I cut are probably useless, but I just shoved all the interface vars in there when I did a few of them, so that I would never have to do them again. If for some reason anyone wants to add an intermediate register, that's fine, but in these cases, I think it's pretty pointless.

I may have lost the file with Set/GetDMapScreenDoor, Set/GetScreenDoor, Set/getScreenState, Set/etDMapScreenState, and a lot of other general purpose getters and setters for that sort of thing, that otherwise work exactly as GetScreenD, SetScreenD, GetDMapScreenD, SetDMapScreenD, and so forth; that would take all of an hour to write up again. I should have it archived, but I don't know where... It was on the drive that fried, and it'd be faster to rewrite it, than to find it on the servers.

Ah yes, The programmers version of TMI. 😉 Many an API has been over-engineered since the dawn of interface design, and it's always hard to get right (I still mess it up). I agree with Saffith here. That is just much /too much.

Especially this one:


case GAMEPAUSED: // INVALID CODE PATH
        ret=Paused?10000:0;  // This will never actually run because the scripts are paused...
        break;

I mentioned this before but a simple int Game->EngineProperty[] and int Game->QuestRule[] would take care of all of these things. I hadn't put them in because 2.5 was supposed version compatible (Although soon it probably won't matter anyway).

ZoriaRPG 02 Dec 2016, 02:16

Gleeok wrote:Ah yes, The programmers version of TMI. 😉 Many an API has been over-engineered since the dawn of interface design, and it's always hard to get right (I still mess it up). I agree with Saffith here. That is just much /too much.
Especially this one:
case GAMEPAUSED: // INVALID CODE PATH
        ret=Paused?10000:0;  // This will never actually run because the scripts are paused...
        break;
I mentioned this before but a simple int Game->EngineProperty[] and int Game->QuestRule[] would take care of all of these things. I hadn't put them in because 2.5 was supposed version compatible (Although soon it probably won't matter anyway).

As I said, I just dumped the entire list of vars into a file, and built a getter on them, as it was a painless thing to do. There are probably four that should be in there.

I suggested turning the QRs into a r/w array, but that was rejected by Saffith. Even if it could only cover some of them, the rules that can be modified on the fly, it would be useful IMO. Also, moving things like 'Big Link Sprite' into a Link class property, pretty much as TileHeight/TileWidth, were on my list, but that's another matter.

{ "getHeartbeep", ScriptParser::TYPE_BOOL, GETTER, GAMEHEARTBEEP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "getCapFPS", ScriptParser::TYPE_BOOL, GETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } }, { "setCapFPS", ScriptParser::TYPE_VOID, SETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },

{ "setHasPlayed", ScriptParser::TYPE_VOID, SETTER, GAMEHASPLAYED, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },

Those were what I planned to retain, above all else. I left out SetHeartBeep, which while it may seem an oversight, is because I wanted to do Link->HeartbeepSfx and Link->HeartBeepContinuous as separate commands, given that you can't set the sound by script at all at present. I also wanted to do Link->HurtSound and Link->HurtEffect (none, flicker, flash).

one of that was stuff that I wanted to d for the very next release. I would frankly do more frequent, smaller updates that are easier to debug, than roll everything into one massive update and play 'now let's see what breaks'. That is exactly why I wanted to do an incremental 2.53, 2.5, and 2.55, each with a small subset of new features, and more bugfixes.

The new drawing stuff, some additional setters, getters, and a few new commands were all of what I wanted to do for '2.53'. Something that isn't likely to cause problems, that gives users something new to try.

Tamamo 08 Dec 2016, 12:56

That's not true at all [MENTION=42228]ZoriaRPG[/MENTION]
I abandoned it because making sure you dicks get along and keep getting along is more important at this time. And that is quite tiring. I haven't gotten an complaint from anyone in while dev or nondev alike (i get both, and I keep them annonymous) it's clear we can't get along. Especially with the lack of communication going on.
Gleeok simple just doesn't give a damn. Saffith has Autism so that leaves? oh wait... that's all the major devs... Oh well. Looks like a volunteer is gonna have to do it.

[MENTION=59858]Moosh[/MENTION]
we're not adding angelscript ever, and I'm adamant about that... It's a terrible languange anyways and I would be much more in favor of rewriting Zelda Classic from scratch to be moddable with pluggins just makes more sense.

ZoriaRPG 08 Dec 2016, 13:19

Tamamo wrote:That's not true at all [MENTION=42228]ZoriaRPG[/MENTION]
I abandoned it because making sure you dicks get along and keep getting along is more important at this time. And that is quite tiring. I haven't gotten an complaint from anyone in while dev or nondev alike (i get both, and I keep them annonymous) it's clear we can't get along. Especially with the lack of communication going on.
Gleeok simple just doesn't give a damn. Saffith has Autism so that leaves? oh wait... that's all the major devs... Oh well. Looks like a volunteer is gonna have to do it.
[MENTION=59858]Moosh[/MENTION]
we're not adding angelscript ever, and I'm adamant about that... It's a terrible languange anyways and I would be much more in favor of rewriting Zelda Classic from scratch to be moddable with pluggins just makes more sense.

Frack, I don't actually remember what you are quoting at this point... I know you're tired of the bantering though; as am I, which is why I'll work on this, make some usable builds, and see what happens.

At least we seem to be making some sort of progress, now that we're discussing these things on the forum, instead of behind closed doors, with everyone having different concepts on what's happening. I might try adding keypress detection for the whole keyboard (available to ZScript) next. That way we can forget about adding any new graphical stuff, and we can all make early-80s style TBAs. 😛

Oh, did I mention usable builds?

Tamamo 08 Dec 2016, 13:31

ZoriaRPG wrote: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.

ZoriaRPG 08 Dec 2016, 16:52

Tamamo wrote:

Oh, right. I was being somewhat polite, there: 'everything she wanted to do was rejected'.

i.e., You wanted to do things, and we all went into bicker mode, every time.

DarkDragon 09 Dec 2016, 09:56

I don't really know what's going on, but if the complaint is that the devs are being too stringent about accepting patches for new features into the repository, I confess I'm very much on the side of the developers.

Patches should absolutely be rejected unless accompanied by a detailed, compelling rationale assessing the impact the patch will have on constraining future development and maintenance. The price for new features is not paid today, but over the next 10-20 years as all future versions of Zelda Classic must be warped to fit around them. Open up any of the source files and you'll quickly find an example of an obscure feature on which we're still paying interest today: all of the different Link movement quest rules; Link tile modifiers; Big Link; the fact that even the emptiest quest has a huge memory footprint due to the reckless allocation of global and screen scripting variables, etc.

ZoriaRPG 17 Jan 2017, 10:39

17th January, 2017: Updated features, and plans, to indicate recent progress, current to Beta 52r5.

ZoriaRPG 19 Feb 2017, 12:51

This is primarily a list of ideas that we would like to implement, and it exists so that we can track them, discuss them, and remember them over time...

None of these are promised, or guaranteed.

Additional 2.future and ZC Canonical Planned Features and Improvements

Allow setting shop price text colour, font.
Add Z3 style shop option. This should be a menu selection for the shop, or a flag int he shop editor, not a QR.

Correct Patra movement, and add an enemy editor flag for them. Patras on the NES wrap around the screen edges.
Correct Ganon NES movement pattern, and add an enemy editor flag to enable it.

Add Z3 bosses.

Fix sprite editor. Add in contextual copy/paste menu, and display the sprite number in the lister.

Make screen-based flags global, or by dmap. Sideview gravity, as an example, should be available by screen, dmap, or as a global quest setting.

Add 'Goto DMap' hotkey and menu option.
Add 'Goto Screen' hotkey and menu option.

Add assets locator (find command) that outputs a lister showing locations of any given asset, with buttons to jump to the map and screen with that asset.

Add TileWidth, TileHeight, HitWidth, HitHeight, HitZHeight, HitXOffset, HitYOffset, DrawXOffset, and DrawYOffset to npc, and item editors.

Add special reflect flags to all weapons, to allow any other weapon to reflect them. This would make it easy to make an Aghanim style enemy, or similar effects.

Add animations, and other visual effects, including lightning, fog, mist, flames, wind, water. Allow setting these to item usage, weapon usage, npc actions, and screen or dmap flags. These should also be able to be called by script.

Make all extant animations able to be called by script, and generated by items, npcs, and so forth.

Add flags or rules for counters (signed, unsigned, 16b, 32b, rolls over).

More to follow.

Improved Tile Editor: Edit entire tile pages in pixel view, and pan around, with levels of zoom.
Export tile pages in a raw format, and import them in a raw format. This would improve colour conversion issues.

Add enhanced music flags to npcs and items. When an npc with an enhanced music flag (and filename) is on-screen, that music is loaded. The lowest numbered npc on the list with enhanced music, will play; so multiple npcs with enhanced music will be enqueued. The music will be loaded one time, and when that npc dies, the list is rechecked. If a different filename is found, that one will begin playing. If other npcs have the same music file. the music will continue. If no npcs remain with music files, the normal dmap music will resume.

This could in theory, also be done for items, and for screens. Each screen could have unique special-case music.

Load any colour into a palette index by script. CHange palettes by script. Load ESPs by script. Edit ESPs and LPals by script.

Add global boolean to disable keyboard input from registering as button presses (set by script). Note: Main system buttons (e.g. F6, F10) will be excluded from being disabled.
Add global boolean to prevent keyboard presses from triggering cheat menus. THis should be an array, with an index per key used, each set by script.

These are to streamline keyboard input by script, so that keypresses can be protected, and prevented from doing anything other than generating a character.

Expand itemclass count from 256 to 512. Classes 163 to 255 (z###) should be user classes. It would be nice to allow the user to rename them. Classes 256 to 511 should not be visible to the user, until we add items for them.

Add any new item classes, after this. Because users already use the z### classes, we can;t just use them as originally planned.,

Add Allegro LoadBitmap() and SaveBitmap() to ZScript.

Revise item editor 'rupee cost' flag. Change Magic Cost to ''Counter Cost' and add a JWIN_SELECT_PROC menu to select the counter ref, with magic as the default.

Copy screen layer, and paste as layer zquest hotkeys. Paste as layer pastes a copied screen, or a copied layer to the selected layer.

Grayswandir 21 Feb 2017, 03:14

ZoriaRPG wrote:Please look over the ZScript Parser things on this list, and let me know which of them are on your to-do list, and which you will likely never do, or want to do:

So, here are my thoughts:

ZScript::Lexer, Parser, Stack

Expand the number of gd registers to a large amount.

Definitely want to do this, but I'll need to learn the ZC save code first, so it's not a priority.

Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.

I'll probably stick this in as soon as I learn how to add gui elements for whatever other reason.

Add some mathematical things, and logical operators.( !<, !>, ^^, NAND, NOR).

Unsure how useful these are. A low priority, and I'd want to check if anybody has objections beforehand.

Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.

Sure? Not really a parser thing, though. No plans for when at the moment.

Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.

This is done, I think? It's green.

Add some directives.

Wonderfully vague. :P

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

Again, I'd need to learn the save format, so wanted but not really going to happen soon.

Add additional routines for handling of strings. : Some implementation of string literals is done.

Anonymous Strings are already done. I want to add TraceS(array, offset) and similar eventually, but not a priority.

Add 2D and 3D arrays.

Working on some prep work for this currently, kinda.

Add special datatypes, and declarations.

Again, kinda working on this at the moment.

Allow global datatype pointers/declarations. This involves preallocating some for this use, similar to arrays.

Not sure what you mean by preallocating here. Otherwise it's fairly simple to switch on now, as I mentioned the other day.

Increase array operational pointers from 4096 to *.

Again, sounds good, but need to learn how first.

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

Again, sounds good, but need to learn how first.

Add extra preprocessing support.

Meh.

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

Not sure if we want ? specifically - might want to add in ternary operators or something.

Add function pointers.

I'm getting closer to adding these in, but some other stuff is taking priority. They'll go in a soon as I'm done, though.

Add custom defined datastructs.

Pretty soon.

Add a few additional types for variables. : I was originally thinking of adding byte, char, long.

Not sure how these'd be useful? Would long take 2 registers?

Fix error messages to be more useful.

Again, nice, but kinda vague.

Detect some common errors, such as reading an invalid pointer ( e.g. [FONT=&amp]LoadNPC(0) [/FONT]) during compilation.

Sounds neat, but not really a high priority.

Include support for linked lists and hash tables internally.

Not really a high priority, kinda surprisingly. I'll probably add these in when it becomes convenient, but I won't specifically work towards them.

Add new typedefs that would be useful. : Grayswandir added typedef.

I didn't particularly want this feature, but I needed some way to test that type scoping was working properly. 😊

Add new tokens, such as switch, case, and the like. : Added switch-case; still need define and enum.

enum sounds good. I'm still wary of define.

Add new directives, such as #DEFINE

ditto

Add octal NUMBERS

These are in already?

Expand IDENTIFIER to cover more (useful) symbols.

Not sure what else is wanted.

Add user-defined pointers.

???

Add user-defined objects.
Add new types, especially those used by AngelScript.
Add compile-time option to 'Export ZScript Code as AngelScript.
--> This would work as 'Export ZScript code to ZASM' does now, and would create a file with the code as AngelScript. This is a 2.60 or 2.65 goal.
Add 'Cross-Compile to AngelScript' output option.
Add token defs for standard var declarations in both cases.

All these are pretty far in the future. They'll depend on how AS turns out.

Add AngelScript style [FONT=&amp]and[/FONT] token, and [FONT=&amp]or[/FONT] token.

Trivial to implement.

Add [FONT=&amp]Until()[/FONT] and [FONT=&amp]Unless() [/FONT]expressions.

Unsure if these are warranted.

Add Repeat(int iterations) loop type.

Low priority.

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.

[/LIST]
No idea how to go about doing so. Low priority.

ZoriaRPG 21 Feb 2017, 18:47

Grayswandir wrote:So, here are my thoughts:
ZScript::Lexer, Parser, Stack
Expand the number of gd registers to a large amount.

Definitely want to do this, but I'll need to learn the ZC save code first, so it's not a priority.

Inform me if you need help with that.

Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.

I'll probably stick this in as soon as I learn how to add gui elements for whatever other reason.

I need to know if [MENTION=1]DarkDragon[/MENTION] 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.

Add some mathematical things, and logical operators.( !<, !>, ^^, NAND, NOR).

Unsure how useful these are. A low priority, and I'd want to check if anybody has objections beforehand.

It would be good to discuss if any of these should not be implemented first, aye. IMO, NAND, NOR, and similar boolean logic should. Logical Xor, possibly. !< and !> might be useful syntactically.

Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.

Sure? Not really a parser thing, though. No plans for when at the moment.

This one should have been marked 'not allowed for canonical'...?

Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.

This is done, I think? It's green.

'It is....it is..... It is green.'

Add some directives.

Wonderfully vague. :P

I was originally thinking of adding #include and #if, along with #define.

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

Again, I'd need to learn the save format, so wanted but not really going to happen soon.

[MENTION=1]DarkDragon[/MENTION] wanted to give each script its own buffer and store them with the quest. Is that still happening?

Add additional routines for handling of strings. : Some implementation of string literals is done.

Anonymous Strings are already done. I want to add TraceS(array, offset) and similar eventually, but not a priority.

Sure. Real strings, or 2D arrays would have a much higher priority.

Add 2D and 3D arrays.

Working on some prep work for this currently, kinda.

Oh? This ended up on my quasi-abandoned list, as I wasn't certain how to begin to implement them globally; and had other concerns. If you have a way, by all means.

Add special datatypes, and declarations.

Again, kinda working on this at the moment.
Allow global datatype pointers/declarations. This involves preallocating some for this use, similar to arrays.

Not sure what you mean by preallocating here. Otherwise it's fairly simple to switch on now, as I mentioned the other day.

Global pointers /are/ preAllocated with the quest at compile time, but it would be nice to get away from that, if there is any way to do it--hint--there isn't as the preallocation is stored in the quest save file. I was going to give them their own array pointers pool, so that global int/float/bool arrays and special case types had separation, though. Mostly as a safety thing.

Increase array operational pointers from 4096 to *.

Again, sounds good, but need to learn how first.
Increase other operational pointers for datatype objects from 255 to *.

Again, sounds good, but need to learn how first.

When I finish the other stuff, amd we merge it all, I'll work on this with you. This part should not be hard for me at all.

Add extra preprocessing support.

Meh.

What happened to that template that you showed to me last month? It looked viable.

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

Not sure if we want ? specifically - might want to add in ternary operators or something.

If it can be ensured not to get in the way of ternary. This was one of /your/ suggestions a year ago, and I wrote up some IDENTIFIER defs for it. Ternary is a higher priority.

Add function pointers.

I'm getting closer to adding these in, but some other stuff is taking priority. They'll go in a soon as I'm done, though.

Know the feeling.

Add custom defined datastructs.

Pretty soon.

Ace.

Add a few additional types for variables. : I was originally thinking of adding byte, char, long.

Not sure how these'd be useful? Would long take 2 registers?

Long is probably out. I did want to add int18 (igr), which would be auto-truncated, or any int that is auto-truncated. Many of these were just ideas, or a way to handle special values for AS conversion, latter. There is a list of them: http://timelord.insomnia247.nl/zc/ffscript_Update_16.lpp

Fix error messages to be more useful.

Again, nice, but kinda vague.

File that under 'note to self'. I'm going to add more verbose and informative errors, but we may need a directive to enable/suppress them.

Detect some common errors, such as reading an invalid pointer ( e.g. [FONT=&]LoadNPC(0) [/FONT]) during compilation.

Sounds neat, but not really a high priority.

Would belong with an IDE or preprocessor.

Include support for linked lists and hash tables internally.

Not really a high priority, kinda surprisingly. I'll probably add these in when it becomes convenient, but I won't specifically work towards them.

This also, was your suggestion a year ago.

Add new typedefs that would be useful. : Grayswandir added typedef.

I didn't particularly want this feature, but I needed some way to test that type scoping was working properly. 😊

No, no, that was awesome. Ace.

Add new tokens, such as switch, case, and the like. : Added switch-case; still need define and enum.

enum sounds good. I'm still wary of define.
Add new directives, such as #DEFINE

ditto

What exactly is your issue with define? With typedef it isn't needed, unless constants are ever revised to be a special datatype, or something; but still...what is it harming? It is literally a few extra lines of AST.

Add octal NUMBERS

These are in already?

They were a year ago, then I pulled them pending some answer on what base we would use. I don't know if I ever did the correct AST for returning them. I see this as 'potentially useful'.

Expand IDENTIFIER to cover more (useful) symbols.

Not sure what else is wanted.

People wanted *, which is dumb. That should be reserved for pointers, but in theory, flex could support some chars that we don't use. I let this one die on the vine.

Add user-defined pointers.

???

For real arrays, and to reference arrays or objects; and for function params.

Add user-defined objects.

Why did you lump this with AS stuff?

[*]Add new types, especially those used by AngelScript.
[*]Add compile-time option to 'Export ZScript Code as AngelScript.
--> This would work as 'Export ZScript code to ZASM' does now, and would create a file with the code as AngelScript. This is a 2.60 or 2.65 goal.
[*]Add 'Cross-Compile to AngelScript' output option.
[*]Add token defs for standard var declarations in both cases.
[/LIST]
All these are pretty far in the future. They'll depend on how AS turns out.

May as well be prepared for the need.

Add AngelScript style [FONT=&]and[/FONT] token, and [FONT=&]or[/FONT] token.

Trivial to implement.

Tried? I would add a parser mode to disable this, btw, for the weird case of someone declaring int and.

Add [FONT=&]Until()[/FONT] and [FONT=&]Unless() [/FONT]expressions.

Unsure if these are warranted.
Add Repeat(int iterations) loop type.

Low priority.

I happen to like Until and Unless, syntactically. I will entertain arguments against any of these three. Repeat() was one of yours, and I like it, too.

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.

[/LIST]
No idea how to go about doing so. Low priority.

[/quote]

Actually, this would potentially be viable. Load the new maps, map datum, items,tiles, combos, npcs, and alll scripts, without clearing the system RAM. All of these things are loaded in a modular manner, so it's mostly a matter of giving the parser a directive to execute a special load function in qst.cpp. If you make a bison/ast side function for this, that calls 'ScriptLoadQst("filename"😉, I could probably tack in a preliminary load routine in a month or so.--the delay, because of the other things on my agenda that must come first.

This would need to occur post-merge, because some load routines have changed, particularly script loading, and it would be critical not to clear the GD regs, and Link's equipment/stats/counters. That seems not too terrible.