ZC [2.future] Feature Requests

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.

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.

I'm gonna be that annoying guy. :P

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!

[MENTION=59862]Lynker[/MENTION]
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.

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

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

Lynker wrote:I'm gonna be that annoying guy. :P

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!

Tamamo wrote:[MENTION=59862]Lynker[/MENTION]
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.

Unsure what feature to request so I'll request something crazy:

The ability to freely move between Maze screens that are adjacent with each other (No looping when trying to move to an adjacent Maze screen) and to have the Maze solution somehow involve all of the adjacent Maze screens instead of just a single screen. I believe this is possible with scripting already and maaaybe tile warps, but a more simplified intuitive approach that doesn't involve manual scripting would be neat.

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.

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 things like that to allow expandeditem lists, without needing to hardcode them.

For my own needs:
More utility in using secrets/flags.
Talking NPCs hardcoded.
FFC's movement behavior that can be manipulated by secrets.
In sum: the ability to make a basic cutscene without using scripts, with NPCs having a conversation, moving around, and performing actions.
I think these have been requested already, just adding them as my own wishlist:
Sideview ladders
Enemy type editor
Map sizes increased (16x16?)
View menu: Ability to set palette per map in addition to per screen.
Subscreen editor: ability to place/move elements with a mouse.
Pie-in-the-sky, prolly 3.0 feature instead: all layers compounded into a single map screen, with a toggle to work on different layers.

Nicholas Steel wrote:Unsure what feature to request so I'll request something crazy:

The ability to freely move between Maze screens that are adjacent with each other (No looping when trying to move to an adjacent Maze screen) and to have the Maze solution somehow involve all of the adjacent Maze screens instead of just a single screen. I believe this is possible with scripting already and maaaybe tile warps, but a more simplified intuitive approach that doesn't involve manual scripting would be neat.

I don't outright reject this, but to be honest, I'm not sure that I comprehend what you want out of this request. You can already make mazes of any number of screens, that deposit the player into a boundary that is more then one screen in size, using basic side warps, so...how do you want this to work, exactly?

EJSnowden wrote:Have you ever used the Age of Kings scenario editor? In particular, the trigger editor? If Zquest could do anything remotely like that, that would streamline an enormous amount of design and script work.

This sounds FANTASTIC. Would love to hear more/update status.

For my own needs:
More utility in using secrets/flags.
Talking NPCs hardcoded.
FFC's movement behavior that can be manipulated by secrets.
In sum: the ability to make a basic cutscene without using scripts, with NPCs having a conversation, moving around, and performing actions.
I think these have been requested already, just adding them as my own wishlist:
Sideview ladders
Enemy type editor
Map sizes increased (16x16?)
View menu: Ability to set palette per map in addition to per screen.
Subscreen editor: ability to place/move elements with a mouse.
Pie-in-the-sky, prolly 3.0 feature instead: all layers compounded into a single map screen, with a toggle to work on different layers.

For the moment, we haven't been discussing adding any new hardcoded engine things, be they items, npcs, or the like. If we did add internal NPCs, they'd need to work differently, and we'd need to change them to some kind of class, or add to the npc class used for enemies. That might be the best solution, to add an 'enemy type' of 'speaking npc', that has some kind of hardcoded path style movement, that doesn;t damage Link, but will allow speaking with a button press. That press would need to be its own variable, as well, to allow people to modify it.

It may be possible to add turn combos, that cause an npc to change directions, that affect any npc object, including enemies to control movement.

I'm not sure how ffcs being modified by secrets would work, but I think it would require some heavy rewriting of the ffc object type. We want to add solidity variables to ffcs, and possibly some memory management so that they don't eat up RAM constantly, so I suppose we could look into that; however, I do not know what kind of control events you'd want, or how you would want to implement them.

Many of the changes that we plan, are toward shifting to using ZScript more readily, and possibly by default for some things. That doesn't mean that we will force people to use scripting, but it may mean that (at least initially), many of the things that we add will be script-mandatory, until we can figure out what kind of interface to use to manipulate them with the editor.

