• Our friends from AlphaCentauri2.info are in need of technical assistance. If you have experience with the LAMP stack and some hours to spare, please help them out and post here.

Bug Reporting

you have to love users that report and issue, find a possible solution and let you know that the possible solution worked - thx for your posts and edits.
 
Okay.

Win7, Bug 4.4, BTS 3.13, I'm using altRoot (I don't suppose that matters, but still).
Everytime I do a combat, I get an error. The relevant lines from PythonErr.log:

This is animals attacking me. I'll let you know if anything similar happens when fighting barbarian units, or AI's (well, that one won't happen soon, I'm on an isolated start).

Code:
Traceback (most recent call last):
  File "BugEventManager", line 361, in _handleDefaultEvent
  File "CvEventManager", line 409, in onCombatLogCalc
  File "CvUtil", line 379, in combatMessageBuilder
AttributeError: 'CombatDetails' object has no attribute 'eVisualOwner'

I suppose eVisualOwner must be something about who controls the unit.
What I found in this reference (http://civ4bug.sourceforge.net/PythonAPI/AllClasses.html ) is this:

CombatDetails
Attributes:
PlayerType eOwner
PlayerType eVisualOwner

I didn't get further than that as I'm not familiar at all where those event managers can be found, or whether the eVisualOwner attribute should always be set. I suppose it shouldn't be hard to find out what's happening, however.

My instinct tells me that there must be some small programming error here. If this attribute might be unset, maybe there is something like
Code:
if isSet(eVisualOwner) then {...}
missing, but I may be wrong. Especially because in that case this bug must have been reported by others too.

Okay I figured my system has a search function over filenames.

I don't think there is an error in

File "BugEventManager", line 361, in _handleDefaultEvent
File "CvEventManager", line 409, in onCombatLogCalc

All it does is calls this: CvUtil.combatMessageBuilder(cdAttacker, cdDefender, iCombatOdds)

So here is the relevant code:

Code:
def combatMessageBuilder(cdAttacker, cdDefender, iCombatOdds):
	combatMessage = ""
	if (cdAttacker.eOwner == cdAttacker.eVisualOwner):
		combatMessage += "%s's " %(gc.getPlayer(cdAttacker.eOwner).getName(),)
	combatMessage += "%s (%.2f)" %(cdAttacker.sUnitName,cdAttacker.iCurrCombatStr/100.0,)
	combatMessage += " " + localText.getText("TXT_KEY_COMBAT_MESSAGE_VS", ()) + " "
	if (cdDefender.eOwner == cdDefender.eVisualOwner):
		combatMessage += "%s's " %(gc.getPlayer(cdDefender.eOwner).getName(),)
	combatMessage += "%s (%.2f)" %(cdDefender.sUnitName,cdDefender.iCurrCombatStr/100.0,)
	CyInterface().addCombatMessage(cdAttacker.eOwner,combatMessage)
	CyInterface().addCombatMessage(cdDefender.eOwner,combatMessage)
	combatMessage = "%s %.1f%%" %(localText.getText("TXT_KEY_COMBAT_MESSAGE_ODDS", ()),iCombatOdds/10.0,)
	CyInterface().addCombatMessage(cdAttacker.eOwner,combatMessage)
	CyInterface().addCombatMessage(cdDefender.eOwner,combatMessage)
	combatDetailMessageBuilder(cdAttacker,cdAttacker.eOwner,-1)
	combatDetailMessageBuilder(cdDefender,cdAttacker.eOwner,1)
	combatDetailMessageBuilder(cdAttacker,cdDefender.eOwner,-1)
	combatDetailMessageBuilder(cdDefender,cdDefender.eOwner,1)

Now apparently, eVisualOwner is not set.
Also, it IS set for the defender (else I would have gotten one more error), so clearly, it must have something to do with the attacker's units.

I tried to check my theory by going on the offensive, but unfortunately, it generated the same error (I expected it to report an error on line 383 now).

In case it matters (I suppose not), here is the debug file's relevant lines:

Code:
21:45:08 DEBUG: BugEventManager - event combatLogCalc: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC990>, <CvPythonExtensions.CombatDetails object at 0x0FBDC210>, 251),),)
21:45:08 TRACE: Error in combatLogCalc event handler <bound method BugEventManager.onCombatLogCalc of <BugEventManager.BugEventManager instance at 0x0F719A58>>
21:45:08 TRACE: 'CombatDetails' object has no attribute 'eVisualOwner'
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC990>, <CvPythonExtensions.CombatDetails object at 0x0FBDC210>, 0, 17),),)
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC120>, <CvPythonExtensions.CombatDetails object at 0x0FBDCB70>, 0, 17),),)
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC210>, <CvPythonExtensions.CombatDetails object at 0x0FBDC990>, 0, 17),),)
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDCB70>, <CvPythonExtensions.CombatDetails object at 0x0FBDC120>, 1, 22),),)
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC990>, <CvPythonExtensions.CombatDetails object at 0x0FBDC210>, 0, 17),),)
21:45:08 DEBUG: BugEventManager - event combatLogHit: (((<CvPythonExtensions.CombatDetails object at 0x0FBDC120>, <CvPythonExtensions.CombatDetails object at 0x0FBDCB70>, 0, 17),),)
21:45:08 DEBUG: BugEventManager - event unitKilled: (<CvPythonExtensions.CyUnit object at 0x0FC0FD18>, 0)
PY:Player 18 Civilization Barbarian State Unit Bear was killed by Player 0

