Anq
Prince
Since build types available to the great farmer are defined in the xml, and all sorts of worker units also define build types in xml, why would there be a need to double-check granular callback from python? Isn't this redundant?
if(pXML->TryMoveToXmlFirstChild(L"PlaceBonusTypes"))
{
int i = 0;
int iNum = pXML->GetXmlChildrenNumber(L"PlaceBonusType" );
m_aPlaceBonusTypes.resize(iNum); // Important to keep the delayed resolution pointers correct
if(pXML->TryMoveToXmlFirstChild())
{
if (pXML->TryMoveToXmlFirstOfSiblings(L"PlaceBonusType"))
{
do
{
pXML->GetChildXmlValByName(szTextVal, L"BonusType");
pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].iProbability), L"iProbability");
pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].bRequiresAccess), L"bRequiresAccess");
pXML->GetChildXmlValByName(szTextVal2, L"TerrainType");
pXML->GetChildXmlValByName(szTextVal3, L"FeatureType");
pXML->GetChildXmlValByName(szTextVal4, L"MapCategoryType");
pXML->GetChildXmlValByName(szTextVal5, L"TechType");
GC.addDelayedResolution((int*)&(m_aPlaceBonusTypes[i].eBonus), szTextVal);
m_aPlaceBonusTypes[i].ePrereqTerrain = (TerrainTypes)pXML->GetInfoClass(szTextVal2);
m_aPlaceBonusTypes[i].ePrereqFeature = (FeatureTypes)pXML->GetInfoClass(szTextVal3);
m_aPlaceBonusTypes[i].ePrereqMapCategory = (MapCategoryTypes)pXML->GetInfoClass(szTextVal4);
m_aPlaceBonusTypes[i].ePrereqTech = (TechTypes)pXML->GetInfoClass(szTextVal5);
i++;
} while(pXML->TryMoveToXmlNextSibling(L"PlaceBonusType"));
}
pXML->MoveToXmlParent();
}
pXML->MoveToXmlParent();
}
I'm not sure what you are talking about...why would there be a need to double-check granular callback from python? Isn't this redundant?
<Civ4Defines xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="..\..\..\Xml\Schema\Caveman2Cosmos.xsd">
<Define>
<DefineName>USE_CAN_BUILD_CALLBACK_GRANULAR</DefineName>
<DefineTextVal>BUILD_BONUS_DONKEY,BUILD_BONUS_HORSE,BUILD_BONUS_ELEPHANT,BUILD_BONUS_BISON,BUILD_BONUS_CAMEL,BUILD_BONUS_COW,BUILD_BONUS_DEER,BUILD_BONUS_FUR,BUILD_BONUS_KANGAROO,BUILD_BONUS_LLAMA,BUILD_BONUS_MAMMOTH,BUILD_BONUS_PIG,BUILD_BONUS_POULTRY,BUILD_BONUS_RABBIT,BUILD_BONUS_SEA_LIONS,BUILD_BONUS_SHEEP,BUILD_BONUS_WALRUS,BUILD_BONUS_GUINEA_PIG,BUILD_BONUS_PARROTS,BUILD_BONUS_BARLEY,BUILD_BONUS_CORN,BUILD_BONUS_FLAX,BUILD_BONUS_MELON,BUILD_BONUS_POTATO,BUILD_BONUS_PUMPKIN,BUILD_BONUS_RICE,BUILD_BONUS_SQUASH,BUILD_BONUS_WHEAT,BUILD_BONUS_ALMONDS,BUILD_BONUS_APPLE,BUILD_BONUS_BANANA,BUILD_BONUS_COCONUT,BUILD_BONUS_DATES,BUILD_BONUS_FIG,BUILD_BONUS_LEMON,BUILD_BONUS_MANGO,BUILD_BONUS_OLIVES,BUILD_BONUS_PAPAYA,BUILD_BONUS_PISTACHIO,BUILD_BONUS_WINE,BUILD_BONUS_HENNA,BUILD_BONUS_INDIGO,BUILD_BONUS_RUBBER,BUILD_BONUS_TIMBER,BUILD_BONUS_CANNABIS,BUILD_BONUS_COCA,BUILD_BONUS_COCOA,BUILD_BONUS_COFFEE,BUILD_BONUS_COTTON,BUILD_BONUS_INCENSE,BUILD_BONUS_MUSHROOMS,BUILD_BONUS_OPIUM,BUILD_BONUS_PAPYRUS,BUILD_BONUS_PEYOTE,BUILD_BONUS_PRICKLY_PEAR,BUILD_BONUS_RESIN,BUILD_BONUS_SILK,BUILD_BONUS_SPICES,BUILD_BONUS_SUGAR,BUILD_BONUS_TEA,BUILD_BONUS_TOBACCO,BUILD_BONUS_VANILLA,BUILD_BONUS_POMEGRANATE,BUILD_BONUS_KAVA,BUILD_BONUS_GUAVA</DefineTextVal>
</Define>
</Civ4Defines>
#ifdef GRANULAR_CALLBACK_CONTROL
// KOSHLING - granular control over Python callbacks - so far implements
// CanTrain
// CannotTrain
// CanBuild
const char* entityList;
// CanTrain
if ( GC.getDefinesVarSystem()->GetValue("USE_CAN_TRAIN_CALLBACK_GRANULAR", entityList) )
{
cvInternalGlobals::getInstance().m_pythonCallbackController.RegisterUnitCallback(CALLBACK_TYPE_CAN_TRAIN, entityList);
GC.getDefinesVarSystem()->RemValue("USE_CAN_TRAIN_CALLBACK_GRANULAR");
}
// CannotTrain
if ( GC.getDefinesVarSystem()->GetValue("USE_CANNOT_TRAIN_CALLBACK_GRANULAR", entityList) )
{
cvInternalGlobals::getInstance().m_pythonCallbackController.RegisterUnitCallback(CALLBACK_TYPE_CANNOT_TRAIN, entityList);
GC.getDefinesVarSystem()->RemValue("USE_CANNOT_TRAIN_CALLBACK_GRANULAR");
}
// CanBuild
if ( GC.getDefinesVarSystem()->GetValue("USE_CAN_BUILD_CALLBACK_GRANULAR", entityList) )
{
cvInternalGlobals::getInstance().m_pythonCallbackController.RegisterBuildCallback(CALLBACK_TYPE_CAN_BUILD, entityList);
GC.getDefinesVarSystem()->RemValue("USE_CAN_BUILD_CALLBACK_GRANULAR");
}
I made that tag and it's intended for use with a lot more than just the Farmer, though he's intended to be included. The problem is that:Is is possible to use <PlaceBonusTypes> tag in the animalplacing buildinfo xml?
Instead of <ImprovementType>, let great farmers place bare bonus without improvement using <PlaceBonusType>.
Code exists for placing bonus, and it recognizes a sort of nested structure:
Code:if(pXML->TryMoveToXmlFirstChild(L"PlaceBonusTypes")) { int i = 0; int iNum = pXML->GetXmlChildrenNumber(L"PlaceBonusType" ); m_aPlaceBonusTypes.resize(iNum); // Important to keep the delayed resolution pointers correct if(pXML->TryMoveToXmlFirstChild()) { if (pXML->TryMoveToXmlFirstOfSiblings(L"PlaceBonusType")) { do { pXML->GetChildXmlValByName(szTextVal, L"BonusType"); pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].iProbability), L"iProbability"); pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].bRequiresAccess), L"bRequiresAccess"); pXML->GetChildXmlValByName(szTextVal2, L"TerrainType"); pXML->GetChildXmlValByName(szTextVal3, L"FeatureType"); pXML->GetChildXmlValByName(szTextVal4, L"MapCategoryType"); pXML->GetChildXmlValByName(szTextVal5, L"TechType"); GC.addDelayedResolution((int*)&(m_aPlaceBonusTypes[i].eBonus), szTextVal); m_aPlaceBonusTypes[i].ePrereqTerrain = (TerrainTypes)pXML->GetInfoClass(szTextVal2); m_aPlaceBonusTypes[i].ePrereqFeature = (FeatureTypes)pXML->GetInfoClass(szTextVal3); m_aPlaceBonusTypes[i].ePrereqMapCategory = (MapCategoryTypes)pXML->GetInfoClass(szTextVal4); m_aPlaceBonusTypes[i].ePrereqTech = (TechTypes)pXML->GetInfoClass(szTextVal5); i++; } while(pXML->TryMoveToXmlNextSibling(L"PlaceBonusType")); } pXML->MoveToXmlParent(); } pXML->MoveToXmlParent(); }
A couple of tags would be missing for that to work for the great farmer.Is is possible to use <PlaceBonusTypes> tag in the animalplacing buildinfo xml?
Instead of <ImprovementType>, let great farmers place bare bonus without improvement using <PlaceBonusType>.
Code exists for placing bonus, and it recognizes a sort of nested structure:
Code:if(pXML->TryMoveToXmlFirstChild(L"PlaceBonusTypes")) { int i = 0; int iNum = pXML->GetXmlChildrenNumber(L"PlaceBonusType" ); m_aPlaceBonusTypes.resize(iNum); // Important to keep the delayed resolution pointers correct if(pXML->TryMoveToXmlFirstChild()) { if (pXML->TryMoveToXmlFirstOfSiblings(L"PlaceBonusType")) { do { pXML->GetChildXmlValByName(szTextVal, L"BonusType"); pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].iProbability), L"iProbability"); pXML->GetChildXmlValByName(&(m_aPlaceBonusTypes[i].bRequiresAccess), L"bRequiresAccess"); pXML->GetChildXmlValByName(szTextVal2, L"TerrainType"); pXML->GetChildXmlValByName(szTextVal3, L"FeatureType"); pXML->GetChildXmlValByName(szTextVal4, L"MapCategoryType"); pXML->GetChildXmlValByName(szTextVal5, L"TechType"); GC.addDelayedResolution((int*)&(m_aPlaceBonusTypes[i].eBonus), szTextVal); m_aPlaceBonusTypes[i].ePrereqTerrain = (TerrainTypes)pXML->GetInfoClass(szTextVal2); m_aPlaceBonusTypes[i].ePrereqFeature = (FeatureTypes)pXML->GetInfoClass(szTextVal3); m_aPlaceBonusTypes[i].ePrereqMapCategory = (MapCategoryTypes)pXML->GetInfoClass(szTextVal4); m_aPlaceBonusTypes[i].ePrereqTech = (TechTypes)pXML->GetInfoClass(szTextVal5); i++; } while(pXML->TryMoveToXmlNextSibling(L"PlaceBonusType")); } pXML->MoveToXmlParent(); } pXML->MoveToXmlParent(); }
This can easily be added in xml with the current setup for bonus placement.2) There is no AI to support it
Work boats, great farmer, and other workers are working correctly now.I'm just hoping we can recover what we had with the farmer before we move forward in the next release cycle.
The build itself, outside of this tag, is capable of establishing all of those prerequisites. This is a tag for Build Infos as it is, not a new mechanism. All other build tags can be employed to further craft things - and some of the tags here should probably not even be used in the nested tag unless there's a very good reason for it (which my imagination allowed for.) They should often, instead, be established on the rest of the build's tags.The requirements set for the bonus in CIV4BonusInfos.xml would have to be the requirements that allows the build, this is sensible to let the canBuild python function check.
That could work to get the AI to use it BUT it would simply get the AI to spam the most valuable one or the first of the most valuable ones or something equally repeatable. What it needs to consider when considering placing a bonus is:We could simply add some high yields to the bogus improvement that the build places, the improvement is instantly removed and replaced by a bonus when its built, but the AI think it will get the improvement when it chooses to build it.
Can the build xml establish iMinAreaSize, iMinLatitude, and iMaxLatitude requirements?The build itself, outside of this tag, is capable of establishing all of those prerequisites.
Yeah I get that, as Anq initially asked if it was possible to not define improvements at all for great farmer builds by using the PlaceBonusType build tag.you don't HAVE to have an improvement on this build
That is pretty much what I suggested we do, that the improvements value is increased if they have a iDiscoveryChance value, it could do something like:That could work to get the AI to use it BUT it would simply get the AI to spam the most valuable one or the first of the most valuable ones or something equally repeatable. What it needs to consider when considering placing a bonus is:
1) Will doing this give me access to a bonus I don't already have except by trade so I can be assured of having future access to what I'm currently trading for?
2) Will doing this open up my ability to build any new culture wonders or other unusual resource combination buildings in any city this plot is in range of?
3) Will this expand my access to those resources I currently have the least of?
4) Will this make my corporation(s) more powerful?
5) Would this bonus (or likely bonus if it's not certain which would result) promote the most powerful possible use for that tile (such as a mineral on a hill, a plant on plains, etc...)
That one is harder to account for as a value modifier in the AI improvement value evaluation... Perhaps it could be as easy as to reduce the value added from iDiscovery chance based on how many of the bonus that the player have with a minimum value of 1 after reduction.If none of these are compelling enough, to some threshold, it should NOT even bother, because that would then leave room for future other better placements that may eventually become more valuable.
I'd have to review the build infos tags to know the answer to that. There are a lot of prereqs available to builds, some rather complex, so some of it may be possible and others may require new tags. I believe that IS possible as is, though it may require multiple builds be defined. That said, I'd think it better to add such prereqs AS new build tags rather than to the bonus placements specifically since those are really only to be used in special situations I imagined for them. The goal of this tag was, somewhat, to make it possible to make the land and random chance decide what the farmer ends up placing, rather than allowing it to be completely player choice. Or to enable the farmer (or any other worker) to earn promotions to enable more pre-determined bonus placement builds.Can the build xml establish iMinAreaSize, iMinLatitude, and iMaxLatitude requirements?
Can the build xml establish a requirement that only allows a specific terrain if it has a specific feature on it like the bonus requirement can?
e.g. Can be built on grass and plain terrains, cannot be built on desert, but can be built on desert if there's a flood plain feature there.
Since this tag is not intended to be used with an improvement at all, how would a non-referenced improvement's discovery chance play into it? We COULD reference an improvement I suppose, but requiring it seems to run counter to the point of the tag, and if you did, you wouldn't want to ALWAYS have to have the improvement it refers to be destroyed.That is pretty much what I suggested we do, that the improvements value is increased if they have a iDiscoveryChance value, it could do something like:
These would need to be new tags - and if we're going to consider climate, as stated in the previous post, it's about time we did that. The map script could establish climates by latitudes (or whatever it wants to establish them by) but I'd want the map script or direct scenario map to make that determination. The problem I'd have in setting that up on my end would be any interaction with world builder is out of my ability completely. Maybe as a py programmer you could do something with that if there were some basic functions for setting ClimateType on plot? I can see how later on some map change effects may refer to plot ClimateTypes, and it could be useful for spawn infos for sure.Can the build xml establish iMinAreaSize, iMinLatitude, and iMaxLatitude requirements?
Ok, so the BUILD can't directly, but this tag sure can limit the application of a given entry to a specific terrain AND feature (it's an AND relationship, not OR when you apply both a terraintype and featuretype to a placebonus entry).Can the build xml establish a requirement that only allows a specific terrain if it has a specific feature on it like the bonus requirement can?
Why add new tags when all the tags exist for the bonus in question, why set the same values in the build as what is in the bonus when we could simply use the information from the bonus directly to evaluate the build.I'd have to review the build infos tags to know the answer to that. There are a lot of prereqs available to builds, some rather complex, so some of it may be possible and others may require new tags. I believe that IS possible as is, though it may require multiple builds be defined. That said, I'd think it better to add such prereqs AS new build tags rather than to the bonus placements specifically since those are really only to be used in special situations I imagined for them.
I like the idea behind the placebonustag for builds, my point was only that it is not yet ready to replace the current great farmer system which is what Anq asked about. The random part is a good idea, although that could be done in python too during the improvement to bonus switcharoo.The goal of this tag was, somewhat, to make it possible to make the land and random chance decide what the farmer ends up placing, rather than allowing it to be completely player choice. Or to enable the farmer (or any other worker) to earn promotions to enable more pre-determined bonus placement builds.
Sorry for being a bit unclear. You misunderstood my posts about this, I meant "the current system" used for great farmers can mostly deal with the AI evaluations already. My point being that the problem you brought up about missing AI code for great farmers was easiest to solve by simply tweaking how the improvement value is evaluated.Since this tag is not intended to be used with an improvement at all, how would a non-referenced improvement's discovery chance play into it? We COULD reference an improvement I suppose, but requiring it seems to run counter to the point of the tag, and if you did, you wouldn't want to ALWAYS have to have the improvement it refers to be destroyed.
I remember how to use this tag from the original discussions about its implementation, others might like to get a guide though.Ok, so the BUILD can't directly, but this tag sure can limit the application of a given entry to a specific terrain AND feature (it's an AND relationship, not OR when you apply both a terraintype and featuretype to a placebonus entry).
I should start a thread on exactly how to use this tag... I wrote it out in a PM discussion but it could use some review.
If those are on the bonus, then yes, conveniently we could simply refer to those as something that must be observed during the canBuild evaluation without having to add new tags.Why add new tags when all the tags exist for the bonus in question, why set the same values in the build as what is in the bonus when we could simply use the information from the bonus directly to evaluate the build.
Well, I was making that point myself - the tag is not quite ready for use and there are some damned complicated things to work out before we can that I'm not looking forward to having to sort out. Certainly not something to be working on during a freeze for sure.I like the idea behind the placebonustag for builds, my point was only that it is not yet ready to replace the current great farmer system which is what Anq asked about. The random part is a good idea, although that could be done in python too during the improvement to bonus switcharoo.
There may be some of that in the code. I don't know.The tweaks I suggested should really be done anyway to make the AI appreciate improvements that can provide new resources over time through iDiscoverChance more than it currently does, currently it doesn't mean much to the AI that a mine can discover iron when the AI does not have access to iron; it means exactly the same as that a farm can discover wheat when the AI does have access to wheat.
Could... though do you think we can assume such a tag would be used? Or are we saying that we might want a build that allows us to plant potatoes on Mars soil where the map would normally never allow it so we should include such a bool? Now that I'm thinking of it from that angle, I think you're right that adding that tag would be useful.Why not add a bUseBonusRequirements tag to the nested structure of placeBonusType?