new physics <-> old replays ??

[--==Gogo==--]

As we all know there will come a patch that includes changes in the physics engine.

I've read some time ago in this forum that in the replay-files the physics-data is stored and thats also the reason why you cannot rewind when watching a replay.

Will the replays of today still work with the new patch?

[sil3ntwar]

i think its safe to say no.

[Tweaker]

Yah every new patch which fixes or changes a lot of things will ultimately make most old content unusable.... especially replays.

[AndroidXP]

Definitely no.

The replays don't contain any "physics-data" but only the user inputs for SPR files or the position/user-input packets for MPR files. While viewing the replay, these inputs are fed into the physics engine, thus relying on the physics engine to give the same results as it did when the race was being recorded.

Now, if you change the tiniest detail on the underlying physics engine the whole system doesn't work anymore - the replay goes OOS (out of sync), because the same user input is suddenly producing different results.

[Chaos]

exactly, this is why i have 5 different LFS directories from one of the earliest demo ;)

[ORION]

6 here :P

[Frags]

Only 1 here...
Well that would be why all hotlaps will be lost at the release of the new patch :)

[Gentlefoot]

I wonder what else may be affected. I'm thinking about LFS World data generally - pbs, mileage and race results etc. I suppose there's no real reason to lose some of this but I guess PBs will be pretty meaningless following physics changes.

[AndroidXP]

I dunno about PB's but hotlaps will definitely be deleted after the patch.

[MyBoss]

I wonder what else may be affected. I'm thinking about LFS World data generally - pbs, mileage and race results etc. I suppose there's no real reason to lose some of this but I guess PBs will be pretty meaningless following physics changes.


My old MRT5 pbs from S1 still exists.

[Gentlefoot]

Cool - cos I reckon a lot of my PBs are gonna be smashed if there's a load more low speed grip.

[Hyperactive]

In one way it is a bit sad though. I have many gigabytes of mpr files and I guess they are incompatible with the new version.

[insert a humble request of replay viewer here] :shy:

:D

Yes, I am complaining about the new patch now :p

[tristancliffe]

pb's stay, but I always delete the ones that aren't acheivable with new physics. If a certain car on a certain track is 1sec slower then bye-bye pb. If it's quicker with the new physics then I leave them knowing that it'll be overwritten soon enough ;)

[Madman_CZ]

or your could always install 2 version of lfs and keep the old one just for replays... :D

[Razzone]

Definitely no.

The replays don't contain any "physics-data" but only the user inputs for SPR files or the position/user-input packets for MPR files.......

That's not true (at least for SPRs) and you know it.......think about how it would be possible to "Test drive" the SPR with only the parameters you said...without any physics data

[Gentlefoot]

Can anyone actually say they KNOW the answer for sure?

My guess is the physics engine is not encapsulated within the replays themselves, instead being more like a run-time environment within which the SPR/MPR data operates.

[Hyperactive]

I think the mpr/spr files just include the inputs for the car (wind, steering, accelerator, other buttons etc.) and LFS checks these inputs and "drives" the car accordingly. I remember once seeing a corrupted spr file where the car spins into a wall but keeps accelerating and braking like it would still "be on the track". I drove that spr myself and I didn't spin :) But it was in the S1 days...

[bobvanvliet]

That's not true (at least for SPRs) and you know it.......think about how it would be possible to "Test drive" the SPR with only the parameters you said...without any physics data

You can test drive a car from an spr because the replay also contains the setup, this has nothing to do with the physics engine.

