Fealty, Loyalty, and the REF

[Nightinggale]

It could be cool if the new CivEffects had a tag that could affect ImmigrationWeight for a Unitclass. You could easily have Civics, Techs, Fathers, or Traits that adjust immigration chance for a unitclass up or down!

It could be cool if the new CivEffects had a tag that could affect __________

I totally agree and this is likely a place where the game will expand wildly once CivEffects are fully implemented.

About all the new abstract yields and combination yields my head is kind of spinning from all the proposed combinations. But I think the most natural way to control behavior of abstract and combination yields would be from tags in YieldInfos.xml. They would not be the same for all mods so it's best to avoid hardcoding where possible, though I guess some of their core behaviors (ie what yield controls border expansion, what yield triggers an immigrant, what yield controls "Rebel Sentiment" slider, etc) would require hardcoding to a given Yield to be feasible.

I was thinking of yields earlier today. I had a plan to "reverse" the yields, meaning it would start with virtual yields and then modders can add cargo yields to the end. However given that the game expects the virtual yields last, that might be lots of work.

We can't simply set the yields entirely in XML for performance reasons. One solution I have been thinking of is to cache the index of YIELD_HAMMERS in CvGlobals and then use an enum to access virtual yields. Getting a virtual yield would then be calling an inline function, which returns the cached index for hammers + enum argument. This would hardcode the order, but would also be quite fast.

Another solution would be to have an array in CvGlobals and the virtual yield enum would then be the index in that array. It would be a bit slower, but still fairly fast. This array would then need to be filled with XML data.

To be honest I'm actually in favour of the hardcoded order based on C++ coding and performance reasons. Maybe the yield XML would need some bools to tell what they should act like and the DLL will assert if XML and DLL goes out of sync.

I'm not really sure how useful a virtual yield would be if the DLL doesn't provide a special meaning for it. After all, it will be just a yield and it can't be loaded onto units or anything like that. I can't think of a good use for it without some sort of DLL hardcoding.

In the case of Culture (or whatever the border-expanding combo yield would be) the gameplay role may be relatively limited at 1-plot city radius, but could become more interesting if you have 2-plot city radius with gradual border expansion one tile at a time a la Civ5. Or if you stay at 1-plot city radius but let cities progress through several "Culture Levels" (Struggling->Prosperous->Legendary etc) a la Civ4, where maintaining high local Culture Level can grant some benefit.

I like the 1 plot spread approach, but so far I haven't got a clue on how to implement it. I don't really like the 2 plot radius approach though.

This is a good idea for Events, but could be even more versatile if you take advantage of the existing options in EventTriggerInfos.xml and EventInfos.xml to control the behavior of applying and removing a CivEffect.

To be honest I never looked in those files. However having a file of hidden CivEffects, which can be easily triggered by events seems like the way to go. The game is changing towards controlling as much as possible with CivEffects meaning the more different aspects of the game, which can use them, the higher the XML modder freedom becomes.

 

[Kailric]

I'm not sure about the behavior of vanilla iImmigrationWeightDecay (ie does it decay after you get an immigrant or adjust passively per-turn), but the first one does seem more interesting.

The code is only in one place in the DLL and it works like...

if (NO_UNIT != eUnit && bAllowed)

	int iWeight = GC.getUnitInfo(eUnit).getImmigrationWeight();
	for (int i = 0; i < getUnitClassImmigrated((UnitClassTypes) iUnitClass); ++i)
	{
		iWeight *= std::max(0, 100 - GC.getUnitInfo(eUnit).getImmigrationWeightDecay());
		iWeight /= 100;
	}

	aiWeights[eUnit] += iWeight;
}
Then later it picks a unit with...
UnitTypes eBestUnit = (UnitTypes) GC.getGameINLINE().getSorenRand().pickValue(aiWeights, "pick immigrant");

So, its not so simple, and it is used when the loop is done to pick the immigrant.

About all the new abstract yields and combination yields my head is kind of spinning from all the proposed combinations. But I think the most natural way to control behavior of abstract and combination yields would be from tags in YieldInfos.xml. They would not be the same for all mods so it's best to avoid hardcoding where possible, though I guess some of their core behaviors (ie what yield controls border expansion, what yield triggers an immigrant, what yield controls "Rebel Sentiment" slider, etc) would require hardcoding to a given Yield to be feasible.

Actually, we are talking about having it completely set up in the XML what yield does what as well. If there is no yield set it will revert to the defaults. If we ever made the yields as dynamic as Night talks about then we wouldn't be able to have default as who know what yields there would even be?

 

[Nightinggale]

If we ever made the yields as dynamic as Night talks about then we wouldn't be able to have default as who know what yields there would even be?

Isn't it the plan to make yields controlled by XML

