Introduction: I've been watching some entertaining multiplayer replays, but the experience is always ruined for me by some cars lagging and "jumping around". I've seen this behavior even during LAN multiplayer sessions. The only car that doesn't do this at all is always the car of the racer recording the replay.

Suggestion: Create a tool (unfortunately I don't have the skill) that would take multiple replays of the same race and "combine" them together to a new replay file, where the positions of every car would be taken by it's respective "recorder".

Example 1: Three drivers are racing. Each records the race and they all share the replay files (via e-mail, LFS interface or upload to a web). The three files are then combined using that magical tool to produce one perfect replay.

Example 2: Three drivers are racing (again), but this time only two of them are recording. They exchange their replays (which also contain the info about the third racer, but it's laggy). The positions of the two racers are combined and the positions of the third racer are calculated by some mathematical trickery, extrapolation, average of the positions...all extracted from the two replays. This wouldn't give a perfect result, but (I hope) would somewhat minimize the jumping-around effect caused by laggy connection of the third driver.

Conclusion: A "clean and smooth" MPR without cars jumping around, perfect for making videos and for leagues. You'd also have smoother steering-wheel rotation.

What do you think?

+1


Making kind of tool extractor, which can combine for .cpr (Combined Player Replay)

Very nice suggestion. As you said it would help very much for making videos without having cars jumping or driving left-right and then straight ahead.

edit: Nevermind - Server and client replays are probably the same thing. Clients receives packet then extrapolates positions.

Good idea, but I imagine a pretty daunting task.

Well to be honest if you're going the extrapolation method I think 1 replay could be used to make itself smoother. If someone keeps poping back and forth, yet generally keeps going straight your "mathematical trickery" could be used to say "well OK, he couldn't POSSIBLY be that far left at that time, since at the next time actual position was sent he was here" and change stuff that way.

Of course multiple replays would make it better, but it's not impossible to get some of the way there with just one.

Quote from pik_d :

Well to be honest if you're going the extrapolation method I think 1 replay could be used to make itself smoother. If someone keeps poping back and forth, yet generally keeps going straight your "mathematical trickery" could be used to say "well OK, he couldn't POSSIBLY be that far left at that time, since at the next time actual position was sent he was here" and change stuff that way.

Of course multiple replays would make it better, but it's not impossible to get some of the way there with just one.

Of course, I never said that "my" method is the only one. But in this case, you might get some problems when crashes occur (again, this could be avoided by using crash detection).

My main point was to use the local data from every computer and combine it, so that you get absolute smoothnes as in an SPR while still having maximum precision possible.

There's a bit of overlap between SPRs, MPRs and a third combined format that's confusing me. At a conceptual level, it's a good idea.

Initially I thought you were describing (only) the combination of MPR replays to produce a more accurate replay, which is still a real and valid MPR file.

If you look at your own driving in an MPR, you'll see that the control inputs aren't any smoother than a remote driver's. Even combining multiple MPRs cannot be as smooth as an SPR, but it could be possible to smooth out some of the jitter and actual lag.

If you then want to use local (read: hi-def as in SPRs) positioning and/or control input data, the resultant replay would be neither a valid SPR file, nor a valid MPR file. It could not be viewed without coding the whole 3rd format into the client.

The best that I could hope for from a 3rd party utility or from the devs in a relatively short time frame is the possibility of combining MPRs only. Beyond that it's an entirely different kettle of fish. Aren't some parts of the MPR encrypted or coded anyways?

Quote from breadfan :

Introduction: I've been watching some entertaining multiplayer replays, but the experience is always ruined for me by some cars lagging and "jumping around". I've seen this behavior even during LAN multiplayer sessions. The only car that doesn't do this at all is always the car of the racer recording the replay.

I don't believe that's true. The mpr contains the same information about all the players...the person recording it doesn't have an uber high quality version with no display lag. There will be the same number of packets per second for everyone.

Quote from amp88 :

There will be the same number of packets per second for everyone.

Not necessarily. Some will be lost, some will arrive out of synch and be rejected, etc.

What breadfan says regarding the plausibility of cars' motion is correct though. The only car which can be depended on to have the closest possible fidelity of motion is the recorder's car.

I remember at least two times, where my own car was not acurate.

One time, a tyre stack than in the race didn't hitted me, pushed my car in the replay.

The other one I missed a car by few centimeters and in the replay we crashed and get shoted into the sky for a fraction of a second.


Eventhough, I agree that combining mpr could bring more fluid replays

Quote from Whiskey :

I remember at least two times, where my own car was not acurate.

One time, a tyre stack than in the race didn't hitted me, pushed my car in the replay.

This one might actually be a different "bug". I've found that if you shift+u and stare at a tire stack it will move differently than if you are in a car that comes up to a tire stack. My personal theory is that this is because things further away get their physics calculated differently (less CPU intensive) than things close up. So the tire stack will have different physics calculations and therefor will be in different places depending on how you look at it.

Quote from Whiskey :

The other one I missed a car by few centimeters and in the replay we crashed and get shoted into the sky for a fraction of a second.

Right, this is the standard way of proving that your own data is not tons better in your own .mpr. .mpr files only have data for every so many times a second, around 4-6 i think, (probably same as pps (packets per second) set in the server.) So when you were actually playing, your LFS updated your location 100 times a second, compared to in the replay 4 to 6 times a second, and guessing in between.

Quote from Whiskey :

Eventhough, I agree that combining mpr could bring more fluid replays

i thought you meant make 2 files into one, like one after the other without having to switch

but +1 if its not too hard

What...if, everybody...

Should put "Automatic Save Replay"

When host makes a restart, then every client starts to save exactly a same time a replay.


Collecting those replays to \cpr - folder, there LFS has a tool extractor, which can combine multiple replays, in same replay.


Or, Host/Admin could use a command /save_all=replay

Replay1 will be ordered to save for all, but... maybe not all people would accept this situation, where THEY MUST save a replay, without their permission.

-----------------------------------------------------------------------

Let's make solution

in LFS, there is options already

Save always replay
Save manually
Do not save replay

New option: Allow to host saving a replay [ON / OFF]
Host can load your it's saved replay [ON / OFF]

Keeping this ON, LFS should make folder called .hpr (Host Player Replay). This is needed

When saving a replay by host:

it should be something like this:

14062010-174828-AS5_XRT_20

14062010 - Day
17:48.28 - Clock
AS5 - Track
XRT - Car
20 - Number of Connection List

Host would have an option, which can save number from 1-32 (host is 0)

then there would be 32 different replays. Of Course, that there is a permission included.


How to send them to where?

That is the actually a point, well, as told you, giving a permission, host would sending request to your client, that attempting to start loading your replay. Then, in somewhere indicator will receive information about:

Download speed
Remaining time
Downoad bar
Size of Replay.

Of course, this situation needs high-speed internet connection and bugs would be always in somewhere.


So, giving permission to save and send a saved replay by host/admin
sending replays
Host will check replays in folder .hpr
Using LFS's too extractor
Will be converted to .cpr (Combined Player Replay)
and will be transformed to .cpr
To watch, LFS would have option SPR, MPR, CPR (why not HPR also)


EDIT:
What if I want to save replays and I want them also for cpr?

Well, I am not sure about this, but maybe with same commands and same required things

EDIT:
After the convert is accomplished, LFS would ask, give the name of file, and then you put a name


EDIT:

I think also, that this would be additional program, like a CMX Viewer

What happens in the following case:

Player 1 lags. In his/her client he can see no other cars, so he/she moves to the inside of T1.
Player 2 is not lagging. In his client he/she cannot see player 1 (because of player 1's lag), so he/she moves to the inside of T1.

If these were both combined then at the same time players 1 and 2 could occupy the same section of track at the same time. Where would the 'combined' replay say they each were? Would there be a massive lag collision?

What would probably make a lot more sense than all this MPR-combining would be an option to interpolate / smooth out MP replays during playback by utilizing the fact that you already know what happens in the future. That way you could at least get rid of the position update jumps and maybe even of temporary crashes and spins that didn't actually happen, without requiring you to somehow collect the replays of all players (which aren't 100% accurate for the player in question anyway).

The only downside to this is that the cars would sometimes float around a bit, ignoring actual vehicle physics in order to reach the next packet's position, though whether that is any worse than the current teleporting is debatable. I think at least for "live" streaming a smoothed-out-but-sometimes-a-little-fake display would look a lot better than what we have now.

Quote from AndroidXP :

What would probably make a lot more sense than all this MPR-combining would be an option to interpolate / smooth out MP replays during playback by utilizing the fact that you already know what happens in the future. That way you could at least get rid of the position update jumps and maybe even of temporary crashes and spins that didn't actually happen, without requiring you to somehow collect the replays of all players (which aren't 100% accurate for the player in question anyway).

Yeah, pik_d said as much above.

Quote from pik_d :

Well to be honest if you're going the extrapolation method I think 1 replay could be used to make itself smoother. If someone keeps poping back and forth, yet generally keeps going straight your "mathematical trickery" could be used to say "well OK, he couldn't POSSIBLY be that far left at that time, since at the next time actual position was sent he was here" and change stuff that way.

Whoops