Bug Reports and Discussion

Sezren · Nov 8, 2015

Sezren said:
void CvUnit::changeHiddenNationality(int iNewValue)
{
if (iNewValue != 0)
{
if (m_iHiddenNationality + iNewValue == 0)
{
updatePlunder(-1, false);
setBlockading(false);
m_iHiddenNationality += iNewValue;
if (getGroup()->getNumUnits() > 1)
{
joinGroup(NULL, true);
}
updatePlunder(1, false);
}
else
{
m_iHiddenNationality += iNewValue;
}
}
}

Far as I understand the source code this function alone is bugged and the following lines should be removed:
updatePlunder(-1, false);
updatePlunder(1, false);
Even with removal of the hack (in CvPlot::changeBlockadedCount) these lines do not cancel each other because the removal of HN will change which teams are considered enemies.
Furthermore I do not see any purpose for these lines.

Edit: I have not looked into the "joinGroup" part - so this may somehow add some complexity to the problem.

Tholal · Nov 9, 2015

MagisterCultuum said:
I have again come across the issue of an HN unit being able to capture rival cities while not at war.

OK. Written up.

Sezren said:
1) Truffles event can happen on/for peaks - at least on erebus.py map

Have also written up this issue.

3) There appears to be strange code (probably bug) in the code for starting the Infernals:
"if pPlot.isAdjacentOwned():" inside some loop is probably meant to be "if pCityPlot.isAdjacentOwned():"

Good catch! Thanks!

4) The algorithm for reqRiverOfBlood() which determines if the AI should cast it or not does not work properly on Deity with 2 settlers. Only if Calabim loose one of them or fail to build with the second one (both can happen but usually it does not) will they cast it early when it probably is most powerful. Optimally they should also wait a bit longer and be somewhat unpredictable about casting it.

There needs to be some logic that results in the AI arriving at that conclusion. I am more than happy to accept these sort of suggestions on AI spell usage, but I need the logic to go with it.

BTW: Is there any point reporting bugs still? The bug database linked in the first post is very long already and contains many very old bugs.