The non-enemy npc type seems to be something feasible though. Instead of attacks, it would have a movement value, and probably a string value. We might be able to do that in one of the next few releases.

I think a better way to explain my intentions:
Say you set a Trigger(1):
Trigger(1) has any number of assigned Flags and Secret Combos. These can be general (e.g. all Script 98 flags present) or specific (e.g. assign Custom Secret Combo 1 to X/Y coordinate). If all Flags are activated, Trigger(1) activates and initiates all assigned Secret Combos. Trigger(2) can be set with its own unique set of Flags and Secret Combos, and 3, 4, etc.

This is basically how the AoK editor worked, and although I understand it might not even be technically feasible, I think if it were possible, it would enormously reduce reliance on scripting, or even allow more power for scripters, especially if the system were expanded in the future. Examples of more advanced functionality might be: Triggers that can initiate scripts, or be initiated by scripts. A set of global values that can be referenced and manipulated. Triggers that are designated inactive/active by default, and can be activated by another or run in a loop. Flags based on time intervals. Commands that manipulate FFC or NPC behavior- telling them to move to a specific place, cycle to the next combo, cycle to a different FFC, bringing up a text string, or spawning an enemy.

Pie-in-the-sky stuff, I know.

Something maybe more possible: the ability to assign scripts to a screen, in the same way FFC and items already do? Or is this too similar to using an invisible FFC to be useful?

EJSnowden wrote:I think a better way to explain my intentions:
Say you set a Trigger(1):
Trigger(1) has any number of assigned Flags and Secret Combos. These can be general (e.g. all Script 98 flags present) or specific (e.g. assign Custom Secret Combo 1 to X/Y coordinate). If all Flags are activated, Trigger(1) activates and initiates all assigned Secret Combos. Trigger(2) can be set with its own unique set of Flags and Secret Combos, and 3, 4, etc.

This is basically how the AoK editor worked, and although I understand it might not even be technically feasible, I think if it were possible, it would enormously reduce reliance on scripting, or even allow more power for scripters, especially if the system were expanded in the future. Examples of more advanced functionality might be: Triggers that can initiate scripts, or be initiated by scripts.

I'm honestly unsure of how much work this would require, but it feels like something that will be possilble much later down the pipe. The ffc objects have a number of fundamental flaws, and adding this much t them will only compound the problems of correcting those; butwe'll eventually get around to ffc-related things, and see what we can do.

The main concern here, is that there would be a limited number of triggers, under a system that doesn't use scripts, and I feel as if people will want more out of it than that. It may be possible to make a default ffc script, that all ffcs run unless otherwise assigned, and add some GUI options to the editor to set its values.

A set of global values that can be referenced and manipulated. Triggers that are designated inactive/active by default, and can be activated by another or run in a loop. Flags based on time intervals. Commands that manipulate FFC or NPC behavior- telling them to move to a specific place, cycle to the next combo, cycle to a different FFC, bringing up a text string, or spawning an enemy.

Please clarify 'global values'. The remainder of this is already possible with scripts; so I presume that you mean that you want timing options without scripts? Note that other editors that allow this, typically use default scripts, or some similar mechanism, and then set values via a GUI; or by direct code.

The npc things that you want shouldn't be terribly difficult, but it'll require a new npc class.

Pie-in-the-sky stuff, I know.

Something maybe more possible: the ability to assign scripts to a screen, in the same way FFC and items already do? Or is this too similar to using an invisible FFC to be useful?

We have something similar to this on our agenda. At least, I know that I have it on mine, and I seem to recall that [MENTION=42714]Gleeok[/MENTION] wanted to do something similar. Essentially, a new, globally accessible object that can run scripts like an ffc, but that isn;t tied to a screen, and that doesn't have editor ffc attributes. Essentially, a way to do what ffcs can do, without the burden of how the ffc class works. [MENTION=61126]Dimentio[/MENTION] deemed the object a 'mini global', IIRC.

It would act as a global script of sorts, but it runs on demand. Generally, how ffcs are used with scripts, or run with ffcscript,zh, but internal, and with the ability to have independent timing from the global active script, as ffcs do now; but with the addition of using Waitdraw() to control their timing.

