FfH2 0.15 Bugs

Another question on the 'insanity effect' of Perpentach...

I noticed the randomness of the changes as being, well, insane. No change for 100s of turns (using Marathon) setting or changes after just a few turns.

However, also, one change which I think really penalizes the player is a change from three traits to only two. If this lasts for a few hundred turns it is a nasty turn of events.

Again, I guess you could call it all 'insane,' but to balance this out, how about giving Perpentach FOUR traits once in awhile too?:)
 
Repeating my question of animal escapes...

Are the odds calculated for a particular city or a civ?

I had three escapes in three different cities over the course of about 75 turns.

Also, please consider not allowing the escaped animals to attack immediately. Otherwise, you might just as well say they died in captivity because animals with two moves (panther, wolf, tiger) just turn around and attack the city defender(s) and that's it.

Give us a chance to re-capture them. No problem with one-move animals.

Thanks.
 
Sarisin said:
I noticed the randomness of the changes as being, well, insane. No change for 100s of turns (using Marathon) setting or changes after just a few turns.
There's 1% chance every turn that Perpentach's traits will change. Thus, while the changes tend to happen at an average of 80-100 turns, that's not guaranted. It's possible that his traits will never change, or even changing between two turns.

Sarisin said:
However, also, one change which I think really penalizes the player is a change from three traits to only two. If this lasts for a few hundred turns it is a nasty turn of events.
Do you mean that only two traits changed, or that you got only two traits at total? In the second case, that's a bug.

Sarisin said:
Again, I guess you could call it all 'insane,' but to balance this out, how about giving Perpentach FOUR traits once in awhile too?:)
It is balanced; he has three traits, while most leader have only two. But it might be fun if Pepentanch randomly got two, three or four traits, instead of the standard three.
 
I think what's happening with Perpentach getting two traits is that he's selecting the same trait twice. It can be done with adaptive, too. I'd suggest making the same trait not selectable twice (for Insane trait, at least).
 
Barbarians in Deity Raging Barbs games are showing up much delayed in our MP games if we don't have any AIs, and sometimes even if we have only a few AIs.

A normal game the barbs show up around year 7, but in the bugged instances they aren't showing up until year 100 (on Quick/Ancient settings)
 
sureshot,
I believe that barbarian spawning is scripted to average number of citys/county
So if you human didn't build any extra citys early on, the barbs will not spawn.
 
Chandrasekhar said:
I think what's happening with Perpentach getting two traits is that he's selecting the same trait twice. It can be done with adaptive, too. I'd suggest making the same trait not selectable twice (for Insane trait, at least).

I wrote the code so that the same trait can't be selected twice (unless my logic is wrong):

Code:
	def FFHInsane(self, iPlayer):
		pPlayer = gc.getPlayer(iPlayer)
		for i in range(gc.getNumTraitInfos()):
			if (pPlayer.hasTrait(i) and i != gc.getInfoTypeForString('TRAIT_INSANE')):
				CyMessageControl().sendApplyEvent(5012, EventContextTypes.EVENTCONTEXT_ALL, (iPlayer,i,False))
		Traits = [ 'TRAIT_AGGRESSIVE','TRAIT_ARCANE','TRAIT_CREATIVE','TRAIT_DEFENDER','TRAIT_EXPANSIVE','TRAIT_FINANCIAL','TRAIT_INDUSTRIOUS','TRAIT_ORGANIZED','TRAIT_MAGIC_RESISTANT','TRAIT_PHILOSOPHICAL','TRAIT_RAIDERS','TRAIT_SPIRITUAL' ]
		iRnd1 = CyGame().getSorenRandNum(len(Traits), "Insane")
		iRnd2 = CyGame().getSorenRandNum(len(Traits) - 1, "Insane")
		if iRnd2 >= iRnd1:
			iRnd2 = iRnd2 + 1
		iRnd3 = CyGame().getSorenRandNum(len(Traits) - 2, "Insane")
		if iRnd3 >= iRnd1:
			iRnd3 = iRnd3 + 1
		if iRnd3 >= iRnd2:
			iRnd3 = iRnd3 + 1
		CyMessageControl().sendApplyEvent(5012, EventContextTypes.EVENTCONTEXT_ALL, (iPlayer,gc.getInfoTypeForString(Traits[iRnd1]),True))
		CyMessageControl().sendApplyEvent(5012, EventContextTypes.EVENTCONTEXT_ALL, (iPlayer,gc.getInfoTypeForString(Traits[iRnd2]),True))
		CyMessageControl().sendApplyEvent(5012, EventContextTypes.EVENTCONTEXT_ALL, (iPlayer,gc.getInfoTypeForString(Traits[iRnd3]),True))
		if pPlayer.isHuman() and gc.getGame().getGameTurnYear() >= 5:
			popup = PyPopup.PyPopup(-1)
			popup.addDDS('art/interface/popups/Perpentach.dds', 0, 0, 128, 384)
			popup.addSeparator()
			popup.setHeaderString(CyTranslator().getText("TXT_KEY_POPUP_INSANE_HEADER",()))
			popup.setBodyString(CyTranslator().getText("TXT_KEY_POPUP_INSANE",()))
			popup.launch(true, PopupStates.POPUPSTATE_QUEUED)
 
