Pie AE K-MOD merge Project

[keldath]

Hey hey,

Cool yask list.
I guess i can handle these, but shoulnd we wait for the current build to be ready?

 

[Flunky]

Depends on which files are modified for the new build. The smaller changes can be prepared by Ramk or me and then merged. But that's of course easier if the basis is mostly identical.

 

[keldath]

hey,
i merged your PR's,
i guess i need to recompile the dll .
will do it very soon, no worries.

i havent had time to check - for now game load fine?

Pie provided me with an initial dll wishlist:
-) new Mission: drive out religion
Missionaries can remove religions from a city. Up to now, that's a special unit in PAE, that should be merged with the normal missionary.
kmod implements some chance, that failing missionaries can remove another religion from the city. That should be disabled.

ok,
though adding a new mission by dll might be complicated to me - cant we use PlatyPing mods for that? or orion ?

in cvunit - i guess maybe removing this should handle it.
// K-Mod. Instead of simply failing, give some chance of removing one of the existing religions.
std::vector<std:air<int, ReligionTypes> > rankedReligions;
int iRandomWeight = GC.getDefineINT("RELIGION_INFLUENCE_RANDOM_WEIGHT");

-) Generals should only defend, if they are the most healthy (not only strongest) unit in the stack (lead from behind, if you will)

might be easy, some unit fn like best defender chooses who to defend with, GG can be excluded for last or something.

-) Population numbers. Such that Pop 5 doesn't mean 500'000 people in a city. Pop 1 around 500 people, Pop 6 around 50.000. Pop 25 close to 1 M.
Previously: Pop^2.8 *1000.
Suggestion: round(Pop^2.8) * 100 + 400 yields Pop1: 500, Pop6: 15500, Pop25: 821200.
Alternative: round(Pop^2.09)* 1200 - 700 yields Pop1:500, Pop6: 49700, Pop25: 1001300.

For the first version I'll put up a PR. I like the slower start with 500, 1100, 2600, 5300, 9500, 15500 vs. 500, 4100, 11300, 20900, 34100, 49700.

i saw the cvcity calc change you did, i wonder , why is it like this in PAE?

-) Forts in enemy territory: defensive bonus for whomever is occupying it. Currently, PAE modifies the plot culture to change the ownership accordingly.

-) Forts and lookout towers with +1 vision range for units on them. Currently, a promotion is given dynamically onUnitMove.

i cant merge in super forts, with all its possibilities if you want:
visibality range, bombardment, ai code for placing forts, ranged culture, unique improvement per x tiles.

-) Ice on water: should be accessible to land units and not for ships (except for submarines, which PAE does not have).
Something like a "FeatureMakesValid" tag for movement?

can easily be done i think.
i got movable mountains over my mod, i guess same could be applied for ice.

-) Terrain: Desert, swamp and tundra should cause damage. Low priority feature. Already implemented in the old project and could be merged.

another code i have ready in my mod - uses the LadiesOgre code.
i havent used it, but i maintain its code.

-) UnitClassType: Chariot: should not be able to move through the woods (forest, dense, jungle; but savanna is ok). Any road enables movement. Optionally the same for heavy siege weapons.
How could the AI cope with such a rule? Path finding is so far no part of their production planning, I guess.

i guess the path uses check for movable tile, so just placing false to those specific terrain/features, will do the trick.

-) Unit religion: each unit is assigned (statically) a religion based on the city where they were recruited. If two units meet on the battlefield who share the same religion, it might happen that they refuse to fight each other, or one side might defect.
As written before, that's also at least partly implemented in the old project

sounds complicated for me to handle.
i know of some old python mods in existence, but maybe use the PAE code.


so anyway,
let me know when do you think the merge stage of kmod is done and the convert code part begins. feel free to task me with assignments and prioritize what you want first.
at your service,

 

[Flunky]

hey,
i merged your PR's,
i guess i need to recompile the dll .
will do it very soon, no worries.

i havent had time to check - for now game load fine?

[...]
i saw the cvcity calc change you did, i wonder , why is it like this in PAE?

For me it works without problems.

The compilation has no priority, that's just that cosmetic change right now.
The guys are always complaining that ancient cities didn't have a million inhabitants except for Rome maybe. So just reducing those numbers, which have no relevance for gameplay anyway.

ok,
though adding a new mission by dll might be complicated to me - cant we use PlatyPing mods for that? or orion ?

Sure, if you have a modcomp in mind. Otherwise, I should be able to handle it.

in cvunit - i guess maybe removing this should handle it.
// K-Mod. Instead of simply failing, give some chance of removing one of the existing religions.
std::vector<std:air<int, ReligionTypes> > rankedReligions;
int iRandomWeight = GC.getDefineINT("RELIGION_INFLUENCE_RANDOM_WEIGHT");

I re-read that part and explained it to Pie in a PM, let's see what he says.

might be easy, some unit fn like best defender chooses who to defend with, GG can be excluded for last or something.

