Rise of Mankind - Addons (by Jooyo)

[os79]

Really? Why? I was thinking of removing the enslavement code and turning enslavement into a python modmod, because Jooyo's enslavement changes leave something to be desired. But, if you want enslavement, I think everything modified on "06/27/09" is for enslavement.

Oh, and The Mountains Back to Service is working fine. It was just Resource Refinement that was bugged. In fact, I modded Mountains back to service to be a game option.

How do Enslavement leave something to be desired? I understand and agree about outdating trouble with slaves but other than that, I like being able to capture soldiers and turn them into slaves. Very historically correct. Plus it makes Slavery an useful civic option.

As for Mountain Back to Service, I meant waiting for it to required techs for being passable and for efficient mining.

And thanks!

 

[Afforess]

How do Enslavement leave something to be desired? I understand and agree about outdating trouble with slaves but other than that, I like being able to capture soldiers and turn them into slaves. Very historically correct. Plus it makes Slavery an useful civic option.

You misunderstood me. I like the idea. That's why I would redo it as a python modmod. The way slavery was incorperated in the code (CvGlobals.cpp is the real problem section), causes issues. Try loading RoM, with Jooyo's dll, but no XML file changes. You get strange XML load errors. This is because Jooyo (No offense, if you still read this), kinda hacked the code together for enslavement. Remove Enslavement, and the errors are gone. The DLL should not be dependent on XML files. That's just asking for problems.

As for Mountain Back to Service, I meant waiting for it to required techs for being passable and for efficient mining.

And thanks!

I see. I'm working on it.

 

[os79]

You misunderstood me. I like the idea. That's why I would redo it as a python modmod. The way slavery was incorperated in the code (CvGlobals.cpp is the real problem section), causes issues. Try loading RoM, with Jooyo's dll, but no XML file changes. You get strange XML load errors. This is because Jooyo (No offense, if you still read this), kinda hacked the code together for enslavement. Remove Enslavement, and the errors are gone. The DLL should not be dependent on XML files. That's just asking for problems.

Oh, I see. In that case, I'm looking forward to your solution. Now that you taught me that only callback to pythons are actually what slow the game down, not python, I'm supportive of that effort. Less SDK merging/compiling work for me in future if it works out .

 

[Dancing Hoskuld]

@Afforess & os79, does this mean I have to get the python enslavement mod I thought I had working bug free?

 

[os79]

@Afforess & os79, does this mean I have to get the python enslavement mod I thought I had working bug free?

If it functions the same as the one Jooyo tried to SDK-ify, then it would be cool that you and Afforess work together on that. He is currently working on it with some help in SDK/Python forum.

 

[Afforess]

@Afforess & os79, does this mean I have to get the python enslavement mod I thought I had working bug free?

Can I see the mod?

 

[Dancing Hoskuld]

Can I see the mod?

It is based on the zEnslavement and SubdueAnimals mods with a bit of a piracy mod thrown in. I posted it in the mod components thread then found a major problem with it, so I removed it. I then went on holiday almost as far from my computer as it is possible to go on this planet

The code is attached but it is not yet fit for use!

 

[Afforess]

It is based on the zEnslavement and SubdueAnimals mods with a bit of a piracy mod thrown in. I posted it in the mod components thread then found a major problem with it, so I removed it. I then went on holiday almost as far from my computer as it is possible to go on this planet

The code is attached but it is not yet fit for use!

What problems do you have with it?

EDIT: We're hijacking this thread, lets move to somewhere more appropriate. Either PM me or start a thread for discussion...

 

[Afforess]

Since Jooyo has not been active since August, I will be taking over Jooyo's modmod's, unofficially. They will all be included in my installer for Version 1.4, and I will continue to support them. Please do not use Jooyo's downloads or DLL, as they will be out of date for RoM 2.8.

If Jooyo Returns, I will return control back to him.

