Tentative New Combo Flags and Types

[ZoriaRPG]

The following is a list of [I]tentative[I] combo flags and types that I have added to 2.54. I would like to see some discussion on these, whether they are good or bad, and what I may have missed, that we should add.

Tentative Flags

-=SPOILER=-



Tentative Types

-=SPOILER=-

The flags are already partially implemented, and the user can set them and utilise them via scripts. I would prefer to make many of these work without scripts, at some point, but that may be better suited to combo types.

The new types are commented out in the source and are based on suer suggestions.

[Avataro]

What would the "104 Pushed" flag mean?

"Breakaway floor, fall, damage"
//Timed combo that turns into a pit damage) based on a timer

This could be done with combo cycling.

[Saffith]

What would the "104 Pushed" flag mean?
That one already exists, but you can't set it yourself. When a single-push block is pushed, flag 104 is set so the game knows it can't be pushed anymore.

[ZoriaRPG]

What would the "104 Pushed" flag mean?

"Breakaway floor, fall, damage"
//Timed combo that turns into a pit damage) based on a timer

This could be done with combo cycling.

I know. This wasn't my idea. One specific user requested this type of thing, with a timer variable. If you can the list, you might find some other things that fall under similar context, and likely do not need to exist. I have no idea why combo cycling is insufficient, and that one is unlikely to materialise. It might make sense for an eventual flag/type editor.

Clearly, if I work on this, I will give priority to the types and flags that most benefit the programme, and not to the most esoteric things that you can already easily accomplish. :D

I am more interested in knowing if users would want script-specific flags, as once a flag is in there, removing it is not a viable option, and I hesitate to add anything that specific unless we decide that we are never doing something internally. At present, those scripted effect flags could be reserved for internal effects of the same type.

There are also instances here, where we have ( type | flag ) crossover. e.g., Do we make lift objects both flags, and types?

[Avataro]

Can't say I like all these "Scripted" flags that'd require specific scripts. How about using the general purpose script flags for this and let us rename them in ZQuest? Or not. It's fine without renaming them too.

[Tamamo]

i'm with avataro on this one...
If your gonna have to go that far might as rewrite the hole thing using CSON or JSON

[ZoriaRPG]

Can't say I like all these "Scripted" flags that'd require specific scripts. How about using the general purpose script flags for this and let us rename them in ZQuest? Or not. It's fine without renaming them too.

This is certainly something I have considered. I have mused on several occasions on adding a flag editor, of some sort; with the eventual goal to allow the user to set up their own trigger definitions, and results, from lists of events.

The reason that popped some specific script flags in there, is because they are very common, and because I still plan to have scripted quest templates for ZC, with pre-configured datapacks, and I wanted to make it way for a user to set up maps. Allowing renaming them does seem reasonable, but it will require some moderate extra work.


i'm with avataro on this one...
If your gonna have to go that far might as rewrite the hole thing using CSON or JSON


I don't see an advantage of adding dependence on JSON (or CSON), when a struct for flagdata will suffice. Given my hopes for a future flag editor, we're going to need that anyway. I can likely make jwin pull char from a struct, instead of using the present strings, and that does not on initial consideration), seem to be all that hard to accomplish. I am also not overly fond of JS based stuff in general. IMO, it tends to add more overhead than needed.

What would be more interesting, is to allow flags to run their own script events, by attaching a script to them, but that is a far future concept IMO.

I'll work on an initial flagdata struct in the near future. I still need to work on making npcdata available to ZASM, too, and I am working on the structs at present, so this might be a good time to lay out some plans to allow adding this in the future without mandatory changes in the data format.