- Joined
- Jul 10, 2007
- Messages
- 6,306
Currently, codeless save/load isn’t possible because it takes too long to synchronize the data between all of the players. It was previously thought that using the gamecache was the reason, which led to a new approach using orders instead, but it could be that the generous use of TriggerSyncReady is the reason.
There are a two things to consider.
1. Will synchronizing 1 player at a time be faster than synchronizing everybody at once?
2. Will minimizing the use of TriggerSyncReady make the thing fast enough to be usable?
The original model would have a function call a sync method and then a wait method. The sync method would tell the player to send a value to a table. The wait method would do a TriggerSyncReady loop and poll the table. This meant that each player would send a lot of TriggerSyncReady.
The new model uses repeating timers to poll the table instead of a TriggerSyncReady loop. Are the timers asynchronous or synchronous is the first question. If they are synchronous, this would generate as much traffic as a TriggerSleepAction call. I personally believe that they are asynchronous because they can’t call synchronous natives. I also think that evaluated triggers are asynchronous.
It’s probably safe to call the function directly from the timer. However, it may be the case that some timers will run again. If we reuse the timers instead of destroying them, this shouldn’t cause any problems.
Someone needs to compare the old model to the new model in performance. They also need to test consideration #1.
I don’t have time to write code anymore : P. All I can do is provide designs and some direction : D. For one, I have way too many resources that need updates : |. For two, I now have a job ^_^.
This is really the first piece of the puzzle that needs to be fixed. I heard that BitInt isn’t working correctly 100% of the time when the grouping isn’t 1.
Also need to bench the transfer rate for x players to determine how long it’ll take to send x bytes. Should test 2-12 players and provide a table. Anyone wanna volunteer? : )
There are a two things to consider.
1. Will synchronizing 1 player at a time be faster than synchronizing everybody at once?
2. Will minimizing the use of TriggerSyncReady make the thing fast enough to be usable?
The original model would have a function call a sync method and then a wait method. The sync method would tell the player to send a value to a table. The wait method would do a TriggerSyncReady loop and poll the table. This meant that each player would send a lot of TriggerSyncReady.
The new model uses repeating timers to poll the table instead of a TriggerSyncReady loop. Are the timers asynchronous or synchronous is the first question. If they are synchronous, this would generate as much traffic as a TriggerSleepAction call. I personally believe that they are asynchronous because they can’t call synchronous natives. I also think that evaluated triggers are asynchronous.
It’s probably safe to call the function directly from the timer. However, it may be the case that some timers will run again. If we reuse the timers instead of destroying them, this shouldn’t cause any problems.
Someone needs to compare the old model to the new model in performance. They also need to test consideration #1.
I don’t have time to write code anymore : P. All I can do is provide designs and some direction : D. For one, I have way too many resources that need updates : |. For two, I now have a job ^_^.
This is really the first piece of the puzzle that needs to be fixed. I heard that BitInt isn’t working correctly 100% of the time when the grouping isn’t 1.
Also need to bench the transfer rate for x players to determine how long it’ll take to send x bytes. Should test 2-12 players and provide a table. Anyone wanna volunteer? : )