Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

[Thunderbrd]

Mafs will usually clear up on reload making them non-repeatable. IF your MAF/CTDs WERE repeatable and the new update on the SVN gets you through them, then I'd have to say it was probably one of the bugs that update attempted to fix. If they WEREN'T repeatable then the new update still COULD fix it but it might be a mem leak elsewhere.

I wouldn't mind getting some instructions on hunting down memory leaks in the code if there are some ways to narrow in on those specifically.

 

[Thunderbrd]

In the combat odds mouseover, defender retreat %age appears to be taken out of defeat odds rather than victory odds. Eg. ambusher attacks explorer, odds are shown as 53% victory, 0% defeat, 7.8% retreat, 46.1% defender retreat. Whereas the victory odds should be considerably lower because of the defender retreat, whereas the defeat odds are above 40%

I'm certainly not convinced by that post alone as the odds could be nearly 100% if it weren't taking the defender retreat into consideration in that layout.

If you're using fight or flight, early withdrawal makes a flat simple percentage basically impossible and can just provide an estimation of % chance to retreat. What is a 10% chance 1-6 times depending on whether you've been damaged to a particular degree or not? Rather difficult, if not impossible. So there are quick patch fixes to give estimations and the numbers will never appear to add up fully.

What I'd be interested in seeing in that particular odds scenario is the defender's chance of actual victory.

All I can say is i'm not feeling totally thrown off by odds assessments of late. Sure the unusual can happen as we're dealing with randoms but it happens even less often than it did on core CivIV rules. I know I've seen victory chances very high for both attacker and defender and this really only makes sense to say that the chances are that the battle will not end with one destroying the other.

 

[Yudishtira]

I'm certainly not convinced by that post alone as the odds could be nearly 100% if it weren't taking the defender retreat into consideration in that layout.

If it was an assassin ie. a dominant unit attacking, then yes the 0% of defeat could be correct, and the 53% victory could represent the 100% chance of victory minus the 46.7% of defender retreat.

If only!

In this case, the units are almost equal due to the ambusher's huge bonus against recons. The 53% is the base chance of victory with no defender retreat factored in. Should (probably) be 53*(100 - 46.7) ie. 28.25%

I'm not using Size Matters so this is a base 3 str attacking an uninjured base 6 str.

If you're using fight or flight, early withdrawal makes a flat simple percentage basically impossible and can just provide an estimation of % chance to retreat. What is a 10% chance 1-6 times depending on whether you've been damaged to a particular degree or not? Rather difficult, if not impossible. So there are quick patch fixes to give estimations and the numbers will never appear to add up fully.

What I'd be interested in seeing in that particular odds scenario is the defender's chance of actual victory.

The defender's chance of victory (= ambusher's chance to die) in this case is (100 - 53)*(100 - 7.8)%, ie. 43.33%.

I take your point about the impossibility of getting odds exactly right with Fight or Flight (which is on yes), but I hope you will agree that 43.33% would be far more accurate and useful than 0% which is wrong and a bug.

Would you believe me if I posted the save?

 

[JosEPh_II]

Mafs will usually clear up on reload making them non-repeatable. IF your MAF/CTDs WERE repeatable and the new update on the SVN gets you through them, then I'd have to say it was probably one of the bugs that update attempted to fix. If they WEREN'T repeatable then the new update still COULD fix it but it might be a mem leak elsewhere.

I wouldn't mind getting some instructions on hunting down memory leaks in the code if there are some ways to narrow in on those specifically.

I could reload and continue after my MAF. The SVN version using at that time was/is 8657. With the previous save for long EoT also from 8657 but showing 8653 because that was the last dll change. And my latest was clearly a MAF when I closed the Great Artist pop up for Apelles. Hence the Error msg Failed to allocate video memory, with the DX9 file paths and error on line:321 for SurfaceTextureData.cpp. Perhaps Sparth could look at the graphics for that GA Apelles?

EDIT: Updating to 8663 right now to see how EoT's proceed.

JosEPh

 

[Stormwind]

Rev 8661:

