Yudishtira
Spiritual/Creative
The link in the quote still doesn't work, but the link in the original post has been fixed
.
Single Player bugs and crashes - After the 24th of February 2014
- Thread starter Dancing Hoskuld
- Start date
The link in the quote still doesn't work, but the link in the original post has been fixed
.
Hehe, yes, I can't edit your post Sparth.The link in the quote still doesn't work, but the link in the original post has been fixed
eel
Chieftain
- Joined
- Apr 8, 2012
- Messages
- 67
strategyonly
C2C Supreme Commander
Thunderbrd
C2C War Dog
Perhaps its not but I don't have any familiarity with the trade code at this time and in itself its not the simplest beast. Koshling would've been able to do this quickly, yes. It'll probably be something to put on the 'known bugs' list if Alberts can't tackle it before the release.When AIs pay you gold per turn as part of a peace/capitulation deal, they should cancel it at the end of the term. To make it simple, they could cancel any gift (ie. getting nothing for it) trade at the end of its term. If they and you want to continue it, it would then be up to you to ask for it again.
I have AIs furious with me, but nevertheless continuing to pay me (big chunks of) money for nothing! There are also valuable expired resource deals which they could cancel and don't.
If this cannot be fixed in the short term, please tell me why. And please don't tell me it's in any way tricky to get the AI to do this, as I would be sceptical in the extreme.
I think this has always been this way - not sure if it's by design by firaxis or one of those things we picked up from the BBAI team but culture builds have, for a long time now, always stopped the culture build as soon as the city gains a culture level. It's to prevent players (and AI) from forgetting all about the city for longer than intended.
I'll be happy to take a look.
You should update the SVN again before starting that game. You shouldn't still be getting this problem.Not sure if it's a bug or some wrong settings but when I started new game I have noticed some weird options turned on which I didn't even knew they existed. Especially No Future Era which I don't know where to turn off.
Spoiler :
That is interesting. There IS a reason that may be taking place so I will certainly look into this. Thanks for the evaluation... I'd not considered this could be the issue with tales.
Thunderbrd
C2C War Dog
Crash is in the exe. Doesn't give any hints as to how this takes place or what the problem might be (though usually missing or incorrect art reference right?)
Some more minidumps from CTD: View attachment 375937
The one from the latest revision happened at the beginning of my turn; don't remember the other one.
The one from the latest revision happened at the beginning of my turn; don't remember the other one.
Thunderbrd
C2C War Dog
The one from the latest revision is NOT just a graphics glitch... there's a divide by 0 taking place somewhere but the mini isn't helping to zero in on where so I'm running the attached debugger on the game now.
I did not load the save but i had a divide by 0 in CvUnit::getDefenderCombatValues.
Here
Code:
int iOurDamageBase = ((GC.getCOMBAT_DAMAGE() * (iTheirFirepower + iStrengthFactor)) / (iOurFirepower + iStrengthFactor));
int iTheirDamageBase = ((GC.getCOMBAT_DAMAGE() * (iOurFirepower + iStrengthFactor)) / (iTheirFirepower + iStrengthFactor));and the fix
Code:
int iOurDamageBase = ((GC.getCOMBAT_DAMAGE() * (iTheirFirepower + iStrengthFactor)) / std::max(1, (iOurFirepower + iStrengthFactor)));
int iTheirDamageBase = ((GC.getCOMBAT_DAMAGE() * (iOurFirepower + iStrengthFactor)) / std::max(1, (iTheirFirepower + iStrengthFactor)));The save could help because it is crashing inside the exe.
When AIs pay you gold per turn as part of a peace/capitulation deal, they should cancel it at the end of the term. To make it simple, they could cancel any gift (ie. getting nothing for it) trade at the end of its term. If they and you want to continue it, it would then be up to you to ask for it again.
I have AIs furious with me, but nevertheless continuing to pay me (big chunks of) money for nothing! There are also valuable expired resource deals which they could cancel and don't.
If this cannot be fixed in the short term, please tell me why. And please don't tell me it's in any way tricky to get the AI to do this, as I would be sceptical in the extreme
I don't think we made recent changes causing this because i don't remember changes in this area. This means if there is a error it already exists for a long time.
Also since i read about this issues the first time they can't be that critical so what is the short term for you? Don't take this wrong i'am just a bit exhausted.
I don't know that code very well but a Deal has child Trades and if the Deal is killed so are all the Trades. Why should AI players cancel Deals only because they can? if it is still a valid and usefull Deal for them they should not.
Thunderbrd
C2C War Dog
Ok, makes sense... if that's the fix there may be some other places we will need to apply this. This formula is called in a few places in the code, cvglobals, cvgametextmanager etc... I'll look around there.
EDIT: OK, I managed to isolate where they all exist. This must take place due to integer round downs on very weak units under size matters I'd think. Nice to have this found and fixed.
Attaching the debugger to the save has already pointed out some big problems with negative free specialists too... too bad - I was hoping a sum total of a negative free specialist would safely cancel out one that wasn't free. Appears to be more problematic than that so I've enforced a minimum of 0 on the return for free specialists (though the actual tally will still give full consideration to negatives so that a negative can still cancel out a free one from another source and the math won't go funny with an enforced minimum makes a return to 0 state actually add a positive amount.)
EDIT: Also... this save exhibits one of the problems in the AI_Assault code that I was mentioning in PMs...
bool CvUnitAI::AI_pickup(UnitAITypes eUnitAI, bool bCountProduction, int iMaxPath) has been called in the AI_Assault routine. Since the group of transports was asked if it had any cargo space as a group it assumes that the lead unit in the group has cargo space... This AI function only evaluates a UNIT, not a GROUP so as soon as it gets here it sends an assert saying, "wait a minute, this unit doesn't HAVE any cargo space! Why are we running this function again?" It then safely returns out of the function but it's left us with the message that whatever the AI thought it should be doing here it apparently can't.
Now... I believe that one of the big reasons we have a huge delay in the AI_Assault routine is because when it hits these functions it really was supposed to use them - this was the first action the group should've performed but didn't because it only evaluated one cargo full unit rather than the whole group of them. It runs through a number of these attempts to perform actions, finding it can't (when really, the GROUP should be able to) then wondering why, once it gets to the end of the AI_Assault routine, it's found it can't do anything and then re-evaluates. This loops around re-evaluating until it gives up in threshold established frustration.
I know that to loop through all the units IN the group, THEN making calls to functions like AI_Pickup when it finds the first valid cargo available unit would be a little bit more processing (well... potentially a LOT more processing) but I'm thinking it would actually still speed things up as it wouldn't have to re-evaluate the whole AI_Assault routine over and over constantly and I'm also thinking that it would make the whole of this AI structure more successful in performing the tasks it should be performing.
What's you're take on this?
Thunderbrd
C2C War Dog
Ok, yeah, the codes controlling the rule that if a unit isn't unmerged or unsplit it can't perform a number of actions it normally would be able to (to enforce that unit's can't just split up and perform the action that would sacrifice the unit 3 times rather than just once) were totally whack. I'm not sure if I programmed it like this originally but since the initial attempt I'd put some functions in place on unitinfos.cpp that would make this check MUCH easier (and faster!) so by using those rather than a total re-evaluation of the unit's combat classes I should now have this repaired.
Just do it and then we can see how much more processing it takes.
If it just loops through the units of that group and stops if it has a match it should not be to alot overhead. If it is too much overhead we see how it can be reduced.
Thunderbrd
C2C War Dog
Cool... I figured that's what you might say but I wanted you in the know on this so that if you saw something suspicious taking place around these spots you'd have a better idea of what was happening there.
I did some reading and found out that anyone with a graphic card older than aprox. 2004 will have problems with the resolution of the new leaderheads as graphic cards of that time did not support resolutions that are not a power of 2. I figure that those graphic cards would probably have trouble with C2C anyway, so this might not be a problem.... But now you know.
Thunderbrd
C2C War Dog
Actually... in going deeper into this I believe the problem is the function ejecting code itself. CvUnitAI doesn't have the ability to analyze one unit at a time with a statement like pLoopUnit->cvaifunction. This means I can't break the function down into a single unit at a time analysis so I took a closer look and it appears it would be fine if I instead change the evaluation of if the lead unit has cargo to an evaluation of if the group has cargo space to allow the function to continue it's processing. I'll be testing this of course, hoping it doesn't cause any new bugs to go about it this way.
On the VERY + side, I believe this means that the code will be much more efficient than it would be if each unit individually called the function!
Sounds good!
Similar threads
- Sticky
- Sticky
