Caveman 2 Cosmos

[raxo2222]

Early Ancient Era, now called Sedentary Lifestyle Era...

Minor nitpick: While Prehistoric/Ancient is now Ancient/Sedentary era internally its still Prehistoric/Ancient era for us.
This was dirty trick to make BTS EXE select Prehistoric era by default (it defaults to ERA_ANCIENT for vanilla and mods without era before Ancient Era)..
That is if you install this mod for first time, or come from other mod, then players doesn't have to change era in map/game option setup screen.

As for gold/research/culture modifiers I reduced gold and research modifiers by 50% and culture modifiers by 75% (some buildings with culture modifiers got partially buffed though).
All bonuses give only +1% to gold/research/culture where it is applicable.
There could be global and tech modifiers, that I halved (quartered culture one).

 

[Esfera]

The "pedantry" of being logical and consistent is actually a 'sine qua non' of rational discussion.

You are actually being both extremely pedantic and wrong.
As someone with expertise in philosophy. This isn't a "rational discussion", this is a discussion over qualia, and thus subjetive.
Any discussion that uses terminology such as "too much" or "too little" (like this one- "there is too much gold"/"there is too little gold") instead of purely measurable elements cannot be rational by definition.
We are ALL appealing to emotions here, so stop the pedrantry because you are too appealing to emotion, and most of the times there is NOTHING wrong with that, as most things are not measurable.

You should try it sometime.

It is ironic that you acuse me of name-calling when you use personal attacks, you know nothing about me since this account is merely a pseudonymic internet persona, so stop the ad hominems because you have nothing to "ad-hominem" to start with.

"Like wholesale unit upgrades, hurries must be saved up for."
This is already a thing ingame, you can't simply go around abusing the rushing mechanic anymore without either a huge inflaction or running out of the gold that took you thousands of turns to save, as we speak, if players want to rush they are forced to save, you are not proposing anything new.
This is not a serious problem since v37, and since v38.1 it isn't a problem at all.
You are extremely wrong about gold and rushing abuse, as their problems were solved in the past

However, this seems like is getting personal and you seem to be getting extremely angry despite I am not being hostile and my criticism is well-intentioned, so this argument is over, this is not the hill I am going to die on, goodbye.

 

[Toffer90]

MAX_DISTANCE_CITY_MAINTENANCE

Which one is this? And where?

It is in GlobalDefines.xml

One could also increase the UNIT_UPGRADE_COST_PER_PRODUCTION which is in that file too. In MToS I changed it from 100% to 150%. Hurry cost is not a 1 to 1 gold/hammer ratio either so why should unit upgrading be.

150% means 1.5 gold per hammer, and unit upgrading only counts the hammer cost difference between two units, so you don't have to pay the entire hammer cost of the unit you are upgrading to.

Hurry production is at 3 gold per hammer.

 

[JosEPh_II]

It is in GlobalDefines.xml

One could also increase the UNIT_UPGRADE_COST_PER_PRODUCTION which is in that file too. In MToS I changed it from 100% to 150%. Hurry cost is not a 1 to 1 gold/hammer ratio either so why should unit upgrading be.

150% means 1.5 gold per hammer, and unit upgrading only counts the hammer cost difference between two units, so you don't have to pay the entire hammer cost of the unit you are upgrading to.

Hurry production is at 3 gold per hammer.

Thanks for the reminder.

Not sure I would take and make upgrade costs higher. As I don't really agree with your reasoning. But it will be a consideration. If other means of gold reduction don't pan out.

 

[Yudishtira]

You are actually being both extremely pedantic and wrong.
This isn't a "rational discussion", this is a discussion over qualia, and thus subjetive.

This is an example of something genuinely both wrong and pedantic. If anyone's interested. But then you've stated your unwillingness to remain rational.

Yes we can agree to disagree on the rest. I don't think either of us has anything more to add.

 

[JosEPh_II]