Old replays will DEFINATELY not run on a new physics engine. Same reason why the hotlaps are going invalid (they're nothing more than replays, remember?).

The physics engine is in LFS. Replays only contain input data/multiplayer packets, it would be plain silly if they contained the physics engine. Sending them through the wrong engine will simply generate wrong results.

As has been suggested, if you want to keep viewing your old replays, copy your old LFS directory somewhere before upgrading.

[Pablo.CZ]

I hope there will be rewind possibility in new patch. It can be done thru "keyframes" every 30sec or so. If not, we'll wait next year or longer for next physics update => next possibility to change spr/mpr format for rewind support :(
It's annoying to judge accident in long races now..

[Madman_CZ]

id quite like to see the replay controls they used in ea f1 99-02. Hva ethe replay timeline load up and just scroll along it back and forth to view the replay....

[Pablo.CZ]

id quite like to see the replay controls they used in ea f1 99-02. Hva ethe replay timeline load up and just scroll along it back and forth to view the replay....
Stepless rewind isnt possible because of way how replay data is interpreted. But 30s steps are relatively "easy" to do.

[Levi1]

Stepless rewind isnt possible because of way how replay data is interpreted. But 30s steps are relatively "easy" to do. What if LFS could record a ISI/Papyrus-like replay from the SPR and MPR files, storing it temporarily on your harddisk.
Then the replay files will still be small enough for lfsworld and we can rewind them. We wouldn't have to wait a year for the next physics patch either.
It seems logical or am I missing something?

[Razzone]

You can test drive a car from an spr because the replay also contains the setup, this has nothing to do with the physics engine.

Infact I was discussing about PHYSICAL DATA and the "Definitely no.." referred to physical data contained in SPRs. So said it's perfectly clear that old replays won't be of any use with next patch.:thumb:

[Bob Smith]

Just like old replays aren't of much use anymore either. And why ORION has 6 LFS installs (other than having nothing better to do).

[GP4Flo]

I've currently 8 LFS installs on my computer plus the skin viewer, although I'm currently only using two of them. :D

[Micha]

Argh, I wanna become Betatester too. :thumb:

[AndroidXP]

Infact I was discussing about PHYSICAL DATA and the "Definitely no.." referred to physical data contained in SPRs.
1. Physical data != physics data.
Physical data are some paper files you put in a folder, physics data referred to parts of the LFS physics engine - which is not contained in the replays. Of course the setups are included too, but thinking more like a programmer I filed that under "user input".

2. My reply "Definitely no." was the direct answer to his question "Will the replays of today still work with the new patch?". Nothing else.


So in conclusion: read - comprehend - post. Thanks.

[deggis]

Cool - cos I reckon a lot of my PBs are gonna be smashed if there's a load more low speed grip.
I expect WRs to be lower in some tracks after the patch. If patch does what it should do it's not possible to anymore use the sliding as advantage when making WRs if you know what I mean.

[Christian Seidel]

While viewing the replay, these inputs are fed into the physics engine, thus relying on the physics engine to give the same results as it did when the race was being recorded.

Are you really 100% sure about that? I mean did the devs ever confirm that replays work like this?

Because IMHO that wouldn't work - at least for MPRs. Since an internet connection is not always 100% stable you can never be sure to receive all the input data from all clients. So if you only use the input data to re-play the race it would go OOS everytime somebody lags or a packet loss occurs or something. And if you ever looked from the cockpit view in an MPR you will have seen that the steering wheel doesn't move smooth like in SPRs but in steps. And if this represents the input data used to re-create the path everybody was driving it would go OOS at once since you don't have all the input you would need for the "real" way that was driven.

So if my assumption (and remember, it's nothing more than that) is right it seems logical to me, that a replay can only be replayed correctly if you use the location- and direction-data of the whole car to re-create the driving path and the input-data to simulate the appropriate steering wheel movement and such. In this case, even when a lag occurs the replayed car can be placed correctly again after the lag which wouldn't be possible with only the input data since the game cannot know what the driver was doing during the lag. And I saw lagging cars not going OOS in replays. And another consequence would be that as long as the 3D-data of the track and the car doesn't change, the replays would still work.

Just my thoughts - tell me if you know that I'm wrong.:)

[(SaM)]

Seidel, SPRs are very strict and recorded but MPRs arent. MPRs are based on interpolation.

MPR replays can handle small differences because it just sets the car to the recorded state and lets the physics engine roll it in the direction it was heading for a while, and then totally forgets everything and changes the car to the next recorded state. Altough the recorded physics engine (older) is different than the interpolation engine (newer), it will only make the car move a little different in between the updates.
Some stuttering during corners here and there, some small warps forwards or backwards while accelerating and things like that.

An SPR replay has every state( change) of the car recorded on every moment. It does not use interpolation and it needs a physics engine to build and calculate on. If the physics engine is just a bit different, imagine what effect it would have after 10 updates > after 100 updates etc.

OOS!

(I'm not completely sure of this information but I think it's just about reliable.)

[AndroidXP]

Are you really 100% sure about that?
Pretty much yes, but read what I've written in my original reply :)
...but only the user inputs for SPR files or the position/user-input packets for MPR files...When you race online, all you get is a constant stream of position and "user input state" packets from the server. Such a packet contains the position of the car, the forces acting on it and the current user input, like "steer 1.54° to right" and "throttle at 85%".

All LFS now does is take the packet, put the car on the position and input the rest to the physics engine, hoping that the result somewhat resembles what happens in real. This goes on until the next packet for this car is received, putting the car to the correct position where it really was on the driver's PC.

This are the little jumps you constantly see in a MP race, everytime correcting the little inaccuracies between what you calculated and what happend on the PC of the driver. It's most apparent in crashes, where sometimes you see the competitor's car fly around and suddenly it's planted on the ground again, simply because crashes have the highest degree of randomness right now.


Now, what happens when you record and view a multiplayer race is basically that you store all those input packets and then "play them back", as if there's a server sending you those same packets again. The only difference is, that this now also goes also for your car so you can even see the jumping on your own car.

The point is, between those packets, you also use the physics engine. If the latter one changes, this would basically result in bigger correction-jumps, depending on how much the behaviour changed, up until a point where it's simply impossible to watch it because of 2 metre jumps every view seconds.


In conclusion, with a new physics engine:
- SPR files are completely broken
- MPR files should work to a certain degree, but that also depends on what content you need from a MPR packet. If there's some info missing that is vital for the new engine, then you won't be happy either. Scawen may also just make a compability/version check and simply refuse replaying "old" replays. Then MPR would be "completely broken", too.