Python Error when building the Lotus Temple.

Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "PlatyPingWonders", line 165, in onBuildingBuilt
ArgumentError: Python argument types in
CyPlayer.AI_getAttitude(CyPlayer, CyPlayer)
did not match C++ signature:
AI_getAttitude(class CyPlayer {lvalue}, int)

 

[Thunderbrd]

If it was an assassin ie. a dominant unit attacking, then yes the 0% of defeat could be correct, and the 53% victory could represent the 100% chance of victory minus the 46.7% of defender retreat.

If only!

In this case, the units are almost equal due to the ambusher's huge bonus against recons. The 53% is the base chance of victory with no defender retreat factored in. Should (probably) be 53*(100 - 46.7) ie. 28.25%

I'm not using Size Matters so this is a base 3 str attacking an uninjured base 6 str.



The defender's chance of victory (= ambusher's chance to die) in this case is (100 - 53)*(100 - 7.8)%, ie. 43.33%.

I take your point about the impossibility of getting odds exactly right with Fight or Flight (which is on yes), but I hope you will agree that 43.33% would be far more accurate and useful than 0% which is wrong and a bug.

Would you believe me if I posted the save?

It's not about belief or disbelief. It's just something I'm not wanting to get caught up in the analysis paralysis over.

I believe the issue is that you're taking the chance of victory as being the other unit's chance to die when I believe it is the chance you'll survive the fight be it through withdrawal or destroying the opponent fully.

For example, I don't think the defender's withdrawal factors into the attacker's chance of victory because if he withdraws or dies it's still a victory for the attacker. But the Attacker's chance of withdrawal will increase the Attacker's chance for victory because even a withdrawal is a success.

But the defender's withdrawal it does factor into the defender's chance of victory because if they survive they are victorious to a degree as well. And so on. This is why you will sometimes see 100% chance of victory on both sides. (Pretty much means this WILL end in a withdrawal by either the attacker or the defender.)

 

[Yudishtira]

I believe the issue is that you're taking the chance of victory as being the other unit's chance to die when I believe it is the chance you'll survive the fight be it through withdrawal or destroying the opponent fully.

It's possible that there is some semantic issue here, but remember the attacker's defeat odds are being reported as exactly zero. It's so plainly a bug, and even more plainly so if you are right and the 53% represents my (attacker's) survival chance.

 

[Dancing Hoskuld]

The sound file for the Asatru tech is garbled.

 

[Dancing Hoskuld]

Rev 8661:

Python Error when building the Lotus Temple.

Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "PlatyPingWonders", line 165, in onBuildingBuilt
ArgumentError: Python argument types in
CyPlayer.AI_getAttitude(CyPlayer, CyPlayer)
did not match C++ signature:
AI_getAttitude(class CyPlayer {lvalue}, int)

I am not well. Ours is a simple port of Platypings. the code should be almost identical the only difference being the indentation. In Python leading white space is code. Can some one compare the latest Platyping version with ours. Thanks

 

[Morlark]

The relevant code was changed in r8397 to:

		pPlayer = gc.getPlayer(pCity.plot().getOwner())
		for iPlayer2 in range(gc.getMAX_CIV_PLAYERS()):
			pPlayer2 = gc.getPlayer(iPlayer2)
			if (pPlayer2.isAlive()==True) and (pPlayer2.isBarbarian()==False) and pPlayer != pPlayer2:
				while pPlayer.AI_getAttitude(pPlayer2) < gc.getInfoTypeForString("ATTITUDE_CAUTIOUS"):
					pPlayer.AI_changeAttitudeExtra(pPlayer2, 1)
				while pPlayer2.AI_getAttitude(pPlayer) < gc.getInfoTypeForString("ATTITUDE_CAUTIOUS"):
					pPlayer2.AI_changeAttitudeExtra(pPlayer, 1)

