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

[Gleeok]

[Thread Hijacking In Progress]

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!


This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:

Spoiler: show

No. Not sarcasm. Haha. Fooled you.

[/Thread Hijacking In Progress]

[Mitsukara]

(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]

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/Z...f100e0a95b2d49

+	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.

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]

[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!


This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:

Spoiler: show

No. Not sarcasm. Haha. Fooled you.

[/Thread Hijacking In Progress]

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

Spoiler: show

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                           } },

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]

(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]

Spoiler: show

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.

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]

Spoiler: show

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 ? (question-mark) to be used in function names, such as ?InAir()
• 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. LoadNPC(0) ) 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 and token, and or token.
• Add Until() and Unless() 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.
  
  • This would allow setting time, or events in a quest, based on real-time events.
• Add PrintToLog(char str) to ZScript.
  
  • This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.

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 Walkspeed 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 import "questtemplate*.cfg" 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.

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]

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.

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]

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. @Christopho 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]

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

Spoiler: show

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                           } },

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).