Yes. I am still in the process of moving things over to Bitbucket (https://bitbucket.org/Tholal/more-naval-ai)

Flugan said:
New to the forums, but a long time player. Thank you very much for all your work on FFH2 and MNAI. Loads of fun.

Forgive me if this has been covered but I can't get the 'Barbarian World" option to work correctly.

Also sometimes blockades get stuck in place, but I can solve that issue in worldbuilder if need be.

Welcome and glad to hear that you're enjoying the mod! Never heard of any issue with Barbarian World. Whats is happening? No Barbarian cities? Blockade issues are known.

Sezren said:
Regarding the bug with Hyborem naval blockade. It has nothing to do with killing the unit. The behaviour is quite simple: When Hyborem appears and a barbarian ship is doing a blockade then a Hyborem-blockade will be permanently added to the blockaded tiles. Obviously it has to do with Hyborem having the barbarian trait.

Interesting. I'll write that up today.

Sezren said:
Far as I understand the source code this function alone is bugged and the following lines should be removed:
updatePlunder(-1, false);
updatePlunder(1, false);
Even with removal of the hack (in CvPlot::changeBlockadedCount) these lines do not cancel each other because the removal of HN will change which teams are considered enemies.
Furthermore I do not see any purpose for these lines.

Edit: I have not looked into the "joinGroup" part - so this may somehow add some complexity to the problem.

I've tried a few times to fix this blockade issue without any luck. I think that double call to updatePlunder was something that either I or someone else added to try and fix the issue a long time ago. The joinGroup call is just telling the unit to ungroup (so that we dont end up with a group of mixed HN and non-HN units).

Tholal · Nov 9, 2015

I did find some issues with the Barbarian World option. Will make some tweaks to that code.

Flugan · Nov 9, 2015

Tholal said:
I did find some issues with the Barbarian World option. Will make some tweaks to that code.

Usually there are no Barbarian cities spawned. I tested it some more, and every once in a while the cities would show up, but it was rare and seemingly random. Most games didn't have any cities spawned at all.

I used global highlands as the map, but tried others as well with the same results. Often when the cities did appear they were clustered very close together, which I thought was actually pretty cool, but didn't think was intended.

On a side note, after I reinstalled everything, even the base civ4 and bts games, my custom game preferences for FFH2 won't save. I understand this is an installation issue rather than a bug, but any ideas would be welcome.

Thanks again.

Sezren · Nov 9, 2015

Tholal said:
There needs to be some logic that results in the AI arriving at that conclusion. I am more than happy to accept these sort of suggestions on AI spell usage, but I need the logic to go with it.

Ok. Maybe I will come up with a function.

Tholal said:
I've tried a few times to fix this blockade issue without any luck.

With "this" you mean this just described easy-to-demonstrate/reproduce bug (almost every use of "declare nationality" produces permanent blockades)? I really dont see how this could not be fixed by removing those 2 lines... It may not fix all blockade problems but the HN-declare one should be gone. Those 2 lines just dont make any sense as I tried to explain. And the rest of the code (in that function) looks correct to me.

Edit: I hope the source code I am using fits with yours...

Tholal said:
The joinGroup call is just telling the unit to ungroup (so that we dont end up with a group of mixed HN and non-HN units).

Ok.

Sezren · Nov 10, 2015

Sezren said:
Ok. Maybe I will come up with a function.

Was more difficult than I expected. Tested a lot. Appears to be doing pretty much what I wanted it to do:

Code:

def reqRiverOfBlood(caster):
	pPlayer = gc.getPlayer(caster.getOwner())
	num_cities = pPlayer.getNumCities()
	if num_cities == 0:
		return False
	if pPlayer.isHuman() == False:		
		# the idea here is to a) cast it when it makes sense to do so and b) to be properly unpredictable about it
		sum_benefit_x100 = 0
		max_pop = 0
		zturn = gc.getGame().getGameTurn() * 100 // gc.getGameSpeedInfo(CyGame().getGameSpeedType()).getVictoryDelayPercent()
		zturn_mod = zturn
		for pyCity in PyPlayer(caster.getOwner()).getCityList() :
			pCity = pyCity.GetCy()
			this_pop = pCity.getPopulation()
			if this_pop > max_pop:
				max_pop = this_pop
			happies = pCity.happyLevel() - pCity.unhappyLevel(0)
			sum_benefit_x100 = sum_benefit_x100 + min(max(happies * 100, 0), 250)
			zturn_mod = zturn_mod + pCity.getY() * 19 + pCity.getX()
		avg_benefit_x100 = sum_benefit_x100 // num_cities
		quality = min(350, max_pop * 100) + avg_benefit_x100 + max(75, num_cities * 50) + max(zturn, 50) + (zturn_mod % 151) * 4
#		print "q = %(grr)d, max_pop = %(aa)d, avg_benefit_x100 = %(bb)d, num_cities = %(cc)d, zturn = %(dd)d, zturn_mod = %(gg)d _ %(hh)d" % {"grr":quality,"aa":max_pop,"bb":avg_benefit_x100,"cc":num_cities,"dd":zturn,"gg":zturn_mod,"hh":zturn_mod % 151}
		if quality < 500 + 650 + 25:
			return False
#		print "q = %(grr)d CAST_RIVER_OF_BLOOD_NOW at turn %(trn)d" % {"grr":quality,"trn":gc.getGame().getGameTurn()}
	return True

Tholal · Nov 10, 2015

Sezren said:
With "this" you mean this just described easy-to-demonstrate/reproduce bug (almost every use of "declare nationality" produces permanent blockades)? I really dont see how this could not be fixed by removing those 2 lines... It may not fix all blockade problems but the HN-declare one should be gone. Those 2 lines just dont make any sense as I tried to explain. And the rest of the code (in that function) looks correct to me.

I'm not seeing that behavior. A HN ship that declares nationality is having its blockade successfully removed (except against Barbarians, which I just noticed). I think that spells that cause HN to be removed are not behaving the same as the unit casting the Declare Nationality spell. And killing a ship under HN also doesnt remove the blockades.

As far as that code you mention, it does indeed look strange. I'll take a look at it.

Edit: Preliminary tests show that those two extra calls to updatePlunder() may indeed have been the source of all the blockade woes. Will do some more testing. Thanks!

Sezren · Nov 10, 2015

Tholal said:
I'm not seeing that behavior. A HN ship that declares nationality is having its blockade successfully removed (except against Barbarians, which I just noticed).

I have read your edit but in case I/it am/is still unclear: You write "is having its blockade ...". But:
a) it is not necessary that the ship is doing a blockade; a ship not doing a blockade and casting "declare nationality" will also cause the bug
b) the bug has several effects; the worst is the construction of the permanent blockades; they go against all teams which the ships owner is at war with; so if you say "only against barbarian" it just means the ships owner (probably you?) was not involved in other wars; just try declare war first to another civ and then cast "declare nationality"

