v27 and above - Single Player Bug/Crashes report thread

[Stormwind]

I just noticed that in my game with Rev 4651 the turn of 'Winter 572AD' is followed by the turn of 'Fall 572AD'. Isn't winter to be considered the last season of the year? Gamespeed is Eternity and this game was started in June last year.

 

[strategyonly]

Barbarians seem to exhibit that issue, and it may be because the defensive code looks at the civilization as a whole when determining the local garrison it needs to keep close, which is not really a valid concept for barbs, so perhaps it is implicated - I'll take a look and se if I can figure out what is happening in your save

Worker logic hasn't really changed for a number of releases, so no sure what's happening there - again I'll look at your save

Is there anything I need to enable in the assets for that save to work (in regard to the lotr civ etc.)?

Edit - nvm - the save game attached to the post I replied to does not correspond to the images in that post, so no example to look at. If anyone has a game where the barbs are amassing very large stacks and just keeping them at home please post the example, and next time I have some time I'll look at it...

Dang wrong one, try this one, sorry. I had moved since then, dang too many things at one time, my bad!!
SVN 4651, NO viewports.

Forgot to say that I have alot of Barb options included (see pic)

 

[Thunderbrd]

@Koshling: Ok, so I'm analyzing a game that is reported to cause MAF failures. The round went by after a recalc without any issues. However, I did get an assert here after an evaluation from an unspecified player evaluated the Paper Money civic (I doubt that it matters WHAT civic was just evaluated but I figured I'd mention it...)

CvPlayerAI @ line 19888 " FAssertMsg(iPass <= 2, "Civic decision takes too long."); "
Apparently they had to go around the eval 3 times or more? Can this happen if its finding tie values or something along those lines? Is it possible it could on occasion be getting stuck in the eval loop to the point of an overload? I'm a little curious why it can go through the evaluation more than once in the first place...

Anyhow, this is apparently your neck of the woods there but there isn't any direct evidence that this is causing any MAF failures unless it could be more likely to cause such a problem for machines with a little less umph. I believe it was reported by someone with a fairly decent system so I'm not sure if that's a valid possibility that it would do so on his while not on mine.

 

[Dancing Hoskuld]

We're not talking about any kind of 'Great Commander' issue in that right? I have it in mind to reduce the xp they can receive - making sure they always get the ability to decimalize their xp awards and totals so that they can be given less than 1 per battle would help a lot...

So if we're talking more about simply how many xp are being earned by hunters and such since we have so many animals spawning out there, the only real way we should address that would be to adjust the global threshold values for GG emergence. Not sure where those are but any XML modder could find it in the globals and adjust it I think. If its not there then its in the dll and needs to be adjusted there but most modders leading up to where we are have been clever enough to work in some kind of global value that can be tweaked on things like that. I'm not entirely sure what the actual calculation is but it does exponentially require more and more with each GG earned so it could probably help C2C overall to adjust the base value on that... even in the later game they come pretty quickly.

First it is all units when there is a limit on how many experance points they can get from barbarian and animal combat. GlobalDefines.XML variables BARBARIAN_MAX_XP_VALUE and ANIMAL_MAX_XP_VALUE define the maximum that a unit can get from combat unless the game option unlimited XP is on GAMEOPTION_INFINITE_XP.

Second there are two promotions, PROMOTION_BARBARIAN_HUNTER and PROMOTION_ANIMAL_HUNTER, that allow you get XP for your unit past the limit but they should not be giving GG points also. these promotions are not in the game if the infinite XP game option is on.

Currently the python checks on combat result if the looser was (barbarian not animal) and the unit has more XP than the limit and does have the promotion then it changes the XP for the unit. Similarly for animals.

Now the question is - is the code passing the correct variables to the dll? As usual there is no doco so it may be saying add GG points when it shouldn't. the call is

pWinner.changeExperience(1,999,True,False,True)

are any of those true/false values ones that tell the dll to give GG xp?

Looks like we are only giving 1XP but should be giving based on the XP of the unit that lost.

It is not checking for the "Barbarian Generals" option on either; which it should.

 

[Dancing Hoskuld]

I just noticed that in my game with Rev 4651 the turn of 'Winter 572AD' is followed by the turn of 'Fall 572AD'. Isn't winter to be considered the last season of the year? Gamespeed is Eternity and this game was started in June last year.

Winter is only the end of the year in the northern hemisphere. I am more worried that winter is followed by "fall".

 

[ls612]