Note that this is merely a concept, and not anything real at present, so we have no idea how it'll work; if it becomes 'a thing'.

Please clarify 'global values'.

The remainder of this is already possible with scripts; so I presume that you mean that you want timing options without scripts? Note that other editors that allow this, typically use default scripts, or some similar mechanism, and then set values via a GUI; or by direct code.

So here's a thing. Not sure if anyone mentioned this one.

The ability to directly copy an item class to a blank item class allowing you to create a variant line of the same type of item. For example. We have the wand in the game and its class wand. How about a wand that shoots something other than magic waves. How about one that shoots a fireball that can pierce? Doing so without affecting the same item requires quite a bit of time coding in ZScript but as its a relatively simple function that can be applied based on a "base item type" that already exists why not just have the ability to clone the family and provide a few more options in the editor. This would save a lot of headaches for people who want multiple types of an existing weapon (like wands or arrows).

Speaking of arrows; how about more item counters. The current method of creating a proper item counter was mentioned by someone as being hard/impossible to work with. More counters would allow a few useful things like multiple ammo types for your bow, or even a supply of low recovery level potions, or other special items scripted by modders that have trackable limited uses.

And along with those counters, I've run into this situation twice now; Keys that are unkeyed (ie normal keys) will currently work in dungeons where level specific keys are used even if the item is disabled. What I've been trying to do is make it so normal keys work only on chests in the overworld while level keys are required to get though dungeons.... so... why not have options set for key items on where they can be used. Options could include "doors only", "doors and armos/chest combos", "lock blocks", "doors and chests", "doors and lock blocks", "all locks". If you felt so inclined, perhaps an option to have more than one type of door lock available which would require more complex key-finding. Also, how about an option where finding the "master key" ie. boss key would allow you to use the key to open all dungeon locks?

Also, on the subject, an option to eliminate knock-back on certain damage combos. Currently if you hit a damage combo you get thrown backwards as if hit by an enemy. I wanted to make a poisoned swamp in an area on my last project but scrapped the idea as moving around became much too annoying since Link would touch the water then instantly throw himself back like he just realized the water was made of spiders or something.

Lelouche Vi Britannia wrote:So here's a thing. Not sure if anyone mentioned this one.

The ability to directly copy an item class to a blank item class allowing you to create a variant line of the same type of item. For example. We have the wand in the game and its class wand. How about a wand that shoots something other than magic waves. How about one that shoots a fireball that can pierce? Doing so without affecting the same item requires quite a bit of time coding in ZScript but as its a relatively simple function that can be applied based on a "base item type" that already exists why not just have the ability to clone the family and provide a few more options in the editor. This would save a lot of headaches for people who want multiple types of an existing weapon (like wands or arrows).

Hah!I recently put together a very basic model (on paper) for defining Script Itemclass types. This would use the z* itemclasses, and allow a user to define them directly, then apply them to an item and have that item do whatever they set up for that itemclass.

We also need to fix the Magic Book, as setting its power doesn't affect the flame damage.

Speaking of arrows; how about more item counters. The current method of creating a proper item counter was mentioned by someone as being hard/impossible to work with. More counters would allow a few useful things like multiple ammo types for your bow, or even a supply of low recovery level potions, or other special items scripted by modders that have trackable limited uses.

(emphasis, mine)

Do you happen to have a reference for that comment? I'm not sure what you mean by a 'proper counter'; nor do I know if this is intended to imply that it is difficult to accomplish this in ZScript, or difficult to modify the source to expand the number of available counters; else something entirely different.

If you are scripting things, and need many counters, you can just store the values in an array, or variable. I suppose we can add more, but I don't know how much of a pain that would be. I don't think it would be too difficult, but I've no idea yet; and depending on how the values are stored, it could either be easy-peasy, or a true nightmare.

I want to change the way counters work, in general, to use signed longs, instead of (supposedly unsigned) ints. I say 'supposedly' there, because they roll over at a signed int value, but Tamamo claimed they were unsigned. Negative counters do have practical applications, and should be a thing in the future.

