Caveman 2 Cosmos

Without labeling the numbers more clearly I can't follow what you're tracking.
I mean the individual progress for each type of GP that can be accessed in WB. I learn from source code that it's a different thing that doesn't add up together as GP points.
 

Attachments

  • 2019-05-03 (1).png
    2019-05-03 (1).png
    4.9 MB · Views: 116
Latest SVN, Playing Complex Traits with developing leader and start with no positive traits, having selected Progressive, Medical, and Negotiator, I found myself in trouble getting different great people other than doctors.
I got my first GP doctor at turn 218 in prehistoric era thanks to free specialists from Progressive. After ranking up to have Medical, I got 5 doctors at turns 308, 345, 375, 401, and 423, to trigger GAs spanning 49 turns in total, before entering classical era at turn 443. For the upcoming GP I have focused on prophets from the beginning, and with State Church civic, I can have 20+ prophets in this city each turn. However, the probability of getting the great prophet versus doctor is still 1 to 19. I don't get it. The Medical trait only contributes +2 doctor points, and while sometimes the governor appoints one doctor (1 max), that is mere 5 points for a great doctor, versus more than 60 for a prophet. I have this snapshot just to show the 5%-95% probability breakup.

In another game, having chosen Spiritual early gave me an unstoppable streak of great prophets and created an ever-lasting GA. I did avoid choosing civics that grant unlimited prophets (Divine Cult, State Church), but rather chose Caste System so all my cities focused on engineer specialists. Still never did a great engineer come out. Would there be anything wrong with the free GP points given by the Complex Traits? Just assuming. I know nothing about modding, in particular how these trait-attributes are defined, probably in an XML that is accessible?

Now that you mention it, I've noticed a similar thing. After my faulty report regarding the intersection of Divine Prophets and Limited Religions (Divine Prophets prevents the automatic founding of a religion upon researching the tech, while Limited Religions prevents you from receiving the free great prophet from Divine Prophets), I changed all the specialists in my cities (or at least the major ones that might produce a great person) to priests. But it seems stuck at 99% engineer, 1% prophet, and various 0% other things. The first time, I chalked it up to being too late with the switch and and that the contribution to Great Prophet progress didn't accumulate enough to alter the chance. Likewise with the next city (a different one) remained at 99% (despite about a dozen priest specialists) even though it took some turns before it spawned its great engineer. As it is now building progress toward a third Great Person, all cities remain at 99% engineer and 1% prophet, so I was starting to get suspicious.

Without labeling the numbers more clearly I can't follow what you're tracking.

I think what he's saying is that a Great Doctor spawned, on the next turn - despite 0 doctor specialists in the city - he accumulated 1808 great doctor "progress" toward the next GP. Meanwhile, the same city having 30 priests, accumulated only 89 "progress" toward a great prophet. So the Great Doctor progress is vastly outpacing the Great Prophet progress, despite 0 doctors and 30 priests.

I should double check whether any of my traits are contribution Great Engineer points.

Edit: Yes, I have Industrious, which contributes +2 Great Engineer in each city, just as Ang's post has Medical, which contributes +2 Great Doctor, and later Spiritual, which is +2 Great Prophet. Seems likely that the great person points from Complex Traits is being multiplied or otherwise contributing more than it should.
 
Last edited:
Now that you mention it, I've noticed a similar thing. After my faulty report regarding the intersection of Divine Prophets and Limited Religions (Divine Prophets prevents the automatic founding of a religion upon researching the tech, while Limited Religions prevents you from receiving the free great prophet from Divine Prophets), I changed all the specialists in my cities (or at least the major ones that might produce a great person) to priests. But it seems stuck at 99% engineer, 1% prophet, and various 0% other things. The first time, I chalked it up to being too late with the switch and and that the contribution to Great Prophet progress didn't accumulate enough to alter the chance. Likewise with the next city (a different one) remained at 99% (despite about a dozen priest specialists) even though it took some turns before it spawned its great engineer. As it is now building progress toward a third Great Person, all cities remain at 99% engineer and 1% prophet, so I was starting to get suspicious.



I think what he's saying is that a Great Doctor spawned, on the next turn - despite 0 doctor specialists in the city - he accumulated 1808 great doctor "progress" toward the next GP. Meanwhile, the same city having 30 priests, accumulated only 89 "progress" toward a great prophet. So the Great Doctor progress is vastly outpacing the Great Prophet progress, despite 0 doctors and 30 priests.

