Talk:Plan for implementing battlescripting
The Mad Cacti: A separate equivalent? If we used an exactly identical copy of interpretloop, that would work. I suppose we could do that if we're desperate for a workaround or fast results (that sounds like reasonable justification to me). I think a hack to call a gosub in another function/module is probably infeasible, even with setjmp/longjmp. Unless we somehow set up a second stack for the interpreter, co-routine style. Hmm... that sounds fun
Bob the Hamster: Multiple separate stacks might be a good idea for multitasking too.
I have several ideas:
- I also think it should use a separate stack for battle script so that a FIGHTFORMATION command will pause while the battle is executing but still allow scripts to run during battle (which are separate scripts). You would also need separate timers so that timers still don't expire until end of battle; critical timers will still need to stop the battle and whatever it is doing in order to continue with the main script.
- An alternative is to use an entirely different file for battlescripts; this may be more klugy but possibly might work more easily I am not quite sure. (Nevertheless, you should avoid using an alternative file if you can, since it is too klugy.)
- The battle memory are currently local variables in the underlying BASIC code. Since multiple battles don't happen at once, they could perhaps be made global; running plotscripts with them would seem to be difficult if they are local.
- Possible battlescripting events could be:
- Begin battle (just after it initializes the battle memory, in order to allow the script to alter it)
- Battle finished (could also perhaps return a value to bypass the normal victory screen?)
- Menu item (a menu item could be assigned a script; this script can then display a submenu, initiate an attack, set which targets are allowed, etc)
- Allow an attack to chain into a script (which may in turn queue an attack)
- AI decision (a script is called when it is the AI's turn, in order to decide what to do; if it fails the decide the default AI will be used)
- Hero or enemy defeated
- Called after aim and/or damage math is calculated for an attack that requests it, and then it can alter the result with its own math
- Battle stats are separate from global stats. The best way is probably to implement these as separate commands.
- This even includes elemental resistances and elemental counters; this is possible even for heroes it seems so you could allow the begin battle script to initialize these parameters for heroes. The untargetable and "harmed by cure" bitsets also look like they might work with heroes too, so those too can be initialized (it allows heroes to have these parameters then, without storing them in the game data itself). This even allows altering them (for heroes and enemies) during battle.
- Max stats are also provided, so these too can be adjusted during battle in a temporary way.
- A script could then also be used to cause alterations to stats to persist outside of battle too.
- A script could also use this to save the hero's poison register to a global variable and then restore it when the battle starts over again, in case you want poison to persist between battles.
- Writing to the animation buffer could also be a command so that you can implement your own animations.
- Extra commands for use in battle could include:
- Read and alter current and max battle stats for any slot
- Read and alter elemental resistances and counters for any slot
- Read and alter bitsets for any slot
- Read and alter the ready meter and initiative values
- Read and alter the revenge/thankvenge/stored-target/last-hit damage amounts, targets, and masks
- Set which targets are allowed and therefore perform an attack when the player selects the target
- Write a caption
- Write a harm text
- Queue an attack
- Queue an animation (possibly unimportant?)
- I am not sure about all of this; however, these are my suggestions and proposals and ideas about it.
--Zzo38 (talk) 08:28, 28 November 2014 (PST)
The comments about separate stacks are 6 years old. We already have a newer plan for how scripting could be added to battles. The two main things we are waiting on are script multitasking, and further cleanup of the battle system to convert display to be slice-based. I do like your suggestions for possible commands. Although there will definitely not be any commands for writing to the animation buffer. It will be vastly easier to make new animations with simple scripts, not scripts that write into a less-capable scripting format. --Bob the Hamster (talk) 12:14, 2 December 2014 (PST)
- Yes, and that is why I put "(possibly unimportant?)" I realized that (when someone told me). OK then you may need to allow one script to pause while another script task is running. Converting the display to slice based is probably a good idea too; this allows further customization, as well as making the system more uniform. --Zzo38 (talk) 09:23, 4 December 2014 (PST)