A couple of screenshots from my current Civic test game in relation to the discussion over too much gold for comparison.
1st screen shot is settings.
2nd is main game screen

You will see that I am researching Patriarchy which will be my 28th Civic option tech researched. My Treasury is 6,541 gold with 490 gold per turn, on Emperor Difficulty, Standard C2C_World, low sea level and very basic game set up Option list. Default number of AI of which I have so far only met 1, Wrub. Crowded maps (many AI) activate more trade and thus more Gold.

Of the 27 Civic choices I have activated 20 of them. 7 are not really usable for me at this stage since I have yet to found a religion and I do not use Banditry Civic until I really have to (and that is rare when I do).

All this to contrast Tajo game set up and his way of play. Perhaps Tajo should give his Settings screenshot and current main screen as a comparison too mine?

EDIT: I have just updated to 10746 from 10712. So PPIO is now active in my game. And these screen shots are after the update.

 

[Yudishtira]

A couple of screenshots from my current Civic test game in relation to the discussion over too much gold for comparison.
1st screen shot is settings.
2nd is main game screen

You will see that I am researching Patriarchy which will be my 28th Civic option tech researched. My Treasury is 6,541 gold with 490 gold per turn, on Emperor Difficulty, Standard C2C_World, low sea level and very basic game set up Option list. Default number of AI of which I have so far only met 1, Wrub. Crowded maps (many AI) activate more trade and thus more Gold.

At 100% research on Emperor you should be under 1000 gold and 10-20 per turn. And you should have un-upgraded units which in your pic you don't.

 

[JosEPh_II]

I guess Tajo does not want to play show and tell with me. Oh well.

 

[raxo2222]

10781

• Reviewed the Info classes' Delayed Resolution usage, and optimized a few based on the premenu loading order.
• Corrected a typo in TB Trait Mod.
• Changed Thunderbrd's Combat Mod structs to use generalized pairs to facilitate code reuse in the parsing code.
• Unindented list tags in DisallowedTraitTypes, EnabledCivilizationTypes, FreeTraitTypes, EnforcesGameOptionOffTypes, EnforcesGameOptionOnTypes, PrereqOrCivics, and PrerecAndCivics tags.
• Revised Property and GameObject systems code a little, mostly to keep const-ness around.

Now that I have learned more about this Delayed Resolution system, I can finally go back to my buildingclass branch to fix the problem.

You should write what happened in SVN 10778, 10779 and 10780 in log, that is write down changes even if it didn't happened in main trunk itself.

 

[Anq]

You should write what happened in SVN 10778, 10779 and 10780 in log, that is write down changes even if it didn't happened in main trunk itself.

Since I have posted, I'm going to quote @billw2015's changes there.

 

[Thunderbrd]

10783

• Fixed some issues in AI_establishStackSeeInvisibleCoverage.

@Thunderbrd
Take a look at my changes that function was not working and causing the slowdown in @Yudishtira's game. I can't promise that it's completely fixed but it should be much better.
@billw2015
AI_establishStackSeeInvisibleCoverage was the real reason for that slowdown.

I've suspected there was an issue there for a bit now. I'm interested to see your fix.

 

[Thunderbrd]

@alberts2

I can see some things this new method fixes and it's definitely how it should've gone. And I am NOT trying to say I did this right to begin with, but I think you may have stepped back into a bug I had set things up this way to avoid.

