ZC [2.future] Feature Requests

[Demonlink]

Hmmm, a few features I would like you guys to consider are the following:

1) Sideview ladders (given the variety of scripts at PureZC are either broken or don't have all functions to work properly).
2) Sideview water (because why not?)
3) I'm not sure if this would directly affect the engine, but another request would be expanding the Palette table to use more than just CSets 2, 3, 4 and 9.
4) Lastly, a few new items wouldn't hurt, like the Pegasus Boots, Shovel, and such. I know they're already existent as scripts, but I feel they would work better being hardcoded in the engine, because by doing this, you can save a lot of scripting space, flags and misc. Plus, sometimes setup is a bit quirky, especially when you want to combine them with other scripts.

So far, those are the only things that I could come up with.

[ZoriaRPG]

Hmmm, a few features I would like you guys to consider are the following:

1) Sideview ladders (given the variety of scripts at PureZC are either broken or don't have all functions to work properly).
2) Sideview water (because why not?)
3) I'm not sure if this would directly affect the engine, but another request would be expanding the Palette table to use more than just CSets 2, 3, 4 and 9.
4) Lastly, a few new items wouldn't hurt, like the Pegasus Boots, Shovel, and such. I know they're already existent as scripts, but I feel they would work better being hardcoded in the engine, because by doing this, you can save a lot of scripting space, flags and misc. Plus, sometimes setup is a bit quirky, especially when you want to combine them with other scripts.

So far, those are the only things that I could come up with.

We'll certainly be goinginto some sideview fixes. I think that was on the to-do list already, but if not, I'll add it.

I've had a list of hardcoded item requests, and to be fair, some might be viable, however, here's the catch:

All new item classes would need to be added to the table. We wouldn't use any of the 256 classes, as doing that could break quests. Say that we made zz95 the boots: Anyone using that for a custom item, would have a broken quest in 2.55. I also don;t want us to add items that are easy to do with scripts. Boots, maybe, but I was thinking of making Link's walking speed, and animation, a variable.

A shovel would be easy to add, but people might want it to work differently. Plus, it could end up being a Link class item if we did it traditionally. I might do that though, as it's a common Zelda item that wouldn't be terrible, however we'll need to define a new Link->Action (LA_DIGGING) and animation.

My main concern with hardcoding new items is that people will want them to work differently, like the sword, now. Soke though, would in fact make sense.

I was actually thinking of doing something different: Making pre-packaged quest templates, for quest styles, that have pre-included and compiled items, and engine effects. I've already been working on one that emulates the Gameboy style games, and we could include thingslike thatto allow expandeditem lists, without needing to hardcode them.

If we hardcode anything, i think the ice rod, fire rod, and cane of somaria are the most popular requests. We do need to fix/change magic consumption on a frame basis, and add a timed consumption value to all the items, particularly the Cane of Byrna.

Sideview Castlevania-styled staircases. Just like in Link stuck in Castlevania.
Extend combo type and combo flag tables. 5 scripted entries in both tables sometimes is not enough.
Screen->SecretCombos[] r/w.
Screen->UndoSecrets(). Flicking gates on and off, rotating bridges are examples.
Syntax highlighting in buffer.

A flag editor is planned, as are additional custom flag IDs.
I like Screen->Secrets(false), and I can;t believe that I forgot about this. Really, I'd like to make it possible to individually set/unset screen secrets.

r/w Undercombos, is good.

Not sure about stairs internally, as that would require massive reworking, but grawswandir might be willing to do it.

I'm gonna be that annoying guy.

I'm sure it's going to be worked on, but of course ALttP scrolling. Another thing I feel is important is some sort of way to talk to NPCs/signs without the use of a script.

A big one would be to get rid of the subscreen, and use subscreen elements ON the actual screen, like a normal 3D Zelda games. I know some ZC quests have attempted and succeeded with this! It would be amazing to use from the get-go.

Good luck on making this semi-new engine!

@Lynker
That would actually belong in the ZC 3.0 Suggestions. ZC Scrolling would requiring rewriting most of 2.x.
It's something I've thought about myself, it's possible. But it would be a pain in the ass to code.

Precisely. I'll just say it now: Z3 scrolling (internally) is not planned for 2.future. This is the most anticipated feature request of the lot, and I'm not saying it's impossible, but some of the changes that we're making could greatly improve custom scrolling engines. I've already made a scrolling engine, and with some of the changes that we're making, if this becomes viable, I'd rather include a template quest for it.

Reading enemy lists from any screen is the biggest single thing that we plan to add that will improve scrolling engines, and the npcdata class is a close second.

The same applies to changing the screen dimensions. Making subscreens invisible is on the list, but making the screen square is not, for very good reasons. Most of how ZC operates depends on a fixed screen size, so the amount of engine redesign to do this would be immense.

I do have 'make screen boundaries(where scrolling occurs) a variable' on the to-do list, so it would be possible to change the ultimate screen dimensions downward, but this would in turn make the internal maps look very odd, as the questmaker would need to fill the area outside the boundary space with combo 0, so there'd be a big black grid around the screens when viewing the map.

I'm not sure there would be any resolution to this, unless we make a combo type 'Screen Edge' and somehow rework maps to tile screens ignoring the areas outside the bounds; but that likewise would be a mess.

To be fair, this is something that I've wanted personally as well; but that doesn't give it any higher priority. We will of course consider these things 'down the road', but not for any initial 2.future things.

Anyhow, keep the requests flowing. I'm only responding to this one directly, because a few of these are repeated from other members.

Sideview fixing though, that's going to happen eventually.