Tholal said:
I think that spells that cause HN to be removed are not behaving the same as the unit casting the Declare Nationality spell.

I didnt find any other way in the source to change the HN status than through the one function.

Tholal said:
And killing a ship under HN also doesnt remove the blockades.

Just tested this and all blockades were removed. I do not think this situation calls the questionable code part. Or do you mean something other than "a HN ship does a blockade and gets killed while doing that"?

Tholal said:
Edit: Preliminary tests show that those two extra calls to updatePlunder() may indeed have been the source of all the blockade woes. Will do some more testing. Thanks!

Ok good. I dont think it will fix the Hyborem appearance problem though...

Sezren · Nov 11, 2015

If I cause the AC to go to 100 then I get hit by the apocalypse twice. Other players get hit only once. The event message comes up only once I think but city populations are halved twice (and probably unit deaths too but due to RNG not so easy to be sure).

If the AC goes to 100 due to some other civilization I only get hit once. I do not know if the civilization causing it gets hit twice then.

I do not know if other Armageddon events (Enraged, Blight, ...) are also affected.

I messed around with some game files but I do not think this is causing it (though I cannot exclude the possibility). Also used world builder to go to ~99 AC and then spread AV in a city to go to 100 (so to exclude this being a world builder problem).

This was on game speed 'Quick' if it matters.

ciruela · Nov 11, 2015

MNAI2.6.3 work well with my scenario Game of Thrones V7.5a
but for Game of Thrones S1 to S6 which well with vanilla,With MNAI When play Scenario and after start loading,Game finished and said you lose game.

S1,S2,S5 shows as pic 1,blank Tech Advicer and then lose game

Spoiler :

S3,S4 said error in GameStart event Handle and lose game

Spoiler :

Tholal · Nov 11, 2015

ciruela said:
MNAI2.6.3 work well with my scenario Game of Thrones V7.5a
but for Game of Thrones S1 to S6 which well with vanilla,With MNAI When play Scenario and after start loading,Game finished and said you lose game

You are trying to set techs for Team 6 which is set to None as a Civtype.

Sezren · Nov 11, 2015

Minor bug in: def doArmageddonApocalypse(argsList):

if (CyGame().getSorenRandNum(100, "Apocalypse") <= iPercent):

should be:

if (CyGame().getSorenRandNum(100, "Apocalypse") < iPercent):

ciruela · Nov 12, 2015

Tholal said:
You are trying to set techs for Team 6 which is set to None as a Civtype.

Thanks for locating my scenario problem!

Sezren · Nov 12, 2015

