catid

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. If you want specifics, just ask.

Southpark rules "It is possible for your clock to be 80ms ahead of server, and mine to be exact. It is possible for a packet to get from you to me in 70ms. Therefore it is possible for me to get a packet 10ms before it was sent. Therefore your calculations will incorrectly wrap. Clamping or not, this will happen." cat_time = server_time + 80 ek_time = server_time transit_time <= 70 80 > 70 true Okay, but it doesn't matter how they wrap so long as the bounds are taken. The values get clamped to zero when they go negative or really large positive, ie. when they wrap. In other words, SubSpace never has negative calculated transit time, so there's no problem. I really don't see what else there is to dispute about this. If you believe that timestamps should be allowed to come in higher than local timestamps, then say that. It's wrong, but at least say what you mean.

Well, to write a SubSpace client they'd need to know something about how best to sync using the information available. Some people might want to know how it works, not just that it works. Actually the differences in clocks between server and two remote clients are neatly cancelled out in the calculations. JeffP's logic compacts nicely into an equation between each client's RTT ping and how long it !@#$%^&*umes the ping took to send one-way. I made a mistake when I said you can just set both sides of that unsync inequality equal to show it's perfectly sync'd. Here's the actual deviation from perfect sync: 2/5*([local ping] – [remote ping]) - ([local one-way] - [remote one-way]) = 0. This implies that the two timestamps are equal, when the time it takes to transmit is zero. In other words, the difference in timestamps will be zero between the two clients. It's arguable whether or not JeffP made a good choice with these coefficients. In my paper, I say it could use some testing.

Oh! Well it might have been so that people who are unsync'd horribly for some reason aren't going to interpolate themselves off your screen (or radar). I bet 15 is some kind of "nice" value for the interpolation.

Feel the love. \=) No idea why it sets that extra bound; that may have been a mistake. There are other, similar bounds set on the ping calculation code, though they are not as mysterious: // slow pings get ignored until the next sec.chk if (round_trip > syncPing + 1) { if (ticks - lastSyncRecv <= 12000) return; } This is understandable, because we want to encourage that unsync. inequality to fail, which can be done if ping times best represent actual transit time. // ping spikes get ignored if (round_trip >= syncPing * 2) { if (ticks - lastSyncRecv <= 60000) return; } This is done for the same reason. We'll only accept a much higher ping after one minute of spikeness (3 attempts). I think that it waits too long, personally. I wrote the paper mainly to investigate the sync system. It may be valuable to someone writing a client.

The original -will- fail when the 32-bit ticker rolls over, specifically when the two timestamps straddle the discontinuity. I think if you want to improve on the original (well-tested) code, you should fix this problem as well.

Bah, fine, I'll spell it out for you. The SubSpace hiword extrapolation code only produces "incorrect" -intermediary- values, but the final result will be the same. (numpf, i will prove[a]) The one case you found that seems to fail: [local time] < [remote time] 0xffff < 0x10008 will produce transit_time < 0, though it is not the actual transit time. The bounds i mentioned earlier will set transit_time = 0, when the value is used for interpolation by the game physics. Thus, they are two ways of performing the same calculation. Yes, the synchronization protocol makes some !@#$%^&*umptions in order to best approximate perfect sync, which is given by that handy inequality. If you set the two sides equal, it's perfectly in sync. Note that there are random variables inherent in the system, so terms such as "highly likely" are exactly what should be used in the places where I used them.

Well, I do go out of my way to show that receiving a timestamp greater than a locally generated one is highly unlikely. There are several hurdles, which you can figure out from the inequality I derived last night: [transit time] < 2/5*([local ping] – [remote ping]) - ([local one-way] - [remote one-way]), [local ping] > [remote ping], implying on average only half the players could p!@#$%^&* this hurdle. Note also that these bounds are taken... [transit time] = [receive time] - [send time] // From MERVBot, also part of original SubSpace algos. if ((transit_time < 0) || (transit_time > 30000)) { transit_time = 0; } else if (transit_time > 4000) { transit_time = 15; } So you see, it wouldn't matter anyway. numpf: you are incorrect that the results are wrong

Quot erat demonstrandum, numpf your mods are unnecessary. Please don't poke fun at MERV. It was an honest attempt to give something back to the community, before I knew how to program properly.

0x0000ffff sent as 0xffff received at 0x00010008 becomes 0x0000ffff (-1) LO(0x0000ffff) > LO(0x00010008) (correctly)--> HI(0x0000ffff) = HI(0x00010008) - 1 So none of these three cases proves that the algorithm is broken.

0x00010001 sent as 0x0001 received at 0x0000ffff becomes 0x00010001 (+1) 0x00000fff sent as 0x0fff received at 0x00001008 becomes 0x00000fff (0) The algorithm does not need to consider these first two, because they break one of the !@#$%^&*umptions made in designing it.

-*BAD WORD*-o, Snrrrub messaged me sometime last night that EkTed believes the algorithm in the position packet protocol for extrapolating the upper 16 bits from the lower 16 bits provided in the packet is b0rk. I found quickly that the problem of disproving this was worth solving. Go here for the paper: Paper download

G'day, I took a break from my studies this weekend to upload a slew of new files to my website. http://www.mervbot.com There's a developer release of build 39 available. You can try out the new EVENTs for the plugins and let me know if anything is amiss. Check dllcore.h for the list of events and stuff. syntax for sending events plugin2core is tell(makeBLAH(BLARG)); There are two new plugins available, of apparently high quality. My copy of ASSS has been released on the website, so developers who want to code from Windows can take advantage of the new stuff before Grel and i negotiate patches and such (sigh...)

the only reason MERV does it that way... is because i was learning the protocol as i was writing the bot, and it was easier to write that way. i make up for it by doing those nifty packet diagrams, which i use as a reference as much as the next guy