Gnurro
commented
3 years ago I guess 'set flags' can go into encounterMemories, since that's already there and has functionality that might be useful for setting game flags, as well. It already has a 'timer' for each 'memory' added with the encounterDef key addMemory, for example. It's mainly intended for World Event emulation, but that could become a secondary thing for it, with it becoming a general, persistent 'flag storage' in state. However, I already see people mess up with it majorly, either bloating the object to hell or making such a mess of it that the whole framework becomes useless - and people might even overdo it enough to lead to 'savegame bloat' like Beth games get, which can potentially lead to absurd delays, if not adventures becoming unplayable... On the other hand I'd rather not hardcode any limits (beyond core safety things like the memory insertion limit, which can still be forcibly ignored). If anyone has ideas to prevent that bloat in a smart way, I'd highly appreciate the input. Current encounterMemories (Beta7) does this by obligatory 'memoryLingerDuration', meaning they will eventually disappear.
tl;dr: Good idea, something to do this will be added sooner or later.
Chained encounters add flow control to how events are decided and branches allow for a large number of configurations. There is, however, the possibility that user will want to specify perquisite encounter encounter that must be completed for another encounter to happen, but not necessarily in a chained fashion. A quick example is that: To fight the dungeon boss, three side-bosses must be defeated in any order, before the dungeon boss is fought. The side bosses themselves are independent encounters and do not rely on each other.
A more elaborate example: A novice join a magical school and are trained in the School of Fire. This sets off the
"FireSchoolTraining"encounter chain. Once the"FireSchoolTraining"is done, the encounter chain is over. It then sets the flag"pyromancer"which will be used to check against all spell 'encounters'. Each spell that the pyromancer can cast is an encounter, so "Fireball", "FlameStorm", etc. Logically, if the pyromancer hasn't gone through training then it's expected that they can't cast Fireball or Flame Storm.Another example from the same vein: Your new pyromancer then decides to join the School of Life Magic, but is denied because they have already completed training in the School of Fire. This is because he has the
"pyromancer"flag.On how to store a list of flags. I would have the user define each and every flag into an array in the shared js file, that way the script can reference them more easily. Then have the variable
"SetFlag:"reference the index number of the list (and possibly store it into state.flags array.), though if the actual flag name can be used that would be preferred.For the flag conditional two variables could be used
Flag: This flag must be active.!Flag: This Flag is must not be active, which covers the two examples above. The flag would compare the value assigned to the state.flags values and check to see if any values match run through the conditionals.