Working Amnesia-Style Inventory System (In Progress)

[Abion47]

I personally would not like a sanity system. Please don't go back to amnesia... Why do we have to be forced by a sanity system ? Frictional Games explained this part very well (go check it out, should be on their blog somewhere). If someone eventually manages to bring it back, it should be an option. I personally would not play custom stories or mods with a forced sanity system. It'd be just a step back..

It's not being "forced" at all. Like I said earlier, I'm disabling the sanity parts of the inventory HUD, i.e. commenting out the parts of the code that deals with it. I'm not removing it entirely solely because if someone were to make a sanity system in the future, all it would take is uncommenting the relevant bits and a few minor tweaks to make it compatible.

So in short, it's there for people who want to enable it, and for everyone else it may as well not even exist.

[Abion47]

...Well dang, this is embarrassing.

So I got everything packaged and ready to start working on the How-To's and demo level, when one possibility occurred to me that completely slipped my mind. So I tried to do a "Save and Exit" action to see how the modules would react... and the game crashed. And it didn't really tell me a whole lot of information beforehand, either.

So yeah, I'm gonna have to figure this one out before I tote this mod out, as I imagine a mod's inability to save the game would be a bit frowned upon. I don't suppose any of you guys have some pointers on how to setup a script to be able to save, even from an HPL2 standpoint? It would save me from having to crack open some more script files and do a bunch more digging if so.

[Romulator]

Posting the hpl.log from the appropriate folder could help. I have been reading the logs lately so I may be able to see an error if there is one which pops up~

[Abion47]

Here it is: http://pastebin.com/9ek8YWaV

Looking through it, I don't see a whole lot of relevant stuff. There's the stupid sound and CathTool errors that have popped up every step of the way, as well as a couple interesting failed calls to the "InventoryModule" (I say interesting because the calls should be looking for the "InventoryHandler" instead) but nothing that really happens around a time I'd think it was interrupting the saving. Maybe the failed calls to _Global_SetIsHudVersion could be screwing it up somehow?

[Mudbill]

Does this happen regardless of whether you pick up those Omnitools or not? Perhaps it's related to one of those items? Maybe try a clean map, join, save and exit, does it then still occur?

I could also suggest you cut (comment) out some of the code you added lately to reduce the troubleshooting spectrum to a minimum.

[TiManGames]

Maybe when you save and exit, the game needs modules to save the inventory parameters (memory data). Maybe you didn't create them so the game crashes.

[Abion47]

Maybe when you save and exit, the game needs modules to save the inventory parameters (memory data). Maybe you didn't create them so the game crashes.

That was the first thing I thought, but I looked back at the PlayerToolHandler class that I based a lot of my decisions on how to handle the journal and inventory data on, and that class doesn't seem to have a whole lot of anything special dedicated to saving its states. (And that would be a very important system to be able to save properly. Imagine loading a save in the middle of the level and discovering your omnitool was gone.)

Also, if it was a matter of not saving something that should've been saved, then wouldn't that mean that I would just load up again and the stuff was simply missing? Hardly a desirable position to be sure, but I doubt that if it were something like that it would result in a hard crash. I suspect it's something more along the lines of it trying to save something that doesn't want to be saved.

[TiManGames]

Maybe when you save and exit, the game needs modules to save the inventory parameters (memory data). Maybe you didn't create them so the game crashes.

That was the first thing I thought, but I looked back at the PlayerToolHandler class that I based a lot of my decisions on how to handle the journal and inventory data on, and that class doesn't seem to have a whole lot of anything special dedicated to saving its states. (And that would be a very important system to be able to save properly. Imagine loading a save in the middle of the level and discovering your omnitool was gone.)

Also, if it was a matter of not saving something that should've been saved, then wouldn't that mean that I would just load up again and the stuff was simply missing? Hardly a desirable position to be sure, but I doubt that if it were something like that it would result in a hard crash. I suspect it's something more along the lines of it trying to save something that doesn't want to be saved.

Run the exe on debuger program and see what is activated when the game crashes.
Look in the call tree and see what functions are activated.

[Abion47]

Does this happen regardless of whether you pick up those Omnitools or not? Perhaps it's related to one of those items? Maybe try a clean map, join, save and exit, does it then still occur?

I could also suggest you cut (comment) out some of the code you added lately to reduce the troubleshooting spectrum to a minimum.

Here's the new log of that: http://pastebin.com/XDGSfqD7

I created a brand new map with just a start area and a plane, loaded it up, then saved and exited, and the same thing happened.

Run the exe on debuger program and see what is activated when the game crashes.
Look in the call tree and see what functions are activated.

Yeah, I know. I was just seeing if there was something quick to look at, since I discovered this after I had already wrapped up my debug environment and hoped that I didn't have to go through and set it all up again.

---

Now this is interesting. I loaded up my other test CS map instead that has no usage of the inventory system whatsoever, and it crashed as well. I'm gonna backup my mod files and try reinstalling SOMA. Maybe in my digging through the game files I screwed something up.

---

Tried reinstalling SOMA. It made my other CS map save fine, but the inventory map is still crashing. What's more, when I set up the debug environment again, it crashed the exact same way - no error messages, no stack traces, no exceptions, nothing. The game just freezes up and quits, and I get a generic windows dialog saying it crashed. The empty map as well... just a silent and hard crash.

---

I've narrowed it down to something within the journal module. I ran the map with the inventory module enabled (but not going anywhere that requires making calls to the journal) and it saved just fine.

---

Ahem. I would like to direct everyone's attention to this scripting article on the wiki. Particularly, the section where it talks about not having object handles among your member variables. Then I would like to show Exhibit B, where I had a member variable that I created near the beginning of working on the journal module, that I never used once and had completely forgotten about. But apparently, when FG says that handles as member variables isn't supported, they are not kidding. Like, game-crashes-without-saying-a-word levels of not kidding.

[Abion47]

Alright. The good news is that it is working properly now, and I've been able to create and save games in a variety of states without any problems. The bad news is that I still have some things left to do with the mod (like moving some local variables into the member scope for performance reasons, moving some text constants as well as map-specific entries into lang files, and making the demo map and tutorial documentation that I promised. What's worse is that I have to spend the next few days focused on a work-related project, so there will probably still be some time until I can get this mod wrapped up and uploaded.