No longer manage a Group's lifetime explicitly in native code, but instead leverage Lua's garbage collector to handle it's lifetime.
In this change, Groups will be stored internally in the core inside a weak table, so that they will still be reference-able when needed, but if no reference were to exist in Lua code, they will be subject to garbage collection.
Whenever a Group is used by native code, its wrapped by a owned_lua template class, this is akin to std::shared_ptr--It reference counts the usages of that group internally in the core, including managing it in the Lua registry index when in use, so that it won't be collected.
With this approach, the exponential memory usage growth caused by long running procedures due to the creation hundredths of thousands of groups per iteration, is mitigated, since the temporary groups will be reaped more frequently, as opposed to the old approach of them being cleared only after the topmost Lua function had finished executing.
For now a single GC step is triggered whenever the total number of groups is more than 2048--an arbitrary value that seems to work well enough, but which can be changed/optimized after proper profiling.
A major upgrade with this approach is the removal of the concept of Groups "kept alive" and having to "explicitly delete" them to make them outlive a Lua function execution, since they will now follow Lua's variables lifetime properly.
Prevents errors down the line due to overpaying since a card with sum_param of 0 will never contribute to the total and error out when the client sends a response
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.
LUA_FUNCTIONs don't really need to check the amount of parameters to be at least 1, as that's implicitly checked by the mandatory first parameter being the lua_object itself
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
Update lua functions to already have the pduel parameter passed inside them, thus not needing to manually retrieve them in the functions.
Add also a yieldk macro that does the same thing but for the yield continuation function, removing the redoundancies
Most of the library functions are used as "class member functions" where the first parameter is always the corresponding lua object, update the LUA_FUNCTION macro so that the functions already have a "self" parameter corresponding to the already parsed lua object.
Added a new LUA_STATIC_FUNCTION macro for functions that are to be called without an associated object
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
In loops don't reevaluate it each iteration, in some functions already checking the value before entering a specific codepath don't repeat the same check
This reverts commit 20b0ef47b9.
With this change, a group being iterated by FilterCount was subject to having the container being iterated being altered mid iteration by the filter function, thus invalidating the iterators and possibly crashing the core.
Use the new function that return "0" if the object is not a function so that the functions can automatically take advantage of the change in check_matching that skips the second type check each function call.
Semantically the proper operator to use for oneline increments is the preincrement one, the postincrement is the one to be used only in teh cases where the previous value is required.
