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.
update the following functions to allow passing the player parameter directly, if needed:
Card.IsReleasable, Card.IsReleasableByEffect and Card.IsDiscardable.
Card.IsReleasableByEffect can also take an effect as 2nd optional parameter
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
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
* Update Card.IsReleasable to accept a second, optional parameter for the reason. Update GetReleaseGroup, GetReleaseGroupCount the same way as well, with the new parameter being the 4th. Defaulting it to REASON_COST will prevent massive script changes (cards that tribute by effect already use Card.IsReleasableByEffect).
* Update EFFECT_CANNOT_RELEASE to pass the reason and the reason effect a 4th and 5th parameters to its target function
* Pass the reason down the line until get_release_list, check_release_list,is_player_can_release and card::is_releasable_by_nonsummon, updating internal function calls accordingly
---------
Co-authored-by: Edoardo Lolletti <edoardo762@gmail.com>
lua_pushboolean was expecting an int, but if checking for a race whose bit was higher than an uint32, that value was truncated to 0, thus passing "false", now make sure to actually pass a boolean by explicitly checking for != 0
Decouple the summon location from the summon type, also keep track of the sequence and if the card was in a pzone, this allows to use symbolic locations in Card.IsSummonLocation as wel
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
The given lua stack to a c function has enough room to push few return values without issues, so all the functions that return a fixed amount of values (usually 1 or 2) weren't touched, all the others that return an unknown amount are now properly calling checkstack to make the lua api allocate the space needed for all the return values.
Bump the race value size from 32 to 64 bit, giving us 32 new race values.
This is needed to futureproof the new upcoming rush card types, that could end up making the card types become more than 32.
This change breaks both the core abi and the messages.
For the abi now the race field in the OCG_CardData struct changed from uint32_t to uint64_t.
For the messages, QUERY_RACE will now be an uint64_t instead of uint32_t, MSG_ANNOUNCE_RACE will send an uint64_t for the races that can be declared, and also will now expect an uint64_t as answer, also, the HINT_RACE property associated with MSG_HINT will be using the full uint64_t data field as well.
