Fresh loads saved container data into a reconciliation pool and waits for the vehicle, bale, placeable, or storage adapters to claim each entry.
At the moment, any entry that is not claimed is removed in one of two ways:
- saving the game writes only active containers, not the unresolved reconciliation pool;
- the first in-game hour clears any entries still left in the pool.
This makes sense when an entry belongs to an entity that was genuinely deleted. The difficulty is that a temporary registration or identity mismatch looks the same. Possible examples include content being temporarily unavailable, an adapter registering later than expected, or a third-party mod changing the identity information Fresh uses for matching.
If the same entity becomes available again after the save has been rewritten, its previous Fresh batches and ages can no longer be recovered.
A deterministic test can be done with a backup save:
- Create and save a tracked container with aged contents.
- Change its identity in
rm_FreshData.xml so it cannot be claimed on the next load.
- Load the save, then save again or advance through the first in-game hour.
- Restore the original identity and reload.
- The earlier batch ages are no longer available.
Would it make sense to distinguish unresolved entries from confirmed deletions?
Some possible approaches:
- keep the current behavior, but document it and make the log message clear that unresolved data is being discarded;
- continue saving unresolved entries until reconciliation has definitely finished;
- retain unresolved entries for a small number of loads or save cycles before pruning them;
- keep them in a separate dormant section and provide an explicit cleanup path.
My preference would be a short grace period with clear logging. That would protect against temporary mismatches while still allowing records for genuinely deleted entities to be cleaned up.
There is also an intentional clean-slate path for save formats older than version 4. Git history appears to show version 4 was already in place for v0.5.0.0, the first tagged early-access release, so this probably does not require a public migration. It would still be useful to confirm whether development saves from versions 1–3 are expected to be supported.
Fresh loads saved container data into a reconciliation pool and waits for the vehicle, bale, placeable, or storage adapters to claim each entry.
At the moment, any entry that is not claimed is removed in one of two ways:
This makes sense when an entry belongs to an entity that was genuinely deleted. The difficulty is that a temporary registration or identity mismatch looks the same. Possible examples include content being temporarily unavailable, an adapter registering later than expected, or a third-party mod changing the identity information Fresh uses for matching.
If the same entity becomes available again after the save has been rewritten, its previous Fresh batches and ages can no longer be recovered.
A deterministic test can be done with a backup save:
rm_FreshData.xmlso it cannot be claimed on the next load.Would it make sense to distinguish unresolved entries from confirmed deletions?
Some possible approaches:
My preference would be a short grace period with clear logging. That would protect against temporary mismatches while still allowing records for genuinely deleted entities to be cleaned up.
There is also an intentional clean-slate path for save formats older than version 4. Git history appears to show version 4 was already in place for
v0.5.0.0, the first tagged early-access release, so this probably does not require a public migration. It would still be useful to confirm whether development saves from versions 1–3 are expected to be supported.