• Our friends from AlphaCentauri2.info are in need of technical assistance. If you have experience with the LAMP stack and some hours to spare, please help them out and post here.

Single Player bugs and crashes v40 plus (SVN) - After Oct 2019

It's not, I played it 7 turns before it CTD'ed, the ctd wasn't repeatable either.

I think SO meant that turns take longer than he likes every 3-6 turns or so.
yeah, probably so, i might take every 6-8 turns then but its the same not repeatable, but then again in so many turns it keeps stalling , , ,
 
yeah, probably so, i might take every 6-8 turns then but its the same not repeatable, but then again in so many turns it keeps stalling , , ,
ugh... that would take forever on a debug run to find the issue and I may not be able to if I'm not trying to actually play the turns out. By stalling, how long are we talking here?
 
Btw, we are getting a butload of asserts when cities are razed. It's complaining about values that are typically modified by a city are not what they are expected to be after the city has been removed in the CvCity::kill() routine.

I've looked a bit into it, but have trouble figuring out what exactly is wrong here.

If any other coders than me would look into this I would appreciate it as I currently lack the enthusiasm needed to look deeper into it.
 
Couple things:

Generally like the new build screen (haven't played in a year, nice job Toffer). Issue 1: Using the debug '+' command to build buildings, the build list doesn't seem to hook into that event properly and update the list. Issue 2: Shift-Clicking on buildings hides the icon in the build list properly, but I would expect the rest of the icons to shift over. Makes it hard to fill out the build queue when you have to move the mouse and click on each individual icon.

Also, Game did a hard crash, right around getting sedentary living. Not sure what caused it, though.
 
Btw, we are getting a butload of asserts when cities are razed. It's complaining about values that are typically modified by a city are not what they are expected to be after the city has been removed in the CvCity::kill() routine.

I've looked a bit into it, but have trouble figuring out what exactly is wrong here.

If any other coders than me would look into this I would appreciate it as I currently lack the enthusiasm needed to look deeper into it.
Been doing that as long as I can remember. I haven't been able to figure out what the problem is, though I suspect it may just be that some asserts that may be well placed for usual use are not being properly routed around during the destruction process. Probably not actual bugs otherwise since no problems are being created so far as I can see.
 
ugh... that would take forever on a debug run to find the issue and I may not be able to if I'm not trying to actually play the turns out. By stalling, how long are we talking here?
I ran 20 turns on the debug dll attached to VS and it didn't CTD. Maybe the debug dll is sturdier against CTD's and that one has to do it with a different build, I got a CTD after 7 turns on the assert dll, but I didn't have it attached to VS at the time as I didn't know what SO meant by "stall" when I did that.
 
I ran 20 turns on the debug dll attached to VS and it didn't CTD. Maybe the debug dll is sturdier against CTD's and that one has to do it with a different build, I got a CTD after 7 turns on the assert dll, but I didn't have it attached to VS at the time as I didn't know what SO meant by "stall" when I did that.
The debug dll CAN clean up some bad unit states at times but it's unusual for that to be the cause of a freeze.
freeze is a better word, thx TB, am just having problems right now, mind not thinking on all cylinders
Freezes that aren't repeatable are very hard to debug because there's no dump for that and trying to replicate, as Toffer is finding, is a nightmare. However, it can often BE replicatable because it's usually a problem in the unit AI somewhere that you just need to have saved before clicking the end turn on the round before it takes place so it can be repeated and then observed at end turn. If you can find that kind of save, it would be very helpful.
 
Also, what happened to sea tunnels? Can't seem to build them anymore. Options enabled and have civil engineering.
 
Also, what happened to sea tunnels? Can't seem to build them anymore. Options enabled and have civil engineering.
They can be built on coasts only, later techs are needed to build them on seas and oceans.
 
Heres a dump for the random crashes.
I'll need to try to figure out how to make minis work now that version control is so much more fluid. I'm not sure how I can even do this because we aren't saving dlls anymore.
 
I'll need to try to figure out how to make minis work now that version control is so much more fluid. I'm not sure how I can even do this because we aren't saving dlls anymore.
I've never been able to use a mini other then one from my game cause I'm too dumb to get the pdb version right, and now that mod is on github I don't even know what the current version is or where to find it. ha
 
I've never been able to use a mini other then one from my game cause I'm too dumb to get the pdb version right, and now that mod is on github I don't even know what the current version is or where to find it. ha
That's my problem. You can't even build a dll after the fact to get the exact same fileset as what a person was using at the time so without saving the dll and pdb with the updates, you can never use a minidump. Effectively, if I'm understanding this properly, that means that moving to github and setting things up as we have, we've lost the ability to use a mini that wasn't generated on our own system with the dll we were running at the time.
 
That's my problem. You can't even build a dll after the fact to get the exact same fileset as what a person was using at the time so without saving the dll and pdb with the updates, you can never use a minidump. Effectively, if I'm understanding this properly, that means that moving to github and setting things up as we have, we've lost the ability to use a mini that wasn't generated on our own system with the dll we were running at the time.
Unless the mini was generated by an SVN user, the dll and pdb files on the SVN for a given revision is identical for anyone who has that revision; so if we know what SVN revision the mini was generated on we can use it.
 
Back
Top Bottom