Bug Reports

FAssert(checkPower(false));

Yeah, I mentioned this bug in a PM other day. It stems from Civs gaining techs that decrease equipment modifiers like Horseshoes is a 25% discount on horses required for scout. If a scout is already in existence when they learn the tech the bug pops up. I haven't traced down exactly why this happens though. When a new trait is processed it sorts through all units and adjusts their power accordingly. So it seems this bug should be avoided...
 
Yeah, I mentioned this bug in a PM other day.
Apparently I didn't fully get the bug at the time. However now that I got it myself to test on and understand what caused it, I fixed it.

CvPlayer::setProfessionEquipmentModifier() now recalculates the cache on the very line after the ProfessionEquipmentModifier is changed. Now no code can be called with an outdated cache. At least it will not be outdated due to this issue.
The only sideeffect is that it recalculates the entire cache for the player in question each time setProfessionEquipmentModifier() is called. This mean it will be recalculated multiple times if more than one profession is modified even though strictly speaking it would only have to set the cache after the last change. I think we can live with that.

Edit: noticed one issue. The cache is saved, which I guess is a good thing considering it makes it easier to hunt bugs. The question now is should we change that and recalculate on load? Should we increase savegame version and only do it on old savegames? Or should we just don't care and say it's ok as we broke all savegames yesterday anyway. The amount of people who is likely to be hit by this is likely countable on one hand.
 
Apparently I didn't fully get the bug at the time. However now that I got it myself to test on and understand what caused it, I fixed it.

CvPlayer::setProfessionEquipmentModifier() now recalculates the cache on the very line after the ProfessionEquipmentModifier is changed. Now no code can be called with an outdated cache. At least it will not be outdated due to this issue.
The only sideeffect is that it recalculates the entire cache for the player in question each time setProfessionEquipmentModifier() is called. This mean it will be recalculated multiple times if more than one profession is modified even though strictly speaking it would only have to set the cache after the last change. I think we can live with that.

Edit: noticed one issue. The cache is saved, which I guess is a good thing considering it makes it easier to hunt bugs. The question now is should we change that and recalculate on load? Should we increase savegame version and only do it on old savegames? Or should we just don't care and say it's ok as we broke all savegames yesterday anyway. The amount of people who is likely to be hit by this is likely countable on one hand.

I'd say do what we have to do to get a more stable game. I don't have any saves I want to keep atm. I have been playing through games on Autoplay looking for failed asserts and checking up on how the AI is doing.
 
When you press the Enter key, the game drops to the desktop without an error message.

Thanks, mastrude. I checked this out and I am confident this bug has been dealt with in the current Git version. There was a couple or so crash bugs still present in 2.0c. Today was a hectic day and I didn't get the official update released but I will by tomorrow in fact I'll start putting it together now.
 
I've been playing published version 2.0d with the assert DLL. Getting error messages like these:

First Game, 2.0d
Assert Failed

File: CvUnit.cpp
Line: 1252
Expression: pCity != NULL
Message:

(Game kept playing. Didn’t crash.) Lots and lots of identical messages after that.


Second Game, 2.0d
Assert Failed

File: CvGameTextMgr.cpp
Line: 9222
Expression: eYield == NO_YIELD || kPlayer.getSellToEuropeProfit(eYield, iAmount * (100 - iCommission) / 100) == iGross
Message:
(Game kept playing. Didn’t crash. and lots of identical messages after that.)

Another game:

Assert Failed

File: CvTeam.cpp
Line: 997
Expression: eTeam != getID()
Message: eTeam is not expected to be equal with getID()

----------------------------------------------------------

Clue me in, please. Are these of interest to you, Kailreic, or are they just warning messages? If these are useful, is this the correct thread to post them in?

Also I have a question. As I recollect a copy of the Assert DLL is included with 2.0d. Can you use this with the development version as well? I would have thought the development version had it's own version of this.

Also, I have a kind of aesthetic question: You guys are adding more and more stuff to the mod. Do you think you may overrun the KISS principle? I like Kael's Fall From Heaven 2 mod very much. I also like Fall Further, but it is just loaded with stuff. For that reason, I frequently play Kael's original version.
 
