Is there any way to fix a slot with desynchronzided "shards" a.k.a. daycount bug in singleplayer?

[myxal]

(@mods: not quite sure where in the forum this question would belong, feel free to move this where it might get attention of the right people)

This issue* has been annoying me (and others) for years now and this time I don't have a backup (I forgot to turn on my snapshotter )

Is there something I can edit in the save files or execute in the console, to fix a slot broken like this? I see few ways out of this:

• Get the game to recognise that the shard it's spawning me in hasn't been updated. Is there a way to edit saveindex so that the slot resumes the "correct" shard? (In my caves that would be caves, at the ruins entrance) I expect that re-entering the shard where the game crashed would re-run the catch-up (LongUpdate without affecting the players or other shards).
• I tried manually LongUpdate-ing the affected shard to get to the right daycount, but this causes the other affected shards to move 5 days ahead as well (so I'd essentially have to trigger the bug in all other shards to level things out - not happening).

* the issue:

Spoiler

Most recent example:

• Leave ruins on day 83 to get some some resources on the surface.
• Spend 5 days on the surface.
• Return to ruins on day 88, get crash, or get killed + shut the game down immediately.
• Relaunch the game, I appear in ruins at the entrance on day 83 (when the game last saved the ruins shard - when I was leaving), with inventory from day 88.
• Caves and surface shards are at day 88 as they should be.

 

[myxal]

Oh, the answer for the 2nd method is right there... thanks, @PaintDream

LongUpdate(<time_delta>, true)

The 2nd parameter is "skip_player" so it's obvious what it does. And the remaining shards are unaffected, yaay! Unfortunately, skip_player doesn't skip Chester and the items in him, so perishables must be on the player, and ultimately, I'd still prefer to make the 1st method work, if at all possible.

[myxal]

@Portmanteau I'd be perfectly happy with a smaller fix - making the game save state immediately after entering another layer and Updating that layer. Force-quitting and death sequence overrides are unfortunately a fact of life for many DS players unwilling to give up rollbacks from DST, myself included. As the game is now, it's leaving its data in an inconsistent state for up to 1 game day after any layer traversal. What were the devs thinking...™