shavit-checkpoints.sp - fix aFrames and iPreFrames not always being set#1244
shavit-checkpoints.sp - fix aFrames and iPreFrames not always being set#1244rtldg merged 7 commits intoshavitush:masterfrom mourningsickness:master
Conversation
or something.. idk.. why was it like that.. is this segmented thing even supposed to be that way? who cares.. it's segmented anyway. at least valid use of this function/native will work now (right?)
shavit-stats.sp - fix error due to IsPlayerAlive() being called on di…
|
meh workaround of getting the replay frames separately works fine. logic too busted |
|
looking at the code again, i think it should be merged actually. behavior won't change for internal calls, and for external calls, it will grab the player's current frames.. so works as seemingly intended |
|
Current implement is for the segment style, unless you have any special needs? Otherwise, this patch will be a waste of performance |
|
|
also, a super marginal performance loss for what i would understand to be expected behavior from SaveCheckpointCache.. due to that arraylist being a part of that enum struct.. also meant to link this: https://github.com/KawaiiClan/bhoptimer-savestate/blob/085eefc3f1fa7241e1d5a7e48454ee6240eb7b8b/shavit-savestate.sp#L340 but both are unnecessary to do imo, because they should be handled by this native. if it were only to be used internally and only for seg, then it shouldn't be a native. |
also i am a bhopper, of course i have special needs |
|
well i think it's best to add a parameter to control it, saving frames by default will make some settings in the segment meaningless like cvar |
|
that's true, and a good idea |
|
made it use a bool parameter instead, defaults to false |
i am disabled
| cp_cache_t cache; | ||
| int index = GetNativeCell(4); | ||
| SaveCheckpointCache(saver, target, cache, index, plugin); | ||
| bool saveReplay = GetNativeCell(5); |
There was a problem hiding this comment.
can you make this bool saveReplay = (numParams >= 6 && GetNativeCell(5));
otherwise plugins that people don't recompile (how many really exist though 🙃) will throw errors due to param count
There was a problem hiding this comment.
ah yes, sure
…compiled with the new include
or something.. idk.. why was it like that.. is this segmented thing even supposed to be that way? who cares.. it's segmented anyway. at least valid use of this function/native will work now (right?)