AlazkanAssassin said:
sureshot,
I believe that barbarian spawning is scripted to average number of citys/county
So if you human didn't build any extra citys early on, the barbs will not spawn.

Good call. The follwoing is the logic used to determine if the game should start spawning barbarians:

Code:
	if (GC.getEraInfo(getCurrentEra()).isNoBarbUnits())
	{
		bAnimals = true;
	}

	if (getNumCivCities() < ((countCivPlayersAlive() * 3) / 2))
	{
		bAnimals = true;
	}

	if (getElapsedGameTurns() < ((GC.getHandicapInfo(getHandicapType()).getBarbarianCreationTurnsElapsed() * GC.getGameSpeedInfo(getGameSpeedType()).getBarbPercent()) / 100))
	{
		bAnimals = true;
	}

The first check is always false because all eras are barbarian eras in FfH.

The second check is the most important, basically if there are more than 1.5 cities per civ then that returns false.

The last is a combination of the handicapped setting and the gamespeed. For quick diety games that works out to turn 7 as the earliest. If its after that turn the then check returns false.

All 3 checks have to retusn false for barbarians to spawn.
 
Haven't been following the thread, so don't know if this has already been reported: the Kuriotate player building a new city and choosing to make it a settlement when prompted by the popup will cause multiplayer games to go out of synch. There are no problems when the city hub cap has been met and you found a new settlement directly, though.
 
Nikis-Knight said:
That's funny, cause in the multiplayer cames, you'd hunker down and wait for the onslaught before building settlers... and so they never came.:mischief:

Yeah, especially if you do OCC on a Large map with raging barbs, like we were planning once. :P
 
Okay, this one's particularly bad, as it was supposed to be fixed...

The bird glitch is still a problem in version 'k'.

True, it's not the same as it was before... it's inverted, actually.

When a bird is loaded on a unit in the field, it is invisible and cannot be directly selected (as opposed to the 'j' version where everything else is invisible). Although far more tolerable then the previous situation, it's still clearly a bug.

I'm confused as to why this was even a problem in the first place... birds worked just fine in 'i'.
 
Kael said:
I wrote the code so that the same trait can't be selected twice (unless my logic is wrong):

Something is wrong then, because I have had the number of traits for Perpentach reduced from three to two on a number of occasions. Usually there are three, but there have been only two.
 
Kael said:
I wrote the code so that the same trait can't be selected twice (unless my logic is wrong):

Code:
		iRnd1 = CyGame().getSorenRandNum(len(Traits), "Insane")
		iRnd2 = CyGame().getSorenRandNum(len(Traits) - 1, "Insane")
		if iRnd2 >= iRnd1:
			iRnd2 = iRnd2 + 1
		iRnd3 = CyGame().getSorenRandNum(len(Traits) - 2, "Insane")
		if iRnd3 >= iRnd1:
			iRnd3 = iRnd3 + 1
		if iRnd3 >= iRnd2:
			iRnd3 = iRnd3 + 1

