ID:2849873
 
Resolved
Internal savefile indices were thought to still exist in some cases where they didn't, causing read/write failures.
BYOND Version:515.1598
Operating System:Windows 10 Home
Web Browser:Chrome 109.0.0.0
Applies to:Dream Daemon
Status: Resolved (515.1599)

This issue has been resolved.
Descriptive Problem Summary: Saving results in Read() and Write() runtime errors where none occurred in 514. Recreated using Luber's appearance manager because I couldn't reliably reproduce the bug with swapmaps.

Numbered Steps to Reproduce Problem:https://mega.nz/folder/cldgwbLZ#5z352KjZh2_5NuoUwfizsw

Luber's test case: https://mega.nz/folder/dhcyWYgR#qp1k2YfuKOYm54xM70ngxA

Expected Results: No runtime errors

Actual Results: Runtime errors

Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? On 514 stable.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) All versions of 515.

Workarounds: Use 514 stable.

The actual bug is most likely when chaining Read/Write calls through datums saved in contents/lists, and when you're trying to manually read(or possibly write) to the same named directory as the datum call before.

Tested on 515.1598
/*
Bad savefile on load:
use AddObjToContents() to add an obj to your contets
use SaveMob() to save your mob with contents
use LoadMob() to runtime because the directory "asd" it tries to read from the object in contents is also present in the mob itself, so it bugs out
note that the bug is also present in saving as can be seen in the savefile contents you get when you save/load, it never properly saves the "asd" value under the mob

adding multiple objects will also cause the objects after the first one to cause the same runtime
*/

savefile/byond_version = 514 // does nothing like usual

var/buggedSavefileKey = "asd"

mob
verb
AddObjToContents()
usr << "Adding obj to contents"
new /obj(usr)

ClearContents()
usr << "Clearing contents"
usr.contents = null

SaveMob()
if(fexists("mob.sav")) fdel("mob.sav")
usr << "Saving mob to mob.sav"
var/savefile/F = new("mob.sav")
F << usr
input(usr,"","",F.ExportText()) as message

LoadMob()
if(!fexists("mob.sav")) return
usr << "Loading mob from mob.sav"
var/savefile/F = new("mob.sav")
input(usr,"","",F.ExportText()) as message
F >> usr

ToggleLoadBug()
buggedSavefileKey = buggedSavefileKey == "asd" ? "asd2" : "asd2"

mob
Write(savefile/F)
..()
F["asd"] << 1

Read(savefile/F)
..()
try
var/val
F["asd"] >> val
catch(var/exception/e)
world.log << "---------Catch block------------"
world.log << "[e] on [e.file]:[e.line]"
world.log << "src = [src]([ref(src)]) type: [type]"
world.log << "F = [F]([ref(F)]) vars: [json_encode(F.vars)]"
world.log << "--------------------------------"
throw(e)

obj
Write(savefile/F)
..()
F[buggedSavefileKey] << 1

Read(savefile/F)
..()
try
var/val
F[buggedSavefileKey] >> val
catch(var/exception/e)
world.log << "---------Catch block------------"
world.log << "[e] on [e.file]:[e.line]"
world.log << "src = [src]([ref(src)]) type: [type]"
world.log << "F = [F]([ref(F)]) vars: [json_encode(F.vars)]"
world.log << "--------------------------------"
throw(e)
Added Luber's test case to the OP.
Lummox JR resolved issue with message:
Internal savefile indices were thought to still exist in some cases where they didn't, causing read/write failures.