and the current context needs to be passed correctly to bAsync
This here is what I was trying to get it to do. I attempted to follow the processing to see where many uses of bAsync were getting an assigned value. In almost all uses of the boolean, I was finding there was never any coding to assign a value to bAsync other than passing it along as a default false value in the function declaration. Thus, it did not seem like it could possibly work as intended as bAsync would thus only EVER be showing up as false in these cases.
I admit that I doubted that I was going about it correctly, but since the only example I found of bAsync ever being assigned a non-default 'false' value involved checking whether the currently active player was human or a part of a team with a human player on it, I attempted to see if it was simply lacking this check in all other uses of bAsync. I wanted to share my changes with you (and perhaps they should've been commented out to do so) so that I could show you what I meant if you followed the processing routines.
NEVER in any of these does bAsync ever even get an opportunity to be declared true so it casts doubt on the legitimacy of even utilizing any different approach between an async method and a sync'd method. If my theory was correct, and this was indeed a problem, it would explain a lot since known problem spots were relying on bAsync turning up as true to process in a manner that wouldn't present an OOS error. Since bAsync never had any coding to give it an opportunity to become true, of course it would always register as false since it had been passed as a meaningless parameter with a false default setting to get to the function where we could be having troubles.
Obviously, checking whether the active player is human or part of a team with a human on it was not a solution for correctly defining bAsync. So how does this boolean EVER register as true? And why is this evaluation the ONLY place in the code that ever potentially assigns a non-false value to bAsync?
BTW, I'll reverse my changes, yes. It was only meant to be left there temporarily to see if you could make anything of what I was perceiving as a potential problem there.
Also... question to clarify something you stated there:
Synchronization as a general issue is only applicable in a simultaneous multiplayer setting so why wouldn't we want the code to simply always act as if its got to behave as if it were async during such gameplay whether it needs to or not? Wouldn't it be safer to go about it like that?
EDIT: after reading and rereading what you posted above, I believe I'm beginning to understand that bAsync is never assigned based on a static status in the game itself so much as an assignment that should be picked up when calling to a function FROM a function that is already running Async. But what I still find odd is that NOWHERE in the dll (with the exception of that one example) is a true value passed to bAsync in a function call where bAsync is a variable. I'm probably pretty useless at determining that a function is supposed to be running in Async context and I still need to understand a lot more about how messages are passed to update each connected computer, how those messages are picked up and how they help the computers 'get back on track' and back into a deterministic state, but doesn't it seem funny that the dll will NEVER utilize the bAsync variable in so many cases where we're attempting to use it to avert a OOS problem? Interestingly too, most of the py files exposing these functions that use the bAsync variable don't seem to offer the bAsync variable for definition either.
