Caveman 2 Cosmos (ideas/discussions thread)

[raxo2222]

I am curious, why were the free plant resources removed from Svalbard Global Seed Vault wonder?

I kind of need them to make a super capital as otherwise I lack the tiles. I was able to grab them from older revision to copy-paste into my local copy so damage mitigated though.

You don't need those plants, as all those plant related buildings have megabuilding replacements.
Also it wasn't realistic - that world wonder only stores seeds, not produces resources.

 

[Toffer90]

Pretty jarring that this says Revolt %/Turn: 0.21%

The % after the value (0.21) makes it obvious what unit revolt is given in.
Revolt/Turn: 0.21%
Alternative:
Revolt chance per turn: 0.21%

 

[Blazenclaw]

Revolt chance per turn: 0.21%

I originally did that, but it sticks out quite a bit (# of characters). Revolt/Turn is technically a bit less clear in my eyes? Idk, you can change if you want, I don't have strong opinion on it.

 

[Thunderbrd]

I originally did that, but it sticks out quite a bit (# of characters). Revolt/Turn is technically a bit less clear in my eyes? Idk, you can change if you want, I don't have strong opinion on it.

Fascinating discussion tbh as I can see all 3 as having pros and cons and it just depends on what we think is more important, clarity or brevity. I think I lean more towards the clarity being more important than the brevity and what's really weird is that the 'Revolt Chance/Turn: x%' IS much more clear to me than 'Revolt/Turn: 0.21%', which just rubs me like 'am I misinterpreting something here?' which causes me to pause to think longer as I see it, therefore being a little disruptive for trying to be minimal, but 'Revolt Chance per turn: x%' is indeed a touch obtrusive.

Funny the stuff we care about huh?

 

[makotech222]

@Toffer90 Nice to see you still working here Might as well throw a suggestion your way. For the city build list, it would be nice to add a toggle in the options to re-order buildings after adding to queue. Currently, it just leaves an empty square and you need to move your mouse over to click on the next building. Would be nice to just fill in empty square automatically, basically.

Would also appreciate a hotkey to add all available buildings to queue.

 

[Somebody613]

@Toffer90 Nice to see you still working here Might as well throw a suggestion your way. For the city build list, it would be nice to add a toggle in the options to re-order buildings after adding to queue. Currently, it just leaves an empty square and you need to move your mouse over to click on the next building. Would be nice to just fill in empty square automatically, basically.

Would also appreciate a hotkey to add all available buildings to queue.

That's how it originally used to work, lol - back when it was still in the Vanilla format at the bottom of the city screen.
The problem is that it starts LAGGING heavily between clicks, if you want to add LONG lists.
Technically, though, I guess it WOULD be a good "step back", probably.
Or at least a good graphical option to have to choose from.
I approve.

 

[makotech222]

i hacked the refreshing into my own build and it doesn't have any performance issues. I was originally involved in moving from the old buildable list into the new UI element lol.

 

[Blazenclaw]

i hacked the refreshing into my own build and it doesn't have any performance issues. I was originally involved in moving from the old buildable list into the new UI element lol.

Did you see the inverse, why it refreshes by default on a certain subset of buildings? I never got around to looking myself/asking toffer why it does that, or if it was required.

 

[Somebody613]

i hacked the refreshing into my own build and it doesn't have any performance issues. I was originally involved in moving from the old buildable list into the new UI element lol.

So maybe it WOULD be a good idea to revert this?
People, come on - OPINIONS?

 

[makotech222]

Did you see the inverse, why it refreshes by default on a certain subset of buildings? I never got around to looking myself/asking toffer why it does that, or if it was required.

Its designed to refresh if a unique building is clicked, or something that can have an effect on whether other buildings could be built. For example, if you have 3 mutually exclusive wonders, clicking one will refresh the list and remove the other 2.

 

[Somebody613]

Its designed to refresh if a unique building is clicked, or something that can have an effect on whether other buildings could be built. For example, if you have 3 mutually exclusive wonders, clicking one will refresh the list and remove the other 2.

It reacts to "religious buildings", though, including for some weird reason Sacrificial Altar, which aren't mutually exclusive with anything, no?
Anyways, can we get something like a vote thread for "should we revert to auto refresh like before, at least as an option"?
It was quite useful for clicking long lists, lol.
And for quick speeds, it makes sense to put quite long lists in NEW cities - and "macros"... well, don't work as well as they should.

 

[Blazenclaw]

Anyways, can we get something like a vote thread for "should we revert to auto refresh like before, at least as an option"?

Not really big enough for a vote thread probs. Would probably be a checkbox in the options for the build menu edit: whether to refresh all or none, if nonrefresh isn't really annoying to implement.

 

[Somebody613]

Not really big enough for a vote thread probs. Would probably be a checkbox in the options for the build menu, /if/ nonrefresh isn't really annoying to implement.

Wut? It's already non-refresh for most buildings, except [Group Wonders] and [religious buildings]. My request is to (optionally) make ALL buildings REFRESH, lol.

 

[pi4t]

Is it possible to change the formula for inflation easily? As things stand, I don't think it's a very good mechanic at all. I posted my concerns on the discord, but I'll repeat them here as they motivate the suggestion I'm about to make.

Personally, I'm of the opinion that inflation shouldn't be a thing, or at least shouldn't work the way it does. As it is, it effectively acts as a hard cap on the number of things you can hurry per N turns, no matter how much gold you're generating. If you go above that, your gold generation will permanently decrease until you repay the "debt" by spending turns without hurrying anything. Which means that rather than hurrying being a reward for having a lot of gold generation, it's just a "free building" button you can click every so often assuming you remember.

Basically, it doesn't matter whether I'm generating 100 gold per turn surplus (before inflation) or 1000 gold per turn - the optimal way to hurry things is to hurry one building, then wait for the inflation to go back to 0, then hurry another, etc. If you hurry any more often than that, then your inflation will go up, very rapidly. At this point you'd have two options: keep going, hurrying buildings as soon as the inflation drops enough that you can afford to, or let the economy recover by not hurrying anything until inflation is back under control. With either option, in the long term you don't end up hurrying things any faster than if you'd kept inflation low in the first place, and you lose a whole bunch of gold.

This is a pity, because hurrying things is an obvious way to spend surplus gold you might be generating, and it becomes available just as you're finishing the early economy-draining expansion period. I often seem to end up with large amounts of extra gold hanging around, with nothing to spend it on. (I suspect that's partly a result of my game settings, but in a mod with as many moving parts as C2C it's bound to happen from time to time whatever settings you choose...) Hurrying has the potential to be a correcting option when this happens, much like how you can build science/gold/culture if you have a surplus of hammers. But at present, it...isn't.

I suggest that instead, if it's possible to code this, the consequences of a given use of hurrying should last a fixed number of turns, no matter how much more things you hurry in the meantime. But while you're still feeling the effects of that first hurry, any future hurries will quadratically increase the inflation generated. So, picking some plausible-sounding numbers, the formula could be something like:

I=n^2

where I is the total inflation this turn, and n is the number of times you pressed the hurry button within the last (say) 5 turns. This is scaled off a (hypothetical) gamespeed in which inflation currently increases by 1 every time you hurry, and decreases by 1 whenever you spend 10 turns without hurrying anything.

Let's see what this would look like in action. In all these calculations, when I talk about the total cost I'm ignoring the gold spent by clicking the hurry button, as that's the same in both cases.

Case 1: I hurry one wonder, and nothing else for the next 10 turns. Under the current system, inflation goes up by 1 for 10 turns, costing a total of 10 gold. Under the proposed system, inflation goes up by 1 for 5 turns, costing a total of 5 gold. In both cases, inflation is negligible compared to the direct cost of rushing.
Case 2: I get invaded, and need an army urgently, so I hurry 20 units in one turn. I then hurry nothing for the next 200 turns. Under the current system, my inflation goes up to 20, then gradually decreases over the next 200 turns. Using the triangle number formula, the total cost is 10* 20*19/2, or 1900 gold. With the proposed system, my inflation will be 400 for 5 turns, for a total of 2000 gold. Very closely comparable costs.
Case 3: I have a 200gpt surplus I want to turn into production long-term. Under the current system, I am simply unable to do this, as discussed - it doesn't matter how big my surplus is, I will only be hurrying one item every 10 turns in the long term. If I do things correctly, I will also keep 199gpt of the budget surplus. Under the proposed system, I hurry 14 items, causing my inflation to increase to 196 per turn. I then wait 5 turns for it to go away, and hurry another 14 items, and so on. Overall, I end up hurrying 2.8 items per turn, and using the whole budget surplus.
Case 4: I have somehow managed to generate 2000gp per turn I want to turn into production. Under the current system, I again end up hurrying one item every 10 turns. Under the proposed system, I can rush about 44 items every 5 turns, giving me a hurrying rate of 8.8 items per turn. This is a significant advantage which will probably see me pull ahead of my opponents, but isn't too ludicrous.


One criticism I can see of this formula is that it's very abrupt - you go from (say) 400 inflation down to 0 in a single turn. However, this can easily be corrected by modifying the formula; for example:

I=(n_0 + 4n_1 /5 + 3n_2 /5 + 2n_3 /5 + n_4 /5)^2
where n_0 is the number of hurries you did this turn, n_1 is the number you did last turn, n_2 the number you did two turns ago, etc.


Thoughts?

 

[Blazenclaw]

Is it possible to change the formula for inflation easily?

Toffer was the one who wrote the current implementation. I don't really wanna get sucked into this right now, but the meat of the current code is this:

Spoiler Code if you wanna read :

int CvPlayer::getInflationMod10000() const
{
    int iInflationPerTurnTimes10000 = 100 * getHurriedCount();

    iInflationPerTurnTimes10000 *= GC.getHandicapInfo(getHandicapType()).getInflationPercent();
    iInflationPerTurnTimes10000 /= 100;

    int iMod = (
        m_iInflationModifier
        + getCivicInflation()
        + getProjectInflation()
        + getTechInflation()
        + getBuildingInflation()
        - 100 * isRebel()
    );

    if (iMod != 0)
    {
        iInflationPerTurnTimes10000 = getModifiedIntValue(iInflationPerTurnTimes10000, iMod);
    }

    if (isNormalAI())
    {
        iMod = (
            GC.getHandicapInfo(GC.getGame().getHandicapType()).getAIInflationPercent() - 100
            +
            GC.getHandicapInfo(GC.getGame().getHandicapType()).getAIPerEraModifier() * getCurrentEra()
        );
        if (iMod != 0)
        {
            iInflationPerTurnTimes10000 = getModifiedIntValue(iInflationPerTurnTimes10000, iMod);
        }
    }
    return 10000 + iInflationPerTurnTimes10000;
}

void CvPlayer::doAdvancedEconomy()
{
    PROFILE_FUNC();

    if (getHurriedCount() > 0)
    {
        int iTurnIncrement1000 = GC.getHURRY_INFLATION_DECAY_RATE() * GC.getGameSpeedInfo(GC.getGame().getGameSpeedType()).getSpeedPercent();
        iTurnIncrement1000 = getModifiedIntValue(iTurnIncrement1000, getHurryInflationModifier());

        if (GC.getGame().getElapsedGameTurns() % std::max(1, iTurnIncrement1000 / 1000) == 0)
        {
            changeHurriedCount(-1);
        }
    }
}

At this point you'd have two options: keep going, hurrying buildings as soon as the inflation drops enough that you can afford to, or let the economy recover by not hurrying anything until inflation is back under control. With either option, in the long term you don't end up hurrying things any faster than if you'd kept inflation low in the first place, and you lose a whole bunch of gold.

Maybe something like letting inflation decrease faster the higher it is would be sensical? That could also allow for inflation to decrease slightly even if you've hurried e.g. one thing this turn, because you've hurried 10 things last turn. You'd essentially want to reach some sort of equilibrium with buildings hurried per turn that the eco can afford. I'd also be a proponent of making the gold->hammer conversion even more expensive as hammers go up, but really there just needs something to be done about gold going crazy as the game goes on, heh.

 

[JosEPh_II]

I'd also be a proponent of making the gold->hammer conversion even more expensive as hammers go up, but really there just needs something to be done about gold going crazy as the game goes on, heh.

When I restricted Gold and other things in Preh Era by Civics to get players and AI off the Default start civics, the back lash was fierce. But I stood my ground.

When I can get several games into the Ren Era and beyond I will tighten up the Civics from those Eras. The last real changes I did was in Classical and Medieval eras. And that was over a year or so ago. I have a short list of Civic changes I need to get into the mod soon. Being it's winter here I have had a bit of time to play test.

The Culture changes have also affected Civic choice(s) and when to change as well.

I'm running an Ultra GS game right now on a Cutom Continent map where each player gets their own Continent to start on. Therefore almost no trade interaction during Prehistoric Era (except for the rare chance 1 continent is in raft/canoe distant of another by a lucky island set between them). Bu mid Ancient contact begins to heat up. You quickly find out who the tech leaders and best start positioned players are. (I should have used Ultra GS more often, instead of Normal and the occassional Bliyz GS games)

 

[Toffer90]

I suggest that instead, if it's possible to code this, the consequences of a given use of hurrying should last a fixed number of turns, no matter how much more things you hurry in the meantime.

That's how it works already.

But while you're still feeling the effects of that first hurry, any future hurries will quadratically increase the inflation generated. So, picking some plausible-sounding numbers, the formula could be something like:

I=n^2

Do you really want more punishing inflation?

 

[Toffer90]

Maybe something like letting inflation decrease faster the higher it is would be sensical? That could also allow for inflation to decrease slightly even if you've hurried e.g. one thing this turn, because you've hurried 10 things last turn. You'd essentially want to reach some sort of equilibrium with buildings hurried per turn that the eco can afford. I'd also be a proponent of making the gold->hammer conversion even more expensive as hammers go up, but really there just needs something to be done about gold going crazy as the game goes on, heh.

That would motivate the player to hurry as much as possible as inflation will drop faster the higher it is, so it is advantageous to get it as high as possible, i.e. that's when you are the most effective and get the least amount of inflation problem per hurry action. Don't think its a good idea considering the added complexity for such a small tangible return.

Current inflation system is very basic, I too want the gold amount spent to influence the inflation amount, though it's a bit of work to transform it from the current simple scheme to that more code/math intensive dynamic scheme. It's on my toDo list, but there's a lot of other things I will prioritize before getting to it.

 

[pi4t]

That's how it works already.
Do you really want more punishing inflation?

That's incorrect. I hurried a ton of things a hundred turns ago, and my inflation is still high and only gradually decreasing. In the code that Blazenclaw quoted, you can see that the HurriedCount drops by 1 every N turns, where N depends on the game speed. This means that if you hurry 30 things in one turn, and then hurry one thing every N turns, the HurriedCount will always remain at 30-31. I am proposing that HurriedCount become a count of how many things you've hurried in the last N turns, so if you do what I describe above the HurriedCount will drop to 0-1 after the first N turns. We then change how HurriedCount affects inflation to account for the fact that it lasts less time.

The overall effect is that inflation becomes less punishing with my proposal. If you hurry a bunch of stuff in one turn, and then do no more hurrying, then inflation will cost you about the same amount of gold overall as it currently does (although it will all be paid in a big chunk in the first few turns). If you hurry whenever you can afford the inflation, then it costs you much less. Which is good, because "hurry whenever you can afford the inflation" is currently strictly worse than "only hurry when your inflation has died away".

 

[Toffer90]

That's incorrect. I hurried a ton of things a hundred turns ago, and my inflation is still high and only gradually decreasing.

Indeed, that is what I interpreted that you suggested it should do.

I suggest that instead, if it's possible to code this, the consequences of a given use of hurrying should last a fixed number of turns, no matter how much more things you hurry in the meantime.

Each and every given hurry action gives inflation that lasts a fixed amount of turns, the amount of turns per hurry is based on gamespeed.
.

Edit: I guess I have to go back and reread what you said, was probably too tired to interpret it correctly.