Clue me in, please. Are these of interest to you, Kailreic, or are they just warning messages? If these are useful, is this the correct thread to post them in?
They are asserts, which mean the code except some condition and it turns out that condition failed to appear. The only cause of this would be bugs, or the assert itself is wrong, but then the assert is the bug. Surprisingly bugs belong in the bugs thread :)

Also I have a question. As I recollect a copy of the Assert DLL is included with 2.0d. Can you use this with the development version as well? I would have thought the development version had it's own version of this.
The DLL change with each change in the development version and as such is not interchangeable with 2.0d. Use the one which came with the version you are playing. The development version only supplies an assert DLL.

Also, I have a kind of aesthetic question: You guys are adding more and more stuff to the mod. Do you think you may overrun the KISS principle? I like Kael's Fall From Heaven 2 mod very much. I also like Fall Further, but it is just loaded with stuff. For that reason, I frequently play Kael's original version.
I share your concern. However I think we need to add a whole lot more and at a much faster rate to reach the "too much" level.

One thing which is very useful with asserts is a savegame, which asserts. Not only is it possible to debug right at the place where it went wrong, it will also be a good platform to test solutions for the problem. Please supply savegames with the bug reports.
 
First Game, 2.0d
Assert Failed

File: CvUnit.cpp
Line: 1252
Expression: pCity != NULL
Message:

(Game kept playing. Didn’t crash.) Lots and lots of identical messages after that.


Second Game, 2.0d
Assert Failed

File: CvGameTextMgr.cpp
Line: 9222
Expression: eYield == NO_YIELD || kPlayer.getSellToEuropeProfit(eYield, iAmount * (100 - iCommission) / 100) == iGross
Message:
(Game kept playing. Didn’t crash. and lots of identical messages after that.)

Another game:

Assert Failed

File: CvTeam.cpp
Line: 997
Expression: eTeam != getID()
Message: eTeam is not expected to be equal with getID()

I looked through these and you can pretty much ignore them as they are not lethal and don't really change the game. The mod should play through without any failed asserts so I'll look into fixing these in the coming days. And yes, these is the correct forum to post this. You done good!
 
I found a crash bug but can't quite figure out why it is happening. Some how the Native ID 229 unit in the save is testing positive for a promotion ready when it doesn not have a group, that is testPromotionReady() in CvUnit:doTurn() function uses GetGroup() but the unit's group is NULL.

Anyway, I added a "if (isPromotionReady() != bNewValue && getGroup() != NULL)" check to make sure group is not null here.

Sense the unit passes the Assert "FAssert(getGroup() != NULL || GET_PLAYER(getOwnerINLINE()).getPopulationUnitCity(getID()) != NULL)" right before the crash I am assuming that only units on the map in a group can become eligible for promotion, but some how this Native unit is gaining experience inside a city or something.
 
Avoiding promotions sounds like a bad solution to this if the real bug is gaining experience. You will hide the real bug and then when you attack the natives, all the citizen will leave town and in one turn they will all get all sorts of promotions they shouldn't have.

Right, its a temporary fix as I don't have time right now to look into this further. The code is there to simply "wake up" a unit that is ready for promotion but units inside a city can't be "woke up". So, when the unit in question leaves the city it will then be eligible for promotion. And this doesn't happen very often so I don't see it becoming a problem as far as getting promotions they shouldn't have.

Edit: I posted the save in case you have time to look into it more.
 
2.0d published version bad asserts:

Spoiler :
Assert Failed

File: CvGameTextMgr.cpp
Line: 8514
Expression: iModifiedProduction == aiYields[eYieldType]
Message:

----------------------------------------------------------
Another one:

Assert Failed

File: CvGameTextMgr.cpp
Line: 8285
Expression: iBaseProduction == city.getBaseRawYieldProduced(eYieldType)
Message:

----------------------------------------------------------
And one more.
Assert Failed

File: CvGameTextMgr.cpp
Line: 8514
Expression: iModifiedProduction == aiYields[eYieldType]
Message:

----------------------------------------------------------

Assert Failed

File: CvGameTextMgr.cpp
Line: 8285
Expression: iBaseProduction == city.getBaseRawYieldProduced(eYieldType)
Message:

----------------------------------------------------------
Assert Failed

