Caveman 2 Cosmos (ideas/discussions thread)

Great, now I'm wondering; there are those here who want PPIO pushed to SVN pretty much right away.
The easiest thing for me would be to just merge the whole thing right away and deal with any grievances the best I can after the fact.
If I were to do a partial merge, then I need to be made aware of what specific part(s) of it that should not go onto the SVN, so I'm giving folks a last chance to share their concerns about it now.

A partial merge will probably mean a 2-3 weeks delay in getting it on the SVN as it may not be trivial depending on what specific part(s) that I need to isolate/separate from the whole of PPIO.
A full merge means a maximum of 1 hour of work on my part.

I'll wonder on this for 1-2 days before making a conclusion.
 
Last edited:
Great, now I'm wondering; there are those here who want PPIO pushed to SVN pretty much right away.
The easiest thing for me would be to just merge the whole thing right away and deal with any grievances the best I can after the fact.
If I were to do a partial merge, then I need to be made aware of what specific part(s) of it that should not go onto the SVN, so I'm giving folks a last chance to share their concerns about it now.

A partial merge will probably mean a 2-3 weeks delay in getting it on the SVN as it may not be trivial depending on what specific part(s) that I need to isolate/separate from the whole of PPIO.
A full merge means a maximum of 1 hour of work on my part.

I'll wonder on this for 1-2 days before making a conclusion.
I remember a few seemingly innocent rule changes it makes. Can we bring those up for discussion again?
 
Great, now I'm wondering; there are those here who want PPIO pushed to SVN pretty much right away.
The easiest thing for me would be to just merge the whole thing right away and deal with any grievances the best I can after the fact.
If I were to do a partial merge, then I need to be made aware of what specific part(s) of it that should not go onto the SVN, so I'm giving folks a last chance to share their concerns about it now.

A partial merge will probably mean a 2-3 weeks delay in getting it on the SVN as it may not be trivial depending on what specific part(s) that I need to isolate/separate from the whole of PPIO.
A full merge means a maximum of 1 hour of work on my part.

I'll wonder on this for 1-2 days before making a conclusion.
This is only Python and UI changes right? I have stopped all Python work for now and am only working on the XML. Mostly merging into core a number of mods which should have been done last time.
 
Can we bring those up for discussion again?
I'll list em up as fast as I can remember them.

The "enhanced tech conquest" rule changes are the first that comes to mind.

The original code tries to give tech boost to 5 techs every time.
Spoiler Here's its math for how many beakers it give per tech :
Code:
        # Get the percentage amount of tech points that is given by the population

        iTempPercent = pCity.getPopulation() * g_iPercentagePerCityPopulation        # g_iPercentagePerCityPopulation is by default at 1
        iPercent = min(max(0, iTempPercent), 100)

        iExtraTechPoints = 0

        # Get the base percentage amount of tech points
        iBaseTechPoints = int(iTechCost * (g_iBaseTechnologyTransferPercent/100.0))     # g_iBaseTechnologyTransferPercent is by default at 5

        if (g_bRandomTechnologyTransferAmount):
            iExtraTechPoints = pMapRand.get(iPercent, "TechConquest")
        else :
            iExtraTechPoints = int(iTechCost * (iPercent/100.0))

        # Get the total amount of tech points to be transfered
        iTotalTechPoints = iBaseTechPoints + iExtraTechPoints

        if (iTotalTechPoints >= iTempCost):
            if (g_bDisableFullTechnologyTransfer) and (iTempCost > 1):
                return iTempCost - 1
            return iTempCost

        return iTotalTechPoints
Only population size of the city influence the force of the tech conquest, bigger is better and it caps out at 100 population as a max force.

My code considers how many techs behind the conqueror is behind the conquered in total to decide the force of the tech conquest.
fForce = (1 + iTechsBehind/10.0) * iPopulation / (CyPlayerO.getTotalPopulation() + iPopulation)
iPopulation is the population of the conquered city, CyPlayerO.getTotalPopulation() is the total population of the entire nation that used to own that city.

So the relative size of the conquered city, relative to other cities within the nation that just lost the city, influence how big a victory taking the city was and thus influence the force of tech conquest.
Rationale: A Chinese city of 4 million people is consider a village, countryside really, by most Chinese today.and thus the size does not automatically mean that it is a technological stronghold if its one of the smallest cities in the nation.

My code will only give beakers towards techs that the conqueror can immediately research and which is of course known by the conquered.
There is however no enforced max limit to how many techs the conqueror may gains beaker towards with my code,
My code does not allow you to actually get the tech on the turn you conquer the city, there will always be 1 beaker left.
So conquering many cities in one turn will result in less knowledge gained from it, this is both about reducing steamroll a bit as well as having the rationale that a rushed conquest probably means its a violent time where knowledge easier gets lost in war.

