Bug Reporting

[EmperorFool]

@Ench - I'm very glad you got it working. Can you please open the BUG Options screen (ALT + CTRL + O) and switch to the System tab. Scroll down so all of the directories listed under Asset Search Paths are visible and take a screenshot? That might help us diagnose the problems with that Config folder.

Thanks!

 

[Ench]

@Emperorfool
Wow, you are quick.. quicker than me, finding my own glitch: as i had both the mod and the gamefiles on the same partition, so i had accidentally moved the config-files instead of copying them, and deleted them to 'clean' the game again. Argh. It couldn't work this way.

Having reinstalled BUG 3.5 freshly, then replacing CvModName.py with your new one DOES work now.

Sorry for the confusion.

 

[Cybah]

1. Is it possible to move this to the right if there is no worst enemy?

2. The German translation is too large. What about "Lagebericht" or simply "Situation" instead of "Situationsbericht".

 

[ruff_hi]

I had thought we caught that by putting in the null (circle with line thru it) icon if there wasn't a WE.

 

[Cybah]

Dunno what this was/is (after "ok" it did not appear again):

 

[Dresden]

I had thought we caught that by putting in the null (circle with line thru it) icon if there wasn't a WE.

The null icon got commented out in revision 1471 and that section now looks like this:

	def Grid_WorstEnemy(self, iRow, iLeader):
		pWorstEnemy = PlayerUtil.getWorstEnemy(iLeader, self.iActivePlayer)
		if pWorstEnemy:
			self.iconGrid.addIcon(iRow, self.Col_WEnemy,
									gc.getLeaderHeadInfo(pWorstEnemy.getLeaderType()).getButton(), 45, 
									WidgetTypes.WIDGET_LEADERHEAD, iLeader, pWorstEnemy.getID())
		else:
			pass
			#self.iconGrid.addIcon(iRow, self.Col_WEnemy,
			#						ArtFileMgr.getInterfaceArtInfo("INTERFACE_BUTTONS_CANCEL").getPath(), 35, 
			#						WidgetTypes.WIDGET_GENERAL, -1)

Didn't see anything specific in the log but it was probably related to changing the widget data. Hopefully EF knows why it's commented out.

 

[EmperorFool]

The null icon got commented out in revision 1471.

That was me, and I thought it would look better blank. I didn't realize it shifted the stacked bar over. I can change it back, but first this weekend I'll see if I can fix IconGrid_BUG so it works with the blank.

 

[EmperorFool]

I fixed the problem with IconGrid and IconGrid_BUG: any empty icon or stacked bar columns would cause the following columns to be offset.

@Cybah - Line 1254 of the latest CvMainInterface is

if (pLoopUnit.IsSelected()):

While I would expect this to be called "isSelected()" (note the lowercase i), I don't see that this could randomly fail with a C++ exception. What does line 1254 looks like for you?

 

[Cybah]

The same. I did not touch CvMainInterface.

 

[EmperorFool]

Can you describe what happened up to that point in the game? What I'm asking is did you just load a game or was it a new game? Approximately how many turns had you played since starting/loading the game (a few or a lot)? Were there any abnormal conditions involved? Anything else I can go on?

 

[Cybah]

round 289. I've tried to replay a savegame up to this point but this error did not appear again. So, I think it has something to do with the actual monitor screen. maybe a drawing error cause of too many XYZ ?

 

[EmperorFool]

I think it has something to do with the actual monitor screen. maybe a drawing error cause of too many XYZ ?

That seems unlikely to me, but I can't rule it out. I would expect a much harder crash from something like that. In this case, IsSelected() was probably called on an invalid unit. I'll have to dig into the DLL code.

 

[·Imhotep·]

@EF:

Not that it bothers me greatly, but the system tab in the Config Screen shows BUG 3.5 build 1457 for me, although I have the recent 1492 build from SVN. Seems that the auto-update on the version number ain't working...

 

[The Doc]

@EF:

Not that it bothers me greatly, but the system tab in the Config Screen shows BUG 3.5 build 1457 for me, although I have the recent 1492 build from SVN. Seems that the auto-update on the version number ain't working...

