Bug Reports and Discussion

[Legendary]

were you playing more naval ai or extramodmod?

I was playing more naval ai

 

[[to_xp]Gekko]

oh ok, I was asking because I had that issue in master of mana so might have been caused by the wilderness system which emm shares. is the problem reproducible or just a one time thing?

 

[Legendary]

oh ok, I was asking because I had that issue in master of mana so might have been caused by the wilderness system which emm shares. is the problem reproducible or just a one time thing?

Well I only tried it with the same map script (big and small) and there it was reproducible.

 

[Tholal]

I've got a saved game for the 3 pieces of Barnaxus turn 231 instead of the save I posted which is about turn 330. I don't know if that's too early?

I'll have to add in some logging to track down this issue. I saw the AI in one game recently who had 3 versions of Barnaxus alive!

I get a crash to desktop whenever I try starting a game in 2.53. I've tried reinstalling the patch/clean install several times with the same results. Oddly enough, I have actually got a current game going on which I somehow managed to start fine, but as that was several weeks ago, I don't know how I managed it.

Dont know what to tell you regarding this. Have you tried using the Play Now option to make sure the options are reset?

currently when a HN unit "defeats" an item ( like Orthus' axe ) the item is destroyed. could the code check for HN units defeating and item unit and give it the appropriate item promotion when it happens?

I'll add something about this to the feature requests. It's a little more complicated than just giving the promotion to the unit (what if the unit already picked up an item this turn? What if the unit can't have the promotion?)

When an HN ship performing a trade blockade is defeated, the blockade can become permanent and unremovable. I have 3 of them in my current game. At least one of them was caused by some kind of sea tortoise animal unit. Another was an HN pirate ship that got revealed and the blockade remained afterwards. I could not find a way to remove the blockades in world builder

Hmmm... I thought I had fixed this issue a while back. I'll double check on it.

Is there any fix in sight for the issue where Orthus and the Infernals always spawn as close as possible to the bottom left corner of the map when using custom maps instead of mapscripts?

No idea what would cause this. Orthus and Infernal spawns are handled in python and dont make any changes based on map type. What map are you using where this happens?

Hi.
After a long absence from playing ffh, i reinstalled it today. When playing around with it i noticed that when the barbarian world option is enabled, all barbarian cities at the start are on one landmass (relatively close together). Since i never encountered this issue before, this seems to be new and feels like a bug (?). I used the "big and small map script.

I haven't knowingly made any changes to how barbarian cities are placed when the Barbarian World option is on. I'll take a look and see if anything stands out in that code.

 

[Qgqqqqq]

Yeah, I have.

 

[lfgr]

I think in revision 1417 you accidently disabled improvements that don't spawn units (dungeons, towers, graveyards) from spawning themselves.

 

[Tholal]

I think in revision 1417 you accidently disabled improvements that don't spawn units (dungeons, towers, graveyards) from spawning themselves.

Looks like you are right. First bugfix for version 2.61!

New code that hasnt been tested yet.

for (int iJ = 0; iJ < GC.getNumImprovementInfos(); iJ++)
                    {
						if (pPlot->canHaveImprovement((ImprovementTypes)iJ, NO_TEAM))
						{
							int iImprovementChance = GC.getGameINLINE().getSorenRandNum(10000, "Spawn Improvement");
							if (iImprovementChance < GC.getImprovementInfo((ImprovementTypes)iJ).getAppearanceProbability())
							{
								if (GC.getImprovementInfo((ImprovementTypes)iJ).getSpawnUnitType() != NO_UNIT)
								{
									if (pPlot->isVisibleToCivTeam())
									{
										continue;
									}
								}
								pPlot->setImprovementType((ImprovementTypes)iJ);
								pPlot->setFeatureType(NO_FEATURE);
							}
                        }
                    }

 

[MagisterCultuum]

In the new Blizzards.py there are a couple places where it says pPlot.getOwner() == iIllians where I'm pretty sure it should say gc.getPlayer(pPlot.getOwner()).getCivilizationType() == iIllians

The way it is written it would not effect the Illian civilizations, but rather whatever player happens to have an index the same as the index of the civilization type.


By the way, wouldn't it be better for the new Blizzard code to take advantage of the temporary feature feature, rather than eliminating forests etc forever?

 

[Tholal]

In the new Blizzards.py there are a couple places where it says pPlot.getOwner() == iIllians where I'm pretty sure it should say gc.getPlayer(pPlot.getOwner()).getCivilizationType() == iIllians

iIllians is defined at the top of the functions

iIllians = gc.getInfoTypeForString('CIVILIZATION_ILLIANS')

By the way, wouldn't it be better for the new Blizzard code to take advantage of the temporary feature feature, rather than eliminating forests etc forever?

Blizzards wont move onto terrain that already has a feature. In the canBlizzard function it has the following check.

			if pPlot.getFeatureType() != -1:
				return False

I thought about adding in some temporary feature replacement but it gets a little messy since Blizzards are also features and I didn't want to travel too far down the rabbit hole with this feature before the 2.6 release.

 

[MagisterCultuum]

iIllians is defined at the top of the functions

iIllians = gc.getInfoTypeForString('CIVILIZATION_ILLIANS')

I know, but that does not change the fact that pPlot.getOwner() returns the index of the player (where the first player is 0, the second 1, etc, down to the barbarian state being 50) rather than the type of civilization.

The Illian Civ is the 11th listed in CIV4CivilizationInfos.xml in my modmod (it may be different in yours, as I think I may have reordered it), so iIllians = gc.getInfoTypeForString('CIVILIZATION_ILLIANS') is equivalent to iIllians = 10. That means that the 11th player in the game would be treated as Illian even if that was the only civilization in the game that was not of the Illian civilization type. The other players who are Illians would not be treated as such.


You could use iIllians = cf.getCivilization(gc.getInfoTypeForString('CIVILIZATION_ILLIANS')) instead of iIllians = gc.getInfoTypeForString('CIVILIZATION_ILLIANS') if you prefer, but that would only work in games with only one Illian Civ. If you wanted to make it work only for Auric, you could use iIllians = cf.getLeader(gc.getInfoTypeForString('LEADER_AURIC'))

Blizzards wont move onto terrain that already has a feature. In the canBlizzard function it has the following check.

			if pPlot.getFeatureType() != -1:
				return False

I thought about adding in some temporary feature replacement but it gets a little messy since Blizzards are also features and I didn't want to travel too far down the rabbit hole with this feature before the 2.6 release.

I was actually thinking more about def spellCallBlizzard(caster): that about Blizzard.py, as that spell could replace pretty much any feature except Ancient Forests with a Blizzard. It would probably be better if the previous feature would be restored once the blizzard is called to an adjacent tile, or moves away through he new Blizzard.py code.

 

[Tholal]

I know, but that does not change the fact that pPlot.getOwner() returns the index of the player (where the first player is 0, the second 1, etc, down to the barbarian state being 50) rather than the type of civilization.

I see. Interesting. I guess that I will have to do something along these lines instead.

pPlayer = gc.getPlayer(pPlot.getOwner())
if pPlayer.getCivilizationType() == iIllians

I was actually thinking more about def spellCallBlizzard(caster): that about Blizzard.py, as that spell could replace pretty much any feature except Ancient Forests with a Blizzard. It would probably be better if the previous feature would be restored once the blizzard is called to an adjacent tile, or moves away through he new Blizzard.py code.

Good point. I forgot about that spell. The feature replacement is original code. I'll add a note to look into updating this so that the feature removal is only temporary instead.

 

[MagisterCultuum]

edit: I'm not sure how I ended up making this a double post.

Anyway, you should remember that pPlot.getOwner() returns -1 if the plot is unowned, and that trying to evaluate gc.getPlayer(-1) causes a serious error. You can avoid that my checking pPlot.isOwned() first (which is slightly more efficient than checking if pPlot.getOwner() != -1:, as you do in line 146 just before the one place where you correctly check for the civ type instead of player index).

 

[lfgr]

There's a bug in CIV4GameText_FFH2.xml:

<TEXT>
	<Tag>TXT_KEY_TECH_ENABLES</Tag>
	<English>[COLOR_HIGHLIGHT_TEXT]Enables [LINK=literal]%s1_Name[\LINK][COLOR_REVERT]</English>
	<French>[PLAYERCOLOR_LIGHT_GREEN]Enables [LINK=literal]%s1_Name[\LINK][COLOR_REVERT]</French>
	<German>[PLAYERCOLOR_LIGHT_GREEN]Enables [LINK=literal]%s1_Name[\LINK][COLOR_REVERT]</German>
	<Italian>[PLAYERCOLOR_LIGHT_GREEN]Enables [LINK=literal]%s1_Name[\LINK][COLOR_REVERT]</Italian>
	<Spanish>[PLAYERCOLOR_LIGHT_GREEN]Enables [LINK=literal]%s1_Name[\LINK][COLOR_REVERT]</Spanish>
</TEXT>

This should probably be the same in all languages ([PLAYERCOLOR_...] doesn't work).

 

[Terkhen]

While working on ExtraModMod, I just noticed something weird happening in CvPlayer::calculateResearchModifier. This could be a major bug, or I could just have missed something.

On line 9260 of the More Naval AI CvPlayer.cpp file, we can see the following code (which is untouched from vanilla BtS).

	int iPossiblePaths = 0;
	int iUnknownPaths = 0;

	for (int iI = 0; iI < GC.getNUM_OR_TECH_PREREQS(); iI++)
	{
		if (GC.getTechInfo(eTech).getPrereqOrTechs(iI) != NO_TECH)
		{
			if (!(GET_TEAM(getTeam()).isHasTech((TechTypes)(GC.getTechInfo(eTech).getPrereqOrTechs(iI)))))
			{
				iUnknownPaths++;
			}

			iPossiblePaths++;
		}
	}

	FAssertMsg(iPossiblePaths >= iUnknownPaths, "The number of possible paths is expected to match or exceed the number of unknown ones");

	iModifier += (iPossiblePaths - iUnknownPaths) * GC.getDefineINT("TECH_COST_KNOWN_PREREQ_MODIFIER");

This code loops through all technologies, finds all researched OrPreReqs and unknown OrPreReqs for the technology currently being researched. Using those two values, it computes the research % increase caused by knowing multiple paths to the same technology. The weird bit is that the bonus is being granted even when you only know only one path to the current technology, and therefore all technologies with OrPreReqs are being researched faster than others just because of this.

The even weirder bit is that if a technology has a single OrPreReqs, it is getting a hidden 20% research bonus for free. There are a lot of technologies in FFH2 that are defined this way.

As a result of this small mess, we have a hidden bonus to research which is not being shown anywhere. If this is confirmed, I'm not sure about what should be done about this.

 

[RedJacK]

Hi there,

We started to play FFH2 with friends again and because we knew that FFH2 still gives OOS errors we thought that extramodmod would erase these. We were wrong. @ 200-300 turn mark they started coming again. Anyone has any solution?

Civ IV + BTS + FFH2 + o-Patch + newest extramodmod is our current "build"

 

[Terkhen]

Hi there,

We started to play FFH2 with friends again and because we knew that FFH2 still gives OOS errors we thought that extramodmod would erase these. We were wrong. @ 200-300 turn mark they started coming again. Anyone has any solution?

Civ IV + BTS + FFH2 + o-Patch + newest extramodmod is our current "build"

Please use the ExtraModMod thread for bug reports about it ( http://forums.civfanatics.com/showthread.php?t=486227), as this one is for More Naval AI. I will answer you in the ExtraModMod thread soon.

 

[Tholal]

There's a bug in CIV4GameText_FFH2.xml:

This should probably be the same in all languages ([PLAYERCOLOR_...] doesn't work).

Fixed. Thanks!

While working on ExtraModMod, I just noticed something weird happening in CvPlayer::calculateResearchModifier. This could be a major bug, or I could just have missed something.
...
As a result of this small mess, we have a hidden bonus to research which is not being shown anywhere. If this is confirmed, I'm not sure about what should be done about this.

Pretty sure that is by design. Here's a post from 2006 explaining how tech research works and it mentions the x1.2 modifier for single prereqs - http://www.civfanatics.com/civ4/strategy/tech_research.php

 

[Terkhen]

Tholal: That article seems like an unoficial explanation about how research works, but it does not mean that in vanilla Civilization it worked that way by design. It could have been an overlook in the original code, as it seems far too strange to include by design differences in research rates between technologies that are identical from the point of view of the player.

For example in FFH2 and MNAI, Corruption of the Spirit requires Way of the Wicked and Knowledge of the Ether (both tagged as AndPrereqs), while Engineering requires Mathematics and Construction (Mathematics is an OrPrereq and Construction an AndPrereq). Engineering will enjoy a 20% increase in research, while Corruption of the Spirit will not (also note that Corruption of the Spirit does not behave as the article mentions, as it has at least one prerrequisite and it is not getting the bonus). All technologies with a single requirement use OrPrereq in FFH, so at least all of them are getting the bonus... but even if it is something known in the article, it still feels weird to me that the early technologies with no prerequisites do not get the same bonus.

On the other hand, I understand that fixing these inconsistencies may be considered to be out of More Naval AI's scope, because if the obvious fix is applied (apply the 20% bonus for each OrPrereq researched beyond the first one), then all technologies would need to have their costs changed in order to maintain the same "real" research rate, and that would both look ugly and imply modifying vanilla FFH data. If you are still interested, I could come up with a proposal.

 

[Bad Player]

In my (very slowly being created) scenario I've noticed that the AI sometimes leaves a city undefended at the start of the game (and since the scenario starts with civs at war, an enemy scout attacks an empty city and destroys the entire civ).

Another thing I noticed is that (the Bannor in this particular case) moves their settler ahead of their warrior at the start of the game to make a city and the undefended city is attacked before the warrior arrives (again the issue of starting at war). I'm not sure if the AI needs changing or not since it won't occur normally I guess.

 

[Folket]

Have you tried to add an extra archer to the city and give it the city defence AI script?

As for the settler see what AI script the AI usually use to escort settlers and give try it. Also use a unit with the same amount of moves as the settler. i.e. Perhaps an archer with mobility promotion.