Caveman2Cosmos v43 Player Guide

[Capt_Skirk]

Upscaled research cost option is on bottom of list.
These can be sorted in SVN once savebreaking period starts.

Also Complex Traits option is somewhere under traits option.

thanks for fast reply... *sigh* it seems im somehow wrong, still

bottom of list ... (you mean the very last option to check (when setting up a custom game) the last option i can pick there to check is: c2c combat mod without warning; i see the upscaled unit and building cost somewhat above

about traits i find only 4 options: no neg, pure traits, developing leaders, start w/o pos trait

oh wait .. do i need the SVNversion ???? *blush*

 

[raxo2222]

thanks for fast reply... *sigh* it seems im somehow wrong, still

bottom of list ... (you mean the very last option to check (when setting up a custom game) the last option i can pick there to check is: c2c combat mod without warning; i see the upscaled unit and building cost somewhat above

about traits i find only 4 options: no neg, pure traits, developing leaders, start w/o pos trait

oh wait .. do i need the SVNversion ???? *blush*

Read carefully whole list of options.
Or you maybe downloaded V38 instead of V39 by accident?
Or deleted V39 instead of V38?

You don't need SVN, I said, that options can be sorted logically in SVN once we start savebreaking stuff.

 

[Toffer90]

Where did you download v39?
Sounds like you got v38 somehow.

 

[Capt_Skirk]

dl was from moddb .. found out .. problem was not the download but extracted it in wrong folder .. now it works with the new traits and upscaled science cost option etc )

 

[raxo2222]

Switching to Windows Vista SP2 compatibility mode works better than Windows XP compatibility mode - it helps with Windows 7 related crashes, and has same performance as Windows 7.
That is Windows XP compatibility mode degrades performance and Windows Vista SP2 compatibility mode doesn't degrade it.

 

[Thunderbrd]

Guys, let me know if I've forgotten anything in the v40 update here.

 

[Harrier]

Guys, let me know if I've forgotten anything in the v40 update here.

Download from ModDB worked fine and installed with no problems.

 

[MattCA]

Guys, let me know if I've forgotten anything in the v40 update here.

Recalc (Medieval Era) took only seconds instead of minutes.

Actually 1 thing id like to mention is that changeRouteChange() on the recalc bug toffer found.
You only need to recal that if you actually changed that value in the xml so id suggest just commenting it out from the recalc function temporarily.

 

[Thunderbrd]

You only need to recal that if you actually changed that value in the xml so id suggest just commenting it out from the recalc function temporarily.

Changes in the XML are what recalcs are setup to handle in the first place.

 

[MattCA]

nevermind

Edit: haha I couldn't figure out what I was talkin about for a second there.

in void CvTeam::recalculateModifiers() it eventually get to a part that loops through techs and runs processTech() for each tech type. In the CvTeam:: processTech(TechTypes eTech, int iChange, bool bAnnounce) function is this little part

Spoiler :

    for (iI = 0; iI < GC.getNumRouteInfos(); iI++)
    {
        changeRouteChange(((RouteTypes)iI), (GC.getRouteInfo((RouteTypes) iI).getTechMovementChange(eTech) * iChange));
        setLastRoundOfValidImprovementCacheUpdate();
    }

which has the changeRouteChange() method.

Spoiler :

void CvTeam::changeRouteChange(RouteTypes eIndex, int iChange)
{
    FAssertMsg(eIndex >= 0, "eIndex is expected to be non-negative (invalid Index)");
    FAssertMsg(eIndex < GC.getNumRouteInfos(), "eIndex is expected to be within maximum bounds (invalid Index)");
    m_paiRouteChange[eIndex] = (m_paiRouteChange[eIndex] + iChange);
}

which simply adds stuff, and it looks like m_paiRouteChange is never reset. (small chance it is and this is all wrong)

I'm not exactly sure how toffer seemed to figure that out in 5 min.
After looking at it again obviously you can't comment out that 1 part like I said because the recalc uses the same code as when you get a new tech.
I assume this isn't fixed already because the possible bonus from the python event doesn't seem to be saved which you'll need if you reset the m_paiRouteChange values.
Anyways, like I said, I think the tag for this is only on 1 tech that comes later. This must be a very old bug, so probly not a big deal.

 

[Toffer90]

Actually 1 thing id like to mention is that changeRouteChange() on the recalc bug toffer found.

Changes in the XML are what recalcs are setup to handle in the first place.

Didn't anyone fix that issue?
Issue description: That the tech modifier to route cost isn't reset before it's added in the recalc, giving that one route that are affected by techs lower and lower movement cost every time a recalc is performed if the relevant tech has been invented.

 

[MattCA]

I made this and put it at line 14792 in CvGame.cpp, right before the Teams are recalculated.

Spoiler :

#define TEMP_FIX
#ifdef TEMP_FIX
    for (int iI = 0; iI < GC.getNumRouteInfos(); iI++)
    {
        for (int iJ = 0; iJ = GC.getNumTechInfos(); iJ++)
        {
            int iChange = GC.getRouteInfo((RouteTypes)iI).getTechMovementChange((TechTypes)iJ);
            if (iChange > 0)
            {
                for (int iTeam = 0; iTeam < MAX_TEAMS; iTeam++)
                {
                    if (GET_TEAM((TeamTypes)iTeam).isAlive() && GET_TEAM((TeamTypes)iTeam).isHasTech((TechTypes)iJ))
                    {
                        GET_TEAM((TeamTypes)iTeam).changeRouteChange((RouteTypes)iI, -(iChange));
                    }
                }
            }
        }
    }
#endif

It's not a proper fix, but should keep the numbers straight for now.

 

[billw2015]

Didn't anyone fix that issue?

Well I already made the v40.1 patch branch so it can go in there.

 

[Thunderbrd]

I made this and put it at line 14792 in CvGame.cpp, right before the Teams are recalculated.

Spoiler :

#define TEMP_FIX
#ifdef TEMP_FIX
    for (int iI = 0; iI < GC.getNumRouteInfos(); iI++)
    {
        for (int iJ = 0; iJ = GC.getNumTechInfos(); iJ++)
        {
            int iChange = GC.getRouteInfo((RouteTypes)iI).getTechMovementChange((TechTypes)iJ);
            if (iChange > 0)
            {
                for (int iTeam = 0; iTeam < MAX_TEAMS; iTeam++)
                {
                    if (GET_TEAM((TeamTypes)iTeam).isAlive() && GET_TEAM((TeamTypes)iTeam).isHasTech((TechTypes)iJ))
                    {
                        GET_TEAM((TeamTypes)iTeam).changeRouteChange((RouteTypes)iI, -(iChange));
                    }
                }
            }
        }
    }
#endif

It's not a proper fix, but should keep the numbers straight for now.

I'm not looking closely here, but usually the value in the data container would be zeroed out during the recalculation process. Often any kind of change or adjustment to try to undo anything set can create further problems if the adjustment isn't exactly the same as the amount they currently have. There's a function where all those data containers are zeroed out in the recalc process... can't recall the name of it off the top of my head but it's very obvious.

No, I didn't touch any of this stuff... I guess I'd assumed someone else got to it. I wasn't paying too much attention to what this needed, just casual attention to the conversation. My apologies.

 

[Toffer90]

I made this and put it at line 14792 in CvGame.cpp, right before the Teams are recalculated.

Spoiler :

#define TEMP_FIX
#ifdef TEMP_FIX
    for (int iI = 0; iI < GC.getNumRouteInfos(); iI++)
    {
        for (int iJ = 0; iJ = GC.getNumTechInfos(); iJ++)
        {
            int iChange = GC.getRouteInfo((RouteTypes)iI).getTechMovementChange((TechTypes)iJ);
            if (iChange > 0)
            {
                for (int iTeam = 0; iTeam < MAX_TEAMS; iTeam++)
                {
                    if (GET_TEAM((TeamTypes)iTeam).isAlive() && GET_TEAM((TeamTypes)iTeam).isHasTech((TechTypes)iJ))
                    {
                        GET_TEAM((TeamTypes)iTeam).changeRouteChange((RouteTypes)iI, -(iChange));
                    }
                }
            }
        }
    }
#endif

It's not a proper fix, but should keep the numbers straight for now.

This will cause issues when the relevant xml change; it needs to be a full reset of the m_paiRouteChange array values (All zero!), before applying the xml values anew during the recalc.

Here's the post where I outlined my hypothesis about the issue: Link

 

[MattCA]

it needs to be a full reset of the m_paiRouteChange array values (All zero!), before applying the xml values anew during the recalc.

That and save if a player completes that event. I was gonna look more into this
const EventTriggeredData* CvPlayer::getEventOccured(EventTypes eEvent, bool bIncludeExpiredEvents) const

but I'm goin to bed so I figured id make somthin in 10 min instead. I thought getting around the bug was more important then the abiity to change the xml atm.

 

[dbiss17]

Is there place that explains what the personality section for leaders means? Like, the "Full war" vs "limited war" vs dogpile war? What does all of that mean?

 

[billw2015]

Luckily I was just looking at war AI today. Certainly Dog Pile war means that they will only attack someone who is already at war. Full and limited are down to how much resources they want to commit to the war from what I can tell. I will be looking at it in more detail in the future so will know more then.

 

[Uriel246]

Im playing the new v40 version (great UI improvements!! thanks to all of you! Now i can play even in 1440p and see all the things Hurray!)

Now my question is: In prehistoric era, i have group of 9 stone axeman, but i cant only merge them once, making 3 groups but cant merge this 3 groups into a unique unit.

Has "Size Matters" now some type of tecnology limit to number of times you can merge units? Or maybe the units have some type of limitations?

 

[KaTiON_PT]

Im playing the new v40 version (great UI improvements!! thanks to all of you! Now i can play even in 1440p and see all the things Hurray!)

Now my question is: In prehistoric era, i have group of 9 stone axeman, but i cant only merge them once, making 3 groups but cant merge this 3 groups into a unique unit.

Has "Size Matters" now some type of tecnology limit to number of times you can merge units? Or maybe the units have some type of limitations?

That's working as intended. Each era allows you to merge a rank higher than the previous one, or in other words: in prehistoric you can group up 1 time, in ancient 2 times, etc.