Bug Reporting

Same here. Follow Lemon Merchant's instructions for downgrading BAT 2.1 to from VD 8.0 to VD 7.5 so you can continue this game and future games. The download link for VD 7.5 is two posts after that post in the same thread.
 
Yo EF, so we meet again :D I've worked past those annoying python issues I was having with tsentom's stuff, if you remember...or rather I worked around them. So now I'm moving on to smaller bugs! Yay!

The only real one left right now is small but pretty persistent. I've combined most of tsentom's ThomasWar mod with Phugus's LoR mod, which uses BUG and RevDCM. Most of the merger's working excellently now, except for a few civs who, when played, have no UI. The game doesn't crash or anything, and I can still move the units around and stuff, but there is absolutely no UI. No city screen either (though I can found a city with B key and click on it, but there's no city screen, just a perspective change like in the city screen fat cross window), and I have to use Escape to even get back to the Main Menu. The advisors work, at least I can go open them up, but the tech tree is all wonky; sometimes not all the techs are visible, and the arrows connecting the techs are gone.

It's only a few civs that do this, but they always do, every time, and no other civs ever do. It doesn't matter which leader I choose for the civs either. And every single time, each of the civs spits out the same thing in the PythonErr log:

Spoiler :
Traceback (most recent call last):

File "CvAppInterface", line 75, in preGameStart

File "CvScreensInterface", line 83, in showTechChooser

File "CvTechChooser", line 202, in interfaceScreen

File "CvTechChooser", line 214, in ConstructTabs

File "CvTechChooser", line 251, in DrawTechChooser

File "CvTechChooser", line 331, in placeTechs

File "CvTechChooser", line 354, in addIconsToTechPanel

RuntimeError: unidentifiable C++ exception
ERR: Python function preGameStart failed, module CvAppInterface


Every. Single. Time.

But all the other civs run perfectly, it's only these few that do this, but they always do it. I can't begin to think where the real problem could be, but I hope you can tell.

All the problem civs are ones imported from ThomasWar (Australia, Mexico, etc) but all the other ThomasWar import civs work fine.

Thanks again in advance EF! Or anyone else with ideas
 
My guess is that some unique units or buildings' button artwork is specified incorrectly because you're seeing the error in the tech chooser. For a hint, open that screen and see which tech is missing a UU/UB.

I don't know why that would stop the main interface and city screen from drawing. You should see a different error message for that. Are you sure that's the only message in the error log?
 
@TenchuHawke - Thanks for the thorough analysis. I did add some events in BULL during combat:

  • Collateral Damage
  • Flanking Damage
  • Retreat
  • Withdrawal (barrage-only units)
If either unit dies normally, nothing should be different. However, I can't see how new events could cause any trouble. All they do is log a message with Autolog if you have that on--do you?

Have you tried using the Unofficial Patch 3.19 DLL in place of BULL? Could you if you haven't, please? Also, are you two using different BUG settings such as Autolog, Unit Naming, or PLE?

I am running into the same OOS problem that TenchuHawke described; running a Pitboss game with BUG 4.2 and BULL 1.0, my friends and I are getting OOS the first time a human player's unit attacks (but not when an AI unit attacks, IIRC.)

- The same error happened with autolog, unit naming, and PLE all enabled, as well as when all were disabled.

- I still get the OOS warning even if I'm the only player connected to the game, except the warning text flashes on and off instead of staying on consistently.

- I am both hosting the Pitboss game and playing in that game from the same computer; not sure if this might be a factor?

- I didn't get the OOS error after combat when running with BUG 4.2 and the UP 1.4 DLL, or with just BUG 4.2 and no modified DLL.

Please let me know if there's any more information I can provide, or if a save file or connection information would be helpful. A big thank you for all of the BUG team's work; this mod is fantatsic!
 