(yea, i suicided my warrior on a Bear on a hill and I WON!) :D

I also figured out why no one has reported this bug yet: it's kind of hard to notice (only reason i did is my logger was set on).
I don't understand why does the attacker have an eVisualOwner and the defender hasn't.

Sorry for the long message. I hope it's helpful.
 
@csarmi - Thank you for the very detailed report. :goodjob: I haven't seen this either, but my test games probably don't involve any animals. While this looks to be a bug in the original BTS code, I'll take a look and submit a fix to the Unofficial Patch if it is.
 
Thanks.

Just make sure to let me know what the error was cause I'm really interested. I mean if it's not a problem. I cannot figure it out myself, as it seems. I don't know how I can find which codes use this eVisualOwner attributes (how is it set and when, etc). Well, I'm sure I should be able to, but it might take me a lot of time as I'm not really familiar with the game code. (also, I would want to fix it in my program).

Hah. :)

Shouldn't it be present in 'CyStructsInterface1.cpp'?

The strange thing is that here: http://code.google.com/p/sanguoforc...s/CvGameCoreDLL/CyStructsInterface1.cpp?r=291 it is present (a google search found some mod using it, i suppose), but it's missing from all Civ4 vanilla/warlords/bts as well.

May it be something that was fixed in BTS 3.19? I'm using 3.13 ...

I suppose it isn't as easy as adding some extra lines in that cpp file. Something tells me there must be much more to it.

edit: The same is happening with normal barbs. Which is not very surprising. I suppose it will happen with other civs too.
 
These data structures are defined by the original game and unmodified by BUG. It looks like you found the right file. You can see they are the first class listed in the Civ4 Python API. eVisualOwner is a PlayerType. While animals do not have an owner (it is probably -1), barbarians do.

But the above error is saying that the field itself doesn't exist. Perhaps this was added by a patch to BTS, but that seems unlikely. Anyway, I'll have to dig in to be sure.
 
Yup I did find that reference. Reading the files helped me more, however.
Still, I figure the source code needs to be recompiled to get it fixed so it's not something I should be able to do myself. What would it do, by the way? I don't have the game up right now, but it seems that I cannot see the combat chances in the combat log. So maybe it's that.

Indeed the field does not exist (it is not even defined in that structure file).
 
Yes, the log messages would not be added. You won't need a recompile to fix it, though. You'd need to fix the Python so it doesn't try to access that invalid field.
 
The reporting tool doesn't seem to work for me. The sourceforge page says "Artifact: This ArtifactType Does Not Allow Anonymous Submissions. Please Login. "

So I'll report here:

BUG or BAT (don't know which, installed them both the same day) has broken my right mouse button in game =[

Where before I could click and hold to see a path, combat odds, etc, now the Rclick has gotten really erratic.
Sometimes the Rclick doesn't register at all.
Sometimes it works like normal, but doesn't show any information while the button is held down.
Most irritating of all, sometimes the game acts as if I've clicked (pressed & released) when I'm holding the right mouse button down. This results in my unit(s) moving, and then when the next unit gets autoselected, I need fast reflexes to stop it from moving too - the game seems to be treating my 'hold down right mouse button' as if I'm 'repeatedly clicking the right mouse button really fast'.
The different variations seem totally random, so I never know how a particular click by me will turn out. For now I've 'solved' the problem by selecting 'right click menu' in options, but I'd like my normal right-click back.

Any idea what's happening?

PS - the problem is specific to civ4 (mouse 100% normal in other applications) and the game worked fine for a few hours after i installed the mods. I was playing in normal mode (not BAT) when the problem appeared, and the problem didn't go away with a reboot.
 
I can't see how either of those could bork your mouse. Are you sure that it only happens in Civ? Have you turned off the right button menu option?
 
The sourceforge page says "Artifact: This ArtifactType Does Not Allow Anonymous Submissions. Please Login. "
This means that you must create an account at sourceforge to log an issue or suggestion. We had an issue with a bot trying to enlarge our BUG members so we turned off the 'anonymous' feature.
 
I can't see how either of those could bork your mouse. Are you sure that it only happens in Civ? Have you turned off the right button menu option?

Yes, it seems very strange, but it's true nonetheless. I'm totally confident that the problem only happens in civ (approx 12 hrs computer usage since the problem happened), and as for the right button menu option, I had to turn it ON because the default mode was screwy. When I turn on the 'right click menu' option, the mouse behaves properly.

But I liked how it was before, when I could hold down the right mouse button to see a path and get combat odds. :/
 
Same here. BUG doesn't do anything with the right mouse, and as you said it worked for a while in BAT and stopped working outside of BAT. BAT files are all stored into a single folder inside the Mods folder which is utterly ignored when playing without BAT.

Some things to try:
  • Uninstall BAT and BUG
  • Reinstall Civ4 (I know, yuck!)
 
PS - the problem is specific to civ4 (mouse 100% normal in other applications)
Apart from the sentence above, it sounds very much like a hardware problem (push sensor under the right mouse button gone bad so that it doesn't send its signal continuously although it should).

Which other applications did you test? I'm asking because in most applications such an error wouldn't occur anyway, because they don't use the right mouse button in the way Civ does. Most applications either require just a single click (not continuous holding of the mouse button), or they don't immediately start an action if the button is released (in many games and 3d design programs, holding the right mouse button lets you swing the camera around, but that wouldn't be affected much by a slightly defective sensor, it would just produce a slight stutter in the movement that may or may not be perceivable).

If you have a mouse driver that shows clicks visually in its settings screen, then you could use this scree to double-check the right mouse button.

Another possibility is that some other programm is running that affects the right mouse button (Autohotkey might be a candidate), or that Civ polls the mouse in a way that it picks up earlier on slight defects, but both are very unlikely from your description.

Finally, a Civ4 reinstall might indeed be an option. Before you do that, switch between windowed mode and fullscreen mode and see whether that affects the problem. Civ4 sometimes _does_ produce some oddities wrt the mouse; I sometimes get a strange effect where the mouse just jitters in the upper right corner of the screen after switching from fullscreen Civ4 to my desktop. So it's not inconceivable that it introduces some oddities into right button clicking as well. But I never encountered any mouse problems inside the game, only when switching out of it.
 
ok weird, so I went back and tried what Psyringe suggested and now it just works. Likely sources of the problem were: Low mouse battery (did I change it in the meantime? Don't remember...), Autohotkeys, and who-knows-WTH-was-happening-but-it-was-Civ4.

R-click-and-hold is usable in windows, it creates a selection box and when you release, brings up the r-click menu with everything inside the box selected. Other than that Psyringe was right, there aren't many apps that use right-click-and-hold.

Anyways, thanks for the suggestions! I'll let you know if the problem reappears.
 
Hi boys,

Ok, I have a weird one. For some reason, my new working version of BAT has begun lagging at the beginning of a turn. It takes a second or two for the little globe to come up, even on the first few turns. I also have an MPLog.txt file in my logs folder. That's something new.

I'm using the BAT 3.0.1 DLL, and for all intents and purposes, I'm using all of the same Python and XML as BAT 3.0.1, just in the new folder. Here's a dump of my init.log file:

Code:
[2670.409] DBG: CIV Init
[2670.409] VERSION: App: C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe
[2670.409] VERSION: Build: Thu May 14 11:17:10 2009
[2670.409] VERSION: 3.1.9.0 (128100)
[2670.861] VERSION: Mod Loaded: D:\Users\Admin\Documents\My Games\Beyond the Sword\Mods\BAT Mod 4.0\
[2670.861] DBG: FILE Cat Init
[2671.829] DBG: Game Init
[COLOR=Red][2671.829] DBG: Multiplayer Init BEGIN
[2671.875] DBG: Multiplayer Init END[/COLOR]
[2671.875] DBG: Audio Init
[2672.562] DBG: ArtFileMgr Init
[2672.562] DBG: Python Init
[2682.827] VERSION: CIV Version: 319
[2682.827] VERSION: Minimum Version: 0
[2682.827] VERSION: Save Version: 302
[2682.827] DBG: Input Init
[2682.827] DBG: Engine Init
[2682.842] DBG: Checking available screen resolution
[2682.889] DBG: Validating screen resolution
[2682.889] DBG: Creating rendererer
[2683.466] DBG: Engine: renderer Initialized
[2683.497] DBG: Engine: Shaders Initialized
[2683.529] DBG: Engine: Scene Lights Initialized
[2683.544] DBG: Music Start
[2683.638] DBG: Font Init
[2683.653] DBG: Begin MenuManager
[2683.669] DBG: Total Frame MS: 13323.0  FPS: 000  Min:000 Max:000 Avg:000  SampleFilter:10.000000
 Time   :   Ave  :  Min% :  Max% : Num : Profile Name
-----------------------------------------------------
--------------------------------------------------
[2701.640] DBG: Engine: Camera Initialized
[2707.163] DBG: SyncRandSeed is 2683959, MapRandSeed is 2683959

I've never noticed an MP init before, and I'm wondering if the horrible lag has something to do with the game checking for other MP player's moves? I've removed all of the new code that I was working on, and I've cleared the caches.

If I load BAT 3, no problem. BAT 4 with the same code and DLL, lag problem.

Thoughts?

-N
 
Aside from the path on the App line, the Mod Loaded line, and the random number seeds reported that is an exact match for what is in my last init.log, and that was generated when launching Final Frontier Plus.

I expect those two lines have always been in there. It's also not likely that it would wait for non-existent other players if it isn't begin run as a multiplayer game.

And now for the perhaps not very useful stuff:

Check the size of the other logs it is generating. It is possible that you are logging a lot of information. In my case, since FFP has a lot of optional print statements in its Python that I keep activated, I get a huge PythonDbg.log file - the last time I played it was for about 40 turns in a late game situation and resulted in a file that is approaching 68MB in size, so each time the end-turn button is pressed it is logging over 1.5MB of stuff at this point in the game (early on its a lot less, though). I have noticed that some mods produce other log files that are quite large. On the other hand, even logging 1.5MB per turn should add well under a second to the processing time.

Have you altered the logging settings in CivilizationIV.ini? There are a number of log options that could have been activated, like SynchLog, RandLog, and/or MessageLog that may not have been activated before.

Better BtS AI also creates a log file, BBAI.log, which you probably incorporated into your DLL when you added that.

And then there is the BUG event logging. This can produce a ton of output, particularly if the Update event is logged (which it is by default - I changed that for my merge of BUG with FFP, although that specific change didn't make it into the FFP release) since that is called multiple times per second.

Also, does V4 have the same on/off settings for Python callbacks that V3 did? Each callback takes some time to process, even if it does nothing. Compare Assets\PythonCallbackDefines.xml.

And then, of course, there are all the potential coding issues in the DLL... Looping over things way too many times and such.

It could easily be a combination of multiple factors.

Yeah, I know, "multiple factors" = "not much help here"...
 
Yeah, I know, "multiple factors" = "not much help here"...
No, really. Lots of good things to check. Thank you.

I just found it weird that since I was using the exact same Python, XML, and the DLL as BAT 3, there would be a lag between them. Maybe it is the logging functions. There seems to be a lot of "SpyUtil" messages in the PythonDBG log.

When I get home from work in the morning, I'll have to sit down and play a few turns of BAT 3 and look at the logs, then play v4 and compare. I'm darn sure that I turned my mods off...

I was actually using onBeginPlayerTurn to draw a new HUD based on the era. I got the idea from Xienwolf and his Religious HUD mod. I was porting it over to BUG/BAT when this mess happened. Maybe I have some loose code laying about.

I'll try your suggestions in the morning G-E, again, thanks very much for the help. :)
 
BUG adds onBeginActivePlayerTurn for just such an occasion. It fires only when the human's turn starts. However, even checking every player turn shouldn't add much lag. Same for logging unless you're running from a tape drive, though you can disable it in the BUG Options screen's System tab. Set both logging levels to ERROR.

Have you added new unit or building graphics? Another suggestion is to send it to someone on a different computer to make sure it's not just a hardware issue. I don't recall how beefy your setup is, but it's possible that it's just shuffling a lot of models and textures over the bus.
 
@ God-Emperor and EF:

It turns out that I'm something of a nitwit. (Like that's a surprise. :lol: )

Part of the new code that I was working with used a modified CvEventsManager.py at one time. I don't need it now, but I forgot to delete the file. It was in the 4.0 folder, but not in the 3.0 folder, which is why 3.0 ran with no lag.

I renamed the file to a .tmp extension and the game runs just fine. :blush:

And while I have your two great minds looking at this... I can't remember if CvEspionageEventManager.py has been removed from BUG. It seemed to cause some issues a while back, but I can't remember now. Putting the file in the Contrib folder doesn't seem to do anything. Is it still needed?
 
Back
Top Bottom