And along with those counters, I've run into this situation twice now; Keys that are unkeyed (ie normal keys) will currently work in dungeons where level specific keys are used even if the item is disabled. What I've been trying to do is make it so normal keys work only on chests in the overworld while level keys are required to get though dungeons.... so... why not have options set for key items on where they can be used. Options could include "doors only", "doors and armos/chest combos", "lock blocks", "doors and chests", "doors and lock blocks", "all locks". If you felt so inclined, perhaps an option to have more than one type of door lock available which would require more complex key-finding. Also, how about an option where finding the "master key" ie. boss key would allow you to use the key to open all dungeon locks?

I do like the idea of custom key types, and matching combos; or additional key types. You can fix the level keys issue with a tiny global function:

[spoiler]

int BackupKeys[214747];
const int KEYS_BACKUP_CTR = 0;
const int KEYS_ACHIVED = 1;
void LevelKeysOnly_ByDMap(){
    int levelKeyDMaps[]={1,2,3,4,5,6,7,8,9}; //Populate with the DMap numbers.
    bool disable_keys;
    for ( int q = 0; q <= SizeofArray(levelKeyDMaps); q++ ){
        if ( Game->GetCurDMap == levelKeyDMaps[q] ) disable_keys = true;
        
    }
    if ( disable_keys && !BackupKeys[KEYS_ARCHIVED] && Game->Counter[CR_KEYS] ) {
        BackupKeys[KEYS_BACKUP_CTR] = Game->Counter[CR_KEYS];
        BackupKeys[KEYS_ACHIVED] = 1;
        Game->Counter[CR_KEYS] = 0;
    }
    if ( !disable_keys && BackupKeys[KEYS_ARCHIVED] && BackupKeys[KEYS_BACKUP_CTR] ){
        Game->Counter[CR_KEYS] = BackupKeys[KEYS_BACKUP_CTR];
        BackupKeys[KEYS_BACKUP_CTR] = 0;
        BackupKeys[KEYS_ACHIVED] =  0;
    }
}
void LevelKeysOnly(int min_lvl, int max_lvl){
    if ( Game->GetCurlevel() >= min_lvl && Game->GetCurlevel() <= max_lvl && !BackupKeys[KEYS_ARCHIVED] && Game->Counter[CR_KEYS] ) {
        BackupKeys[KEYS_BACKUP_CTR] = Game->Counter[CR_KEYS];
        BackupKeys[KEYS_ACHIVED] = 1;
        Game->Counter[CR_KEYS] = 0;
    }
    if ( ( Game->GetCurlevel() <= min_lvl || Game->GetCurlevel() >= max_lvl ) && BackupKeys[KEYS_ARCHIVED] && BackupKeys[KEYS_BACKUP_CTR] ){
        Game->Counter[CR_KEYS] = BackupKeys[KEYS_BACKUP_CTR];
        BackupKeys[KEYS_BACKUP_CTR] = 0;
        BackupKeys[KEYS_ACHIVED] =  0;
    }
}

Also, on the subject, an option to eliminate knock-back on certain damage combos. Currently if you hit a damage combo you get thrown backwards as if hit by an enemy. I wanted to make a poisoned swamp in an area on my last project but scrapped the idea as moving around became much too annoying since Link would touch the water then instantly throw himself back like he just realized the water was made of spiders or something.

We'd need to add a flag for that. I already planned to turn most of Link's conditions into vars, including knockback.

This is also very easy to do, by script...something like this as a global function:

[spoiler]

void NoKnockbackCombos(){
    int combo_d[]={32000, 32001, 32002}; //Populate with IDs of combos that prevent knockback.
    int c[5];
    c[0] = Link->X+Link->HitXOffset+Link->DrawXOffset;
    c[1] = Link->Y+Link->HitYOffset+Link->DrawYOffset;
    c[2] = c[0]+(Link->HitWidth);
    c[3] = c[1]+(Link->HitHeight);
    for ( int q = 0; q <= 6; q+ ) {
        for ( int w = 0; w < 176; w++ ) {
            for ( int e = 0; e <= SizeOfArray(combo_d); e++ ) {
                if ( GetLayerComboD(q,w) == combo_d[e] && ComboAt(w) 
                &&
                RectCollision( ComboX(w), ComboY(w), (ComboX(w)+16), (ComboY(w)+16), c[0], c[1], c[2], c[3]) 
                &&
                ( Link->Action == LA_GOTHURTLAND || Link->Action == LA_GOTHURTWATER ) ){
                
                    Link->HitDir = -1;
                }
            }
        }
    }
}
        

