DLL - Unified Yields

[Vicevirtuoso]

I can confirm that Honor is not affected by SetBaseCombatStrength() with CP active. Killed a barbarian unit with 8 base strength, set with that function to 133 strength, and was only awarded 12 culture.

 

[Gazebo]

I can confirm that Honor is not affected by SetBaseCombatStrength() with CP active. Killed a barbarian unit with 8 base strength, set with that function to 133 strength, and was only awarded 12 culture.

Thanks for testing. I'll change it in the next point update.
G

 

[Ulixes]

Hi Whoward, if you have a moment, I've a question:

I don't remember what's the difference between Policy_SpecialistYieldChanges and Policy_SpecialistExtraYields.

Apparently they both add yield to specialists, do the first subtract yield too ?
When it's appropiate to use one and when the other ?

 

[whoward69]

Looks like Policy_SpecialistExtraYields is a blanket addition regardless of specialist type, whereas Policy_SpecialistYieldChanges allows finer grain control (like Trait_SpecialistYieldChanges) as you specify which specialist is to receive the bonus

 

[Ulixes]

I feel dumb.
It was obvious, I didn't check well.

Thank you anyway for the quick answer!

 

[S3rgeus]

I see that to add these new yields, on the DLL-side you guys have added YIELD_TOURISM and the like to the YieldTypes enum in CvGameCoreEnums.h. Did you consider changing YieldTypes to be like the other DB-defined enums, where it only has one defined value (NO_YIELD = -1) and used the IDs taken from the database as the other values?

I'm looking at adding some more yields to my own mod now and it looks like Firaxis' use of NUM_YIELD_TYPES as the ceiling for yields (instead of something like a theoretical GC.GetNumYieldInfos()) is fairly prolific. Is the volume of existing code why you guys elected to add to the enum instead of convert them all to use the DB ids directly?

EDIT: Related to yields and such, you guys might find this change useful. I pulled apart most of the DLL-side Faith-specific functions (i.e. removed CvPlayer::GetFaithPerTurn() and the associated GetFaithXXXXX() functions down the chain from it) and redirected them to the generic yield handlers. I don't have the player base to say whether this works correctly for all permutations of yield sources, but it definitely runs and lets you get some faith. I left the Lua API untouched to prevent breaking a bunch of UI files that would then cause compatibility problems.

 

[JFD]

There is a Building_SpecialistYieldChanges(BuildingType, SpecialistType, YieldType, Yield) table, but perhaps you could see fit to add to the next version a Policy_SpecialistYieldChanges(BuildingType, SpecialistType, YieldType, Yield). Would save me using a dummy building to simulate the same effect.

 

[meRlinX_AT]

Hallo,

the Building_ResourceYieldModifiers with food is still not working?

i will use it with an building, that reduces the food

 

[Gazebo]

Hallo,

the Building_ResourceYieldModifiers with food is still not working?

i will use it with an building, that reduces the food

That's a vanilla function. it probably works, but doesn't show up in LUA because you are assigning a negative value (the lua only applies if positive, IIRC).

G

 

[whoward69]

There is a Building_SpecialistYieldChanges(BuildingType, SpecialistType, YieldType, Yield) table, but perhaps you could see fit to add to the next version a Policy_SpecialistYieldChanges(PolicyType, SpecialistType, YieldType, Yield).

Should be already there - item 26 in the list in post #1 (along with Belief_SpecialistYieldChanges - item 7)

 

[Gazebo]

Should be already there - item 26 in the list in post #1 (along with Belief_SpecialistYieldChanges - item 7)

Yep - JFD attributed it to me in the latest version, but I informed him that it was the work of the great whoward!

G

 

[JFD]

EDIT: Nevermind.

 

[HorseshoeHermit]

This project describes 'Tourism' as a local yield, saying it doesn't accrue.

I am quite confused by this sentiment; Tourism does nothing but accrue, accruing Tourism is what wins the game with it. And it isn't local to anything.

Certainly, the architecture has some flaws where the value is considered a static property of a city, and the empire is only coded to inspect City values for Tourism to determine what amounts to push onto other civs, but that doesn't make it local. Either it is global like Faith, or it is not a yield at all.

If you make it like food or production you're gonna have problems, because Tourism doesn't build up to anything, it's just a number. You'd have to base the citizen yield functions more on the GreatWork stuff than food, gold, or GPPs.

Research does not actually store up either; it goes straight into a tech. Tourism is the same - it goes into every met civ, earmarked with its source (you!). The two functions that manipulate it in this respect are easy to find: CvPlayerCulture::GetInfluencePerTurn, and CvPlayerCulture:: DoTurn

