Still fails to save, something about a null reference or something. Now with the autosaving it kills the game by trying to save and failing, it also asks windows firewall for permission to connect to the internet, which I by principle deny singleplayer games the perms to
Viewing post in Version 8: Return to War comments
Hey,
Sorry about the bugs. I think they're caused by you not having user-level write permission to the folder which Shadows is in. As it is just an Indie game I didn't want to start writing to AppData and making folders on the user's disk, so saves its saved games to where the .exe is. We've now put a check to see if it has permission, and not fail catastrophically if it doesn't. Sadly, it won't be able to save under those conditions.
Regarding the network thing, that's a Unity built-in which we can't disable. It doesn't need any network capabilities and doesn't communicate over the network in any way, so go ahead and lock it down.
New bugfixed version is out, hope it works for you. You may need to disable autosaves in the options (buttom right) or it'll try to autosave once before realising it can't.
Thanks for the feedback
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
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.
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
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
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.
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!
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.
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!
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.