You're proving my point there. We don't want suggestions, we want a fix. Big replays exist, they can't be opened, this needs fixing. Period.
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.
I 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 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 years
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. If we count every league that run 24hours races, we are talking about +1000 drivers affected. LMU it's not even a product, so i don't care. S397 or/and MSG hold a bomb for many years on their fault, this is not new and should be fixed years ago. We are not asking for new features, just to make things worked, as they should be.
I was joking earlier but forgot about that point. On the dedi side we need to keep the full replay, which is probably the best reliable data. 3 Gb is quite acceptable for 24 h data. For analysing race, i would better use client side (marshalls) data. If they stay for 2 or 3 hours they can share that smaller data if needed. And that makes some kind of failsafe if server screws the replay too. 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 ... And i have found a throtling parameter in json file. It looks like some kind of setting to send full data to a client/spectator probably for replay purposes. Any info on that ? With that enable, maybe some client/spectator can have more precise data to save in replay ?
Consider posting a problem replay file here. If, or when, they come back to rfactor they have something to test with.
You 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.
Hi, I would like to report an issue with big replay file (24h race) that cannot being loaded. I believe it's a known issue. If the dev team could take a look into it, it would be very nice. Thanks for the help. Sincerely Kamal
