Update specific data mid-frame for commands?

[adakitesystems]

With the release of BWAPI4 4.3.0 and improved latency compensation, I've been told it's possible for data to change mid-frame. This is relevant to BWAPI4J since we only update the vast majority of data once per frame.

The following scenario should be verified with BWAPI module and client versions 4.2.0 and 4.3.0 in C++ and BWAPI4J. If the tests corroborate the scenario, a decision should be made whether BWAPI4J will support dynamic value changes within the same frame. @N00byEdge suggested such changes can be supported by manually setting the values in Java after a successful command if using the bridge is too slow.

Scenario
latcom enabled:

frame=8000
worker.isGatheringGas()=false
worker.gather(refinery)
worker.isGatheringGas()=true
frame=8001
worker.isGatheringGas()=true
frame=8002
worker.isGatheringGas()=true
frame=8003
worker.isGatheringGas()=true

latcom disabled:

frame=8000
worker.isGatheringGas()=false
worker.gather(refinery)
worker.isGatheringGas()=false
frame=8001
worker.isGatheringGas()=false
frame=8002
worker.isGatheringGas()=false
frame=8003
worker.isGatheringGas()=true

Here is a full list of all the latcom done in the server and C++ client: https://github.com/bwapi/bwapi/blob/af07c94b1953932b4745a0678612b955512ec387/bwapi/BWAPI/Source/BWAPI/CommandTemp.h#L175

Discussion snippet from BWAPI4J Discord:

Adakite: All right then then latcom should still be ok in BWAPI4J if data such as isGathering() and getOrder() is only updated once per frame? Is there a concrete scenario in which I can test if latcom is working? For example, maybe set LF to 6, issue gather command, if gather command is true, then the next frame isGatheringGas() should be true with latcom on, but with LF6 and latcom off, it will be false?
N00byEdge: yes
N00byEdge: exactly
N00byEdge: But in theory, you could update your cache when the command succeeds
N00byEdge: if latcom is enabled
N00byEdge: to be consistent with the server data
N00byEdge: move() could set the target etc immediately
N00byEdge: but would not need to C++ code
N00byEdge: you can just set the target to the arugment
N00byEdge: if you that for all orders, you will have fully featured, same-frame latcom
N00byEdge: and the server will handle all future frames for you
Adakite: sounds like a good idea but I think it will get messy if something is missed. for example, we could manually set getTarget or getOrder, however, we won't know the getOrderTarget until the engine or until BW generates it. unless we implemented the algorithm from OpenBW?  Do you get what I mean with the getOrderTarget?
Adakite: or maybe I mean getTargetPosition.
N00byEdge: I don't see how that's a problem, the target position is what you fed to move(), no?
Adakite: it's the position where the unit will move to if you issue an attack or move. it's the true position. not where you ordered the unit to go
N00byEdge: oh
N00byEdge: yeah latcom doesn't set that either
Adakite: ah ok
N00byEdge: Those are undefined until the commands have taken effect
Adakite: yes
N00byEdge: non-order functions that is
N00byEdge: so latcom will only help with the order ones
N00byEdge: there is no real way to do the actual ones

[Bytekeeper]

Well updating values in BWAPI4J means essentially partially copying latcom, not?
We could update just the single unit that was given the command - but I don't know if latcom is changing the state of other units within the same frame as well.

[adakitesystems]

We could update just the single unit that was given the command

That's a good point.

but I don't know if latcom is changing the state of other units within the same frame as well.

That's true, it might. For example, if an SCV is ordered to gather from a mineral, the SCV's isGatheringMinerals will be updated but will the mineral'sisBeingGathered be updated?