Just a question though:

    CLLNode<IDInfo>* pUnitNode = headUnitNode();
    while (pUnitNode != NULL)
    {
        CvUnit* pLoopUnit = ::getUnit(pUnitNode->m_data);
        pUnitNode = nextUnitNode(pUnitNode);

        if (pLoopUnit->AI_getUnitAIType() == eUnitAI)
        {
            if (GC.getGame().isOption(GAMEOPTION_HIDE_AND_SEEK))
            {
                if (pLoopUnit->visibilityIntensityTotal(eInvisibleType) > 0)<-- just having this ability is not enough to be counted - it also has to be specifically made for this purpose
                {
                    iCount++;
                }

is that enough of a filter to count that unit?

I had made it count by the unit type because I was finding that the filters to count the unit was insufficient to be totally sure that unit was for that exact purpose it was really being counted for. Other units that had visibilities of other types, just not as their most valuable type, were being counted, even if they were not assigned to fulfill that particular visibility type's role, and thus throwing off the count.

Thus, since a trained dog does have some ability to see through size invisibility, does not necessarily mean it was made for the purpose of seeing through size invisibility, even though it WAS made for the purpose of seeing invisibility (camo in this case). Thus he would, being present count towards both if the actual unit type of the best possible responder wasn't used here, thus giving a false read that a size invisibility sensing unit was present when one actually isn't yet. Just an example. This can get a lot more complicated. How can we ensure that the TYPE of invisibility they have been made to see through is clearly delineated to the unit permanently so that it cannot cause code confusion with other types?


This issue, along with others, has had me debating whether we need a sub-category system for unitAI assignments. This could help with clearly denoting army leaders and some different behaviors for calling and organizing army stacks only to be defined on those units with the leader sub-category assigned. Problem is, I'm not the best judge at how to best setup such a sub-AI designation system, particularly how to setup establishing that in the way the unit was called in the brokerage so that it would assign the sub-AI category to the unit called for that purpose.

 

[olduser]

I had made it count by the unit type

How do you know that a unit of the best unit type answers the request?

This issue, along with
others, has had me debating whether we
need a sub-category system for unitAI
assignments

Some unitAI's defenitely need subtypes.

 

[Yudishtira]

Thus, since a trained dog does have some ability to see through size invisibility, does not necessarily mean it was made for the purpose of seeing through size invisibility, even though it WAS made for the purpose of seeing invisibility (camo in this case). Thus he would, being present count towards both if the actual unit type of the best possible responder wasn't used here, thus giving a false read that a size invisibility sensing unit was present when one actually isn't yet. Just an example. This can get a lot more complicated. How can we ensure that the TYPE of invisibility they have been made to see through is clearly delineated to the unit permanently so that it cannot cause code confusion with other types?

Correct me (or just say no) if I'm wrong, but:
Rather than how many units with (in the example) size perception there are, don't you want to know how many points of size perception is present? If so, you need to count the (size perception of the) dogs who weren't trained for the purpose, as well as (that of) any size perception specialists.

 

[Thunderbrd]

How do you know that a unit of the best unit type answers the request?

Well, I THOUGHT this was defined earlier in the code stream but I might've had an oversight at this stage - and there's some other issues with my approach. Again, no defense of that - it's clearly wrong. I see other reasons for that too (like you can't assume the upgrade path will keep the unit even able to upgrade to the best type for that role in the future but that doesn't change it's AI intent...)

Some unitAI's defenitely need subtypes.

I am THRILLED you agree with me on this. I've been terrified of suggesting it. And of having to admit I KNOW I suck at data storage forms too much to be the guy to set this up properly. But we DO need it right? Like bad - would solve a lot of our struggles to be able to establish and refer to this on a unit. We can discuss the how-to-best go about it in the Armies thread I started the other day if you like. I'd love to see the thought process that comes up with how to go about this sort of thing being explained as we go so I can follow it and interact with it properly.

 

[Thunderbrd]

Rather than how many units with (in the example) size perception there are, don't you want to know how many points of size perception is present? If so, you need to count the (size perception of the) dogs who weren't trained for the purpose, as well as (that of) any size perception specialists.

We don't need to look at the units that aren't for this purpose - we let them just be incidental side-benefits at best in this case. Those units would've been made for other reasons and we don't want to assume they will sufficiently be present to fill in for this one as best as possible. They won't be compelled to promote to be as specialized in this sort of thing as possible and they should not be accounted as filling in for the role just because they are present. Make sense?

 

[Yudishtira]

We don't need to look at the units that aren't for this purpose - we let them just be incidental side-benefits at best in this case. Those units would've been made for other reasons and we don't want to assume they will sufficiently be present to fill in for this one as best as possible. They won't be compelled to promote to be as specialized in this sort of thing as possible and they should not be accounted as filling in for the role just because they are present. Make sense?

Worrying about future promos and future demand makes this task about 100 times more complex and time-consuming. This is absolutely not a criticism, but I don't think you have time for it.

Also, why count units when it is just as easy to count points of (in this case) size perception? Which results in a more accurate figure for right now, and minimizes the number of risky assumptions made. (As long as you count only units trained for this city, not ones that are passing through or will leave as soon as they can.)

If I still haven't convinced you, I'll drop it, and assume I'm missing something (after all it is all too probable that I am...).

 

[Thunderbrd]

Worrying about future promos and future demand makes this task about 100 times more complex and time-consuming. This is absolutely not a criticism, but I don't think you have time for it.

Also, why count units when it is just as easy to count points of (in this case) size perception? Which results in a more accurate figure for right now, and minimizes the number of risky assumptions made. (As long as you count only units trained for this city, not ones that are passing through or will leave as soon as they can.)

If I still haven't convinced you, I'll drop it, and assume I'm missing something (after all it is all too probable that I am...).

A unit that's specialized in this role will take the promotions that will support that specialization. Units that aren't should take promotions that support what they are specialized in. The way this system works, it should be compelling the AI to send one Visibility specialist in each type of visibility to staff a city (and many stacks ask for one of each if possible as well), both for further defense and to create as solid a possible barrier against being taken advantage of by invisible units. Only a specialist unit in this regard will be able to reach the highest amounts currently possible, and they are reluctant attackers and defenders because they have this role, leaving other units that may incidentally near rival them to do what those units are instead supposed to do when they are supposed to do it, possibly leaving the cities they were in and the stacks they were part of then uncovered by the visibility they offered. Said units may also be bad influences on a city and therefore shouldn't be hanging around the city, or they could be limited unit types. Besides, these AI types being present has the side effect of increasing the protection for the city or stack it's assigned to, and though that may not be its ultimate role, it is a secondary benefit of their presence.

You might have a strong visibility on camoflage coming from a stalker, but a stalker is not best used FOR that purpose unless it's employed in countermeasures against stealth units - to hunt them down basically. They shouldn't be trained just to go sit around in a city, especially if you are using limited units. It's a waste for them. Therefore, though they have a high visibility on camo, they are not designated as a potential 'visibility on camo AI unit'. If one happens to be in a city, the ordering process should not be looking at him and thinking the city is covered with this need because if he's doing anything like what he should be doing as the type of AI he's been assigned, he WILL be leaving the city soon to go cause what damage he can.

 

[Yudishtira]

10794

• NOT a total fix for occasional crash (access violation) at info-checksum stage due to my misuse of delayed resolution pointers. I have to review the pointer attack problems I created at 10781 when I changed the delayed resolution system.

How far away is a complete fix for this? Can these commits be moved to a branch?

 

[Tajo]

Just because you posted them earlier does not mean that I remember your posting. That is why I said what I said.

Well sorry but I can't be held resonsible for your lack of memory and the demeaning tone in your reply was downright annoying and inappropriate. If you have some attitude or memory issues, they are not my fault and I am not aware of them nor do I want to be but I do expect that if I write something to a forum, person replying to it has the decency to properly address it in its context.


Back to the money issue then. I am currently at late classical era and pour over 1350 gold of income per turn into my coffers. Tech/culture sliders and civics are at current maximums so yeah, definitely far too much money income in V39. Otherwise, no complaints at all. Crashes sometimes randomly when moving on the map but this is an old "feature".