3gbHow big is such a 24h replay?
I mean, it makes sense that it would have the same problem, as it is the same engine as rf2.The priority is LMU.
They want to release it on the 20th february.
I wouldn't expect any response from the devs before.
It seems logical that LMU will not have this problem, and if they solve it in LMU should be easy to implement the solution in rF2.
Who knows.
I mean, the AMD bug also took very long to fix. The online system after years still doesn't support a good oval plugin. It'll either be fixed very quick, or it will take yearsI wouldn't be so pessimistic, it'll probably take some time. When I opened the thread about the track cut widget, no dev answered the thread, but 15 days later, there was a game update including a fix. The more people like this thread, higher are the chances we'll get a surprise fix in the future. Fingers crossed.
The lack of response from the devs both here and on the discord support channel is not giving me any hope that this will be looked into.
The devs are busy with LMU release deadline, which is roughly a month away and it has been communicated that there won't be rF2 updates until then.
Meanwhile someone could try my suggestion and lower the replay fidelity option, which could help if this is simply a "data amount bigger than x causes crash" issue.
We can't lower replay fidelity, we are talking about dedi replays, not client. Every community or organization rely on them. So stop giving suggestions without understanding the problem.
We can't lower replay fidelity, we are talking about dedi replays, not client. Every community or organization rely on them. So stop giving suggestions without understanding the problem.
I would rather disable replay on server, limiting ressources used to help performance/latency of server, but organize marshalls session to make sure they save contiguous data for the all race.
That solves the replay not readable and make some redundancy possible.
My thoughts ...
Jimmi said he couldn't make the replays any smallerYou can't do that in league racing because a client-side replay has more latency and throttling itself than the server-side replay. The way at least rF1 used to work was that it prioritizes latency to other cars near the client car so other cars may appear laggy in a client replay, which is a problem for analyzing cut detection an incidents.
You can run /unthrottle <client name> on the server for clients, but not sure if it does work anymore.
The 3 GB size could be the actual issue here if rF2 uses some legacy 32-bit libraries. In 32-bit software 2 GB was typically a hard limit for file size, why is why reducing replay fidelity on server *may* help.
This has already been reported in 2016 thoughI fully trust the developers to solve this problem!