If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
>> An educated guess tells me that any netcode that starts out using
>> control input is stuffed. > Well, that's about all the net games ever made, then. Almost all current racing games use position updates as opposed to control inputs for online racing. Need for Speed 4 - High Stakes and Need for Speed 5 - Porsche Unleashed are two of the few games that allow players to choose between control inputs or position updates for online play. The limit is 8 players per race and virtually no one uses control input mode because there is too much delay in control feedback. Another issue is that some racing games react differently depending on the system they are running on. Control input for online play wouldn't work at all on these games. > If you let clients just send their positions, they can hack the > game to speed up, for example. Yes, and that's exactly what happens online. If the replays record enough telemetry information for every car in a race, then they can be used to check for cheats. This is how it's done in NR2003. You just have to put up with it in some games. In NR2003, a server can ban specific players, which helps, but it also gets abused, some players getting unfairly banned. In LFS, a player can post a vote during a race to eject a player, again the potential for abuse occurs here, like the "crasher" putting up a vote to ban the "crashee". Real time cheat detection schemes are difficult to implement. EA uses this for NFS7 (Underground 1) and NFS8 (Underground 2). The server code tries to determine if the telemetry info it receives indicates a cheat or unfair play. Even with months of updates, EA never got this to work right. It rarely detects true cheats, and about 90% of the time that it does disqualify a player, it wrongly does so (false detection of a cheat or unfair play). < saving control inputs during replays If both control inputs and telemetry were saved during replays, then the replay could be re-run using the control inputs to check for hacked physics. However this would mean that all factors affecting performance, like tuning, would be included in the replay, and a lot of players guard their setups. Note that Need For Speed 2 thru 5 save only the control inputs for replays (along with car id, tuning, assist and cheat codes used), and work perfectly, even when viewed on other systems. In order for this to work, the control inputs are filtered (one byte for each control input, sampled at a fixed rate) before being applied to a player's car and stored in the replay. For NFS 2 thru 5, these replays make great cheat detectors for offline runs, since it just used the creator's control inputs on the viewers game. < some games are system senstitive, so control inputs wouldn't work < it also means that these games aren't fair EA's NFS7 was extremely affected by system speed. There was a patch but it over-compensated, so that faster lap times would occur on slower machines. On some newer racing games, the peformance varies from system to system, the same control inputs on one system won't have the same results as the same control inputs on another system. This could be do to the controller (wheel versus joystick), system speed, graphics card speed, sound card speed, ... . Live for speed S1 runs better if you enable force feedback, as this has the affect of adding a stability assist in the game. Since most newer games use telemetry based replays, replays can't be interchanged to check if the game runs the same on two different systems. In the case of one of the more popular games, I read a thread were a player played a game at a friend's house, and had to adjust the setup to compensate for the game performing differently between the two systems (the player brought his own controller, a momo racing wheel, and used the same controller driver, so it wasn't a controller issue). One of the systems resulted in faster lap times than the others. One test that can be used is to run fraps to capture screen data while running a race. I've found a few games where performance seems to improve when running a fraps capture while playing. Another simple thing to try is to reduce the graphics (lower resolution). The only games I know of that use controller input based replays are the Need for Speed games 2 through 5, and Toca Race Driver 2. These are also the only games I've confirmed to run on multiple systems and perform exactly the same. |
Ads |
#32
|
|||
|
|||
"Nick" > wrote in message ups.com... > Lets say that a remote players' data takes 100ms to get to the server, > and it takes another 100ms to get to you, their data is already 200ms > old by the time it gets to you. To go back another 50ms (server rate) > to take an average is just increasing the inaccuracies twofold (older > data, and averaging). Plus, what happens if data from the remote > player gets lost for a bit? You either use some data that's whole > seconds old to get your average, or you have no velocity data at all. > Either way it's pretty meaningless. This is what makes it so hard, you > come up with something that sounds like it works, it works on your LAN, > but as soon as it hits the internet it dies, and more often than not > it's hard to figure out why it died, because you can't replicate the > conditions, and you can't exactly set breakpoints in a multiplayer > game... > > As soon as a car goes around a corner, the velocity keeps changing, but > the acceleration remains pretty constant (towards the centre of the > corner), so if you only use velocities, then as soon as you lose data > in a corner, all the cars start going straight (imagine swirling a rock > on a piece of string around your head-losing a packet is like cutting > the string, the rock moves in a straight line with its last known > velocity, now that it has no acceleration acting on it to drag it round > the circle). > I think that you, and others in this thread, and Papy even, have overlooked the opportunity to use each clients computer cpu to do AI ie any car with no incoming data defaults to AI control. There are a number of things that can happen when data resumes eg the car flashes for the same amount of time it was discoed (5 sec max say) and during this flashing is only a ghost ie no collision. Also, prediction is probably always in use in Papy sims I'd say anyway. I would imagine the server looks at all client pings eg client A is pinging the server at 100, client B at 50 so there is a local client prediction on A and B's game, relative to each other, of 150ms ahead. I would imagine that there are "benifit of the doubt" routines for collision, especially in the braking zones. As for Velocity and acc, those deltas could also be computed by clients from incoming data. A rule I'd like to see all sim companies stick to is that there is never a collision based on prediction - only when the data proves overlap at the same point in time. |
#33
|
|||
|
|||
For using AI to predict, it's overkill because usually the prediction
is only needed for a small amount of time, a quarter of a second say, so just extrapolating from the last known vel/acc is close enough. When delays start to increase beyond a second, there are far more problems with that clients connection than just lag, and they will probably be disconnected anyway. I'm pretty sure clients never simulate collisions with predicted data, I mean, clients *predict* collisions, but the server is the only one with the true information on positions of all cars, the server calculates the collision and tells the clients. You will never collide with a car because of prediction, only because of true contact, although you might collide with somebody because you *thought* they weren't there (due to prediction), the truth is they were there, you just didn't see them because of the packet loss. You could calculate velocity and acceleration from storing old positions, but the velocity would be quite inaccurate, and the acceleration would be dire. Imagine a car going through a chicane in a quick left-right fashion, and you will quickly see that the large swing of the velocity vector and the massive swing of the acceleration vector cannot even be estimated with any kind of accuracy by taking old car positions. All I can say is, I once thought as you did, 'it seriously can't be as hard as people make it sound', but when you try it, it really is. You can't figure out all the ifs and buts and situations for lots of cars interacting over lossy, laggy channels in your head, you just need to keep trying it out and fixing all the problems which come up with prediction, collisions, etc... this is definitely one area where the practical bears no resemblance to the theory whatsoever-and jeez do I wish it did! |
#34
|
|||
|
|||
> virtually no one uses control input mode because
> there is too much delay in control feedback. Or, there was when Quake came out. QuakeWorld introduced clientside prediction which removed this phenomenon for the 95% of cases where your character is not physically interacting with another player (eg a car-car collision, or player collision in Quake). That was 1996, by the way. > Another issue is that some racing games react > differently depending on the system they are > running on. Control input for online play wouldn't > work at all on these games. That is true, but only for badly coded games. Sorry, I mean games that have been coded not to take this into account. If you're going to use control inputs, then you make sure your game is deterministic with regard to the same inputs. In truth, this isn't such a big deal. If you record replays using control inputs, then you want them to play back in the same way on all systems. The only games I can remember which had this problem were Grand Prix 2, maybe GP3 as well, and I haven't played GP4 enough to know if it's in there as well, but I expect so. > If the replays record enough telemetry information > for every car in a race, then they can be used to > check for cheats. This is how it's done in NR2003. Do you know for a fact that it works this way? That clients send their positions to the server and the server accepts them on blind faith until you check after the race to see if anybody was moving a bit outside the game laws of physics? If that's the case (I'm not suggesting it isn't, I would just like proof because it sounds a bit far-fetched), do Papy not care about online cheating, because that's a huge and easily-exploited hole, and I'd like to know how they got around it. > Note that Need For Speed 2 thru 5 save only > the control inputs for replays (along with car id, > tuning, assist and cheat codes used), and work > perfectly, even when viewed on other systems. And that's exactly the same concept as control input based multiplayer. If you like, you could think of it as each client seeing a real-time 'replay' of each other client in the game. You can crash into them because the server calculates the collisions for each client. |
#35
|
|||
|
|||
"Nick" > wrote in message oups.com... > > I'm pretty sure clients never simulate collisions with predicted data, > I mean, clients *predict* collisions, but the server is the only one > with the true information on positions of all cars, the server > calculates the collision and tells the clients. You will never collide > with a car because of prediction, only because of true contact, > although you might collide with somebody because you *thought* they > weren't there (due to prediction), the truth is they were there, you > just didn't see them because of the packet loss. > There are hoards that can tell you this is wrong - I have countless recollections of a car on the low line "warping" up into the car to the outside. You know it is crude, linear prediction because you will often see the lower car immediately drop back down to where it actually is once dataflow recommences. |
#36
|
|||
|
|||
Byron Forbes wrote:
> There are hoards that can tell you this is wrong - I have countless > recollections of a car on the low line "warping" up into the car to the > outside. You know it is crude, linear prediction because you will often see > the lower car immediately drop back down to where it actually is once > dataflow recommences. 1) If the client predicts somebody to move up into them, then simulates a crash, that client will have a 'predict' crash, but when the server data gets through, it will tell the client that no, there wasn't actually a crash, you just thought there was, and that client will warp from the crash state back to racing. I've had that happen to me in NR2002 where I've crashed into someone, got up into the wall, started rolling, then popped back onto my wheels on the racing line and continued racing... 2) I used to race NR2002 on dialup, and a few times I've been the cause of 'warp' collisions, where I've hit someone and the people behind said I warped into them because of my bad connection. Every single time it has been me making a mistake and pushing up into him. On my machine, I see it happen oh-so-clearly, but everybody else sees me in a cloud of warp and just assumes it was a predict collision. I even had it happen 5 laps from the end of a RASCAR race, where I hooked the apron, pushed up and put somebody in the wall (sorry!), but everybody else thought it was warp. I came clean and admitted my mistake |
#37
|
|||
|
|||
"Nick" > wrote in message oups.com... > Byron Forbes wrote: >> There are hoards that can tell you this is wrong - I have countless >> recollections of a car on the low line "warping" up into the car to the >> outside. You know it is crude, linear prediction because you will often >> see >> the lower car immediately drop back down to where it actually is once >> dataflow recommences. > > 1) If the client predicts somebody to move up into them, then simulates > a crash, that client will have a 'predict' crash, but when the server > data gets through, it will tell the client that no, there wasn't > actually a crash, you just thought there was, and that client will warp > from the crash state back to racing. I've had that happen to me in > NR2002 where I've crashed into someone, got up into the wall, started > rolling, then popped back onto my wheels on the racing line and > continued racing... > > 2) I used to race NR2002 on dialup, and a few times I've been the cause > of 'warp' collisions, where I've hit someone and the people behind said > I warped into them because of my bad connection. Every single time it > has been me making a mistake and pushing up into him. On my machine, I > see it happen oh-so-clearly, but everybody else sees me in a cloud of > warp and just assumes it was a predict collision. I even had it happen > 5 laps from the end of a RASCAR race, where I hooked the apron, pushed > up and put somebody in the wall (sorry!), but everybody else thought it > was warp. I came clean and admitted my mistake > Well, I have warped up into people heaps of times - in my replay there is clearly no contact and they end up in the wall - permanently! You are simply wrong about that. I'd need to see a replay of what you describe in 1) - got one? I've never seen anything like that in 7 years! |
#38
|
|||
|
|||
Byron Forbes wrote: > Well, I have warped up into people heaps of times - in my replay there is > clearly no contact and they end up in the wall - permanently! > > You are simply wrong about that. Okay, so it can happen, it's never happened to me though, all of my high ping 'warp' accidents have been caused by me, not warp. I have absolutely no idea how the game can even work if clients can have accidents with predicted cars unless the server decided there was contact... weird. > I'd need to see a replay of what you describe in 1) - got one? I've > never seen anything like that in 7 years! Well I don't have NR2003, this was NR2002, and I was on dialup, so it's a pretty specialised situation. I'd guess it was in NR2003 though. I don't make a habit of saving client replays, because they're always wrong (especially if you're a 56k'er!) and just eat my much-coveted HD space! I used to get it a lot on Papy superspeedway servers, where there are *always* crashes involving lots of cars, and due to my lag and the erratic trajectories involved, my poor 56k connection couldn't cope and cars would be jumping everywhere-so I'd always hit somebody. About half the time the server would correct me back into the race-and I could even keep on going if I remembered to hold my control inputs while my computer was predicting a crash, in case I was really still going around the track! |
#39
|
|||
|
|||
|
#40
|
|||
|
|||
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
rFactor Multi ? | Ed White | Simulators | 2 | March 16th 05 07:39 PM |
If multiplayer code in NSR is as good as rFactor... | Bill Bollinger | Simulators | 0 | February 7th 05 04:12 AM |
rFactor MP Test Fix: unfortunately doesn't fix ... :( | Hans de Heer | Simulators | 7 | January 15th 05 03:16 PM |
rFactor demo - any fix? | [email protected] | Simulators | 23 | January 15th 05 12:47 PM |
rFactor: Fix available for "Trymedia" problem! | Hans de Heer | Simulators | 1 | January 15th 05 12:43 PM |