I think there's a bug here.
Say the RNG returns iRnd1 = 3, iRnd2 = 1, iRnd3 = 2.
iRnd1 is left unchanged = 3
iRnd2 is lower than iRnd1, so it's not changed either.
iRnd3 is lower than iRnd1, but it's greater than iRnd2. You add one to it, which in fact makes it equal to iRnd1.


If I may suggest so, the usual technique for chosing a set of non-duplicated elements from a sample list rather consists in picking them one by one, and systematically erase each of them from the list as they are picked. It's a little tedious (and less funny than manually messing with indices), but very robust.
 
Xuenay said:
Haven't been following the thread, so don't know if this has already been reported: the Kuriotate player building a new city and choosing to make it a settlement when prompted by the popup will cause multiplayer games to go out of synch. There are no problems when the city hub cap has been met and you found a new settlement directly, though.

K, im going to take away the ability to choose if its a settlement or city in multiplayer games.
 
Endovior said:
Okay, this one's particularly bad, as it was supposed to be fixed...

The bird glitch is still a problem in version 'k'.

True, it's not the same as it was before... it's inverted, actually.

When a bird is loaded on a unit in the field, it is invisible and cannot be directly selected (as opposed to the 'j' version where everything else is invisible). Although far more tolerable then the previous situation, it's still clearly a bug.

I'm confused as to why this was even a problem in the first place... birds worked just fine in 'i'.

I cant reproduce a problem here with 0.16. It could be that it has been fixed in some of the other changes.
 
SchpailsMan said:
I think there's a bug here.
Say the RNG returns iRnd1 = 3, iRnd2 = 1, iRnd3 = 2.
iRnd1 is left unchanged = 3
iRnd2 is lower than iRnd1, so it's not changed either.
iRnd3 is lower than iRnd1, but it's greater than iRnd2. You add one to it, which in fact makes it equal to iRnd1.


If I may suggest so, the usual technique for chosing a set of non-duplicated elements from a sample list rather consists in picking them one by one, and systematically erase each of them from the list as they are picked. It's a little tedious (and less funny than manually messing with indices), but very robust.

Might I suggest changing the code to something like:

Code:
                iRnd2 = CyGame().getSorenRandNum(len(Traits), "Insane")
		while iRnd2 == iRnd1:
			iRnd2 = CyGame().getSorenRandRum(len(Traits), "Insane")
		iRnd3 = CyGame().getSorenRandNum(len(Traits), "Insane")
		while iRnd3 == iRnd1 || iRnd3 == iRnd2:
			iRnd3 = CyGame().getSorenRandNum(len(Traits), "Insane")

Caveat for the above code, I do not know python so it may be syntacticlly incorrect. What it will do is keep picking traits until there are three that don't match.

This also has the benefit of making the spirtual trait accessible if the first trait picked was not either spiritual or raider.
 
mindlar said:
Might I suggest changing the code to something like:

Code:
                iRnd2 = CyGame().getSorenRandNum(len(Traits), "Insane")
		while iRnd2 == iRnd1:
			iRnd2 = CyGame().getSorenRandRum(len(Traits), "Insane")
		iRnd3 = CyGame().getSorenRandNum(len(Traits), "Insane")
		while iRnd3 == iRnd1 || iRnd3 == iRnd2:
			iRnd3 = CyGame().getSorenRandNum(len(Traits), "Insane")

Caveat for the above code, I do not know python so it may be syntacticlly incorrect. What it will do is keep picking traits until there are three that don't match.

This also has the benefit of making the spirtual trait accessible if the first trait picked was not either spiritual or raider.

Cool, I switched to your model which is a much simpliar way to do it.
 
one thing about that code, doesnt it lend itself to the possibility of never ending loops if the RNG is mean (i.e. keeps picking the same number)?

might be better to do the while loops with "rnd2 = rnd2+1" inside to guarrantee a maximum of two loops for the first one and three for the second, unless you're a gambler lol
 
Back
Top Bottom