Winter is only the end of the year in the northern hemisphere. I am more worried that winter is followed by "fall".

That is quite concerning, unless you are flying from America to Australia.

I'll look and see what is going on with the dates, as that is not the only odd thing I've noticed with them.

Edit: That part of the game uses 8 month turns, so going from Winter to Fall is perfectly possible and reasonable.

 

[Thunderbrd]

First it is all units when there is a limit on how many experance points they can get from barbarian and animal combat. GlobalDefines.XML variables BARBARIAN_MAX_XP_VALUE and ANIMAL_MAX_XP_VALUE define the maximum that a unit can get from combat unless the game option unlimited XP is on GAMEOPTION_INFINITE_XP.

Second there are two promotions, PROMOTION_BARBARIAN_HUNTER and PROMOTION_ANIMAL_HUNTER, that allow you get XP for your unit past the limit but they should not be giving GG points also. these promotions are not in the game if the infinite XP game option is on.

Currently the python checks on combat result if the looser was (barbarian not animal) and the unit has more XP than the limit and does have the promotion then it changes the XP for the unit. Similarly for animals.

Now the question is - is the code passing the correct variables to the dll? As usual there is no doco so it may be saying add GG points when it shouldn't. the call is

pWinner.changeExperience(1,999,True,False,True)

are any of those true/false values ones that tell the dll to give GG xp?

Looks like we are only giving 1XP but should be giving based on the XP of the unit that lost.

It is not checking for the "Barbarian Generals" option on either; which it should.

Ok, admittedly the code there is a bit baffling on a first glance through as the naming of functions was not done in a way that makes it terribly clear whether we're talking about experience that counts towards GG pts or experience for just the unit. But from what I can tell by closer inspection, the last parameter there is a bool that enables or disables whether the experience earned can go towards GG pts.

The parameters there on changeExperience are (int iChange, int iMax, bool bFromCombat, bool bInBorders, bool bUpdateGlobal)

So it should be

pWinner.changeExperience(1,999,True,False,False)

EDIT: As for the XP award, its a BASE 1 that is then possibly further evaluated by the odds and tweaked potentially by the Dynamic XP option. That may be fairly appropriate.

And why should it be checking for barbarian generals? The Barbarian Generals option is not about whether you get GG pts for dispatching barbs, but rather about whether barbs can participate in getting Great Generals isn't it? If this option is off, the code does seem to not award GG pts to the barbarian civ.

 

[Thunderbrd]

Winter is only the end of the year in the northern hemisphere. I am more worried that winter is followed by "fall".

Winter is what we're in during January in the Northern Hemisphere so its both the beginning AND the end of the year... doesn't sound too concerning unless there's more going on there.

 

[Dancing Hoskuld]

And why should it be checking for barbarian generals? The Barbarian Generals option is not about whether you get GG pts for dispatching barbs, but rather about whether barbs can participate in getting Great Generals isn't it? If this option is off, the code does seem to not award GG pts to the barbarian civ.

No, it is about getting generals from combat with barbarians. If it is off then combat with wild animals and barbarian units does not count towards Great General points.

 

[ls612]

Winter is what we're in during January in the Northern Hemisphere so its both the beginning AND the end of the year... doesn't sound too concerning unless there's more going on there.

It isn't a problem, the turns at that point are 8 months, and the code shows that the seasons indeed DO progress forward as opposed to backward. So there is no bug there.

 

[Thunderbrd]

Ok. Well... interestingly enough, it appears to achieve both interpretations. All GG pts awards are filtered out for the barbarian civ if the option is not on. Simply put, according to the dll, without the option, there will be no Barbarian Great Generals.

I'm also seeing the evaluation for the unit being awarded xp taking a look at whether its enemy was a barbarian or not with the use of that bUpdateGlobal. However, interestingly enough, this is only doing so correctly according to the game option on melee fights. Not being done right on Interceptions at all... so if you intercept a barbarian air unit (which may be considered impossible at the time of the programming) then you wouldn't get GG pts from it.

Actually, on more review I'm finding the changeExperience call misprogrammed in a few spots. Good call to do a review there!

Yeah, there's some spots where there's issues as to whether units should be or should not be getting xp from fighting a barb under that option. However, along the same lines of thought, the two effects, 'enable Barbs to have GGs' AND 'enable GG pts to accumulate from fighting barbarians' should really be two different options don't you think?

 

[BlueGenie]

