We need a simplified way to tell if a function is synced across the network ideally in a way where network synced can be assert checked in singleplayer.
I just had the idea to copy the concept of a shared pointer. We need a global counter. Make a new class, which increase the counter in the constructor and decrease in the deconstructor. This way all we need to do is to add an instance at the start of functions known to be called asynchronous, like ok button clicked event for popup windows.
What remains is a global function to tell if the counter is 0. The counter and the test function can ideally be static members of the new class, hence everything being packed into a single class.
Works with #938, through we may still have an issue with diplomacy responses. Maybe python expose the new class can solve that.
We can assert check isSync() whenever we alter game state as in any data, which should stay in sync. Random calls, hence random seeds comes to mind as a reoccurring culprit.
Known issue
Testing events are done through a menu, which will end up being async, yet the code being tested is normally executed in sync. Maybe some "ignore sync" class is needed based on the same principle, through that will remove the simplicity of having just a single class for all of this.
We need a simplified way to tell if a function is synced across the network ideally in a way where network synced can be assert checked in singleplayer.
I just had the idea to copy the concept of a shared pointer. We need a global counter. Make a new class, which increase the counter in the constructor and decrease in the deconstructor. This way all we need to do is to add an instance at the start of functions known to be called asynchronous, like ok button clicked event for popup windows.
What remains is a global function to tell if the counter is 0. The counter and the test function can ideally be static members of the new class, hence everything being packed into a single class.
Works with #938, through we may still have an issue with diplomacy responses. Maybe python expose the new class can solve that.
We can assert check isSync() whenever we alter game state as in any data, which should stay in sync. Random calls, hence random seeds comes to mind as a reoccurring culprit.
Known issue
Testing events are done through a menu, which will end up being async, yet the code being tested is normally executed in sync. Maybe some "ignore sync" class is needed based on the same principle, through that will remove the simplicity of having just a single class for all of this.