Has there been any further information as to BULL 1.0 causing OOS in MP games when a player attacks anything? I play ROM with my friends and we are stuck in 2.71 because of that very problem. We'd thought it was from the RevDCM latest version - is that based on BUG/BULL? Oh dear, I AM blond and get confused at times... :) Maybe its age? hehe

Anyways, I just want to be able to play ROM 2.8 MP and am not a modder so I rely on the good will of you all!
 
I cannot answer your question satisfactorily except to say that either it is a merge error in RevDCM or that multiplayer usually breaks (OOS) when coders do one or both of the following:

1) If there is a portion of code that executes only on the local machine, it must not change the game state. If there is a portion of code that runs on all networked machines including the local machine, then the game state may be changed.

2) If a coder makes a call to getSorenRandomNumber exclusively on the local machine, and not an identical call on all machines, the game state is broken. This is confusing because you would think that a getter method does not change the game state, but in the case of getSorenRandomNumber function, the determinism of the sorenRandomNumber generator is broken with respect to the network.

Cheers
 
My guess is that some unique units or buildings' button artwork is specified incorrectly because you're seeing the error in the tech chooser. For a hint, open that screen and see which tech is missing a UU/UB.

I don't know why that would stop the main interface and city screen from drawing. You should see a different error message for that. Are you sure that's the only message in the error log?

Thanks as always EF! But I haven't been able to find any problem with the artwork. The tech chooser doesn't scroll when I test out these civs, but from what I can see there's no missing button art there, and there's no missing art in the civilopedia. And yeah, that error I posted before is the only one in PythonErr, and it happens every time for every one of these problem civs.

Any other suggestions, anyone? Beuller?

Edit: Oooh! However, I got a slightly different error for the Italian civ. The tech tree looks different too; half the techs are msising. Here's the error log for the Italians. The first bit of it is the same, but then there's a little extra too:

Spoiler :
Traceback (most recent call last):

File "CvAppInterface", line 75, in preGameStart

File "CvScreensInterface", line 83, in showTechChooser

File "CvTechChooser", line 202, in interfaceScreen

File "CvTechChooser", line 214, in ConstructTabs

File "CvTechChooser", line 251, in DrawTechChooser

File "CvTechChooser", line 331, in placeTechs

File "CvTechChooser", line 354, in addIconsToTechPanel

RuntimeError: unidentifiable C++ exception
ERR: Python function preGameStart failed, module CvAppInterface
Traceback (most recent call last):
File "BugEventManager", line 350, in _handleDefaultEvent
File "RevolutionInit", line 101, in onGameStart
File "RevolutionInit", line 161, in onGameLoad
File "DynamicCivNames", line 50, in __init__
File "DynamicCivNames", line 206, in onSetPlayerAlive
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 1: ordinal not in range(128)
 
----
Continue our previous conversation. I decided to log few bug here as well

PlayerUtil
getDefensivePacts should use getTeam() not getID(); in askedPlayer.getID() != player.getID()

getPossibleEmbargos ditto, canTradeIteam can be optimized to call w/ testDenial=true and avoid getTradeDenial call altogether
item must be the team like in war checks.


DiplomaticUtil
isWillingToTalk()
should use player.AI_getMemoryCount(PlayerTypes, MemoryTypes)
 
Thanks, took care of those too. I also simplified the code a little.

DiplomaticUtil
isWillingToTalk()
should use player.AI_getMemoryCount(PlayerTypes, MemoryTypes)

AI_isWillingToTalk() already checks that when you're not at war, and I need the other checks that the function does. Am I missing something?
 
I think I uncovered a small quirk in the pre-chop improvement and forests functionality. Here's the scenario that results in the forest still being chopped.

Worker A is assigned to chop/improve. Worker B is then moved from a different tile and also set to chop/improve. Since there's only 1 turn left, worker B's chop order is cancelled as expected, but worker A's chop order remains. This results in worker A chopping the forest next turn.

I believe if the workers were grouped first before given their chop order, the logic would work since the cancel order would also apply to the group.