(I couldn't just stand their and let such good work die...)

 

[os79]

Since Jooyo has not been active since August, I will be taking over Jooyo's modmod's, unofficially. They will all be included in my installer for Version 1.4, and I will continue to support them. Please do not use Jooyo's downloads or DLL, as they will be out of date for RoM 2.8.

If Jooyo Returns, I will return control back to him.

(I couldn't just stand their and let such good work die...)

Wow, you are a hero .

So the modmods of his (Terraforming, etc) will be in your next modmodpack? To ease installment process and to better finesse them with your dll?

 

[Afforess]

Wow, you are a hero .

So the modmods of his (Terraforming, etc) will be in your next modmodpack? To ease installment process and to better finesse them with your dll?

Yes, all except for his missile launcher (I don't care for it, and it's my modmod...) and enslavement. I kept the enslavement code in the SDK, and plan on changing it to work for all civics, since slaves can't dissappear when civics change, and making slaves really POW's.

 

[Dancing Hoskuld]

The missile launcher is a stand alone modular unit, so it probably does not need much maintenance anyway. I like it because it makes the V1 and Cruse missiles useful. Currently they do not have the range they have in history. I use them to bombard city defences and their dosen't reach from one city to the next.

 

[Sinapus]

The missile launcher is a stand alone modular unit, so it probably does not need much maintenance anyway. I like it because it makes the V1 and Cruse missiles useful. Currently they do not have the range they have in history. I use them to bombard city defences and their dosen't reach from one city to the next.

I just went into the units xml file and increased the range to something more useful.

 

[dudeSDCA]

Hey everyone,

Quick question. When I use the option for the expanded culture (and additional tiles to be worked by the city), I obviously want more room between cities. However, the AI, when it finds the "best location" for a city for settlers (those blue boxes), tend to pick plots no more than 2-3 out from my current cultural borders.

Is there a way to increase how far out from the borders it looks for a recommended plot? While I can routinely ignore the AI settle options, the AI relies on them, and it can gimp the size of their cities.

Thoughts?? (and thanks in advance)!

 

[Afforess]

Hey everyone,

Quick question. When I use the option for the expanded culture (and additional tiles to be worked by the city), I obviously want more room between cities. However, the AI, when it finds the "best location" for a city for settlers (those blue boxes), tend to pick plots no more than 2-3 out from my current cultural borders.

Is there a way to increase how far out from the borders it looks for a recommended plot? While I can routinely ignore the AI settle options, the AI relies on them, and it can gimp the size of their cities.

Thoughts?? (and thanks in advance)!

I just reviewed the code, and I think the exact opposite problem is happening. If there is only regular city radius's, the AI still tries to plan for larger cities. At least, that's how the code has it.

 

[os79]

Go to GlobeDefines.cml and search for:
City_Range
Then you can change the number from 2 to 3. That should limit your choices to three or farther plots from a city to settle.

I'll trust Afforess on how AI itself does the things.

 

[Afforess]

I'll trust Afforess on how AI itself does the things.

Don't trust me, trust the code.

int CvPlayerAI::AI_foundValue(int iX, int iY, int iMinRivalRange, bool bStartingLoc) const
{...
...
    if (!bStartingLoc)
    {
        if (!AI_isPlotCitySite(pPlot))
        {
            for (iI = 0; iI < [B]NUM_CITY_PLOTS[/B]; iI++)
            {
                pLoopPlot = plotCity(iX, iY, iI);
                if (pLoopPlot != NULL)
                {
                    for (int iJ = 0; iJ < AI_getNumCitySites(); iJ++)
                    {
                        CvPlot* pCitySitePlot = AI_getCitySite(iJ);
                        if (pCitySitePlot != pPlot)
                        {
                            if (plotDistance(pLoopPlot->getX_INLINE(), pLoopPlot->getY_INLINE(), pCitySitePlot->getX_INLINE(), pCitySitePlot->getY_INLINE()) <= [B]CITY_PLOTS_RADIUS[/B])

Jooyo changed CITY_PLOTS_RADIUS to 3 instead of 2 in the defines.h, and NUM_CITY_PLOTS from 21 to 37. But he never updated the AI code, so it is clearly referencing the larger cities code, always.

Not that I see this as a real problem. I always though the AI placed cities too close together, and if this makes them place them farther apart, just 1 tile for, I'm fine with it.

 

[dudeSDCA]

Don't trust me, trust the code.

int CvPlayerAI::AI_foundValue(int iX, int iY, int iMinRivalRange, bool bStartingLoc) const
{...
...
    if (!bStartingLoc)
    {
        if (!AI_isPlotCitySite(pPlot))
        {
            for (iI = 0; iI < [B]NUM_CITY_PLOTS[/B]; iI++)
            {
                pLoopPlot = plotCity(iX, iY, iI);
                if (pLoopPlot != NULL)
                {
                    for (int iJ = 0; iJ < AI_getNumCitySites(); iJ++)
                    {
                        CvPlot* pCitySitePlot = AI_getCitySite(iJ);
                        if (pCitySitePlot != pPlot)
                        {
                            if (plotDistance(pLoopPlot->getX_INLINE(), pLoopPlot->getY_INLINE(), pCitySitePlot->getX_INLINE(), pCitySitePlot->getY_INLINE()) <= [B]CITY_PLOTS_RADIUS[/B])

Jooyo changed CITY_PLOTS_RADIUS to 3 instead of 2 in the defines.h, and NUM_CITY_PLOTS from 21 to 37. But he never updated the AI code, so it is clearly referencing the larger cities code, always.

Not that I see this as a real problem. I always though the AI placed cities too close together, and if this makes them place them farther apart, just 1 tile for, I'm fine with it.

Sweet -- thanks guys! So the conclusion I should draw (aside from trusting Afforess!) is that the AI already is spreading them apart more than vanilla AI.

One additional question -- if I'm also playing with the expanded cultural borders (and I tend to play Gigantic -map games), and I want the AI to spread out more because of the increase in cultural borders, I could change the NUM_CITY_PLOTS from 3 to 4?

Thanks again (you guys are quick!!)

 

[Afforess]

Sweet -- thanks guys! So the conclusion I should draw (aside from trusting Afforess!) is that the AI already is spreading them apart more than vanilla AI.

One additional question -- if I'm also playing with the expanded cultural borders (and I tend to play Gigantic -map games), and I want the AI to spread out more because of the increase in cultural borders, I could change the NUM_CITY_PLOTS from 3 to 4?

Thanks again (you guys are quick!!)

No that would have adverse side effects. The easiest way to do it would be to do what Os79 said:

Go to GlobalDefines.xml in the RoM/Assets/XML and search for:
City_Range
Then you can change the number from 2 to 3. That should limit your choices to three or farther plots from a city to settle.

Play with those values and see if you like the results.

 

[dudeSDCA]

Thanks! Glad I asked for clarification!