My version tend to give less beakers to each tech, but often gives beakers to more than 5 techs too. It can potentially give more beakers than the original code too, the force concept makes it vary more based on more factors.

The math of it is not in one nice chunk of code as in the original, and it is a bit more convoluted, so I don't know if it will help much to present it.
Spoiler but here it goes :

Code:
        iBasePercent = g_iBasePercent
        iPopPercent = g_iPopPercent
        if iBasePercent < 1 and iPopPercent < 1: return

        CyPlayerN = GC.getPlayer(iOwnerNew)
        if CyPlayerN.isNPC(): return

        if iPopPercent < 0:
            iPopPercent = 0
        elif iPopPercent > 100:
            iPopPercent = 100

        # Get the map random object
        CyRandom = GC.getGame().getMapRand()

        CyTeamN = GC.getTeam(CyPlayerN.getTeam())

        CyPlayerO = GC.getPlayer(iOwnerOld)
        CyTeamO = GC.getTeam(CyPlayerO.getTeam())

        bCheckPrereq = g_bCheckPrereq
        aList = []
        iTechsBehind = 0
        for iTech in range(GC.getNumTechInfos()):
            # Continue if the conquering team does have the tech
            if CyTeamN.isHasTech(iTech):
                continue
            # Continue if the old team doesn't have the tech
            if not CyTeamO.isHasTech(iTech):
                continue
            iTechsBehind += 1
            # Continue if the conquerer cannot research the technology
            if bCheckPrereq and not CyPlayerN.canResearch(iTech, False):
                continue
            # Append the technology to the possible technology list
            iCost = CyTeamN.getResearchCost(iTech)
            iProgress = CyTeamN.getResearchProgress(iTech)
            iRemaining = iCost - iProgress - 1
            if not iRemaining:
                continue
            # Append the technology to the possible technology list
            aList.append((iTech, iCost, iRemaining))

        if not aList:
            return

        from random import shuffle
        shuffle(aList)

        iBasePercent += iTechsBehind
        charBeaker = GC.getCommerceInfo(CommerceTypes.COMMERCE_RESEARCH).getChar()
        iPopulation = CyCity.getPopulation() + 1
        fForce = (1 + iTechsBehind/10.0) * iPopulation / (CyPlayerO.getTotalPopulation() + iPopulation)

        iMax = (iPopulation * iPopPercent)
        iCount = 0
        szText = ""
        for iTech, iCost, iRemaining in aList:
            # Get the total number of technology points that will be transfered to the new city owner
            fTemp = 0
            if iPopPercent:
                for i in xrange(iPopulation):
                    fTemp += 100 * (1.0 + CyRandom.get(iPopPercent, "TechConquest")) / iMax

            fPercent = iBasePercent + fTemp * fForce

            iBeakers = int(iCost * fPercent / (20 * (iCount + 5)))

            if iBeakers < 1: continue
            if iBeakers > iRemaining:
                iBeakers = iRemaining

            # Increase the research progress for the new city owner
            CyTeamN.changeResearchProgress(iTech, iBeakers, iOwnerNew)

            szText += "\n\t" + GC.getTechInfo(iTech).getDescription() + u" <-> %i%c" %(iBeakers, charBeaker)
            iCount += 1
 
This is only Python and UI changes right? I have stopped all Python work for now and am only working on the XML. Mostly merging into core a number of mods which should have been done last time.
Yes, there is only minor xml changes to:
CIV4ArtDefines_Misc.xml
Promotions_CIV4GameText.xml
CIV4PromotionInfos.xml
GlobalDefinesAlt.xml
PythonCallbackDefines.xml
More extensive change to:
CIV4DetailManager.xml
BUG_CIV4GameText.xml
Global_CIV4GameText.xml
Seeing the promo xml there may cause someone to wonder and that brings me to another small gameplay change.
I added one new promotion that is meant for settlers only.
The promotion is a simple marker used to spawn the tribal guardian when the settler found a city.
I added it due to a nomadic start consideration I had while redesigning the "abandon city" feature.
When abandoning a city with a tribal guardian in the garrison, the settler created by that action will get that promotion as well as any experience points the guardian may have had. The tribal guardian is removed as it is an immobile unit that is supposed to be part of the city. When the settler is used to relocate the abandoned city the promo and experience points it has will create a new tribal guardian when founding the city again and the guardian will get its experience points back.
 