I should double check whether any of my traits are contribution Great Engineer points.

Edit: Yes, I have Industrious, which contributes +2 Great Engineer in each city, just as Ang's post has Medical, which contributes +2 Great Doctor, and later Spiritual, which is +2 Great Prophet. Seems likely that the great person points from Complex Traits is being multiplied or otherwise contributing more than it should.
I think some civics/wonders/buildings also produce GP points by themselves or give free specialists too.
 
But it is a recent problem, where as free specialists (and their GP) and GP from buildings have existed for a long time without overwhelming the great person pool. I wouldn't have suspected great points from traits necessarily, but it is also highly convenient that the excessive GP pool/balance (I don't think it is affecting actual GP rates) matches the GP gained from the traits. In addition, while I have received a few non-engineer GP in my game, and I bet they were all from before I adopted Industrious as a trait.
 
So how strong building and wonder modifiers influence should be compared to civic/trait/property pseudobuilding modifier influence?
So if latter is +50% total, then former can be +200%?
I can't even imagine trying to establish an acceptable ratio. How many buildings can give a +% modifier to research? How many traits can a player have that would? How many civics? I'm sure you can get a lot more from buildings than you can from either civics or traits, partially because there is no limit to how many buildings you can build, outside of the limit of what has been made available to build.

I think trying to compare the three is a pointless measurement to look at. It is much more important to look at making sure progressions on buildings are not only as gradual as they really can be, with some understanding for some buildings being intended to be impressive and thus curve breaking, constantly improving throughout tech advances, and not too abnormally overpowering.

Balance each of those noted sources independently - they don't have to compare directly to each other but rather to the other options among their category. Civics should be balanced against other civics, traits against other traits, buildings against other buildings, with some expectation that with greater technology comes improvements over the earlier things.
 
Seems likely that the great person points from Complex Traits is being multiplied or otherwise contributing more than it should.
That's what it's sounding like. Not sure how that's taking place but I'll look for it. An extra source of +2 in each city should't be too overwhelming.
 
@Niveras, @Thunderbrd,

Two observations:
1. Recalculating by Ctrl-Shift-T is helpful, it resets the great person rate for doctor back to 2.
2. Triggering leader trait recalculation by Alt-Z switching leader and Shift-Alt-Z switching back does NOT help.

I assume that cities store their great people rate for each type, and do only increments and decrements on them, thus when the stored values go wrong, a recalc helps.

From reading the source code, I learn that recalculateModifiers() basically clears some cached data, resetting the GP rates for instance; then, cities recalculate the GP rates values from own buildings and specialists. I find two methods CvCity:: processBuilding and CvCity:: processSpecialist are the only ones to modify the GP rates property. These codes are never changed. And these two are rather simple, to just modify (add or subtract) the GP rate by the number defined for the building or specialist passed in as argument, nothing else. So it is either the data fed from XML got changed, or that other uses of these two "process" functions cause the problem.

The XML data of buildings that modify great person rates are seldom changed, and my last game started in SVN 10564, which was the latest. So now I'm trying to spot the smoking gun among the many functions that call CvCity:: processBuilding and CvCity:: processSpecialist.
 
Last edited:
For the Farm - Crop and Camp series of buildings, what if the +1 :gold: is replaced with another :food:? This would help reduce a bit of the gold in the game and the extra food would help with the slower growth curve.
 
@Niveras, @Thunderbrd,

Two observations:
1. Recalculating by Ctrl-Shift-T is helpful, it resets the great person rate for doctor back to 2.
2. Triggering leader trait recalculation by Alt-Z switching leader and Shift-Alt-Z switching back does NOT help.

I assume that cities store their great people rate for each type, and do only increments and decrements on them, thus when the stored values go wrong, a recalc helps.

From reading the source code, I learn that recalculateModifiers() basically clears some cached data, resetting the GP rates for instance; then, cities recalculate the GP rates values from own buildings and specialists. I find two methods CvCity:: processBuilding and CvCity:: processSpecialist are the only ones to modify the GP rates property. These codes are never changed. And these two are rather simple, to just modify (add or subtract) the GP rate by the number defined for the building or specialist passed in as argument, nothing else. So it is either the data fed from XML got changed, or that other uses of these two "process" functions cause the problem.

