Taurus 1.02

[Deaf Metal]

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?

 

[Deaf Metal]

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

 

[Deaf Metal]

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:

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.

 

[f1rpo]

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.)

 

[Deaf Metal]

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.

 

[f1rpo]

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.

 

[Deaf Metal]

It looks like the score increases from land don't interact correctly with the score delta option if factor in current turn is turned off - they're delayed by a turn. example: If at the end of turn 1 a city grows 1 and there's a land score increase, turn 2 will score delta the +2, but whatever the land score increase was won't be deltad until turn 3.

 

[Deaf Metal]

I spent a few hours (lol) trying to figure out how to change the vedic event from polytheism to priesthood until I realized it's controlled via Buffy.py in this mod. Is that necessary for compatibility? It's not intuitive for it to control it when it's not set in "buffy mode".

 

[f1rpo]

I was not aware that this BUFFY change is included in BULL/Taurus. I had actually thought that it was, for some reason, reverted in a later version of BUFFY after having been introduced in BUFFY 003. Probably I assumed that because I only saw it mentioned in the 003 release notes and didn't see any change in CvRandomEventInterface.py in my own copy of BUFFY 005. So I agree that this is confusing. I see now that it works through the BUFFY module XML file:

<export module="Buffy" function="canTriggerTheVedicAryans" to="CvRandomEventInterface"/>

It's kind of neat to change only one function in this way – rather than copying the whole file from BtS. Maybe the problem comes back down to the BUG developer documentation having disappeared and modders (myself included, in this case) being unaware of BUG's methods for overriding the original game's Python code. I guess I could just comment out the export element and put a comment about that in BUFFY.py, in case that someone comes across (only) that file and thinks they can easily enable the Vedic Aryans change there ...
BUFFY as a whole is not supposed to be easily enabled on top of Taurus because the main point of BUFFY vs. BULL is HoF participation – and the HoF allows only the original BULL-based BUFFY mod. Although someone might want to enable the HoF compatibility checks just so that they can see whether their settings would be HoF-compatible, so I probably shouldn't throw out the BUFFY module entirely.

 

[Deaf Metal]

Does the sln require Express 2013? I opened in 2010 and it said it requires a newer version, and the sln itself says Version 12.00, but it's still commented as 2010.

How come some FaceBase files, CvTextScreens, FFreeListArray weren't included?

 

[f1rpo]

I've never had trouble opening the sln with VS2010. For some reason, my sln file for AdvCiv has a line
MinimumVisualStudioVersion = 10.0.40219.1
after the # Visual C++ Express 2010 comment. Maybe adding that line would help? Kind of doubt it ... If I remove the sln and open the vcxproj to let VS2010 recreate the sln, I get a file that is pretty much the same as before with a newly generated project ID and "Version 11.00" instead of 12.00. So perhaps it really ought to say 11.00. That MinimumVisualStudioVersion line does not get added to the newly generated file either. And it lacks a section at the end, but I'm guessing that this is either superfluous or will get added once the DLL has been compiled once:

	GlobalSection(ExtensibilityGlobals) = postSolution
		SolutionGuid = {886B8394-6690-4605-8600-4B0B16E1B1CC}
	EndGlobalSection

Probably I have those strange bits in the preambles of my sln files because I've kept copying someone else's file, maybe Nightinggale's or karadoc's.

The excluded headers are unused by the DLL. CvTextScreens seems to have been included by accident, it may be part of the source of the EXE. The free list array probably came with its sibling, the free list trash array, only the latter is used in the DLL. The "F", I believe, stands for "Firaxis Game Engine", presumably code that Firaxis intended to share between several of their projects. As for the interfaces for DLL-to-EXE calls, CvDLLEventReporterIFaceBase.h was made obsolete by one of the final BtS patches, which moved CvEventReporter into the DLL. CvDLLDataStreamIFaceBase.h has always been empty; seems that its job is handled by FDataStreamBase.h instead.

 

[Deaf Metal]

That line didn't help. I can open the vcxproj and it creates makefile.user, but it keeps saying Failed to locate boost and python. I put in makefile.user:

TOOLKIT="C:\Videogames\Civ4SDK\Microsoft Visual C++ Toolkit 2003"
PSDK="C:\Videogames\Civ4SDK\WindowsSDK"
CIV4_PATH="C:\Videogames\Civilization IV Complete\Civ4\Beyond the Sword"

but it's not making any difference.

 

[f1rpo]

Boost-1.32.0 and Python24 are normally inside the CvGameCoreDLL folder of the BtS installation, so that folder probably needs to be appended to your CIV4_PATH. And changing the 12.00 to 11.00 in the sln also doesn't help? Because, if it does, I'll want to change that.

 

[Deaf Metal]

Changing 12 to 11 did make the sln load. But adding CvGameCoreDLL to the path in the makefile.user didn't help.

 

[f1rpo]

Well, are there folders Boost-1.32.0 and Python24 at the path assigned to CIV4_PATH? And Makefile.user in the same folder as the Makefile itself? The Makefile looks for Boost-1.32.0\libs\boost_python-vc71-mt-gd-1_32.lib, first locally, in the folder that Makefile.project is in, then in CIV4_PATH as set by Makefile.user. If not found, there's the failed-to-locate message.

 

[Deaf Metal]

The folders are at the path and makefile.user and the makefile are both in the project folder. I tried pasting the library folders into the taurus CvGameCoreDLL folder and it's still not working.

1>------ Build started: Project: CvGameCoreDLL, Configuration: Release Win32 ------
1>EXEC : FATAL error : Failed to locate boost and python
1>  Building source list
1>EXEC : FATAL error : Failed to locate boost and python
1>  Running fastdep
1>EXEC : FATAL error : Failed to locate boost and python
1>  The system cannot find the path specified.
1>NMAKE : fatal error U1077: '""C:\Videogames\Civ4SDK\Microsoft' : return code '0x1'
1>  Stop.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "set TARGET=Release
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake dll /NOLOGO" exited with code 2.

 

[Deaf Metal]

The folders are at the path and makefile.user and the makefile are both in the project folder. I tried pasting the library folders into the taurus CvGameCoreDLL folder and it's still not working.

1>------ Build started: Project: CvGameCoreDLL, Configuration: Release Win32 ------
1>EXEC : FATAL error : Failed to locate boost and python
1>  Building source list
1>EXEC : FATAL error : Failed to locate boost and python
1>  Running fastdep
1>EXEC : FATAL error : Failed to locate boost and python
1>  The system cannot find the path specified.
1>NMAKE : fatal error U1077: '""C:\Videogames\Civ4SDK\Microsoft' : return code '0x1'
1>  Stop.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "set TARGET=Release
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake dll /NOLOGO" exited with code 2.

Pasting the library folders into CvGameCoreDLL\project fixed the problem for those two, but the sdk path getting cut off after Microsoft is the next problem.

 

[Deaf Metal]

Pasting the library folders into CvGameCoreDLL\project fixed the problem for those two, but the sdk path getting cut off after Microsoft is the next problem.

Removing quotation marks around the path fixed this. It compiled correctly.

 

[Deaf Metal]

There's a problem with the health changes from chopping. This one says chopping a forest increases food. Don't have the save for this one.

 

[f1rpo]

It's the negative, eaten food icon again.

The quotation marks, ah! I didn't notice those – or wouldn't have remembered how quotation marks are supposed to be used in makefiles.