My Request is to up the Tile Page Limit. In my new Tileset I am making it is all 8-bit color. Well, I have been making tiles and then erasing some, making tiles and erasing some, and I am finally to the post where I am almost at max capacity for my Tileset for my games I am making. It would be amazing if we can get the Tile Page Limit to be doubled from 256 to 512.

I'm pretty sure Saffith already fixed magic book damage in the 3.0 source, but I've been wrong before. So yeah.

ZoriaRPG wrote:Do you happen to have a reference for that comment? I'm not sure what you mean by a 'proper counter'; nor do I know if this is intended to imply that it is difficult to accomplish this in ZScript, or difficult to modify the source to expand the number of available counters; else something entirely different.

If you are scripting things, and need many counters, you can just store the values in an array, or variable. I suppose we can add more, but I don't know how much of a pain that would be. I don't think it would be too difficult, but I've no idea yet; and depending on how the values are stored, it could either be easy-peasy, or a true nightmare.

I want to change the way counters work, in general, to use signed longs, instead of (supposedly unsigned) ints. I say 'supposedly' there, because they roll over at a signed int value, but Tamamo claimed they were unsigned. Negative counters do have practical applications, and should be a thing in the future.

http://armageddongames.net/showthread.php?97193-ZC-2-60-Item-Counter-Depletion-in-the-Item-Editor

I may have misinterpreted what was here but I don't think so. It made it sound like customized counters were simply not possible. If you know how to script this out, I would love to know how. I researched it but I guess the math functions required are over my head right now. I'm still getting used to tweeking scripts already made to do what I want them to do (which has become pretty easy now). But other than some really basic stuff, I'm not a guru yet.

Lelouche Vi Britannia wrote:http://armageddongames.net/showthread.php?97193-ZC-2-60-Item-Counter-Depletion-in-the-Item-Editor

I may have misinterpreted what was here but I don't think so. It made it sound like customized counters were simply not possible. If you know how to script this out, I would love to know how. I researched it but I guess the math functions required are over my head right now. I'm still getting used to tweeking scripts already made to do what I want them to do (which has become pretty easy now). But other than some really basic stuff, I'm not a guru yet.

Here is an example:

[spoiler]

///////////////////////////////
/// Custom Counters Example ///
///////////////////////////////
//Counters array.
int Counters[214747];
//Counter Array Indices
const int CTR_ARROW_4 = 1001;
const int CTR_MAX_ARROW_4 = 1002;
    
//Item vconstants
const int IT_ARROW_4 = 200;
//Drawing Arrow 4 COunters Settings:
const int DRAW_ARROW_4_X = -30;
const int DRAW_ARROW_4_Y = 100;
const int DRAW_ARROW_4_FONT = 16;
const int DRAW_ARROW_4_WIDTH = 8;
const itn DRAW_ARROW_4_HEIGHT = 8;
const int DRAW_ARROW_4_COLOUR = 1;
//Initial Set-Up Values
const int INIT_ARROW_4_MAX = 20;
//Script for 'Arrow 4' quiver.
item script Arrow_4_Quiver{
    void run(int increase, int set_exact){
        if ( increase && !set_exact ) IncreaseCounterMax(CTR_MAX_ARROW_4, increase);
        if ( !increase && set_exact ) SetCounterMax(CTR_MAX_ARROW_4, set_exact);
    }
}
//Script for Arrow 4 ammo.
item script PickupCustomArrowAmmo4{
    void run(int amount, int sound){
        Game->PlaySound(sound);
        if ( Counters[CTR_ARROW_4] - amount < Counters[CTR_MAX_ARROW_4] ) Counters[CTR_ARROW_4]+=amount;
        if ( Counters[CTR_ARROW_4] - amount > Counters[CTR_MAX_ARROW_4] ) Counters[CTR_ARROW_4] = Counters[CTR_MAX_ARROW_4];
    }
}
        
