EmperorFool
Deity
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.
Bug Reporting
- Thread starter alerum68
- Start date
Yo EF, so we meet again 
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:
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
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 :
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
EmperorFool
Deity
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?
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?
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!
Maybe its age? heheAnyways, 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!
glider1
Deity
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
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
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 :
----
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)
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)
EmperorFool
Deity
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?
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?
_alphaBeta_
King
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:
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:
You may want to check again.
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.
EmperorFool
Deity
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.
Arizona_Steve
King
EmperorFool
Deity
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!
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
BULL City Bar Options.xml
EDIT after EF responded #2157:
BULL City Bar Options.xml
should be
Civ4lerts Options.xml
Spoiler :
Spoiler :
BULL City Bar Options.xml
Code:
<Tag>TXT_KEY_BUG_OPTLABEL_[COLOR="Red"]CITYBAR_HOVER[/COLOR]</Tag>
Code:
<Tag>TXT_KEY_BUG_OPTLABEL_[COLOR="Blue"]CITYBARHOVER[/COLOR]</Tag>
</Tag>EmperorFool
Deity
Thanks, denev. Fixed.
r_rolo1
King of myself
ruff_hi
Live 4ever! Or die trying
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.
EmperorFool
Deity
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. 
Similar threads
