Negative mResidentialCapacity

[Archy]

Playing probably my fourth game, thinking I'm getting the hang of it barely. Have about 105 people, but the variable mResidentialCapacity is stuck at -35866109 or some number to that effect.
I debugged a bit but got a bit lost so decided to save the game.
It failed the save saying the savefile doesn't exist (I typed it into the little black box) and then the game just closed....so I have nothing to show sorry.

I then started again and just tried saving a new game:
"Couldn't open 'savegames/MyTest.xml' for writing: not found

I guess it's looking in the wrong location maybe?  All the preloaded savefiles are there in the list though, so I'm not sure why it would try and save in a different folder to the one it's showing.  Maybe it's to do with permissions.

Have read a fair bit on these forums but haven't come across this, so hopefully I didn't miss something.

[leeor_net]

It does that because it's not looking to write in the program directory (Windows permissions don't allow for that) so they get written to the user directory instead (typically in C:\Users\ somewhere).

The negative capacity is, I think, either an integer overflow or an uninitialized variable. I thought I squashed that... perhaps not. I noticed a similar issue with the resource storage capacity -- I'll have to look into it because those seem to be mostly new? I dunno.

Anyway, I'd recommend deleting any of the save games in data/savegames, should help getting that working properly. If the issue persists let me know -- it's some underlying changes in the NAS2D middleware that aren't playing nice so I'd definitely like to get that taken care of especially if the game just up and quits (probably an unhandled exception being thrown by the filesystem).

[Archy]

So without any modifications, the list of savegames available is populated from M:\vs\Repos\OutpostHD\data\savegames
However the saving of files is trying to save them to C:\Users\trent\AppData\Roaming\LairWorks\OutpostHD\savegames
The reason it fails is because there is no such folder.  The savegames folder sits within a "data" folder in the OutpostHD folder

To get it to work, I had to change the savegame location in strings.h
const std::string SAVE_GAME_PATH = "data/savegames/";

Strangely, this changes both where the files save to, and are loaded from.  I mean, it's what you'd expect, but operates differently to how it did without the change.


I then reverted my changes and tried what you said by just deleting savefiles, but that didn't change anything.

With regards to the game just closing after a failed save, the main thread (main.cpp) catches the exception, throws a doNonFatalErroMessage, and then continues on to execute SDL_Quit() which I guess quits everything.

Now I can save, I can try and reproduce the negative capacity stuff.

[leeor_net]

Sweet. Glad you got some sort of execution path nailed down for it.

It's still an unhandled exception in that it's not caught in the saving code which would prevent it from propagating up to the main function. In int main(...) it has a large try/catch block that encompasses any exceptions that are thrown but not handled higher up -- that's the doNonFatalMessage() call -- it's supposed to provide a message box indicating what's going on as a sort of 'catch all'. It's not the best way to deal with it, definitely one of those work in progress type deals.

But it sounds like I've got a general idea of where to focus some efforts next.

[Hooman]

Sounds like I may have introduced a bug with some of my refactoring. Guess I haven't really tested game saving and loading much.

Thank you for the info.

[leeor_net]

Eh, it's part of the refactoring process. There's a lot there so it's no surprise that a few things here and there break.