Taurus

Taurus 1.02

Do you know why the combat at the end of this turn is displayed as 2 vs 2.11 yet the lower value has favored odds?
 

Attachments

  • bug Taurus combat odds.CivBeyondSwordSave
    153.7 KB · Views: 1
The team battleground map bundled with the mod is identical to the version that's in bts. The full of resources version is older (3) than the last version posted in its thread (3.11).

I doubt this is due to Taurus, but if you feel like looking at it, ending the turn in this save produces a pile of copies of this error:
Traceback (most recent call last):

File "Hub", line 1151, in minStartingDistanceModifier

NameError: global name 'bSuccessFlag' is not defined
ERR: Python function minStartingDistanceModifier failed, module Hub
 

Attachments

  • bug Hub Taurus.CivBeyondSwordSave
    123 KB · Views: 1
The team battleground map bundled with the mod is identical to the version that's in bts. The full of resources version is older (3) than the last version posted in its thread (3.11).

I doubt this is due to Taurus, but if you feel like looking at it, ending the turn in this save produces a pile of copies of this error:
Traceback (most recent call last):

File "Hub", line 1151, in minStartingDistanceModifier

NameError: global name 'bSuccessFlag' is not defined
ERR: Python function minStartingDistanceModifier failed, module Hub
Replacing the problem area with:
Python:
def minStartingDistanceModifier():
    global bSuccessFlag
    try:
        bSuccessFlag
    except NameError:
        bSuccessFlag = False
    if bSuccessFlag == True:
        return -95
    else:
        return -50
at least made the error not appear at end of turn.
 
Do you know why the combat at the end of this turn is displayed as 2 vs 2.11 yet the lower value has favored odds?
Haven't done any math, but it looks like it could be correct. The Scout is damaged. It still has the higher firepower (average of maximal strength and currently displayed strength), resulting in favorable per-round odds, but is not favored by the overall odds because it can sustain fewer hits (despite also dealing more damage per round than its enemy).
Replacing the problem area with: [...]
at least made the error not appear at end of turn.
The NameError occurs when loading savegames because the script doesn't store its bSuccessFlag persistently. Failure (bSucessFlag=False) occurs only when the player count is less than 2 or greater than 18, so, if the flag isn't defined, it had probably been set to True when generating the map. Returning 0 might be the best choice when the NameError occurs because that should lead to the same result on the DLL side as not catching the Python exception.

The script is not really at fault; the DLL should only query the minStartingDistanceModifier while assigning starting locations, i.e. while generating the map. There's a BtS (or more likely Vanilla Civ 4) bug in CvUnitAI::AI_foundRange, a function that the AI uses when directing a settler to a city site. (There's really no need to evaluate city sites at that point – the AI updates its planned cities once per turn anyway, so K-Mod has scrapped the AI_foundRange function entirely.) The bug causes the AI to evaluate city sites as if it were assigning starting locations. Don't know if that's ultimately consequential. The part with the starting distance modifier – whether 0 is used, -50 or -90 – is probably not very relevant. I don't want to fix the AI bug in Taurus. Perhaps including a more robust version of Hub is the best approach, i.e. one that doesn't throw an exception (like the code you've posted) and returns 0 instead. That should preserve network compatibility with BULL. If the BULL player doesn't have exception popups enabled, they should remain blissfully ignorant of the whole issue. As a side effect, this will place Hub higher in the list of map scripts on the game setup screens (which aren't really modifiable).

I've been thinking that I should perhaps ditch the map scripts entirely, though. I had assumed that BUG also comes with those scripts, but, well, they're only an option (enabled by default) in the BUG installer. And I've been meaning to remove at least SmartMap because it consumes some 100 MB of main memory just by existing in the mod, i.e. without ever being selected by the player. If I go down that route, I'd only put a work-around in the DLL that avoids the exception popups when being asked for the Hub starting distance modifier.

If I keep the scripts other than SmartMap, then I'll remove Team Battleground and include the latest Full Of Resources. Conceivable that Team Battleground got included just so that it appears higher on the menus during game setup, but that doesn't seem desirable to me.
The last change to the resource toggle settings does seem to have mostly removed the problem. Maybe if you tried delaying it a little bit more, it would never happen on my computer.
Thanks, I'll try to do that, and I'll look into the other issues you've raised. (Could take a while.)
 
That hub issue also applies to wheel, might apply to ring too.
The FoR map often blocks out its game options tab and says it's not compatible with the mod, but after reloading sometimes it works.
After generating a map with it, the alt-x city placement often doesn't do anything when clicked on a tile. Program has to be restarted.
 
I see; sounds like I'd better leave those scripts alone and work around the issue in the DLL. I'll look into the Full Of Resources issues.
 
Top Bottom