Handled nowhere parent

[PatrikLundell]

Summary

None

Purpose of change

Fix #75792, i.e. item location load failure crashes saving.

Describe the solution

Handle an item_location parent of "nowhere" by making the item_location itself "nowhere", rather than trying to move the item to the garbage location of "nowhere".

Describe alternatives you've considered

Try to figure out if the original error handling is incorrect for other cases and if it's even possible for other cases.
It's safer to assume it can somehow happen for other cases, so the placement of the item on the ground is a valid strategy for those cases.

Testing

Loaded the bug report save, quick saved, saved & quit, loaded the save again.

Additional context

[mqrause]

I have a feeling this is the wrong approach to fix that issue. Both the load and the save errors come from (de-)serializing an ACT_EAT_MENU activity of which there are multiple in the backlog of the save from the issue. I don't think there should be any, though, so something else broke the save before.

[PatrikLundell]

I agree the change only handles the symptoms of an earlier error, and the error message reflects that.
However, I think it's still worthwhile to try to handle errors as gracefully as possible.

That said, it's far superior to fix the original error if it can be located, and while I think both changes should be made if possible, I'd go with fixing a root problem if only one thing is done.

I didn't even try to look at the horrible unreadable one liners the JSON files contain, both because of the mess and because I don't have much hope of finding anything useful.

Auto saving has a history of messing up things, and I wouldn't be shocked if you can get messed up saves if you're eating from the eating menu while it kicks in (which I guess these activities represent). However, testing it might be tricky unless you can somehow trigger auto saving manually while the PC is chewing.

[mqrause]

Yeah, identifying the real cause is something between hard and impossible. On the user end, a fairly easy fix is to delete the entire backlog. But that's not that good of a solution considering it happens somewhat regularly.

But looking at the deserialization and item_location default values in general, what mostly seems unsafe to me is using tripoint_min. That's simply not a valid tripoint to use anywhere and the ultimate cause of the crash. But if we have no valid tripoint, I think the item_location ultimately has to become nowhere.