Post by NeverGoWest in Version 8: Return to War comments

Viewing post in Version 8: Return to War comments

Thanks for the reply! I will test it out to the best of my ability! No need to be sorry about the bugs, you are doing this for free and I really appreciate the work. About the saving issue I tried to run it as admin, the game was extracted into a folder on my desktop and all other games have never had any issue saving files, even when not running as admin, but I will try again and give you some better error readouts. Does it create any crashlogs anywhere(if it can even do that right now?) and is there anywhere I can report bugs and issues more directly than here?

Edit: Testing the new version right now, I haven't gotten to saving yet, but I encounter this issue now where I can not make my enthralled noble vote for something else, I can only make them boycott the vote. It is for any type of vote, not just provincial or national elections

BobbyTwoHands4 years ago

Hey,

The save bug is odd. We tested it on three computers, and it saved fine. It should have worked from the desktop folder, but, well, computers are complicated, annoying and hard to predict. The error file should be in shadows_v8_data / output_log.txt. We don't currently have any other bug tracking system than here, no. If the bug is a failure to save, it should be fixed somewhat. It may not succeed in saving, but should keep running and not crash.

The voting has been changed, to operate entirely from the voting screen, accessible from the voting button above the ability and power buttons. This replaced the old voting ability buttons, to unify the UI somewhat. It should allow slightly better instant feedback on how the voting is impacted by your own vote, how much more you'll need to do to swing the vote, and who to target to achieve this.

NeverGoWest4 years ago

Okay so yeah I still get failure to save and then error message spam and a crash, I will look for the output log! Where do I send it to you?

NeverGoWest4 years ago

Okay so I reviewed the output log, it seems to contain sensitive information that does not belong to me, mainly file system paths with a name that does not belong to me, there is a first name in the filepath that starts with 'A' and yeah it seems to be some sort of stack overflow and there is an entire block before the game crashes/freezes/breaks of just errors relating to some sort of serialization stuff

NeverGoWest4 years ago

Sorry for the "reply spam" but I have narrowed down the cause of the error! It is related to map size, I had no issue saving and loading a default 32x30 map and somehow when I generated the 64x60 map it saved "fine" but when I tried to load it I got a NullReference error. So it seems to be related to the saving and loading system not being geared for maps larger than default

BobbyTwoHands4 years ago

Excellent work tracking down the repeatability. Sadly, this implies it's an issue we struggled with for over a month, before literally rolling back the entire project to a version of Unity from 2015. It's probably a problem in Unity itself, we were unable to get any form of useful error message, and the crash happens at random parts of the saving process (implying there's a second thread, made by Unity, which either times out or crashes).

The best we're likely to do is to try to compress the save files down a bit before they're passed to the save/load function, and decompress them at the other side. There are some easy ways to do this, and some hard, so we'll see how many we can get done for the next version.

Regarding the private data in the output file, that's just yet more annoying Unity stuff. In general, I think Unity's a decent enough engine, and the game wouldn't be possible without using a third-party engine like this, but some of the decisions the devs made are perplexing to me. My name is in the credits and the github repo, so I'm not too concerned, it's just irritating and odd.

Thanks for your work tracking down the issue, sorry that I can't promise a full fix. We'll look into what can be improved.

NeverGoWest4 years ago

Hey its alright, I have encountered similar issues with a proprietary game engine just not being nice about savedata handling or dealing with large multidimensional arrays, though unity really should be able to handle all that data, is it all stored in map tile objects or something like that? That might be it, try storing the map separately from agents and nobles and stuff, like maybe its expecting to write a block of data each iteration of the writing loop that is much less complex, IDK. I know of unity games that supposedly handle equal, if not larger and denser amounts of data.

If all fails, then I can recommend Godot, much better licensing(you don't have to pay a single dime no matter how much you make, you can release your games and software with any license you want, you fully own the product of your own design and labor), skills carry over just fine from Unitys SDK to Godots SDK. You got full access to source engine code, too. Engine is written in C++ and it supports both C# and their own (very trivial to learn) python or JS like language for scripting, and the community is really, really helpful and supportive.

Regardless, I wish you the best of luck in making this game, I love playing it!

BobbyTwoHands4 years ago

Okay. It is fixed.

The issue was the third-party open source library we were using to save/load was based entirely on a recursive algorithm. Once the number of people grew too large, it kept just going through their social relationships, calling the recursive function each time it encountered a new person. As such, the thing hit a stack overflow due to having, for every person, called a new recurrence of the function.

Technically it worked, it just scaled so badly that once people hit a certain threshold Unity died.

I've reworked how people refer to one another. The new implementation is technically ugly, and goes against accepted best practices, but it at least works.

At least, I hope. New bugfix version is available for download.

NeverGoWest4 years ago

Saving and loading 64x60 map is flawless, testing autosave now, when I have finished testing on this save I will stress/chaos test it by trying double, quadruple, octuple, etc. sizes of maps and if you want I can try and hexedit a test save to be some insane dimensions, with either cloned or random data. :) I really enjoy helping you out here. Will report back if there are any further bugs, crashes or oddities!

BobbyTwoHands4 years ago(+1)

We've got no current bugs which need tracking down, thanks. The TODO file has a few things, but they're mostly just missing features and gameplay adjustments.

Of course, since it's open source, if you really want to see how it works you could even recompile from source (as long as you can find a version of Unity old enough). The code base is somewhat organised, but has had to compromise in a few areas. Certainly not my best code, but sadly not my worst.

Thanks again for the help, though. Glad to have save/loading actually stable and functional for all known configurations. One problem taken care of for the immediate future, leaving more time to implement vampires and zombies.

NeverGoWest4 years ago

Gotcha! I'll keep playing the game, might actually buy the game soon, it being "name your own price" priced after all, I'll probably pay an equivalent of a few packs of cigarettes or a bag of coffee beans, a box of energy drinks, whichever "programmer stimulant" you favor :) Good luck with the development!

BobbyTwoHands4 years ago

Thanks man. New version just compiled, hopefully this one won't break the save/load system again. I prefer to solve new bugs, not the same damn one repeatedly.

itch.io

Viewing post in Version 8: Return to War comments