The XML data of buildings that modify great person rates are seldom changed, and my last game started in SVN 10564, which was the latest. So now I'm trying to spot the smoking gun among the many functions that call CvCity:: processBuilding and CvCity:: processSpecialist.
Good analysis. That's where I would look first as well and I'd be a little confused by finding what you have found.

The data from the XML is very unlikely to have changed and the recalculation pulling on that to correct things suggests this is not suspect.
Uses of the process function may not be the issue either.

Found it - and fixed another small bug in the process that wouldn't allow no GP to be defined and still have an impact - I believe I programmed the XML to have a +GP pts without any GP type definition on one occasion somewhere.

Here's the issue:
Code:
int CvCity::getGreatPeopleUnitRate(UnitTypes eIndex) const                                                                 
{
    FAssertMsg(eIndex >= 0, "eIndex expected to be >= 0");
    FAssertMsg(eIndex < GC.getNumUnitInfos(), "eIndex expected to be < GC.getNumUnitInfos()");
    int iTotalGreatPeopleUnitRate = 0;
    iTotalGreatPeopleUnitRate += m_paiGreatPeopleUnitRate[eIndex];
    iTotalGreatPeopleUnitRate += GET_PLAYER(getOwnerINLINE()).getNationalGreatPeopleUnitRate(eIndex);
    return std::max(0, iTotalGreatPeopleUnitRate);
}


void CvCity::setGreatPeopleUnitRate(UnitTypes eIndex, int iNewValue)                                         
{
    FAssertMsg(eIndex >= 0, "eIndex expected to be >= 0");
    FAssertMsg(eIndex < GC.getNumUnitInfos(), "eIndex expected to be < GC.getNumUnitInfos()");
    if (GC.getGameINLINE().isOption(GAMEOPTION_NO_ESPIONAGE) && GC.getUnitInfo(eIndex).getEspionagePoints() > 0)
    {
        return;
    }

    m_paiGreatPeopleUnitRate[eIndex] = iNewValue;
    FAssert(getGreatPeopleUnitRate(eIndex) >= 0);
}


void CvCity::changeGreatPeopleUnitRate(UnitTypes eIndex, int iChange)                                     
{
    setGreatPeopleUnitRate(eIndex, (getGreatPeopleUnitRate(eIndex) + iChange));
}
This will be fixed on the SVN so I'm not explaining this to anyone to debug it for themselves but just for the sake of discussion.

getGreatPeopleUnitRate adds both the city's native GP pt rate (accumulated by local effects like buildings and specialists) to the national level rate that applies to all cities (iTotalGreatPeopleUnitRate += GET_PLAYER(getOwnerINLINE()).getNationalGreatPeopleUnitRate(eIndex);)

On it's face this seems fine BUT when the changeGreatPeopleUnitRate (which is often called whenever a specialist is assigned or unassigned or a building with a gp rate is added or removed) is called, it calls setGreatPeopleUnitRate, adding the change intended to the local rate to the total city rate. The TOTAL city rate, which also includes the National rate. Thus the national rate and flavoring gets added each time a change is made. The more the player adjusted things, the worse it got.

The fix is to simply change this line in changeGreatPeopleUnitRate:
setGreatPeopleUnitRate(eIndex, (getGreatPeopleUnitRate(eIndex) + iChange));
to
setGreatPeopleUnitRate(eIndex, (m_paiGreatPeopleUnitRate[eIndex] + iChange));

Thereby only tallying into the local city variable local city sources and not continuously compiling in the additional player level amount with each change call.


eek! That's a tough one to spot!
 
  • Like
Reactions: Anq
For the Farm - Crop and Camp series of buildings, what if the +1 :gold: is replaced with another :food:? This would help reduce a bit of the gold in the game and the extra food would help with the slower growth curve.
I would support that, particularly now that food is more challenging.

@JosEPh_II

I refer this comment to you because you're working on civics. You may want to consider how some civics represent the application of subsidies and we here in the States know well that a lot of budget goes towards farm subsidy programs. Do we have a tag that can adjust the output of a building by a civic selection? Could a farm subsidy make 'farm' buildings -1 gold but maybe an additional +1 food? If we can't do it directly, I bet an autobuilding generated by the civic for the capital could do it with some of the global tags that I know wonders use.

