got around to implementing some bit of object persistence between rooms after working on other things for my game recently, since up until now there was no way to recover a room's state after leaving and re-entering lol.
it led to some interesting considerations I wouldn't have otherwise thought about, like the fact that I have puzzle mechanics in here that should be able to reset, but only if they aren't in a "solved" state. if something ever gets lost or stuck, the player can just leave and come back (or revert the save / self-destruct / whatever forces a room reload) to fix it.
...but if the object were resting on a floor button, then its position will be saved for when the room is reloaded (so that it remains sitting on the button).
had to go back and write save/load functions for a bunch of scripts in my code and somehow they all ended up working better than I expected on the first test, and now I'm kinda paranoid that I might've missed something crucial lol.
also had to think about how I wanted each object's save function to be called in the first place, and what sort of ID to use to distinguish instances apart in the save data.
the save system tutorial on Godot's documentation was a bit insufficient here, so I ended up just having each room store an exported array of node paths to all the persistent objects inside it, which it can then iterate over and make the save/load function calls.
when I get around to actually saving things to a file, this approach serves the benefit of being resistant to changes in the node hierarchy / names that could make save files incompatible between updates, since data is basically just being partitioned and referenced by array index. On top of that, the engine will automatically update NodePath objects whenever that path changes, so it's pretty easy to manage.
