DUEL_FAST_EFFECT_IGNITION will treat any ignition effect as fast effect if they're the first in a chain, to match GOAT rulings, DUEL_OBSOLETE_IGNITION instead, now renamed to DUEL_OCG_OBSOLETE_IGNITION will behave as before, with ignition effects being only activateable in response to a summon, as it worked in ocg's master rule 1
Fixed the first in process_instant_event, where only the bits pertaining EVENT_PHASE_START were being checked, thus falsely filtering other events, similar case in process(Processors::AddChain)
Functions from the auxiliary library, assume the stack has always at least 5 empty slots, add macro ensure_luaL_stack to wrap every such call so that the stack is checked for enough free space beforehand. This will make mandatory to use the latest version of visual studio 2017 as minimum for windows (it was already being required for c++17 support regardless), as it needs the conformant c++ preprocessor option to be used.
If other processors were appended at the end of the battle step that could alter the returns buffer, the core could've interpreted the standalone battle phase not to have ended but instead another attack being declared or an effect being activated, thus possibly leading to an out of bound access
Avoid having to deal with UB while relying on signed integer overflow, add new value Processors::restart to be used in place of the -1 when "looping" a process (a value that when incremented by 1 will properly overflow to 0)
Properly implement 58c488de9e:
* If only one effect is providing EFFECT_MUST_ATTACK_MONSTER the attack selection proceeds as normal, with the turn player choosing the attack targets
* If multiple effects are providing EFFECT_MUST_ATTACK_MONSTER, the opponent choose the attack target like it did prior to the other change, if then the EFFECT_MUST_ATTACK_MONSTER effect applied on the selected monster was also applying to other monsters, the turn player will then choose among those monsters a valid attack target
Rewrite the whole ``process`` function of the processor to use instead tag dispatching on variant objects.
Each single processor message got rewritten as a struct, inheriting from a base templated Process struct, containing only the required data for that process, rather than using the generic structure that ended up needing to spam bitwise operations to pack as many arguments in a byte as possible. This makes things easier to follow and streamlines the addition of new processes:
- Define its struct with the parameters it expects by also providing a constructor
- If the process requires an answer, inherit it from ``Process<true>``, if it requires no answer, inherit it from ``Process<false>``
- Add such struct to the ``processors`` variant type
- Declare and implement its corresponding ``bool process(Processors::NewProcess& arg);`` function
Do the required changes to make Duel.AnnounceRace work with the new types and also any possible newly added type removing some hardcodings down the way and adding some extra checks, also apply the same updates to Duel.AnnounceAttribute
If one of such effect has no side effects (no count limit and no value function to execute) glob it with all the other effects, as whichever is picked won't affect the internal lua state and make the player choose the effect only when there is one of such effects that has a count limit or a function to execute.
The way they were changed made the core crash in the case of an EFFECT_ACTIVATE_COST being in play, reorder the sections so that first the EFFECT_TRAP_ACT_IN_HAND and co effects are evaluated and used, and then the cost is paid, so that there's no interference between it and the PROCESSOR_SELECT_OPTION
The core will read those effects' descriptions and prompt the user in the case where multiple of them are available.
It will also call the value function of the choosen effect so that a possible callback is doable (might be changed to a better approach)
Implement it natively rather than via lua, correctly handle the scenario where one of the xyz monsters to be overlaid has an effect to banish any card sent to the grave and it would be still applying if duel.sendtograve was called manually from the script
Properly implement this thing by using a specific effect flag rather than randomly reading the effect value (that could have been set for other purposes)
Add a separate ``set`` function and use memcpy to store/retrieve the data in the buffer, removes the raw cast to a reference that could have also lead to aligment issues.