There could be a lot of other ways to curb gold like this throughout the civic designs. Much of civics is about how and where things are being budgeted so it seems to be a good place to hit players with this stuff, and since civics also can represent improved ways to process wealth and be a big reason for gold suddenly being very forgiving, its another cause to find gold balancing measures from within civic structures - one civic may be strongly penalizing in gold but worthwhile if you've taken another one that opens up around the same time that makes it affordable to use.

Just thoughts - trying to be helpful.
 
Last edited:
On it's face this seems fine BUT when the changeGreatPeopleUnitRate (which is often called whenever a specialist is assigned or unassigned or a building with a gp rate is added or removed) is called, it calls setGreatPeopleUnitRate, adding the change intended to the local rate to the total city rate. The TOTAL city rate, which also includes the National rate. Thus the national rate and flavoring gets added each time a change is made. The more the player adjusted things, the worse it got.

Great find! Thanks for the explanation, so for instance, if I have national +2 from spiritual and call Change(Priest, +3), it brings up Set, and then Get, but the Get is no faithful representation of the variable, it mutates it in the process! The national modifier shouldn't have been counted toward a local city variable!

The fix is to simply change this line in changeGreatPeopleUnitRate:
setGreatPeopleUnitRate(eIndex, (getGreatPeopleUnitRate(eIndex) + iChange));
to
setGreatPeopleUnitRate(eIndex, (m_paiGreatPeopleUnitRate[eIndex] + iChange));

Regarding the fix, I think your fix is very correct to the general get-set grammar. Here, I suppose the Get method be fixed too:
int CvCity::getGreatPeopleUnitRate(UnitTypes eIndex) const
{
FAssertMsg(eIndex >= 0, "eIndex expected to be >= 0");
FAssertMsg(eIndex < GC.getNumUnitInfos(), "eIndex expected to be < GC.getNumUnitInfos()");
return m_paiGreatPeopleUnitRate[eIndex];
}

Instead of spicing the return value, just do what a get means to do, fetch the variable.

Then, the intended functionality can be added back in one line in CvCity:: doGreatPeople
Search getGreatPeopleUnitRate, find it where it used to be -
for (int iI = 0; iI < GC.getNumUnitInfos(); iI++)
{
changeGreatPeopleUnitProgress(((UnitTypes)iI), getGreatPeopleUnitRate((UnitTypes)iI));
}

- and add the national modifier here: (The former code takes eIndex, here we adapt it to take iI.)
for (int iI = 0; iI < GC.getNumUnitInfos(); iI++)
{
changeGreatPeopleUnitProgress(((UnitTypes)iI), getGreatPeopleUnitRate((UnitTypes)iI) + GET_PLAYER(getOwnerINLINE()).getNationalGreatPeopleUnitRate((UnitTypes)iI));
}

And that's all done. :goodjob: Thanks again for sharing details and explaining!
 
Last edited:
There are many buildings that give GP points but don't specify what GP they go to. This should be fine from the building perspective. It should just be possible to give general points without limiting them to a particular GP. They provide points towards the total needed but are not part of the equation when choosing which GP is generated. The specific GP points are used to randomly create a GP based on the percentages of specified GP points. After the GP is created the counts go back to zero.

Hopefully this is not changing.
 
The traits that don't specify a GP unit type are the Philosophical, and its opposite, the Populist.

@Thunderbrd,