Right now yields are hardcoded in the DLL, which mean we have one DLL file for each mod. If we break free of the hardcoding, we would end up with one DLL, which fits all mods.

To answer the defaults: we add a bool to XML telling "this is hammers, this is crosses" etc and then we assert if one of the categories is missing. If the order is hardcoded (as in must fit enum order), then it will assert if the order fails.

Maybe we could (like we talked about civs and native state) split a single hardcoded yield into multiple functions and allow XML to set those functions. Some yields count like half crosses for immigration. Which yields do that could be set in XML.

We have plenty of options, but whatever we do, we have to think carefully because yield performance is crucial to game performance. If we want to do something with yields and can't figure out an efficient cache for it, we can't do it for performance reasons.

 

[Lib.Spi't]

No I think the point that Kail was making was we have to have hard coded effects connected to these combo yields.

The idea that Yield culture expands borders, the expand borders part has to be hard coded.

The good news is that with theses new combo yields, (If it gets set up) is that we can set what quantity of yields in what combinations make culture.

So I think orlanth was missing the idea that we (would be able to) set what makes culture yields in xml, as in 1 clolth and 1 cheese makes a culture. What you decide to call your 'border expanding yield that uses the civ4 culture mechanic' is up to you, and how you make it (how late production starts and how much effort it takes) is also an xml decision.

Same with the other combo yields. their effects are determined in the sdk. Their ingredients (would be) determined in the xml.

 

[Nightinggale]

So I think orlanth was missing the idea that we (would be able to) set what makes culture yields in xml, as in 1 clolth and 1 cheese makes a culture.

Right. I actually didn't think of that.

I have plans for profession input and output. First of all I plan on storing the yields in InfoArrays. This mean we can set a bool array with any number of yields for input and output. Usually zero or one, but the plan will allow 5 input yields should the XML modder decide to make that.

Another addition is iOutputMultiplier. The idea is that every time the profession takes one of each of the input yields, it produces iOutputMultiplier of each of the output yields. If it set to 3, then we can convert 1 luxury food into 3 food (that would actually be an interesting idea for emergency food supply).

If iOutputMultiplier is negative, it takes X number of input yields to produce a single output yield, like -3 will result in 3 ore to one super tool.

It will be a really flexible system to set up in XML, but it will not help to solve the issues regarding hardcoded virtual yields.

 

[Lib.Spi't]

that sounds pretty cool, for WHM I often think about the idea of a supermarket style building that takes a processed food like lux food and converts it back into normal food at like a 1 to 3 ratio (or whatever), so by processing the food you increase total amount.

well, hopefully if we set up this combo yeld production system in the xml, we can have 'virtual game mechanic yields' like proseprity which is always what gives you immigrant power, and then virtual production yields that are just normal (future xml style) yields and are no different to cheese or cloth (except that they are not stored in a warehouse) which can be fed into anything, including the hardcoded 'mechanic' yields.

This way those mechanic yields can be influenced any way we want, border growth could come from knowledge, or grape production, it is up to the modder what feeds it.

 

[Kailric]

Yeah, my idea is we can take each individual mechanic that is influenced by Yields and create a Global Variable for it, and set to -1 (or NO_YIELD). Like, BORDER_YIELD, IMMIGRATION_YIELD, etc then these yields are defined in the XML at game creation. They can also be a combination of Yields as well, and perhaps be a combination of each other if need be. If left as -1 it could assert, but we could also make it so that if the Yield is -1 then that mechanic isn't used, like if a mod didn't want immigration leave it at -1 and even the Immigration Screen isn't accessible. Of course the AI would have to know that Food production is most important for Citizens then.

 

[Kailric]

moved this post to a better thread

 

[Fullerene]

I was thinking how loyalty system in Colonization could model feudal system of medieval era:

All the units have individual loyalty meter/percentage.

One of the empires units is King

King must be nobleman.

All other units are loyal to either directly to the king or another noble unit.

Noble units may have titles like duke, count or prince or baron etc.

When unit operates as "statesman" (I just can't remember the correct title used in M:C just now), he spreads the loyalty of his master.


Then it's up to imagination how to use this kind of system for game play, here are some thoughts:

If unit is on same tile than his master units, it has better combat odds (morale).

If unit works in same city than master, it has small production bonus.

Unit that swears loyalty to the foreign king (for example in conquered city) may refuse to wear arms or have reduced production. And he may just flip sides during combat.

If the king happens to die (in battle, most likely) you need to appoint new king.

When new king is appointed, or sometimes "just for fun", other nobleman may try to claim the crown. Then units that are loyal to that opportunistic nobleman, may turn against you.

It may seem that it would be best to have all units directly loyal to the king, but maybe the production bonuses could be important enough to have the nobility? Since king can only be located at one town at time.



Just an idea.