It's a bunch of lists of CvInfo instances that have some relationship with each other. E.g. the list of improvements related to a given building contains those improvements whose yield gets boosted by the building either locally or globally or which generate a free specialist (Forest Preserve with National Park). Here's the CvGameCoreUtils function that establishes these relationships:[...] Thanks for checking it out. Hm, but is Relation Caching about relations or do you mean some caching from it is used for the yields tag?
Spoiler :
C++:
bool isImprovementRelatedToBuilding(ImprovementTypes eImprovement, BuildingTypes eBuilding)
{
const CvBuildingInfo& kBuilding = GC.getBuildingInfo(eBuilding);
if (kBuilding.getImprovementFreeSpecialist(eImprovement) != 0)
{
return true;
}
// MOD - START - Advanced Yield and Commerce Effects
for (int iMem = 0; iMem < kBuilding.getNumImprovementYieldChanges(); iMem++)
{
if ((ImprovementTypes)kBuilding.getImprovementYieldChangeImprovement(iMem) == eImprovement)
{
return true;
}
}
for (int iMem = 0; iMem < kBuilding.getNumGlobalImprovementYieldChanges(); iMem++)
{
if ((ImprovementTypes)kBuilding.getGlobalImprovementYieldChangeImprovement(iMem) == eImprovement)
{
return true;
}
}
// MOD - END - Advanced Yield and Commerce Effects
return false;
}
Some other quick pointers: A pair of helper function templates SetEconomicEffectEnumeration in CvXMLLoadUtility.h (declared and defined in the header) is used for loading the building improvement yield tags from XML. The yield effects get stored by CvCity:: processBuilding (renamed to "processBuildingActivation" in RI) and CvPlayer:: processBuilding for the local and global effect respectively. Everything related to initializing, accessing, serializing, deallocating that CvCity/ CvPlayer data will need to be adopted. CvCity also uses a helper
struct ImprovementYieldChange
defined in CvStructs. In CvPlot, the BBAI function calculateImprovementYieldChange will be important, specifically the pWorkingCity parameter added for the local (per-city) yield effect. The call locations of the function will require attention too because that's where this new parameter gets passed along. For the help text, there's setBuildingHelpActual and setImprovementHelp in CvGameTextMgr and also stuff in CvDLLWidgetData:: parseActionHelp. And AI support in CvCityAI, CvPlayerAI.I don't think the CvDeal class can tell which side broke a deal. You may have to add a parameter ("eCancelPlayer" or so) and make sure that the info gets passed along. That's what I've done in AdvCiv. (CvDeal handling AI memory at all is questionable software design, but that's probably difficult to refactor.)What I would need to change here to make the deal breaker suffer the attitude penalty instead of the other side/both?
The script does refer to the original WorldSizeTypes in two places. So, if you've added a new world size, it should probably also be added in those two places. If you've only increased the dimensions of the existing world sizes, then it looks like the getGridSize function of Global_Highlands will ignore such changes. Either way, I don't really see why there would be no Ocean.I have modded the map sizes, to larger than unmodded, global highlands map script (and only this script) isn't working as it should, its producing no oceans as it should. Does the global highlands script have any size limits?
Odd. Maybe a known issue with modular loading. Here's one thread I was able to find. In the (BtS) code, it looks like a bug:It seems using modules only works when adding additional code to the xmls. I cannot replace existing details. For the example I am using a Nuclear Plant module and trying to change the GameText strategy text. [...] The attached example file is a module intended for AdvCiv mod.
Spoiler :
C++:
bool CvXMLLoadUtility::LoadGlobalText()
{
// ...
{
// ...
gDLL->enumerateFiles(aszFiles, "xml\\text\\*.xml");
if (gDLL->isModularXMLLoading())
{
gDLL->enumerateFiles(aszModfiles, "modules\\*_CIV4GameText.xml");
aszFiles.insert(aszFiles.end(), aszModfiles.begin(), aszModfiles.end());
}
for(std::vector<CvString>::iterator it = aszFiles.begin(); it != aszFiles.end(); ++it)
{
bLoaded = LoadCivXml(m_pFXml, *it); // Load the XML
if (!bLoaded)
{
// (error handling)
}
if (bLoaded)
{
// if the xml is successfully validated
SetGameText("Civ4GameText", "Civ4GameText/TEXT");
}
}
// ...
}
// ...
}
gDLL->addText(textInfo.getType() /*id*/, textInfo.getText(), textInfo.getGender(), textInfo.getPlural());
Presumably, if the "id" (tag string) of the new textInfo already exists, addText discards it. If that's true, then the game text in modules needs to be put at the beginning of aszFiles, so it should be
aszFiles.insert(aszFiles.begin(),
... after the second enumerateFiles call. If I change it that way, your module seems to work as intended. So I guess I'll make this change in AdvCiv.