//Example bow item that uses 'IT_ARROW_4' and a custom counter.
//Assign to an item, with the item class 'Custom itemclass', or one of the 'zz###' item classes
//as the 'Action; script.
//Arguments:
//Arguments:
// D0: The sound to play for firing an arrow.. 
// D1: The number of ammo to use.
// D2: The sound effect to play for an error, including too many arrows on screen, or out of arrows in the counter.
// D3: The maximum number of arrows that the player may have on-screen at any one time. 
// --> You want to set this argument, as not setting it, will allow the player to fire up to 255 arrows, providing 
// --> that they have sufficient ammunition. Normal values are between '1' and '4'. 
// D4: Set to a value of '1' to allow Link to fire arrows while jumping. 
// D5: The ID of the arrow type to generate.
// D6: The sprite of the arrow when fired.
// D7: The distance from Link to place it. 
item script Arrow_CustomCounter{
	void run(int sound, int errorSFX, int maxOnscreen, int allowLinkZ, int arrowID, int sprite, int dist){
		int numArrows;
		if ( Floor(Link->Z) !=0 && !allowLinkZ ) Quit();
			if ( Counters[CTR_ARROW_4] && !maxOnscreen ){
				( if cost > 1 ) {
                    if ( cost > Counters[CTR_ARROW_4] ) {
                        Game->PlaySound(SFX_ERROR);
                        Quit();
                    }
                    else Counters[CTR_ARROW_4]-=cost;
                }
                if ( !cost ) Counters[CTR_ARROW_4]--;
				if ( sound ) Game->PlaySound(sound);
				lweapon arrow = NextToLink(LW_ARROW, dist);
				itemdata normalArrow = Game->LoadItemData(arrowID);
				arrow->UseSprite(sprite);
				this->Power = normalArrow->Power;
			}
			else if ( Counters[CTR_ARROW_4] && maxOnscreen ){
				for ( int q = 1; q <= Screen->NumLWeapons(); q++ ) {
					lweapon l = Screen->LoadLWeapon(q);
					if ( l->ID == LW_ARROW ) numArrows++;
				}
				if ( numArrows < maxOnscreen ) {
                    if ( cost > 1 ) {
                        if ( cost > Counters[CTR_ARROW_4] ) {
                            Game->PlaySound(SFX_ERROR);
                            Quit();
                        else Counters[CTR_ARROW_4]--;
                    }
					if ( !cost ) Counters[CTR_ARROW_4]--;
					if ( sound ) Game->PlaySound(sound);
					lweapon arrow = NextToLink(LW_ARROW, dist);
					itemdata normalArrow = Game->LoadItemData(arrowOD);
					arrow->UseSprite(sprite);
					this->Power = normalArrow->Power;
				}
				else Game->PlaySound(errorSFX);
			}
			if ( !Counters[CTR_ARROW_4] ) Game->PlaySound(errorSFX);
		
	}
}
//Example Global Scripts
//Active
global script DrawCounters{
    void run(){
        while(true){
            DrawArrow_4_Counter(true);
            WaitDraw();
            Waitframe();
        }
    }
}
    
global script Init{
    void run(){
        Counters[COUNTER_MAX_ARROW_4] = INIT_ARROW_4_MAX;
    }
}
//Global functions
//Draws custom counter from array[index] using settings passed to the remainder of the params.
void DrawCounter(int arr, int index, int x, int y, int font, int width, int height, int colour){
    Screen->Drawinteger(7,x,y,colour,0,sizeX,arr[index],0,128);
}
//Draws the counter for 'Arrow 4'. Set 'only_equipped 'true' if you wish ti display only if equipped.
void DrawArrow_4_Counter(bool only_equipped){
    if ( only_equipped && ( GetEquipmentA() == IT_ARROW_4 || GetEquipmentB() == IT_ARROW_4 ) )
                DrawCounter(Counters, CTR_ARROW_4, DRAW_ARROW_4_X, DRAW_ARROW_4_Y, DRAW_ARROW_4_FONT, DRAW_ARROW_4_WIDTH, DRAW_ARROW_4_HEIGHT, DRAW_ARROW_4_COLOUR)'
    if ( !only_equipped ) DrawCounter(Counters, CTR_ARROW_4, DRAW_ARROW_4_X, DRAW_ARROW_4_Y, DRAW_ARROW_4_FONT, DRAW_ARROW_4_WIDTH, DRAW_ARROW_4_HEIGHT, DRAW_ARROW_4_COLOUR)'
}
//Increases a custom counter max to a specified amount.
void SetCounterMax(int counter, int amount){
    Counters[counter] = amount;
}
//Increases a ccustom ounter max by a specified amount.
void IncreaseCounterMax(int counter, int amount){
    Counters[counter] += amount;
}

I made this purely out of me head, in about ten minutes at most. As can see, it's not terribly difficult to do this, and it allows you to display the counter on the screen, wherever you bloody well please. I hope this it sans-error...

If you want to know how to store, and modify an internal Game->Counter[ctr] by shifting weapons,I can give you an example of that, too. Doing this involves little more than storing one state, (CTR_ARCHIVED_*), and if the weapon is selected, store the previous ammo into a backup array index, read a backup array index for the ammo to load, and transpose their values if the condition test evaluates for the specified state.

[ unintentional double post ]

So then is there a way to have a visual counter show up that changes depending on which item is currently set to B?

Nevermind, figured it out and found the script fix for showing counters for both buttons.

Under Etc->Options, a setting for more streamlined combo placement called "Advanced Combo Brush".

If you want to select a combo you have to right-click and select an option it from a drop-down menu.
If you want to draw a block of combos you have to right-click and select an option from a drop-down menu.
If you want to change the brush size you have to right-click and select an option from a drop-down menu.

Overall, it's a very tedious, clunky process. My proposed "Advanced Combo Brush" setting would be exactly like that in Tiled:

Right-click selects a combo.
Right-click dragging selects multiple combos.

If you want to go back to placing single combos, right-click a single combo. From experience, I find it to be a quick, easy system that enables you to build maps twice as quickly. It has no compatibility issues and the existing system could be kept as the default option. 😊

One fairly easy request😊
A check-box in the "Tile Warp" window that would force Cave/ItemCellar warps to actually go to the map# specified by the DMap

another words: If I tell a Tile Warp on map#2 to go to a Cave/ItemCellar Dmap that is mapped to map#1 I would like it to actually go to map#1 instead of map#2. This would not change the Screen behavior, but this would make repeatable custom guys much easier. Perhaps put the checkbox next to the Combos Carry Over checkbox.

There's an example of what I am trying to do in my betaquest ZeldaRemastered. (I swear it worked before.?)

^^My first Post^^

jimbrads wrote:One fairly easy request😊
A check-box in the "Tile Warp" window that would force Cave/ItemCellar warps to actually go to the map# specified by the DMap

another words: If I tell a Tile Warp on map#2 to go to a Cave/ItemCellar Dmap that is mapped to map#1 I would like it to actually go to map#1 instead of map#2. This would not change the Screen behavior, but this would make repeatable custom guys much easier. Perhaps put the checkbox next to the Combos Carry Over checkbox.

There's an example of what I am trying to do in my betaquest ZeldaRemastered. (I swear it worked before.?)

^^My first Post^^

This seems like a prudent request to fill. Thank you for pointing out something we have overlooked.

[MENTION=42228]ZoriaRPG[/MENTION]
There's a lot of old code that is commented out, unfinished, or just plain unavailable in the quest editor for various reasons.
What are your plans for resolving those issues?

You probably have too much on your plates already, but it can't hurt to request something: Loop start and loop end times for enhanced music like mp3s.

Tamamo wrote:[MENTION=42228]ZoriaRPG[/MENTION]
There's a lot of old code that is commented out, unfinished, or just plain unavailable in the quest editor for various reasons.
What are your plans for resolving those issues?

My plan, in general, is to retain what is useful, finish what is practical, rewrite what is beneficial, and crimp out what is extraneous.

Ideally, to clean up as much as we can. We are also working on useful commenting of the codebase, over time.

Some code that is commented out though, we may retain, if we cannot reach a decision. Some of it is there as a record for historical purposes, and I do not personally wish to obliterate it.

There is also new code that is commented out and unfinished, because one or more of us has not yet completed it. That is a new issue.

As far as practical completion and revision, the general priority list is:

Rewrite Link's Collision Box with all objects and map flags, cleanly. Remove competing functions and make one universal collision calculation.
Rewrite warping, and segregate scripted warping from ordinary warping.
Revise weapons, and npcs.
Move script-only features into a scripting class.
Simplify trigger events, and make them cleaner, and more organised.
Add a series of methods to allow contributors to more readily and easily expand the script engine.
Add and strengthen sanity checks in the ffscript code to reduce accidental user errors that can, for example, do invalid things.
Expand, clarify, and generally improve script error reporting.

The culmination of this will make it much easier to do things, such as allowing custom sized player hitboxes and sprites; adding flags (and the flag editor), create less buggy scripts, and make it far easier to work with the source code. I have already made several documents for contributors, and developers alike, that detail holw to add to, or modify ZSvript functions, and variables; and class-components (weapons, items, and link; thus far).

These are separate docs. [MENTION=1]DarkDragon[/MENTION] suggested inserting the docs in-line with the source, but I feel that doing this will detract from the (already poor) readability. Instead, in-line comments will suffice, and I will eventually bind all these docs and notes into a PDF, as I will do likewise for ZSvript; and if we choose to implement AS as ZScript v9000, for that as well.

you don't have a choice but to retain it in that case.

You do not want to know what would happen if you were to remove the 12 npc enemies we don't really need.
Every npc in zc would be fucked...

This is why i was so against merging 2.x and 3.0.
They we're suppose to be separate before you folks even got the source.

Tamamo wrote:you don't have a choice but to retain it in that case.

You do not want to know what would happen if you were to remove the 12 npc enemies we don't really need.
Every npc in zc would be fucked...

This is why i was so against merging 2.x and 3.0.
They we're suppose to be separate before you folks even got the source.

I honestly must know: Do you do a bit of drinking before you post to AGN every day?

I mentioned npcs on one line, 'Revise npcs'. What the hell are you talking about, at all?

I'm genuinely bewildered by how off-the-wall your reply reads, and I cannot place how it connects to any of this, other than you trying to be smug for whatever reason.

Who said we would ever remove npcs from the engine? The revision plans are related to how npcs work internally, both to the class, and how they can be addressed with scripts. We want to make them more flexible, add some new stuff, clean up some of the hardcoded routines, and whatnot; not rewrite them in entirety.

That act would clearly belong to 3.x.

Hell, I only responded to your earlier post because it had genuine concerns that we care about. Now we're wandering into madness. FWIW, I have a very good idea of what kind of things can occur if you obliterate something that the engine relies upon. Insert sanity check here.

I'm not sure which conversation you're referring to, but my general opinion is that information useful to quest authors should go in external docs, and information only relevant to developers is best incorporated in the source where it's most likely to be seen and maintained.

DarkDragon wrote:I'm not sure which conversation you're referring to, but my general opinion is that information useful to quest authors should go in external docs, and information only relevant to developers is best incorporated in the source where it's most likely to be seen and maintained.

It was in my last git push. The issue is that the details (1) are cross-subject in a manner that they cover aspects of specific engine components that are spread across multiple source files. There is no specific file in which they belong; and (2) I think it is helpful to have docs as separate .txt or .pdf files so that you can review them separately. I have no qualms about inserting it into the source as well, but I feel that a comprehensive docs set that explains how things works would be best as a manual of sorts.

If our system was cleaner, and less convoluted, perhaps it wouldn't matter as much, but I find it helpful when I have a reference to use for any given project.

I also want to improve source comments, but adding thousands of lines of explanatory docs to the source is something that people tend to frown upon in my experience. I used to do a lot of in-line docs in code, and everyone seemed to hate that.