Single Player bugs and crashes - After the 29th of March

Status
Not open for further replies.
I just did a recalc and all my units got enough exp to get a promotion. I have the trait that requires extra exp to get promotions and it seems not to be working after a recalc.

A save could be helpful here. Do you still show having that trait at all after the recalc? There were some adjustments to negative trait recalc processes... I'm wondering if something went a bit wrong there (couldn't have been worse than what it WAS doing though...) Just makes me wonder if they are all losing their values...
 
First off, I just want to say I love this mod and appreciate the hard work everyone has put into it. I have had a problem recently where I would have CTD periodically as my game progressed. The frequency has increased to the point to where it will always crash at the next turn. In the past I could reload a past save and usually get past it.

I have attached my save file and the dump log. The save was from v28, but then resaved with v29 (it didn't make a difference with the CTD). Adjusting viewports made no difference either.
 

Attachments

  • single.7z
    7.4 MB · Views: 55
Playing with the SVN of today I found a strange combat bug.

My strength is 0,85 and the attackers strength is 0,8, although it said 72% chances for attacker to win.

The fight is taking place on a desert tile, yes I know i will lose 15% of my strength after the fight is over and my unit will die if it has less than 15% left after the battle, nevertheless the loss of my WINNING unit is counted as a WIN for the losing combatant as well. As I said, very strange chances and a double victor outcome (I don't think I got GG XP for this though). Is this correct at all?

Could it be that the 15% desert penalty is drawn away prior to the battle so the 72% chances results? And after the battle another 15% is taking away so my winning unit dies? Anyhow, maybe you guys can explain this mechanic :)
 
Nevermind


Before you edited your post you wrote that sometimes units, even with only 1 movement can move on after having won a battle. Yes, I experienced this bug as well, just so you know. You suspected the military captive that a won battle sometimes generate as the cause of this bug. I think that is possible but I can't confirm for sure that the movement bug after attacking a stack only appears with captives - although it very well might be.

What I can say though is: the bug may leave you 1 movement even after attack but you cannot attack twice with the bugged unit.
 
Hello,

I am having CTD when researching Democracy.

Save Game is attached.

I am using Win7, 64bit, 12G Ram, i5 computer
 

Attachments

  • Before CTD.rar
    4.5 MB · Views: 46
Before you edited your post you wrote that sometimes units, even with only 1 movement can move on after having won a battle. Yes, I experienced this bug as well, just so you know. You suspected the military captive that a won battle sometimes generate as the cause of this bug. I think that is possible but I can't confirm for sure that the movement bug after attacking a stack only appears with captives - although it very well might be.

What I can say though is: the bug may leave you 1 movement even after attack but you cannot attack twice with the bugged unit.
Only new thing in that post was my suspicion that it was related to captives, but I've now had it happen when not getting captives, so it's unlikely. And they can still attack again if they have a promotion that gives them multiple attacks per turn, just like other units with multiple movement points.
 
First off, I just want to say I love this mod and appreciate the hard work everyone has put into it. I have had a problem recently where I would have CTD periodically as my game progressed. The frequency has increased to the point to where it will always crash at the next turn. In the past I could reload a past save and usually get past it.

I have attached my save file and the dump log. The save was from v28, but then resaved with v29 (it didn't make a difference with the CTD). Adjusting viewports made no difference either.

I have reproduced this, and am investigating...

Edit - this is a very nasty (perhaps intractable in the short term) problem. Basically each unit needs a unique id, and the algorithm used to assign them mans there cannot be more than a certain number of ids in circulation (for each player) at any given time. The combination of requirements that the ids must be unique (cannot reuse the same id), units must be findable from their id VERY, VERY efficiently, and 32-bit size of the id conspire to limit the total units per player that can be in existence at any given time to under 8,000 roughly. In this save one of the AIs exceeds this limit.

I haven't given up on it yet, but it doesn't have a simple solution I don't think.
 
I am using Realistic Culture Spread. It seems the first time it is supposed to grow borders (it says "The borders of Hattusa are about to expand."). Then it says "The borders of Hattusa have expanded" but the borders do not expand. In fact the borders never grow until the second time when I have this option on. Attached is a save that shows the issue. Look at the culture bar in the city, then hit end turn and see non-growth.
 

Attachments

  • Bug-RealisticNonCultureSpread.CivBeyondSwordSave
    698.2 KB · Views: 43
I have reproduced this, and am investigating...

Edit - this is a very nasty (perhaps intractable in the short term) problem. Basically each unit needs a unique id, and the algorithm used to assign them mans there cannot be more than a certain number of ids in circulation (for each player) at any given time. The combination of requirements that the ids must be unique (cannot reuse the same id), units must be findable from their id VERY, VERY efficiently, and 32-bit size of the id conspire to limit the total units per player that can be in existence at any given time to under 8,000 roughly. In this save one of the AIs exceeds this limit.

I haven't given up on it yet, but it doesn't have a simple solution I don't think.


Maybe it's possible to limit each players total units to 8000 max then, so the problem doesn't appear in other games?
After all there are max units with the cultural unique units, so why shouldnt be a limit to the sum of all units as well?

I am using Realistic Culture Spread. It seems the first time it is supposed to grow borders (it says "The borders of Hattusa are about to expand."). Then it says "The borders of Hattusa have expanded" but the borders do not expand. In fact the borders never grow until the second time when I have this option on. Attached is a save that shows the issue. Look at the culture bar in the city, then hit end turn and see non-growth.

Thats normal behaviour, nevertheless sometimes the first border expansion does happen, for example if there is a lot of flat terrain around the city - although even a river can stop it regardless if flat terrain on the other side.
 
I have reproduced this, and am investigating...

Edit - this is a very nasty (perhaps intractable in the short term) problem. Basically each unit needs a unique id, and the algorithm used to assign them mans there cannot be more than a certain number of ids in circulation (for each player) at any given time. The combination of requirements that the ids must be unique (cannot reuse the same id), units must be findable from their id VERY, VERY efficiently, and 32-bit size of the id conspire to limit the total units per player that can be in existence at any given time to under 8,000 roughly. In this save one of the AIs exceeds this limit.

I haven't given up on it yet, but it doesn't have a simple solution I don't think.

Wasn't this the same problem with barbs/animals a few versions ago? At one point there were so many spawned that the game just hung.
 
Wasn't this the same problem with barbs/animals a few versions ago? At one point there were so many spawned that the game just hung.

Yes, and we addressed that by inhibiting animal spawn. Can't really approach this the same way (would be confusing for users, and disastrously confusing for the AI). However, I have found an issue that is causing the sensitivity to it to be greater than it should be, so I can at least stave it off, hopefully enough that we will cease to see it in realistic situations (testing a change now)
 
Yes, and we addressed that by inhibiting animal spawn. Can't really approach this the same way (would be confusing for users, and disastrously confusing for the AI). However, I have found an issue that is causing the sensitivity to it to be greater than it should be, so I can at least stave it off, hopefully enough that we will cease to see it in realistic situations (testing a change now)

Awesome :goodjob:
 
I have reproduced this, and am investigating...

Edit - this is a very nasty (perhaps intractable in the short term) problem. Basically each unit needs a unique id, and the algorithm used to assign them mans there cannot be more than a certain number of ids in circulation (for each player) at any given time. The combination of requirements that the ids must be unique (cannot reuse the same id), units must be findable from their id VERY, VERY efficiently, and 32-bit size of the id conspire to limit the total units per player that can be in existence at any given time to under 8,000 roughly. In this save one of the AIs exceeds this limit.

I haven't given up on it yet, but it doesn't have a simple solution I don't think.

I suppose if its the Barbarians that are exceeding this limit, we could split the animal and barb 'civs' now...

But if its an actual other civ, which I could see happening in late game sure, then yeah, something far more tricksy is in order. Interested to see what solution you come up with there. (BTW: I like what you did for the culture fixes. Good call ;) )
 
Saw this "TXT_KEY_MEAL_CENTER" when researching Trade. Vanilla v29.
 

Attachments

  • Civ4ScreenShot0003.JPG
    Civ4ScreenShot0003.JPG
    407.9 KB · Views: 54
Hello,

I am having CTD when researching Democracy.

Save Game is attached.

I am using Win7, 64bit, 12G Ram, i5 computer

I am unable to reproduce this crash. Can you do the following please:

1) Provide the dump file (minidump.dmp, in the same folder as your BTS executable)
2) Confirm which version you are running (I'm assuming V29 unless told otherwise)
 
I have reproduced this, and am investigating...

Edit - this is a very nasty (perhaps intractable in the short term) problem. Basically each unit needs a unique id, and the algorithm used to assign them mans there cannot be more than a certain number of ids in circulation (for each player) at any given time. The combination of requirements that the ids must be unique (cannot reuse the same id), units must be findable from their id VERY, VERY efficiently, and 32-bit size of the id conspire to limit the total units per player that can be in existence at any given time to under 8,000 roughly. In this save one of the AIs exceeds this limit.

I haven't given up on it yet, but it doesn't have a simple solution I don't think.

Thanks for looking into it. If I were to delete the stack of dooms on the AI side, would that eliminate this problem (or until they build more units)?

Yes, and we addressed that by inhibiting animal spawn. Can't really approach this the same way (would be confusing for users, and disastrously confusing for the AI). However, I have found an issue that is causing the sensitivity to it to be greater than it should be, so I can at least stave it off, hopefully enough that we will cease to see it in realistic situations (testing a change now)

Excellent! I will look for the latest SVC.

edit: I used the latest SVC and I was able to get through the turn. Patch works. Thanks for the quick response!
 
I don't know if it's a bug, my all of my units seem to only get 1 exp per battle in v29. Even if combat odds say I'll get 5+, I still only get 1. Dynamic EXP is turned off, battlefield promos is on.

This is happening consistently for every battle, not just a single one. I've tried turning on/off dynamic EXP and battlefield promos, but it didn't fix anything.
 
Status
Not open for further replies.
Top Bottom