Not a bug. Just a bug finding related suggestion - unfortunately a bit late in the life cycle of the project: Put an assert(iNum must be in [0..65535]) into this function. It is used in many places and does not appear to catch bad inputs. Problem is that m_sorenRand.get() only takes unsigned short for iNum. One of the effects is that certain XML values cannot be changed arbitrarily without causing behind-the-scenes screwups.
Example: Changing <iDiscoverRand>10000</iDiscoverRand> to <iDiscoverRand>21850</iDiscoverRand> and playing Marathon (with 3x research) will break it really bad - every mine gets the bonus in a few turns.

int CvGame::getSorenRandNum(int iNum, const char* pszLog)
{
return m_sorenRand.get(iNum, pszLog);
}

Sezren · Nov 16, 2015

There appears to be something buggy with defensive strikes. Maybe it requires 'Blitz' promotion as well. I have been unable to properly pin it down. However I found one setup which appears to cause easily reproducible strong misbehaviour:

0. Play Ljosalfar. Use world builder for the following:
1. Have several Galleon transport ships.
2. Move many (10+) flurry units onto the ship stack.
3. Create a stack of 2 barbarian triremes right next to the ship stack.
4. Press next turn.

The barbarians will attack. There will be many (like 10) defensive strikes against them - or maybe only against the first attacking ship - at least this is the print sequence. I think once I got even more than the number of flurries on the ships.
It does however not seem to happen with only one ship attacking.

[to_xp]Gekko · Nov 17, 2015

blitz allows infinite defensive strikes, it's likely an oversight but Tholal considers it a feature since blitz promotion is pretty hard to get anyway

Sezren · Nov 17, 2015

[to_xp]Gekko;14058907 said:
blitz allows infinite defensive strikes, it's likely an oversight but Tholal considers it a feature since blitz promotion is pretty hard to get anyway

I know. Please read my bug report more carefully. Blitz is not supposed to allow for >1 defensive strikes vs 1 attack. It usually does not. Just in some bugged cases. The one I described I managed to reproduce so I posted it here.

Tholal · Nov 20, 2015

Sezren said:
If I cause the AC to go to 100 then I get hit by the apocalypse twice.

Good catch! Though I have no idea why its happening. I'll write it up

Sezren said:
Minor bug in: def doArmageddonApocalypse(argsList):

Thanks. I'll fix it.

Sezren said:
Not a bug. Just a bug finding related suggestion - unfortunately a bit late in the life cycle of the project: Put an assert(iNum must be in [0..65535]) into this function. It is used in many places and does not appear to catch bad inputs. Problem is that m_sorenRand.get() only takes unsigned short for iNum. One of the effects is that certain XML values cannot be changed arbitrarily without causing behind-the-scenes screwups.

OK. I can do that,

Sezren said:
Blitz is not supposed to allow for >1 defensive strikes vs 1 attack.

Correct. I wrote up this issue today - https://bitbucket.org/Tholal/more-naval-ai/issues/64/units-with-blitz-and-drill-can-get-too

Sezren · Nov 22, 2015

Tholal said:
Correct. I wrote up this issue today - https://bitbucket.org/Tholal/more-naval-ai/issues/64/units-with-blitz-and-drill-can-get-too

Tholal said:
Based on this report from the forums, though so far, I am unable to replicate.

Appears to happen every time for me. There is clearly something wrong with the messages or at least the message order is not "sequential": The trireme which survived cannot possibly have that much health left after being hit by all the defensive strikes. See attached screenshot.

Tholal · Nov 26, 2015

Sezren said:
Appears to happen every time for me.

I am still unable to replicate. I tried several variations including your exact scenario (2 galleons, 10 flurries, 2 barbarian triremes) and never saw multiple defensive strikes on one target.

If you can provide a savegame (ver 2.7 please) with a repeatable occurrence of this issue I can try to debug it.

Bug Reports and Discussion

Chieftain

Emperor

Emperor

Chieftain

Chieftain

Chieftain

Emperor

Chieftain

Chieftain

Warlord

Attachments

Emperor

Chieftain

Warlord

Chieftain

Chieftain

QCT junkie

Chieftain

Emperor

Chieftain

Attachments

Emperor

Similar threads