I tweaked revolutions code a bit, tweaked some numbers I felt were a bit off and so on.
Barbarian civ code has been pretty much rewritten, an emerging civ may get several barb cities if they are close enough together, and more barb units in the area is converted to the new civ.

I changed the star signs code to apply to all units spawned as well, original code only worked for units trained in cities, this means barb/neander spawns may get star signs, heck I might not even have restricted animals from getting them.
Units spawned from events could potentially get them too. Fixed a bug where one of the star signes would never be picked during the random selection as well, probably should have fixed it on the SVN, but I forgot about it, just remembered it now.
 
I'll list em up as fast as I can remember them.

The "enhanced tech conquest" rule changes are the first that comes to mind.

The original code tries to give tech boost to 5 techs every time.
Spoiler Here's its math for how many beakers it give per tech :
Code:
        # Get the percentage amount of tech points that is given by the population

        iTempPercent = pCity.getPopulation() * g_iPercentagePerCityPopulation        # g_iPercentagePerCityPopulation is by default at 1
        iPercent = min(max(0, iTempPercent), 100)

        iExtraTechPoints = 0

        # Get the base percentage amount of tech points
        iBaseTechPoints = int(iTechCost * (g_iBaseTechnologyTransferPercent/100.0))     # g_iBaseTechnologyTransferPercent is by default at 5

        if (g_bRandomTechnologyTransferAmount):
            iExtraTechPoints = pMapRand.get(iPercent, "TechConquest")
        else :
            iExtraTechPoints = int(iTechCost * (iPercent/100.0))

        # Get the total amount of tech points to be transfered
        iTotalTechPoints = iBaseTechPoints + iExtraTechPoints

        if (iTotalTechPoints >= iTempCost):
            if (g_bDisableFullTechnologyTransfer) and (iTempCost > 1):
                return iTempCost - 1
            return iTempCost

        return iTotalTechPoints
Only population size of the city influence the force of the tech conquest, bigger is better and it caps out at 100 population as a max force.

My code considers how many techs behind the conqueror is behind the conquered in total to decide the force of the tech conquest.
fForce = (1 + iTechsBehind/10.0) * iPopulation / (CyPlayerO.getTotalPopulation() + iPopulation)
iPopulation is the population of the conquered city, CyPlayerO.getTotalPopulation() is the total population of the entire nation that used to own that city.

So the relative size of the conquered city, relative to other cities within the nation that just lost the city, influence how big a victory taking the city was and thus influence the force of tech conquest.
Rationale: A Chinese city of 4 million people is consider a village, countryside really, by most Chinese today.and thus the size does not automatically mean that it is a technological stronghold if its one of the smallest cities in the nation.

My code will only give beakers towards techs that the conqueror can immediately research and which is of course known by the conquered.
There is however no enforced max limit to how many techs the conqueror may gains beaker towards with my code,
My code does not allow you to actually get the tech on the turn you conquer the city, there will always be 1 beaker left.
So conquering many cities in one turn will result in less knowledge gained from it, this is both about reducing steamroll a bit as well as having the rationale that a rushed conquest probably means its a violent time where knowledge easier gets lost in war.

My version tend to give less beakers to each tech, but often gives beakers to more than 5 techs too. It can potentially give more beakers than the original code too, the force concept makes it vary more based on more factors.

The math of it is not in one nice chunk of code as in the original, and it is a bit more convoluted, so I don't know if it will help much to present it.
Spoiler but here it goes :

