Difference between revisions of "Door Sync"
m (some formatting fixed) |
m (added link to code) |
||
| Line 34: | Line 34: | ||
Each RNG above is a separate call to the SS RNG function. So when I said 2x 4x 8x, it's the probabilities of the doors being "open" over a period of time. | Each RNG above is a separate call to the SS RNG function. So when I said 2x 4x 8x, it's the probabilities of the doors being "open" over a period of time. | ||
| + | ---- | ||
| + | Here's the code for doors right out of VIE... | ||
| + | [[Door_Sync_Asm]] | ||
---- | ---- | ||
Revision as of 15:13, 23 March 2005
Source: http://www.ssforum.net/index.php?showtopic=2871&view=findpost&p=38260
catid says:
I've looked at the door synchronization. It works like this:
In the main game loop, the door function is called with a parameter for the number of game frames that have passed since the last time the door function was called. Game frames are in hundredths of a second.
This is how most of the synchronized stuff work in SubSpace.
For each iteration, as I recall, it checks what type of door mode the arena is using, and iterates the door "seed" value, either once or 7 times (depends on door mode). The seed is used to generate random numbers for the new door states. The seed changes with each number it generates.
Every 2 minutes, the server will send a new timestamp and a new "seed" value to all the clients (same for all clients). The clients will call the door function with the difference in time since the timestamp, which gives you as good synchronization as you get with position packets.
There are a few problems with this method; some are unavoidable without redesigning the protocol. For instance, when the server changes the seed, the timers used to change the doors is overriden, so the door delay period that straddles the updating of the seed will be shorter for some people.
This is just a general overview of how it works.
Mr Ekted says:
Weighted door mode uses 7 random numbers. One of them affects 2 of the 8 bits--the 2 most "toggling" door, so they stay in sync. The other 6 control the other 6 bits, which toggle 2x 4x and 8x less often.
In weighted DoorMode, every DoorDelay unit of time, all door state bits are updated.
Bits 0 and 4 are set to (RNG & 1)
Bit 1 is set to (RNG & 3) != 0
Bit 2 is set to (RNG & 7) != 0
Bit 3 is set to (RNG & 15) != 0
Bit 5 is set to (RNG & 3) != 0
Bit 6 is set to (RNG & 7) != 0
Bit 7 is set to (RNG & 15) != 0
Each RNG above is a separate call to the SS RNG function. So when I said 2x 4x 8x, it's the probabilities of the doors being "open" over a period of time.
Here's the code for doors right out of VIE... Door_Sync_Asm
