O-GL/Developer Journal
Today, I started implementing my network flow design more and came to a few conclusions and solidified my design more. I'll write my thoughts about instant shots and clients moving instantly vs clients that have a full ping movement delay.
Instant movement problems: 1. That all clients see all the other client positions behind the server by server-to-client time. 2. The client that made the move is ahead of the server by client-to-server time.
Delayed movement has problem #1 but not #2.
-
Ok, if you want to apply instant shot to any of these ways of movement you have to apply certain tricks.
Required with instant movement:
1. Server needs to rewind world reality to the time the client was behind the server when the shot occured. This will effectivily fast-forward the clients' shot so that it is running server time (really only makes sense if you think of 'slow' projectiles). So server is rewinding the time it took the reality to get to the client (server-to-client time) + the time it took to get the shot to the server (client-to-server time) = full ping time.
2. Because the client is moving ahead of the server, and your view of the world is behind the server, you basically took the shot at total pings worth of movement above the server - not good!. That aside, the server will not rewind the client that made the shot's position so that the shot is the same on the server as on the client. So, here again, we see proof that the client will be 1 ping ahead of other clients, or half ahead of the server and half behind the server. This is not good because it allows someone with a high ping to be in a position to get a potentially unfair shot.
Required with delayed movement:
1. This is the same as above.
2. Because the client is moving behind the server, as with your view of other clients, the server will also rewind your position. So, here, we basically have both your movement and the other clients' movements behind the server by server-to-client time. This is ok, but still not so good because your movement is delayed by full ping time.
The best solution IMO, is the delayed movement and instant shot. This is because it, er, enables you to actually hit stuff. Low Ping Bastard's are still disadvantaged because they have to wait their ping time to move.
After I get that solution done, a potential solution I can do to fix full lag wait is to decrease it to half wait, and predict halfwait in front of what the server sends you (so you're basically running at same time as server). However, the prediction would just be velocity based I dont know if the errors are worth the extra half ping until I actually implement it (later of course).
-
The final thing, which I found out a while ago, and I think have come to my conclusion on is: finding server-to-client time or client-to-server time is impossible! Believe me, I spent at least a few weeks on this 
. I could only figure out a way to find out how much those values have changed, but not what their actual values were.
OMG, last day of 2003! I better write something to make that 2 updates for the year 2003 *wink wink*. I seriously gotta start writing in here more often lol .... Been doing alot of stuff since my last update like going to camps, lans, and other fun "learning" because after I implemented my network code I realised it sucked and got depressed for a bit figuring out what to do next. I cant believe how unplayable even a 100ms is on delayed movement. I also cant believe this problem was solved by JC in the Quakeworld days so long ago ... hats off to him for listening to the fans who said Quake was "unplayable" online (I read a quote saying QuakeWorld was a "BIG architectural change" and that he barely even thought about high ping playability during Quake).
Only problem, is i cant do much with karma on the network. I even figured out a way to do instant shots, as well as instant movement. Instant shots are achieved by making the shot come from the position you were at one ping ago. This makes replays possible because the game state is basically the same on all machines after they have rewound time. It uses a special trick where the shot you made is coming from a previous position, but it is also hitting the same thing that you aimed at by finding the correct rotation. You would send this rotation to the server all the time instead of your simulated rotation to maintain smoothness on the server. I dont think zeroPing use this method. Anyway, I'm sure that in the future, instant movement and instant shots will make it so that everyone plays without lag ... but those with high pings get discrepancies and will still be saying bad words to their modems ^^.
Interesting thing about the repulsor implementation is how simple it is. I mean, its a bit harsh to expect modellers to write code, but I think repulsors are a sorta technical thing rather than an arty thing so they should be left to the programmers. That said, it works by the vehicle spawning (usually) two repulsors at a set position. This is made even easier for you by doing the bulldog wheel placement trick where you just specify and offset.
The Repulsors themselves are very simple also:
var() bool bEnableRepulsion;
var() vector CheckDir; // In owner ref frame
var() float CheckDist;
var() float Softness;
var() float PenScale;
// Used internally for Karma stuff - DO NOT CHANGE!
var transient const int KContact;
I like it alot and it seems to work well but there is problems with the placement on the vehicles in the UT2R I think because some slopes can be rather buggy. I'm still not sure how the repulsor works because it seems a bit hackish due to the softness variable and the speed at which it stabilises. Could be wrong though.
Later that day
I modified the hoverbike to only have one repulsor. One thing that is moderately disturbing is that SHover extends SVehicle and its PostBeginPlay function spawns two repulsors for you unconditionally. Therefore, if you wanted to make another hover vehicle with different numbers of repulsors, youd have to call super(classabovesuper).PostBeginPlay(). ANYWAY, not that big of a deal.
I found that repulsors are similar to other constraints. For example, KConstraint Actor1 would be the vehicle and Actor2 is an actor in tries to maintain CheckDist along CheckDir. Only problem is they extend Actor (instead of KConstraint) and they are a composite of KParams (instead of being spawned on their own). Seems like bad design .
I also went back to Tim's Networking doc to check on what he said about quakeworld. It seems QW wasn't so good after all: "lock-step prediction protocol" and the "network code and the game code are separate modules". Gee, Carmack made it sound so good . I still admire him tho 
.