You 'd have to write up another function for the interface, an actual "pushTourism" function, but it can be done.

void CvPlayerCulture::addInfluenceInstance(int iTourism)
{
//for some reason the value for your tourism modifiers is housed in the capital!
//{get a handle to the capital city}
	CvCity *pLoopCity;

	for (pLoopCity = m_pPlayer->firstCity(&iLoopCity); pLoopCity != NULL; pLoopCity = m_pPlayer->nextCity(&iLoopCity))
		{
			if (pLoopCity->isCapital())
			{
				break;
			}
		}
	CvCity& pCapital = *pLoopCity;

//Compute the modified influence to each player
[INDENT]//for (each player who is alive) (by IDs)
{

//if we met this player and they aren't us and they are valid for influence
[indent]{
	CyPlayer& kPlayerReference = GET_PLAYER(iLoopPlayerID);

	iInfluenceModifierToPlayer = pCapital->GetCityCulture()->GetTourismMultiplier(iLoopPlayerID, false, false, false, false, false);
//put that influence to that player
[indent]
			//Apply all modifiers except possibly the Internet
			//bool bHasGreatFirewall - this really ought to be determined some better way than looking it up every time
			int iInfluenceToAdd = iTourism * iInfluenceModifierToPlayer

			//from GetInfluencePerTurn(PlayerTypes)
			int iTechSpreadModifier = kPlayerReference.GetInfluenceSpreadModifier();

			if (iTechSpreadModifier > 0 && bTargetHasGreatFirewall)
			{
				int iInternetDifference = iTourism * iTechSpreadModifier / 100;
				iInfluenceToAdd -= iInternetTechDifference;
			}
[/indent]
	m_aiCulturalInfluence[iLoopPlayer] += iInfluenceToAdd;
}[/indent]
}
[/INDENT]
//Ask the UI to update?
//Notify every subsystem that cares reactively about influence levels - public opinion.
//Check for victory?
}

I'd rather not check for victory, and call this function in the doTurn of the city , making sure to do so before checking doTurn for PlayerCulture. The notification seems obligatory.

Of course, this should be refactored out of GetInfluencePerTurn so as to house the logic of "how to know what Tourism actually becomes in influence".
And goddang that GreatFirewall check.

 

[Gazebo]

Well, it may 'accrue' in that sense, but the DLL handles tourism completely differently from all other yields in terms of data storage and per turn computations.

G

 

[JFD]

Perhaps a Building_GreatWorkYieldChanges akin to the existing Policy_GreatWorkYieldChanges?

 

[HorseshoeHermit]

The DLL handles all yields completely differently. This project is intended to reverse that. But the logical nature of the yield, based on the game rules, is objective and discoverable. The ideal form of patchmods would be to make the code resemble the rules.
Supposing we didn't want to kick around Tourism and maintained that it came only from cities, that it -only- appeared per turn from the "TPT" amount, and the TPT amount is some static reading of the state of each city and tech, policy, and hotel modifiers, that still makes it confusing to call a local yield . It does not belong to a city because a city cannot obtain it.

It is an attribute of a city, but you don't call buildings yields.

Perhaps a Building_GreatWorkYieldChanges akin to the existing Policy_GreatWorkYieldChanges?

Will that table modify the way that a city yields Yields from its great works when the city contains the building, or will it modify the yields of GreatWorks housed in that building?
I guess a good name for the latter would be "GreatWorkBuilding_GreatWorkYieldChanges".

 

[Vicevirtuoso]

What are the odds we could get GreatWork_YieldChanges? As in, a specific Great Work provides bonus Yields regardless of the city/building in which it is placed?

 

[JFD]

Will that table modify the way that a city yields Yields from its great works when the city contains the building, or will it modify the yields of GreatWorks housed in that building?
I guess a good name for the latter would be "GreatWorkBuilding_GreatWorkYieldChanges".

It would modify the yields of all great works in all cities. Building_CityGreatWorkYieldChanges, Building_BuildingClassGreatWorkYieldChanges, and Building_BuildingClassCityGreatWorkYieldChanges would be for more specific things, I guess.

 

[whoward69]

The DLL handles all yields completely differently. This project is intended to reverse that.

No it wasn't - as that would be a massive amount of refactoring of the spaghetti, fraught with danger and requiring full regression testing. The aim of this project was to make all the database tables behave consistently and conformantly - as per post #3

 

[sukritact]

Are there equivalents of "Building_TradeRouteYieldChange" and "Building_ImprovementYieldChange" (both local and global versions)?