I think LFB does this great already, let's try the defender selection as implemented by kmod/LFB for now. I'd only modify the LFB-xml-values to reflect the importance of GGs and the irrelevance of limited units. I'll try
LFB_BASEDONGENERAL = 6 and LFB_BASEDONLIMITED = 1.

i cant merge in super forts, with all its possibilities if you want:
visibality range, bombardment, ai code for placing forts, ranged culture, unique improvement per x tiles.

I'll read up on that, but sound great.

can easily be done i think.
i got movable mountains over my mod, i guess same could be applied for ice.

The hard part about ice is that water plots are currently generally blocked for any land unit that is not bCanMoveAllTerrain.

another code i have ready in my mod - uses the LadiesOgre code.
i havent used it, but i maintain its code.

Nice, but is it already in the DLL code in our repository? I find only feature-based damage, not terrain-based damage.

FeatureTypes eFeature = plot()->getFeatureType();
if (NO_FEATURE != eFeature)
{
if (0 != GC.getFeatureInfo(eFeature).getTurnDamage())
{
changeDamage(GC.getFeatureInfo(eFeature).getTurnDamage(), NO_PLAYER);
}
}

i guess the path uses check for movable tile, so just placing false to those specific terrain/features, will do the trick.

What does the AI make of it, when their chariots cannot move towards the enemy because there is a lot of woods but no roads?

sounds complicated for me to handle.
i know of some old python mods in existence, but maybe use the PAE code.

I have some code for that, but I have to check if it's any good.

so anyway,
let me know when do you think the merge stage of kmod is done and the convert code part begins. feel free to task me with assignments and prioritize what you want first.
at your service,

I think the merge stage is done and we can distribute it to a few interested testers.

 

[Flunky]

Yep, Super Forts sound absolutely perfect.
@pie_at it also implements a mechanic that an improvement can get upgraded by a unit being encamped on the plot. Could that be a thing for Latifundia with slaves?
https://forums.civfanatics.com/threads/super-forts.444512/

@keldath your 'missionary removes religion' can stay, pie approved it after I read and explained properly.

 

[keldath]

Yep, Super Forts sound absolutely perfect.

alright, ill merge it.

our 'missionary removes religion' can stay

cool.

The hard part about ice is that water plots are currently generally blocked for any land unit that is not bCanMoveAllTerrain.

i dont think that matters - just need to set the proper checks. it will be ok.

it already in the DLL code in our repository?

no, ill merge it in .

What does the AI make of it, when their chariots cannot move towards the enemy because there is a lot of woods but no roads?

that are route limit mods that exists we can use them.
if ai can move to a plot it will choose another, if no options, it will skip the turn.

I think the merge stage is done and we can distribute it to a few interested testers.

oki, ill start

check out:
https://forums.civfanatics.com/threads/platys-peculiar-pleasant-posh-python.497337/
it has inquisition mod and more.
we can use many of those there.

 

[Flunky]

Pie included a lot of Platys components in PAE, I don't think there is much to gain.

 

[pie_at]

Forts:
I don't know if it's good if you can gain culture per turn... but I'd say yes, if the fort gains all the 8 plots surrounding it. even it's in enemy territory? I don't know.

I hope the culture will not flip in empty forts in friendly territory!

Forts act like city walls. the idea is not bad... but what I once had in mind: walls has to be maintained. if you don't care walls will decay!
Perhaps it will be interesting to test my idea of getting walls ruinious with forts. Forts lose 1 defense point per turn and you can upgrade it again by clicking on the fort and pay some gold (eg a fix sum or the difference to the max defense value).


Upgrading improvements: I overread it/couldnt find.... I think it's ok as it is with latifundi. the slaves bing +X and the latifundi lose 1 per turn and will be downgraded. It's the reverse mechanic.

 

[brettschmitt]

Forts:
I don't know if it's good if you can gain culture per turn... but I'd say yes, if the fort gains all the 8 plots surrounding it. even it's in enemy territory? I don't know.

The Forts mod sounds really cool for me. (I think I have played with it already in another Civ4 Mod)
Pie, let's just try it out!

Same for the Super Spies mod.
https://forums.civfanatics.com/threads/bts-super-spies.259221/

I would really like to try all of it and then decide later on, what functions we might take out again, if they don't fit...

 

[keldath]

Forts:
I don't know if it's good if you can gain culture per turn... but I'd say yes, if the fort gains all the 8 plots surrounding it. even it's in enemy territory? I don't know

its quite managble.
i can tweak it, like you prefer.

also, all my mod parts are game optional.
so no worries.
and on top like i said, we can adjust to your needs.


super spies,
thats a big mod, for the time being i have no plans for it, but who knows.

Btw - the default civ number is 52 for now yeS?

 

[keldath]

ok, i merged in the git super forts as a game options,
i set the fort with the new tags in the xml.
i tweaked the original super forts in some places.

