[ZC 2.60] More "Scripted" flags and combos

[CJC]

I'm having trouble coping with the five-flag and five-combo limit. We've got 10 custom item classes... couldn't we have like 20 Script Flags and Script Combos?


I know that sounds sort of greedy, but that's ten for custom items and ten for game functions.

[XMuppetSB]

We've got 10 custom item classes...
Actually, there are 20 custom item classes. And on top of that, there are 20 default item slots labeled as Custom Items 1-20.

[CJC]

Hmmm, so there are. All the more reason for more scripted flags!

[Alucard]

Sorry for necroposting, but I am also supporting this suggestion. Several months ago, I have created a header called stdCombos.zh which contains functions for interaction between combos and various objects (lweapons, eweapons, FFC`s etc.) Here is the link to the header:
http://purezc.magesguild.net/~alucard/zscript/stdCombos20.zh
As you can see, it`s already 2.0 version.
Turns out the 5 blank combo types and 5 blank combo flags is a quite a small amount to work with and expanding it would be helpful to anyone who wants to use this header.

[Tamamo]

Actually if you use smart layering and context sensitivity you can use the flag for several things. For example a general purpose flag that makes link drown in water even with the flippers "deep water similar to the oracle games" could be used on shallows to give them a splash sound effect while walking through it.

[ZoriaRPG]

I favour more scripted flag types, in general. Twenty, is probably overkill, but I don't see why more would be a problem. Too few, is always a problem, and needing to combine flag types to achieve a goal is a bloody pain, which is why I avoid using them in general. Too few types, for the number of desired effects; so better to simply use combo detection, and lists.

[Samer]

I support this, especially since the engine isn't open source. Better to be safe than sorry right?
I honestly don't know anyone, pro/indie/otherwise that makes stuff from scratch unless they REALLY like it.
I mean scripts slow stuff down, the quest developer should know what needs to be scripted or what can be made from the engine.
Plus, it'll allow people to only have to use one version of the system (Zelda Classic) instead of custom builds

Just boost creativity, that's always good anywhere.

[ZoriaRPG]

I support this, especially since the engine isn't open source. Better to be safe than sorry right?
I honestly don't know anyone, pro/indie/otherwise that makes stuff from scratch unless they REALLY like it.
I mean scripts slow stuff down, the quest developer should know what needs to be scripted or what can be made from the engine.
Plus, it'll allow people to only have to use one version of the system (Zelda Classic) instead of custom builds

Just boost creativity, that's always good anywhere.

Not sure what you mean by custom builds. Script glags are just a handy way to make selected combos behave as defined by a script, using ComboF insteaqd of ComboD.

The only real, time-saving factor, is that you can plaster a screen with flags on any combo, but if you need more types than those available, and don;t want to resort to hackish flag stacking (that causes possible problems too), you use an array designed like a structure, and store combo src/dest pairs in it. You read the table with a for loop, check for collision with any given pointer like for ( int q = 0, q <= SizeOfArray(Table), q+2 ) and change the combo if it matches by ++.

It works similar to slash->next, but it can update any combo by +1 (next value in the array), from any factor (e.g. collision, global variable).

The additional flags would allow people to do this without needing the table, and wouldn't require them to manually build their table.

I would hope that 2.50.x could, at some point, support this without breaking .sav files; but if not, it may need to go to 2.60.