What auto-update?

That's still work in progress and more of a show case of what will be in the future.
btw: The version number always refers to the last official release. In this case 3.5 which was SVN-build 1457.

 

[Dresden]

Something's amiss with the autolog withdrawal handling; the withdrawal messages are triggering on decisive combat too.

Examples from single decisive battles:

While attacking, Axeman escapes from Barbarian Axeman (Prob Victory: 68.3%)
While attacking in the wild, Axeman loses to Barbarian Axeman (2.00/5) (Prob Victory: 68.3%)

While attacking, Rifleman decimates Ottoman Longbowman (Prob Victory: 100.0%)
While attacking in Ottoman territory at Ankara, Rifleman (14.00/14) defeats Ottoman Longbowman (Prob Victory: 100.0%)

The withdrawal messages (first in each of the above quotes) come from onSelectionGroupPushMission() and the current test for whether to say anything is:

if self.UnitKilled == 0:

Unfortunately, self.UnitKilled gets set by onCombatResult() -- which generates the second messages in each of the above examples -- and based upon the order of the messages, it appears that onSelectionGroupPushMission() is getting called first and so it isn't aware that a unit was actually killed.

My first thought is to stop using self.UnitKilled as our comparison and instead use the following comparison:

if self.WdlDefender.iCurrHitPoints > 0 and self.WdlAttacker.iCurrHitPoints > 0:

This seems to work great in terms of preventing premature logging but this is a whole new area for me and before I commit I wanted to ask if there is anything obvious I'm missing that would make that a bad idea?

There is also the problem that the determination of "escape" vs "decimate" is not always correct or at least it's different than I expect it to be. It relies on whether or not the attacker or defender took the last damage, but for whatever reason the game sometimes reports the attacker took the last damage even in a "max damage/forced early withdrawal" case. Perhaps we should be comparing the defender's getDamage() to the attacker's combatLimit() instead?

Finally, I was thinking of making the withdrawal messages more similar to the onCombatResult messages by adding the location and strength information (in this case for both). Thoughts?

 

[EmperorFool]

Finally, I was thinking of making the withdrawal messages more similar to the onCombatResult messages by adding the location and strength information (in this case for both). Thoughts?

Yeah, that sounds like a great plan.

 

[ruff_hi]

that whole withdrawal thing was a PITA ... anything you can add to help would be appreciated.

 

[The Doc]

Maybe we should skip the "decimated" message and stick with the "withdrawal" message as the former is somewhat redundant. If the unit is killed it is implicit that it was decimated first and if it withdraws it's not that interesting.

Dresden, it would be great if you could try to rewrite the code for this in a similar way the defeat and victory messages are written if possible. Then those two messages could use the grammatical cases of the German version as well. Maybe the code for the on-screen withdrawal messages in the SDK is of any help for this.

 

[ruff_hi]

Maybe we should skip the "decimated" message and stick with the "withdrawal" message as the former is somewhat redundant. If the unit is killed it is implicit that it was decimated first and if it withdraws it's not that interesting.

There is no withdrawal if the unit is killed ... it is dead. However, there are two types of withdrawal ...

1. I'm not feeling well, about to die, time to run away - boy was I lucky (unit withdraw just before dying)
2. I've done what I can and reached the limit of hurt that I can put on this guy - over to you killers! (unit inflicted maximum damage and game forced it to withdraw)

The logger is trying to show the difference.

 

[Dresden]

that whole withdrawal thing was a PITA ...

Oh boy and it still is . My grand plan of comparing total damage done to the defender against the attacker's damage limit has failed me... because the basic problem is that on an early withdrawal, the CombatDetails structure isn't completely updated for the last round. So... I need to figure out how to get at the actual unit object of the losing unit after an unresolved combat.

The good news is that adding the additional info to the log entries works fine, though:

While attacking in the wild, Cannon (3.00/12) escapes from Barbarian Infantry (8.00/20) (Prob Victory: 7.4%)