Code:
        iBasePercent = g_iBasePercent
        iPopPercent = g_iPopPercent
        if iBasePercent < 1 and iPopPercent < 1: return

        CyPlayerN = GC.getPlayer(iOwnerNew)
        if CyPlayerN.isNPC(): return

        if iPopPercent < 0:
            iPopPercent = 0
        elif iPopPercent > 100:
            iPopPercent = 100

        # Get the map random object
        CyRandom = GC.getGame().getMapRand()

        CyTeamN = GC.getTeam(CyPlayerN.getTeam())

        CyPlayerO = GC.getPlayer(iOwnerOld)
        CyTeamO = GC.getTeam(CyPlayerO.getTeam())

        bCheckPrereq = g_bCheckPrereq
        aList = []
        iTechsBehind = 0
        for iTech in range(GC.getNumTechInfos()):
            # Continue if the conquering team does have the tech
            if CyTeamN.isHasTech(iTech):
                continue
            # Continue if the old team doesn't have the tech
            if not CyTeamO.isHasTech(iTech):
                continue
            iTechsBehind += 1
            # Continue if the conquerer cannot research the technology
            if bCheckPrereq and not CyPlayerN.canResearch(iTech, False):
                continue
            # Append the technology to the possible technology list
            iCost = CyTeamN.getResearchCost(iTech)
            iProgress = CyTeamN.getResearchProgress(iTech)
            iRemaining = iCost - iProgress - 1
            if not iRemaining:
                continue
            # Append the technology to the possible technology list
            aList.append((iTech, iCost, iRemaining))

        if not aList:
            return

        from random import shuffle
        shuffle(aList)

        iBasePercent += iTechsBehind
        charBeaker = GC.getCommerceInfo(CommerceTypes.COMMERCE_RESEARCH).getChar()
        iPopulation = CyCity.getPopulation() + 1
        fForce = (1 + iTechsBehind/10.0) * iPopulation / (CyPlayerO.getTotalPopulation() + iPopulation)

        iMax = (iPopulation * iPopPercent)
        iCount = 0
        szText = ""
        for iTech, iCost, iRemaining in aList:
            # Get the total number of technology points that will be transfered to the new city owner
            fTemp = 0
            if iPopPercent:
                for i in xrange(iPopulation):
                    fTemp += 100 * (1.0 + CyRandom.get(iPopPercent, "TechConquest")) / iMax

            fPercent = iBasePercent + fTemp * fForce

            iBeakers = int(iCost * fPercent / (20 * (iCount + 5)))

            if iBeakers < 1: continue
            if iBeakers > iRemaining:
                iBeakers = iRemaining

            # Increase the research progress for the new city owner
            CyTeamN.changeResearchProgress(iTech, iBeakers, iOwnerNew)

            szText += "\n\t" + GC.getTechInfo(iTech).getDescription() + u" <-> %i%c" %(iBeakers, charBeaker)
            iCount += 1

Yes, there is only minor xml changes to:
CIV4ArtDefines_Misc.xml
Promotions_CIV4GameText.xml
CIV4PromotionInfos.xml
GlobalDefinesAlt.xml
PythonCallbackDefines.xml
More extensive change to:
CIV4DetailManager.xml
BUG_CIV4GameText.xml
Global_CIV4GameText.xml
Seeing the promo xml there may cause someone to wonder and that brings me to another small gameplay change.
I added one new promotion that is meant for settlers only.
The promotion is a simple marker used to spawn the tribal guardian when the settler found a city.
I added it due to a nomadic start consideration I had while redesigning the "abandon city" feature.
When abandoning a city with a tribal guardian in the garrison, the settler created by that action will get that promotion as well as any experience points the guardian may have had. The tribal guardian is removed as it is an immobile unit that is supposed to be part of the city. When the settler is used to relocate the abandoned city the promo and experience points it has will create a new tribal guardian when founding the city again and the guardian will get its experience points back.

I tweaked revolutions code a bit, tweaked some numbers I felt were a bit off and so on.
Barbarian civ code has been pretty much rewritten, an emerging civ may get several barb cities if they are close enough together, and more barb units in the area is converted to the new civ.

I changed the star signs code to apply to all units spawned as well, original code only worked for units trained in cities, this means barb/neander spawns may get star signs, heck I might not even have restricted animals from getting them.
Units spawned from events could potentially get them too. Fixed a bug where one of the star signes would never be picked during the random selection as well, probably should have fixed it on the SVN, but I forgot about it, just remembered it now.
All that sounds OK to me - any chance we can limit star sign assignments to combatants (naval and otherwise)? They often end up on useless units to get them now.
 
All that sounds OK to me - any chance we can limit star sign assignments to combatants (naval and otherwise)? They often end up on useless units to get them now.
Best would probably be to give the star sign promotion a narrower valid "unit combat type" definition and have the code start a random place in the star promo list and ask the dll if the unit can have the promotion, if not, check next star sign promo in the list, rinse-repeat until one is found or the list has been exhausted. I think some of the promos work well on non-combatants too.
 
Best would probably be to give the star sign promotion a narrower valid "unit combat type" definition and have the code start a random place in the star promo list and ask the dll if the unit can have the promotion, if not, check next star sign promo in the list, rinse-repeat until one is found or the list has been exhausted. I think some of the promos work well on non-combatants too.
Well... give it some thought maybe. We get people showing some frustration when merchants and missionaries get combat useful star signs and I can understand the crazed impression that gives.
 
I added one new promotion that is meant for settlers only.
The promotion is a simple marker used to spawn the tribal guardian when the settler found a city.
So you found a solution to the problem of not knowing which unit built the the AI city.
Best would probably be to give the star sign promotion a narrower valid "unit combat type" definition and have the code start a random place in the star promo list and ask the dll if the unit can have the promotion, if not, check next star sign promo in the list, rinse-repeat until one is found or the list has been exhausted. I think some of the promos work well on non-combatants too.
Star Signs are on my list to "fix". I forgot them.
 
