Please post all bugs in our Mantis bug tracker, NOT here.

[Bremer_Sharp]

I am playing on a mac and every time I try and Save/load a my Prison the game crashes. I dont know if its me or something else but its a bit frustrating when i have to start a new game every time i try and play

Thanks

[IEatFimbles]

Its really annoying as I place stuff and it comes up with that cross the game is amazing but unplayable when I cant place sink in kitchen It says it blocked

[Ten98]

You can't fault them for not fixing an issue marked crash/block/urgent/immediate when it's called "It crashed" has the details "It crashed" and the steps to reproduce are "Dunno; it just crashed", even if it does have debug logs.
I've looked at the unsolved highest priority and highest severity stuff. The majority of it is from the most recent version or contains words the effect of "It crashed". Not counting the duplicates, many of which weren't that important in the first place.

You should look again, despite it being a public free-for-all, there are currently a good number of high quality, replicatable bug reports on Mantis.

Yes, there is a lot of crap as well, but the mods are doing a great job of closing duplicates and insufficient detail issues. Since it's public, some of the submissions are actually feature requests rather than bug reports. I'd love to see the Mantis mods close down all of the feature requests as well as the dupes.

The Mantis system itself makes it quite pleasant to carry out these tasks, and I personally take great pleasure in seeing a bug list of 800+ turn into 400+ overnight, just from stripping out dupes and closing the ones that don't make any sense.

400 sounds like a lot, but many of those bugs which aren't technically dupes almost certainly share a common root cause. I'm working on categorising all the bugs now, and adding "tags" to the ones that are similar. As a start, I noticed a lot of the bugs were related to AI pathfinding, so I tagged all the ones I could see with the "Pathfinding" tag. If the devs improved the general pathfinding routines for staff and prisoners, about 20 bugs would be knocked off the list at the same time.

Having 20 separate reports about a related issue which they can view on a Mantis report by selecting the "Pathfinding" flag allows them to understand the issue in a much more managable way, and gives them a much clearer view than if it was just a big ranty forum post about general pathfinding issues, where everyone sticks their beak in, and it devolves into general arguing and trolling (like this thread has)

So although it says 400, they don't need to make a lot of changes to the game to get that down to under 100, they just need to get smart about which bugs take priority, and tagging similar/related bugs can help them to do that.

[Ten98]

Right now, the game is in alpha status. It is not feature complete. The goal at the moment is to implement all of the features that IV and players want. As new features are introduced, new critical bugs will also likely be introduced. There is not much point in fixing bugs right now, as the game does not currently represent a stable release. Bugs that keep people from playing at all should be fixed, but many of the not-so-critical-but-quite-annoying bugs (such as not being able to build near the border) need not be fixed yet. Those are the kinds of bugs that are fun. And yes, they are.

Once the game is basically feature-complete and goes into beta status, IV can and should worry more about bug fixing.

xander

I would wholeheartedly disagree.

