Track Replay problems

[Phantom711]

@BIGNEWY

Thanks.

still though…your mission maker allows for scripts being used, so why is it, that the replay won‘t work if the mission used a script? The whole replay system is unnecessarily complicated. Why does a replay load as if it was an actual mission? I don‘t want that. I just want everything to simply move like in the mission and not like it‘s calculating everything as if it‘s happening again.

And what is it with those replays that load, but nothing spawns?

[Nealius]

Still happening quite a lot with both SP and MP tracks. Others seem to be having the same issue. On occasion after a few days (PC reboots maybe?) they sometimes sort themselves out for others, but I haven't experienced that yet. Here's a whacky log from one today:

Quote

2024-09-29 05:14:36.105 ERROR   Dispatcher (Main): Unexpected end of track fiber track/net : idx = 0, time = 0.000000, missing at least 18446744073423911241 bytes

That converts to 16,384 pebibytes. I didn't even know anything above a terabyte existed until today.

[Nealius]

On 9/12/2024 at 9:04 PM, BIGNEWY said:

Failure to load will happen with tracks created in MP that maybe using external scripts. 

Replays using external scripts used to work fine up until the August update(s).

Edited September 29, 2024 by Nealius

[FreightDog]

This is still an issue for me, just ran the latest update today.

[Nealius]

Syria, no scripts, no mods, no dynamic slots. Client replay fails to load. Server replay loads normal. Flown the same mission three times and 2 out of the 3 replays work fine. Only one of them is busted. No common denominator on what causes the load fail.

Server track (works): https://we.tl/t-QrbnG5PVIB

Client track (broken): https://we.tl/t-k8J4nE2T2P

[Hulkbust44]

Replay function only loads to a point then says "mission load fail." 

No tracks work, friend has the same problem. 

Search function yielded no similar results for this core issue.

 

[v2tec]

I can confirm that, but only for multiplayer tracks.

Also, the game stucks at the loading screen with the error message "mission load fail" and you have to kill dcs with the task manager, because there is no other option to continue or quit the game. Bad error handling.

 

null

Edited October 7, 2024 by v2tec

[sleighzy]

1. Drop a DCS log file here from when this problem occurs, need more information. Can be found in "C:\Users\username\Saved Games\DCS\Logs", will be either "dcs.log" or a text document named "dcs" in your Windows is hiding file extensions.

2. Some multiplayer servers use scripts, you may not be able to load these replays as you don't have the scripts on your local machine.

[FreightDog]

This has been happening to me since the last update every time I try and replay a track. Single player. Log attached. Doesn't crash, but briefly states "mission load fail" before just hanging unresponsive at "Terrain init: 1.vti".

 

I have to force DCS close from TM or closing the window from the taskbar.

dcs.log

[Nealius]

This is a widespread issue with reports scattered all over the forums. So far the blame has been pinned on "external scripts" or "large track files" when missions without scripts and small track files also fail.

 

[BIGNEWY]

feel free to add the track here so we can try it, but as mentioned above some servers use external scripts or data which create a problem for the replay system. 

I will merged the threads so we can all discuss it in one place. 

[Nealius]

Kola map, no mods, only two scripts are MOOSE and AIRBOSS. Client track fails to load. https://we.tl/t-iiXSt3M42j

Out of 6 tracks I've tried the past month or so, only half have worked, including ones with heavy external scripts. Single player, multiplayer, doesn't seem to make a difference. The ones with no mods and no scripts also fail. There's no correlation--at least on my machine--between these hangups and scripts, nor SP vs. MP. Each time the error log claims there to be terabytes or petabytes of missing data on .trk files that are only 100mb or less.

Edited October 11, 2024 by Nealius

[durp]

not that I can contribute much at all, but it worked end of last year and beginning of this year, some update broke it, regardless of 'external' scripts.
either 2.9.6 or 2.9.7 broke the replay system (again) and with the cinematic camera feature and such, I was hoping this would be tackled at some point, but now it just 'external' scripts.

 

 

[Phantom711]

@BIGNEWY @Nealius

Sorry to bring this up again...

What I discovered now is, that when I use the "Quit to desktop" option to leave the game (multiplayer), a nicely working replay is created. Same applies to other brute force measures to end the game (i.e. Task manager). If I leave via "Quit" or "Leave server" the replay comes up with "Mission Load Fail".

Sounds good, right? Well yes, but unfortunately replays that worked up to like 2 or 3 weeks ago (until September update?) now still load, but no clients spawn. ED...this is sabotage....

[BIGNEWY]

4 hours ago, Phantom711 said:

@BIGNEWY @Nealius

Sorry to bring this up again...

What I discovered now is, that when I use the "Quit to desktop" option to leave the game (multiplayer), a nicely working replay is created. Same applies to other brute force measures to end the game (i.e. Task manager). If I leave via "Quit" or "Leave server" the replay comes up with "Mission Load Fail".