10704
  • Moved most headers into CvGameCoreDLL.h precompiled header
Those had been moved out of CvGameCoreDLL.h on purpose to avoid issues with the compiler. We had various problems with reaching compiler limits already, are you sure this won't cause any compilation problems now or in the future?????
Updates
  • Removed a lot of headers from the precompiled header files to avoid them being visible from the compiler heavy Python interface files.
    There are still some Cy interface files that include Cv files directly which in turn include other Cv headers so some more restructuring might be needed.
    But for now it should allow to add some more template heavy code to the Cv headers without breaking the compilation right away.
    The disadvantage of removing some precompilation is that it takes longer to compile the entire project.
  • Added the necessary includes to each CPP that were previously included from the precompilation header.
  • Fixed some accidental variable definitions in headers of the form struct X {} X; that were hidden by only being compiled once in the precompilation.
 
Those had been moved out of CvGameCoreDLL.h on purpose to avoid issues with the compiler. We had various problems with reaching compiler limits already, are you sure this won't cause any compilation problems now or in the future?????
Thanks for pointing out this to me. Yes the current file hits the compiler limit if the /Zm option were not added. But /Zm200 has worked out fine these days (since r9980, around the time of v38 I think) and if it happens again, we sure have more than enough virtual memory to bump up the /Zm factor.
 
Thanks for pointing out this to me. Yes the current file hits the compiler limit if the /Zm option were not added. But /Zm200 has worked out fine these days (since r9980, around the time of v38 I think) and if it happens again, we sure have more than enough virtual memory to bump up the /Zm factor.
There are some compiler bugs leading to issues with internal compiler limits especially in template heavy code even if the /Zm option is set to really high values.

EDIT:
I posted the updated compiler from Visual Studio 2003 SP1 which has lots of bugfixes for @Thunderbrd some time ago i post it again later.
 
Last edited:
Great, now I'm wondering; there are those here who want PPIO pushed to SVN pretty much right away.
The easiest thing for me would be to just merge the whole thing right away and deal with any grievances the best I can after the fact.
If I were to do a partial merge, then I need to be made aware of what specific part(s) of it that should not go onto the SVN, so I'm giving folks a last chance to share their concerns about it now.

A partial merge will probably mean a 2-3 weeks delay in getting it on the SVN as it may not be trivial depending on what specific part(s) that I need to isolate/separate from the whole of PPIO.
A full merge means a maximum of 1 hour of work on my part.

I'll wonder on this for 1-2 days before making a conclusion.
Full merge makes more sense, just change
Code:
<Define>
        <DefineName>COMMERCE_PERCENT_CHANGE_INCREMENTS</DefineName>
        <iDefineIntVal>4</iDefineIntVal>
    </Define>
to
Code:
<Define>
        <DefineName>COMMERCE_PERCENT_CHANGE_INCREMENTS</DefineName>
        <iDefineIntVal>5</iDefineIntVal>
    </Define>

There is too much difference between color border and leader name color.
Spoiler :

Civ4BeyondSword 2019-07-21 13-12-57-71.png

 
Last edited:
EDIT:
I posted the updated compiler from Visual Studio 2003 SP1 which has lots of bugfixes for @Thunderbrd some time ago i post it again later.
Are they the same files, build number 7.10.6030 (versus 7.10.3077 from toolkit), that I can extract from the sp1 updater?

Edit: Here is what I collect in the sp1 updater.
 

Attachments

  • MSVC2003SP1BIN-update-from-toolkit.zip
    2.5 MB · Views: 114
Last edited:
Great, now I'm wondering; there are those here who want PPIO pushed to SVN pretty much right away.
The easiest thing for me would be to just merge the whole thing right away and deal with any grievances the best I can after the fact.
If I were to do a partial merge, then I need to be made aware of what specific part(s) of it that should not go onto the SVN, so I'm giving folks a last chance to share their concerns about it now.

A partial merge will probably mean a 2-3 weeks delay in getting it on the SVN as it may not be trivial depending on what specific part(s) that I need to isolate/separate from the whole of PPIO.
A full merge means a maximum of 1 hour of work on my part.

I'll wonder on this for 1-2 days before making a conclusion.

Then i tried out PPIO the UI changes especially the increased font size caused lots of issues with text overlapping or not beeing displayed. That was on 1920x1080 i don't plan in buying a new laptop soon.

Has that been fixed?
 
Top Bottom