File: CvGameTextMgr.cpp
Line: 8514
Expression: iModifiedProduction == aiYields[eYieldType]
Message:[
----------------------------------------------------------
Assert Failed
This one prevents you from buying weapons.
File: CvPlayer.cpp
Line: 14645
Expression: iPrice <= getGold()
Message:

----------------------------------------------------------


 
File: CvGameTextMgr.cpp
Line: 8514
Expression: iModifiedProduction == aiYields[eYieldType]
Message:[
----------------------------------------------------------
Assert Failed
This one prevents you from buying weapons.
File: CvPlayer.cpp
Line: 14645
Expression: iPrice <= getGold()
Message:

You can pretty much ignore the ones that are CvGameTextMgr.cpp as they are just text discrepancies because of multi yields mods and such. As long as the number of yields produced are accurate anyway.

And iPrice <= getGold()? That means you don't have enough cash to buy weapons right where the price is less than your gold?
 
I just had a 2.0d game drop to the desktop. No error message. I looked at the logs but didn't find anything that seemed relevant. Savegame included. I had just researched something that caused me to get a free War Galley. I think that was Sternpost Rudder research, and it looks like I had just finished (?) Renaissance. I'm guessing this was related to research. If I open the research screen, it shows Renaissance at (-1) turns to complete.

I did find an audio.log with lots of error messages. Please tell me whether this is helpful. Uploaded in two parts.
 

Attachments

I just had a 2.0d game drop to the desktop. No error message. I looked at the logs but didn't find anything that seemed relevant. I did find an audio.log with lots of messages. Please tell me whether this is helpful. Uploaded in two parts.

Thanks for the report, it may be a bug related to one I just found. Try these DLLs from the development Git version and see if the Game Crashes....

attachment removed

Edit: Thanks for the sound file report, I just checked mine and see the same things. I didn't even realize that so I'll check into the missing sounds when I have the chance.
 
Thanks for the report,

I've added the saved game. I am seeing whether I can avoid the crash by changing Renaissance research to Divine Right. Divine Right now shows (1) turns. [Later:] Nope, changing research didn't work. I just got Erik Thorvaldsson as a Founder--that's what got me the war galley. Immediately followed, this time, by a crash.
 
I've added the saved game. I am seeing whether I can avoid the crash by changing Renaissance research to Divine Right. Divine Right now shows (1) turns.

I hit next turn and no crash. Then I accepted the Erik Thorvaldson Father popup and the game crashed. That may have something to do with the Vassal Lord as that FF gives a free unit. What happens when it crashed on you, did you accept that FF?
 
I hit next turn and no crash. Then I accepted the Erik Thorvaldson Father popup and the game crashed. That may have something to do with the Vassal Lord as that FF gives a free unit. What happens when it crashed on you, did you accept that FF?

Yes. That gives me the idea of refusing him. But I wanted the war galley soooo much. :cry:

[Later:] I tried refusing him and the game didn't drop.
[Laterer:] But it dropped later.
[Even later:] By refusing every FF, I was able to finish the game. A very late savefile is attached, the last before victory. The game also failed one time when I tried to shift-move some goods from the Silk Road to my cart. I was trying to buy 25 weapons.
 

Attachments

Yes. That gives me the idea of refusing him. But I wanted the war galley soooo much. :cry:

[Later:] I tried refusing him and the game didn't drop.
[Laterer:] But it dropped later.
[Even later:] By refusing every FF, I was able to finish the game. A very late savefile is attached, the last before victory. The game also failed one time when I tried to shift-move some goods from the Silk Road to my cart. I was trying to buy 25 weapons.

Thanks for bringing this to our attention. The code needs adjusted to prevent Natives from acquiring FFs, that is obvious.
 
Ok, I attached a new DLL that fixes the FF issue.

Also, it will prevent you from shift clicking while in trade screens as this causes a crash.
I am not sure even how to correct that issue as the crash happens outside of our source code. It crashes because the Unit's travel state is Not UNIT_TRAVEL_STATE_IN_EUROPE. I can create a Hack where I temporary change the units travel state to IN_EUROPE and then change it back right after they load the units. Not sure if there is a better solution or not.
 
Back
Top Bottom