Yeah, there's some spots where there's issues as to whether units should be or should not be getting xp from fighting a barb under that option. However, along the same lines of thought, the two effects, 'enable Barbs to have GGs' AND 'enable GG pts to accumulate from fighting barbarians' should really be two different options don't you think?

I don't think so. The option is whether or not Barbs participate in GG accumulation at all, and if they do they should also award GG points on combat. Basically either they are "in" or "out" not halfway "in" or "out".

Cheers

 

[JJOne]

1. In my current game the defenders don't pick the best defender against the attacking unit.
After damaging the unit with cannons, it remains as first defender with practically zero health. And I've had cases with ships listed as best city defenders.
When I'm on the defence it seems to work right and switch the units when damaged?
2. The wonder "Elis Island" doesn't seem to work - native culture (european) is still a building option after having built this wonder.
Version 27.

 

[Vokarya]

2. The wonder "Elis Island" doesn't seem to work - native culture (european) is still a building option after having built this wonder.
Version 27.

It's supposed to give Culture (European) -- the one you get AFTER you build a Native Culture (European) -- in all cities. I wanted it to give all of Culture (African), Culture (American), Culture (Asian), Culture (European), Culture (Middle Eastern), and Culture (Oceanian), but the XML can't give more than one free building per building.

 

[ls612]

It's supposed to give Culture (European) -- the one you get AFTER you build a Native Culture (European) -- in all cities. I wanted it to give all of Culture (African), Culture (American), Culture (Asian), Culture (European), Culture (Middle Eastern), and Culture (Oceanian), but the XML can't give more than one free building per building.

Could you not make the building give multiple free Culture resources (for the Native Cultures)? Then one could build other cultures from other groups and the wonder would function as intended.

 

[Thunderbrd]

It's supposed to give Culture (European) -- the one you get AFTER you build a Native Culture (European) -- in all cities. I wanted it to give all of Culture (African), Culture (American), Culture (Asian), Culture (European), Culture (Middle Eastern), and Culture (Oceanian), but the XML can't give more than one free building per building.

This must be why I have multiple free building enabled tag on my todo list...

 

[Thunderbrd]

@DH, Not sure what these would necessarily be written as in Python but some further research in the DLL suggests that those parameters on changeExperience should read something along the lines of:

pWinner.changeExperience(1,-1,True,False, (Opponent is Not Barbarian OR GC.getGameINLINE().isOption(GAMEOPTION_BARBARIAN_GENERALS)))

 

[Thunderbrd]

CTD, i believe it has something to do with a quantrie effect?? Meaning the AI has to decide whether to take over the city (which it HASN'T in the last 12 turns, it did NOT even attempt to take over the city) WHY??). Or decide to attack the units beside it??

If not then its something all together different.


SVN 4638, NO viewports enabled ALL of DH's folders in the MLF area. btw this is a repeatable CTD.

Unless I get all of DH's folders uploaded into my mod I won't have much of an answer for this one as it won't load without them and the minidump kinda indicated that it may not have been a problem IN the dll itself but perhaps python or something in the exe file (which is often a graphics reference...)

Since I have such a slow internet, I may not be able to get all those modmods in place in time enough to be much help here.

I only caught it for a second but at the top it said there was some error that said something like "barbarian event error". Then I had a CTD. Here is the mini dump.

My version was SVN v4643.

This one was actually quite helpful. Indicated that the reference call I was using to display the leader's name in the message text when a leader selects a trait was a setup for trouble. How it works sometimes and not other times I don't know... but I was able to easily change to an alternative method that I have every reason to believe should get past this crash scenario every time. AKA: Thanks for the report. This one's fixed!

 

[Yudishtira]

It isn't a problem, the turns at that point are 8 months, and the code shows that the seasons indeed DO progress forward as opposed to backward. So there is no bug there.

Season names only work for three-month (or six-month) turns (imho). Please consider just using the month names instead.

Consider this. Assuming you're using a northern hemisphere calendar year (ie. not a December to November year), winter is the first two and last month of the year. So winter is both before and after every other season in every year. If you had ten- or eleven-month turns, you could have two that were winter of the same year - Winter 2013 (Feb) followed by Winter 2013 (Dec).

 

[Hydromancerx]

This one was actually quite helpful. Indicated that the reference call I was using to display the leader's name in the message text when a leader selects a trait was a setup for trouble. How it works sometimes and not other times I don't know... but I was able to easily change to an alternative method that I have every reason to believe should get past this crash scenario every time. AKA: Thanks for the report. This one's fixed!

Yay! I was wondering if all my mini-dumps were fixing anything.