Sounds good, right? Well yes, but unfortunately replays that worked up to like 2 or 3 weeks ago (until September update?) now still load, but no clients spawn. ED...this is sabotage....

I will mention it to the team and see if we can reproduce. But there is no guarantee that tracks will replay from previous versions, things can change in the core.

thank you  

[Nealius]

That's definitely an interesting observation. I always exit normally and noticed that the "lastmission" track that automatically saves is also corrupt if the manually saved (SP) or auto-saved (MP) track is also corrupt. I will test out the brute force method on SP and see how it works.

[Nealius]

After nearly a month of trying the "quit to desktop" method I've found that the "lastmission" track file is 100% functional for me.

[Nealius]

Update, "quit to desktop" method is not as foolproof as it once was. Multiplayer tracks never work. Singleplayer tracks with the F-15E also never work despite "quit to desktop." Logs are still claiming: Unexpected end of track fiber track/action. The "action" file in the .trk "track" folder is somehow corrupted. Another pattern with these corrupted tracks is that the "mission" file inside the .trk has an incorrect mission date format.

Orignal .miz file format:

["Day"] = 26,
["Year"] = 2024,
["Month"] = 12,

Corrupted .trk file format

["Year"] = 2024,
["Day"] = 26,
["Month"] = 12,

Normal .trk files do not have an altered mission date format, only these corrupted .trk files do. Whatever mechanism is altering the date format in the mission file of the .trk is perhaps also repsonsible for corrupting the track file in the action folder.

[silverdevil]

17 hours ago, Nealius said:

Update, "quit to desktop" method is not as foolproof as it once was. Multiplayer tracks never work. Singleplayer tracks with the F-15E also never work despite "quit to desktop." Logs are still claiming: Unexpected end of track fiber track/action. The "action" file in the .trk "track" folder is somehow corrupted. Another pattern with these corrupted tracks is that the "mission" file inside the .trk has an incorrect mission date format.

Orignal .miz file format:

["Day"] = 26,
["Year"] = 2024,
["Month"] = 12,

Corrupted .trk file format

["Year"] = 2024,
["Day"] = 26,
["Month"] = 12,

Normal .trk files do not have an altered mission date format, only these corrupted .trk files do. Whatever mechanism is altering the date format in the mission file of the .trk is perhaps also repsonsible for corrupting the track file in the action folder.

interesting and good find. can the MIZ TRK file be edited to the correct format?

Edited December 30, 2024 by silverdevil
changed MIZ to TRK.

[BIGNEWY]

7 hours ago, Nealius said:

Update, "quit to desktop" method is not as foolproof as it once was. Multiplayer tracks never work. Singleplayer tracks with the F-15E also never work despite "quit to desktop." Logs are still claiming: Unexpected end of track fiber track/action. The "action" file in the .trk "track" folder is somehow corrupted. Another pattern with these corrupted tracks is that the "mission" file inside the .trk has an incorrect mission date format.

Orignal .miz file format:

["Day"] = 26,
["Year"] = 2024,
["Month"] = 12,

Corrupted .trk file format

["Year"] = 2024,
["Day"] = 26,
["Month"] = 12,

Normal .trk files do not have an altered mission date format, only these corrupted .trk files do. Whatever mechanism is altering the date format in the mission file of the .trk is perhaps also repsonsible for corrupting the track file in the action folder.

I will ask the team about this

[Nealius]

Editing the format and repacking it into the .trk doesn't resolve the issue, unfortunately. The main issue is whatever is corrupting the "action" file.

Edited December 30, 2024 by Nealius

[speakinginsilver]

Hi, suffering this kind of random issue for quite long time, too. This one (https://we.tl/t-uRgrfmafJo), for example, ends in "mission load fail" with the following log message:

Cita

2025-01-06 21:08:51.349 INFO    Dispatcher (Main): loadMission C:\Users\Ivan\AppData\Local\Temp\DCS\tempMission.miz
2025-01-06 21:08:51.349 INFO    WORLDGENERAL (Main): loading mission from: "C:\Users\Ivan\AppData\Local\Temp\DCS\tempMission.miz"
2025-01-06 21:08:52.390 INFO    APP (Main): use_xRay: yes
2025-01-06 21:08:52.390 INFO    APP (Main): netfm_enable_coeff_switching: yes
2025-01-06 21:08:52.485 INFO    Dispatcher (Main): Terrain theatre PersianGulf
2025-01-06 21:08:52.505 INFO    EDCORE (Main): (dDispatcher)enterToState_:4
2025-01-06 21:08:52.505 INFO    Dispatcher (Main): Start
2025-01-06 21:08:52.509 INFO    ASYNCNET (Main): track: serverID=1, localID=13
2025-01-06 21:08:52.520 ERROR   Dispatcher (Main): Unexpected track event index track/net : idx = -2138305536