from r8394:

		pPlayer = gc.getPlayer(pCity.plot().getOwner())
		pPID = pPlayer.getID()
		iTeam = pPlayer.getTeam()
		for iPlayer2 in range(gc.getMAX_CIV_PLAYERS()):
			pPlayer2 = gc.getPlayer(iPlayer2)
			if (pPlayer2.isAlive()==True) and (pPlayer2.isBarbarian()==False):
				if pPlayer2.AI_getAttitude(pPID) < 2:
					for i in range (1,200,1):
						pPlayer2.AI_changeAttitudeExtra(iTeam, +1)
						if pPlayer2.AI_getAttitude(pPID) == 2:
							break

As the error message you quoted shows, this function requires an int argument (i.e. player ID) but it is instead being given a player argument. You need to re-add the pPlayer.getID() line and update the function arguments accordingly.

 

[JosEPh_II]

After updating to SVN 8663 I've been recording turn times. After initial Re-Calc turn subsequent turns are taking an avg of 4min 20 secs with an occasional 5 and 6 min turn showing up. The longer one appears when a Great Person is going to be born and the next longest when an Autosave is going to show up (every 4th turn is my setting for AS). None have been less than 4 min 10 sec.

It's now 1306AD Ren Era after alberts2 Date adjustment reset the date for my game from the 1500+ AD to 1100AD. Not sure why the Date code was adjusted though.

JosEPh

 

[Pit2015]

I have mushrooms on tile directly near capital city, i have a mushroom gatherer on it, but i have no mushrooms in city resource screen? Bug?

 

[Noriad2]

I have mushrooms on tile directly near capital city, i have a mushroom gatherer on it, but i have no mushrooms in city resource screen? Bug?

did you build a trail (road) in the plot?

 

[Pit2015]

did you build a trail (road) in the plot?

No but on capital city you get all resources without road or trail that are on a plot directly near the city, i have marble and stone near and got it without road or trail.

 

[Noriad2]

No but on caital city you get all resources without road or trail that are on a plot directly near the city, i have marble and stone near and got it without road or trail.

I'm not sure if that is true. I find that rivers often function as roads for resource purposes, and a river can connect a plot with a city. So sometimes resources are connected and sometimes they aren't, depending on the presence of a river in the right location(s).

 

[Pit2015]

I'm not sure if that is true. I find that rivers often function as roads for resource purposes, and a river can connect a plot with a city. So sometimes resources are connected and sometimes they aren't, depending on the presence of a river in the right location(s).

There is a river also, maybe works not for all resources, maybe some need a trail/road will still a while unitl i get the tech that alows me trails, i will see then.

 

[Noriad2]

There is a river also, maybe works not for all resources, maybe some need a trail/road will still a while unitl i get the tech that alows me trails, i will see then.

Also the Civilopedia says that gathering tech reveals mushrooms, but herbalism tech enables it. Have you researched herbalism yet? For stone, the same tech (hard hammer percussion) both reveals and enables it.
Check the Civilopedia entry under "map bonuses".

 

[Pit2015]

Also the Civilopedia says that gathering tech reveals mushrooms, but herbalism tech enables it. Have you researched herbalism yet? For stone, the same tech (hard hammer percussion) both reveals and enables it.
Check the Civilopedia entry under "map bonuses".

Yeah that may be the problem. ;-)

 

[strategyonly]

Just noticed that 2 buttons have the same pic, Community Discussions and Knowledge Instructions??

 

[olduser]

It's now 1306AD Ren Era after alberts2 Date adjustment reset the date for my game from the 1500+ AD to 1100AD. Not sure why the Date code was adjusted though.

JosEPh

I made the code a bit simpler and fixed a few issues.

There was a error in incrementing the date, if you had xml code like this

				<GameTurnInfo>
					<iMonthIncrement>480</iMonthIncrement>
					<iTurnsPerIncrement>500</iTurnsPerIncrement>
				</GameTurnInfo>
				<GameTurnInfo>
					<iMonthIncrement>360</iMonthIncrement>
					<iTurnsPerIncrement>500</iTurnsPerIncrement>
				</GameTurnInfo>				</GameTurnInfo>

It was changing the date in turn 501 by 480 months instead of 360. That is why the date has changed in your game after my change.