i executed some 50 autoplay games,
game didnt break, but i did see 2 asserts.

this is probabaly from PAE python - maybe units?

AttitudeTypes CvPlayerAI::AI_getAttitude(PlayerTypes ePlayer, bool bForced) const
{
    PROFILE_FUNC();

    FAssertMsg(ePlayer != getID(), "shouldn't call this function on ourselves");

    return (AI_getAttitudeFromValue(AI_getAttitudeVal(ePlayer, bForced)));
}

i saw that in one place there is a check not to call of the same player the function,
but in others i did not see this check, consider adding for each call.

also:

[B]FAssert(AI_getWarPlan(eLoopTeam) == WARPLAN_PREPARING_TOTAL || AI_getWarPlan(eLoopTeam) == WARPLAN_LIMITED);[/B]
                if (isHuman() || kOurMaster.isHuman())
                {
                    if (AI_getWarPlanStateCounter(eLoopTeam) > 20 * iAbandonTimeModifier / 100)
                    {
                        if (gTeamLogLevel >= 1)
                        {
                            logBBAI("      Team %d (%S) abandoning WARPLANS against team %d (%S) due to human / vassal timeout", getID(), GET_PLAYER(getLeaderID()).getCivilizationDescription(0), eLoopTeam, GET_PLAYER(GET_TEAM(eLoopTeam).getLeaderID()).getCivilizationDescription(0));
                        }
                        AI_setWarPlan(eLoopTeam, NO_WARPLAN);
                    }
                }

this is the call stack:

maybe somewhere you guys check war something? or set turnactive?
couldn't tell.

both issues are not game breaking.


anyway - dll is now debug , release is also there - so perhaps execute some auto play games to spot more asserts.

 

[Flunky]

In the PeloponnesianWar scenario are some canDeclareWar/declareWar and also in CvWBDesc.py:

            # Wars
            for item in pWBTeam.bWarWithTeamList:
                pTeam.declareWar(item, False, WarPlanTypes.NO_WARPLAN)

The first one could be CvDiplomacy.py:

(gc.getPlayer(self.diploScreen.getWhoTradingWith()).AI_getAttitude(gc.getGame().getActivePlayer())

 

[Flunky]

Brettschmitt over at civforum.de tests the current version and encountered repeated crashes to desktop without any trace in the logs. If you'd like to have a look, the saves are attached here and above: https://www.civforum.de/showthread.php?112652-PAE-VI-mit-kmod-dll&p=8816729#post8816729

 

[keldath]

Hey, sure, ill debug it.
Same git version right?

 

[keldath]

ok,
started debug,
issue comes from 0 value in the CvSelectionGroupAI::AI_getBestGroupSacrifice.

checking -> ok - some animal causes this: CvUnitAI::AI_animalMove()
edit - the Leopord unit is the culprit for the crash.
its doing some attack move.

also,
can you help out with the additions to the python calls
of

if gc.getGame().getActivePlayer() != gc.getPlayer:
(gc.getPlayer(self.diploScreen.getWhoTradingWith()).AI_getAttitude(gc.getGame().getActivePlayer())

?
i dont have a lot of time to mod so much


----------------
Well,
that explains it:
animals must have the <bAnimal>1</bAnimal> tag.
i changed this in the save game , and there was no assert error.
i continue to execute the game on auto play.
if you want i can push an update to all units and push it to git. let me know.

 

[Flunky]

The animals are not bAnimal, because they should be able to go into the cultural boarders and attack there as well. Do you have a better solution for the desired behaviour?

Sure, I'll add the check.

 

[keldath]

yes,
i can allow it in the dll
its a simple can move check
in -> bool CvUnit::canMoveInto(const CvPlot*

if (isAnimal())
    {
    /*    animals are everywhere!
        if (pPlot->isOwned())
        {
            return false;
        }
*/
        if (!bAttack)
        {
            if (pPlot->getBonusType() != NO_BONUS)
            {
                return false;
            }
            if (pPlot->getImprovementType() != NO_IMPROVEMENT)
            {
                return false;
            }
            if (pPlot->getNumUnits() > 0)
            {
                return false;
            }
        }
    }

ill cancel this out, more elegant solution.

hold on - i did the checks - ill push soon

 

[keldath]

ok done:

https://github.com/keldath/PieAncientEurope/commit/316456d720724864598aa50f983cd73b7d5bee20
review my changes please.
i still have the attitude issue, maybe i didnt fix it well.

also havnt worked on the war error from above.
also - merged your 4 PR's , good work.

 

[Flunky]

I did some corrections on the attitude issue, but don't have time to test it properly right now.

Thanks, now animals might behave as such Could we also set them back to UNITCOMBAT_ANIMAL? Right now, they are all UNITCOMBAT_MELEE. But if that were to be changed, also the promotions would require modification.

 

[keldath]

cool.

yes, the unitcombat does not affect ai play code.