Adding new features on top of already-buggy code, when the bugs in your existing code are known, just not fixed, is a recipe for disaster. Keeping everything in ones head (oh that's still broken, oh don't worry about that bug just now, we'll get around to that) is convenient, and lets you focus on the "fun" part of adding new stuff, but becomes incredibly taxing once the project reaches a certain size. You are much better off going into any new feature development confident that all (or at least most) of your existing features work. Ideally, you will have rationalised your code such that working features are in their own self-contained modules.

That way, when the inevitable bugs from the new features do creep in, you know it's because of a new bug introduced by new code, which is relatively straightforward to identify and fix (you only need to look at what your new code is doing) not a lingering old bug which is manifesting itself in a new way because of the new code, which can be an absolute nightmare (you need to look at ALL of the code).

[111none]

Right now, the game is in alpha status. It is not feature complete. The goal at the moment is to implement all of the features that IV and players want. As new features are introduced, new critical bugs will also likely be introduced. There is not much point in fixing bugs right now, as the game does not currently represent a stable release. Bugs that keep people from playing at all should be fixed, but many of the not-so-critical-but-quite-annoying bugs (such as not being able to build near the border) need not be fixed yet. Those are the kinds of bugs that are fun. And yes, they are.

Once the game is basically feature-complete and goes into beta status, IV can and should worry more about bug fixing.

xander

I would wholeheartedly disagree.

Adding new features on top of already-buggy code, when the bugs in your existing code are known, just not fixed, is a recipe for disaster. Keeping everything in ones head (oh that's still broken, oh don't worry about that bug just now, we'll get around to that) is convenient, and lets you focus on the "fun" part of adding new stuff, but becomes incredibly taxing once the project reaches a certain size. You are much better off going into any new feature development confident that all (or at least most) of your existing features work. Ideally, you will have rationalised your code such that working features are in their own self-contained modules.

That way, when the inevitable bugs from the new features do creep in, you know it's because of a new bug introduced by new code, which is relatively straightforward to identify and fix (you only need to look at what your new code is doing) not a lingering old bug which is manifesting itself in a new way because of the new code, which can be an absolute nightmare (you need to look at ALL of the code).

I completely agree, if you cant build the foundation correctly, of course the building falls down easier

[SaOk]

For the performance drops suddently about 10 minutes playing and never seem to get back to good. If I savegame, exit and come back to load the prison. FPS gets smooth again before again the slowdown after ~10minutes. I am playing the latest alpha 7, problem was also in the earlier versions. Else have been enjoying the game.

My computer: i7 2600k, HD6870, 8 Gt memory, 64bit Win7.

[Gingmax]

For the performance drops suddently about 10 minutes playing and never seem to get back to good. If I savegame, exit and come back to load the prison. FPS gets smooth again before again the slowdown after ~10minutes. I am playing the latest alpha 7, problem was also in the earlier versions. Else have been enjoying the game.

My computer: i7 2600k, HD6870, 8 Gt memory, 64bit Win7.

I have the same problem and my pc specs are more than able to cope with the game. I have to save, quit and reload every 10-15 mins of gameplay. It's really tedious. I've looked on the bug tracker and it is a known issue but there is no info on whether they're trying to fix it. Is there something else I can do in the mean time to help boost things up? I've tried playing on various sized maps but no difference to lag. Also I am aware this is alpha so know not to expect much I was just wondering if anyone knew of a 'quick fix'? On A7 btw

[frenchfrog]

SaOk: You should create a new thread is you have issue if Prison Architect or create a new ticket in the Mantis bug tracking system.

SaOk, Gingmax: If you fire your workers after the 10 minutes slowdown and get some new workers, does it solve the issue?

[Gingmax]

No, it seems to be real time based, the workers/ staff can be idle, and even starts lagging on a new build. I have to do most of the building without prisoners or it really lags. A6 was bad but this version seems worse. My latest prison on med map has 200 prisoners now and i've only built on 2/3 of the map. It took 2 real time days and i can't go any further bc of the lag. I must have a massive leak! I was hoping for a way to plug it!
Also I try to build in really small chunks so not to queue jobs too much, I'm spending more time rebooting than playing!

[Gingmax]

Thanks Frenchfrog, I've changed the way I play - I don't queue too many jobs as this seems to be where the memory leak occurs and reboot every other in-game day, works a treat!!!!

[Parker22]

Thanks Frenchfrog, I've changed the way I play - I don't queue too many jobs as this seems to be where the memory leak occurs and reboot every other in-game day, works a treat!!!!

Yeah - I do something similar- if I need a big new block I'll build it in thirds- it runs smoother. Throughout. Also, mac speed doesn't seem to increase the worker speed that much - so I leave it as normal speed.

I could be imagining that last bit though

[blackmesa365]

In the alpha 8 when prisioners are trying to go out of the cells the guard go and open like if they are staff... This is just in my game or someone are having this problem too?

I am from Brazil so sorry my bad english...

[sandro]

It's happening in my game too. The guard even open the staff door of the kitchen so the prisoner can steal food.

[Georgedinmore]

I have logged into mantis, and filled out the necessary stuff, and i keep getting an application error 401.

My game keeps crashing, and i can replicate to do it each time. And i find this frustrating, because the game is brilliant, yet i can not play because of this crashing.

Please advise?

[djd206]

I cant place a bug report in get this error http://paste.ubuntu.com/5602102/