You may want to alter the logic a little to clear chop orders at the beginning of the next turn before and units move. Every worker on the tile would also need to be stopped. I believe the current logic fails because worker A had >1 turns to go at the time he was given the order. When worker B shortened the time, worker A was never checked again.

Also, in the BUG options screen, there's a missing mouseover help concerning showing the actual building effects on the city bar mouseover. I think it's related to this:
Found a very minor bug:

In BULL City Bar Options.xml, the entry TXT_KEY_BUG_OPT_MISCHOVER__BUILDINGACTUALEFFECTS_HOVER should actually be TXT_KEY_BUG_OPT_CITYBAR__BUILDINGACTUALEFFECTS_HOVER
You may want to check again.
 
Thanks, took care of those too. I also simplified the code a little.
AI_isWillingToTalk() already checks that when you're not at war, and I need the other checks that the function does. Am I missing something?

I mean memory count is what the C++ code uses internally. Should be more robust to stay the same. Other than that I think it's correct.
 
It uses memory only when you are not at war. When you are at war, it starts as unwilling to talk and requires that you do enough damage to surpass a threshold. I could recreate that function in Python . . . or I could just call it. I prefer the latter as it will remain correct for mods that alter the function and is less work.
 
I'm getting a crash to desktop using BAT version 2.1.

Please see this thread for a discussion on the graphics crashing issues in the latest BAT. See Lemon Merchant's posts 11 and 13 for a temporary work-around.
 
BUG Team,

Not sure if this has been reported yet... but some Russian users of History in the Making (BUG 4.2 integrated) are reporting blank interfaces when playing. It seems like when they are using Cyrillic alphabet in their user profiles, it causes the blank interface. But if they create a profile in Latin alphabet, the interface appears.

Here is a post further explaining it from a Russian HiTM player:

http://forums.civfanatics.com/showpost.php?p=8776013&postcount=3465

and here is a screenshot from a Russian user with no interface:

http://forums.civfanatics.com/showpost.php?p=8772959&postcount=3457


Thanks! :)
 
very minor text bug (sorry, if already reported or fixed).

Civ4lerts Options.xml
Spoiler :
Code:
		<Tag>TXT_KEY_BUG_OPT_CIV4LERTS__[COLOR="Red"]CIV4LERTS[/COLOR]_HOVER</Tag>
should be
Code:
		<Tag>TXT_KEY_BUG_OPT_CIV4LERTS__[COLOR="Blue"]ENABLED[/COLOR]_HOVER</Tag>
BULL City Bar Options.xml
Spoiler :
Code:
		<Tag>TXT_KEY_BUG_OPT_[COLOR="Red"]MISCHOVER[/COLOR]__BUILDINGACTUALEFFECTS_HOVER</Tag>
should be
Code:
		<Tag>TXT_KEY_BUG_OPT_[COLOR="Blue"]CITYBAR[/COLOR]__BUILDINGACTUALEFFECTS_HOVER</Tag>
EDIT after EF responded #2157:
BULL City Bar Options.xml
Code:
		<Tag>TXT_KEY_BUG_OPTLABEL_[COLOR="Red"]CITYBAR_HOVER[/COLOR]</Tag>
should be
Code:
		<Tag>TXT_KEY_BUG_OPTLABEL_[COLOR="Blue"]CITYBARHOVER[/COLOR]</Tag>
</Tag>
 
BUG 4.2 , after clicking on "date" twice :
Spoiler :
civ4screenshot0180.jpg

Obviously the GW was not the last wonder done :D

From the save posted here, if you want to test with the same save.
 
looks perfectly sorted to me ... see how the numbers are decreasing! Truthfully, I don't think there is much we can do about that except move the AD and BC to the front - totally yukky.
 
We could do that, or we could put the date in as a +/- number into a hidden column and open the screen sorted by date. Clicking the Date header would again sort them by this not-quite-correct method. There are no UI events for Python in regards to sorting tables or clicking headers. :(
 
Back
Top Bottom