For such a trait as Philosophical, which adds a plain GP point bonus but does not specify any GP unit class, the getGreatPeopleUnitClass() will return NO_UNITCLASS.
The previous code seems to handle NO_UNITCLASS (but doesn't resolve.) As with the new code (rev. 10566), this guard is gone, but for Philosophical, it's simply passing NO_UNITCLASS into changeNationalGreatPeopleUnitRate(), which it doesn't expect to see.

There needs to be a Base (general, gross) GP rate in CvPlayer, as in CvCity, to keep track of such modifier, and some more code to use it.

But the real question is - on the extreme, one city in an early era may not have any specialist at all. Should a city start to accumulate GP points even though it doesn't mean to?

Further, as we save just enough general GP progress to warrant one, how does it determine which GP we get, just randomly? On the other hand, it also possibly enables a crooked strategy: while the general GP points accumulate, we don't appoint a specialist or build particular buildings until we are about to max the gross GP progress. The next turn, we have exactly the type of GP we wanted.

The solution is to, in addition to the general bonus, spread it out evenly, toward every type of GP, while we don't have to divide the bonus into 12 parts - every unit class still receives +2 or so and it's working as normal; more properly, even.

But last question is, how about those later-era GPs, like great statesman, detective, and admiral? Do we want to promote every possible great person from the late game, as early as one can choose a Philosophical trait?

@Dancing Hoskuld ,

As per your opinion, which one is better -
1. spread the points evenly to every great person type.
2. add 0 instead, and if the pool is all zeroes when general GP progress max out, still choose randomly, probabilities equal.

I can think of a case. We appoint a priest (+3) on the last turn before a GP is born. If it is the first way, the pool is already filled very deep and evenly, so a +3 does not bias the result to any degree. If it is the other, then we can effectively get a great prophet, hence the crooked strategy. Is it better to allow such strategy? Or we should tell the player, "reap what you sow."

I read your post again and think that you agree with the first.

========

I don't find any building with GP point that doesn't specify the GP type, so the issue with Philosophical may be new to C2C...
 
Last edited:
I would support that, particularly now that food is more challenging.

@JosEPh_II

I refer this comment to you because you're working on civics. You may want to consider how some civics represent the application of subsidies and we here in the States know well that a lot of budget goes towards farm subsidy programs. Do we have a tag that can adjust the output of a building by a civic selection? Could a farm subsidy make 'farm' buildings -1 gold but maybe an additional +1 food? If we can't do it directly, I bet an autobuilding generated by the civic for the capital could do it with some of the global tags that I know wonders use.
Well there are commerce modifiers in civics, that I changed but then reverted it since you were already taking care of it.
Code:
<BuildingCommerceModifiers>
                <BuildingCommerceModifier>
                    <BuildingType>BUILDING_STATUE_OF_ZEUS</BuildingType>
                    <CommerceModifiers>
                        <iCommerce>0</iCommerce>
                        <iCommerce>20</iCommerce>
                        <iCommerce>0</iCommerce>
                        <iCommerce>0</iCommerce>
                    </CommerceModifiers>
                </BuildingCommerceModifier>
</BuildingCommerceModifiers>

But there aren't building yield modifiers in civics.
That is civics can't adjust :commerce::hammers::food: modifiers in buildings.
 
Great find! Thanks for the explanation, so for instance, if I have national +2 from spiritual and call Change(Priest, +3), it brings up Set, and then Get, but the Get is no faithful representation of the variable, it mutates it in the process! The national modifier shouldn't have been counted toward a local city variable!



Regarding the fix, I think your fix is very correct to the general get-set grammar. Here, I suppose the Get method be fixed too:


Instead of spicing the return value, just do what a get means to do, fetch the variable.

Then, the intended functionality can be added back in one line in CvCity:: doGreatPeople
Search getGreatPeopleUnitRate, find it where it used to be -


- and add the national modifier here: (The former code takes eIndex, here we adapt it to take iI.)


And that's all done. :goodjob: Thanks again for sharing details and explaining!
The difference is about what the get is used in. When it is used in the city help screen parsing, it's easier to have the 'spicing' from the player level data included. Either solution is valid but your approach then adds another step in the text generation. I don't ascribe to the need for the get command to be equivalent to 'give me the local variable only'. Especially within the same document where you can simply call the local variable. The set command should never be calling the get function anyhow, but instead be referencing the local variable, since that is uncorruptable and legally accessible. Get can be then safely used for totals for whatever original purposes it was used for elsewhere in the code.
 
There are many buildings that give GP points but don't specify what GP they go to. This should be fine from the building perspective. It should just be possible to give general points without limiting them to a particular GP. They provide points towards the total needed but are not part of the equation when choosing which GP is generated. The specific GP points are used to randomly create a GP based on the percentages of specified GP points. After the GP is created the counts go back to zero.

Hopefully this is not changing.
Actually I was making another move in support of continued enabling of what you're saying. The offhanded 'bug' was that it was impossible in traits to set a GP pt change without specifying which type that change applied to and I removed that restriction. Without first qualifying with a 'type' definition, any amount used to change the GP rate would be ignored. This only applied to traits - didn't look into how it's set for buildings but that should be working properly there as well since I did look into making sure of that a while back iirc.
 
The solution is to, in addition to the general bonus, spread it out evenly, toward every type of GP, while we don't have to divide the bonus into 12 parts - every unit class still receives +2 or so and it's working as normal; more properly, even.
Disagree. If NO_UNIT or NO_UNITCLASS flavoring (either way it means -1) is found as the only flavoring that's been added by any GP pts, it should randomize evenly between all GP types, sure. There may not be a protection in place for that at the moment. However, it's very unlikely to happen. Otherwise + GP pts unflavored should just be a magnification effect and make it faster to get a GP born but not have any other influence at all on the type likelihood and allow all other sources of flavoring to determine it as if it had just lowered the threshold to get a GP. I don't want 'colorless' GP pts to add chances for GP types that were otherwise unsupported in the birthing process.

AKA, if I didn't add any Artist points, I'd better not have a chance to get an artist just because I had some 'colorless' GP pts added during the process.

Reading onward, I highly prefer option 2. In your example of adding the priest pts at the last minute, yes only a priest should then be possible.

As for Sources of 'colorless' GP, there aren't any buildings that do it right now but there are specialists, the Noble at least being one, maybe the only one.
 
Last edited:
I started a new game with a new SVN version a few days ago, and noticed some odd graphical issues. First, units would often use incorrect models (e.g wild horse showing up as a knight, Neanderthals using human models), sometimes switching between the incorrect and correct models.

Secondly, resources found on hills and peaks are placed flat on top of the terrain, so that it floats over all but the highest point.

I wasn't particularly bothered by this, so I kept playing, but now I'm having a more substantive issue. I have an improved source of turquoise within a city's (workable) vicinity, connected to the city with a path, and a mining camp in the city. Yet, I can't build a turquoise mine. I've been able to do this with other resources like copper and tin. Also, the tooltip says that the turquoise requires a quarry, despite its appropriate building being a mine. I tried building the mine in the city with a quarry and a second time with a mine, just to check, but still nothing.

Are these problems related? What might be going on here?
 
If I recall correctly, turquoise requires stone tool workshop or quarry improvement, and doesn't need a building in your city to be considered connected. Last game I have one turquoise on a mountain peak, and I improve it with my llama worker there (stone tool workshop), and immediately I was able to build "Culture (Guam)". Later, it upgrades itself to an early quarry.

Secondly, resources found on hills and peaks are placed flat on top of the terrain, so that it floats over all but the highest point.
I don't know if it works, but if you open debug menu (Ctrl-D) and there's an option to rebuild terrain. You need to enable cheat (cheatcode=chipotle) though.
It is related with the mapscript you're using, I think.
 
Last edited:
I started a new game with a new SVN version a few days ago, and noticed some odd graphical issues. First, units would often use incorrect models (e.g wild horse showing up as a knight, Neanderthals using human models), sometimes switching between the incorrect and correct models.

Secondly, resources found on hills and peaks are placed flat on top of the terrain, so that it floats over all but the highest point.

I wasn't particularly bothered by this, so I kept playing, but now I'm having a more substantive issue. I have an improved source of turquoise within a city's (workable) vicinity, connected to the city with a path, and a mining camp in the city. Yet, I can't build a turquoise mine. I've been able to do this with other resources like copper and tin. Also, the tooltip says that the turquoise requires a quarry, despite its appropriate building being a mine. I tried building the mine in the city with a quarry and a second time with a mine, just to check, but still nothing.

Are these problems related? What might be going on here?
No, not related. The first is because you are playing with low graphics settings, more specifically, no unit animations (you can get away with low graphics if you make sure to turn this back on). The second is, so far as we know unavoidable but maybe Anq suggested a way to address it, interestingly enough, which may be a key thing to know in establishing multimaps since viewports proved heightmap bugs are an issue with that project. Build the quarry improvement and the mine building, but it has to be improved and connected and inside workable radius to get the building option, which you seem to claim you have. You can usually turn on unbuildable icons and find the one you're trying to build, hover over it, and it may tell you what you still need. Might be a tech? Not sure.
 
Top Bottom