Advanced Civ

If someone wanted to add a building, a Desalination plant would be another option. Placed at Biology maybe? Requires coastal, and Power. Gives a city fresh water. Probably not really a case for this mod, but someone else might like the idea.
Yes, maybe for a mod that fleshes out the (late) Modern era – which, in the original game, veers off into space fantasy in 1970 or so.
And now we wander off topic...
I also find it difficult to get into recent strategy games, even just visually. Having no real familiarity with MoO, maybe I'll actually try Remnants of the Precursors at some point. Seems like a nice project; I've already located the AI code for starting wars, looks familiar: :p
Code:
// 2% chance of war if erratic leader (these guys are crazy)
if (empire.leader().isErratic() && (random() <= ERRATIC_WAR_PCT)) {
    beginErraticWar(view);
    return true;
}
[...] Atari ST emulator [...]
Oh, dear, here we wander off into ... the Classical era. Must be some great stuff there, but I'm totally ignorant of it.
 
I believe the mod changes the calculation a bit, mainly, by making the AI less interested in founding early religions. I would agree that Shrines don't scale well with the map size and that conquering Shrines feels a little cheap – letting the original owner do all the work –, especially when the Shrine is pretty far away from the conqueror's homeland; doesn't feel historically resonant then either, i.e. when the religion is really alien to the conqueror. I had been considering to halve the Shrine income when the Shrine religion is not the state religion (or maybe only when running a different state religion). Founding multiple religions in a row should, ideally, also be more difficult, but, primarily, because the AI struggles with juggling multiple religions, and because games tend to be more interesting when more than a couple of religions compete for adherents.

As for adjusting the Shrine income to the map size, the production cost of Missionaries would then arguably also need an adjustment because, if the income on Huge maps is e.g. only 0.5 GPT per city, then spread via 40-production Missionaries becomes pretty unattractive.

Well, I don't think the balance issues are severe enough to justify such significant changes at this point of the mod's life. (I had, at one point, meant to implement a package of balance tweaks to religion.)
I know you are not actively considering changes so this is just idle talk, but one thing that I have been thinking about is to make shrines give a (big so it is impactful) trade modifier with cities that share the same religion.

Since trade routes are capped in various ways, the bonus would increment throughout the game, and also be independent of map size. You would be encouraged to spread it, particularly to foreign cities, to combine the benefits from foreign cities with the shrine buffs.

I guess the downside is that it wouldn't incentivise spreading the religion as much as possible, but you could consider that a plus as well because it makes shrines for smaller religions worthwhile as well. I don't know whether it makes the Great Prophet tradeoff worthwhile, I guess that is a balance issue.
 
glad to see your back to development :)
ill wait for you to finalize some more :)
14 out of 44 issues left to look into (from that Marathon game). :)
[...] make shrines give a (big so it is impactful) trade modifier with cities that share the same religion.
Does only the Shrine city itself get that trade boost, or all cities of the Shrine owner that share the Shrine religion? Either way, the Shrine city will no longer be a niche where +gold% buildings beat +research% buildings. On the other hand, religion having a strong gold flavor feels rather profane.

In the context of a tech diffusion system (more idle talk), I've thought about increasing the rate of diffusion when two civs have the same state religion, i.e. regardless of Shrines. The intention being, mainly, to make the faith-based AI diplo modifiers less irrational. Without a tech diffusion system, a (moderate) trade route boost for civs sharing a state religion would seem to come closest to that idea. So I guess what I'm saying is that I'd feel more inclined to use a trade route effect for matching state religions than for Shrines.
 
On the other hand, religion having a strong gold flavor feels rather profane.

Better not look at the war chest actual Earth religions are sitting on then, nevermind the money they funnel into other things.
Soup kitchens and food banks and medical care and some of the finest schools around are a significant boost to a nation. Funded by religion. Reflecting that as extra income is as good a method as any.

I like the fact that a shrine city is the oddball and is better with currency buildings. Not because it's a shrine, I just like some cities to not fit in with the rest. CorpHQ works as well. It's the fact it has gold generation not dependent on the commerce slider, yet still multiplied by buildings.
 
Hi all - just wanted to touch base, say thanks to all who participated in the playalong; great fun, learned a lot.

I'm very excited to see @f1rpo is back at work and that this forum is picking up again. I've had to travel a lot for work but have more time now, so if there are RCs to test, I'm game.

XX, J.
 
Does only the Shrine city itself get that trade boost, or all cities of the Shrine owner that share the Shrine religion?
I am not sure, which is why I was vague about it. It's partly a balance issue, and I guess depends on what you'd want to encourage. The city itself is probably more in line with how shrines work right now but then the bonus would need to be significant to be worth the investment.
Either way, the Shrine city will no longer be a niche where +gold% buildings beat +research% buildings. On the other hand, religion having a strong gold flavor feels rather profane.
Is that a pro or con? I guess there is an inclination in the Civ4 game design that religion should not be associated with science but I don't know if that is actually historically justifiable.
In the context of a tech diffusion system (more idle talk), I've thought about increasing the rate of diffusion when two civs have the same state religion, i.e. regardless of Shrines. The intention being, mainly, to make the faith-based AI diplo modifiers less irrational. Without a tech diffusion system, a (moderate) trade route boost for civs sharing a state religion would seem to come closest to that idea. So I guess what I'm saying is that I'd feel more inclined to use a trade route effect for matching state religions than for Shrines.
Yeah sure, it could work that way as well. Reading this, my fingers are really itching to do more involved religion mechanics.
 
I'm very excited to see @f1rpo is back at work and that this forum is picking up again. I've had to travel a lot for work but have more time now, so if there are RCs to test, I'm game.
I've just gotten done with the changes I wanted to make after that Marathon game. I'm attaching a release candidate for AdvCiv 1.08 (and, as usual, a DLL allowing 48 civs). Release notes: Edit: 2nd release candidate posted here. Edit2: Now both are outdated as v1.08 proper has been added to the resource database.
Spoiler :
This update mainly addresses minor issues that I've encountered when playing along with @Jorunkun's Marathon game.

Barbarians: [change id advc.300]
Spoiler :
These changes mostly address problems described in this post of mine (a bit above the 2nd inner spoiler box).
• When deciding whether to place additional Barbarian units, the present number of Barbarian units tied down as city defenders is accurately subtracted (rather than subtracting the Barbarian city count times the number of initial free defenders).
• Slightly decreased the number of extra defenders that large Barbarian cities aim at keeping as a permanent garrison.
• AI civs may train some city attackers just for the purpose of conquering nearby Barbarian cities. This is mainly relevant for AI civs that haven't yet had a war plan against a rival civ.
• Slowed down the diffusion of Sailing to the Barbarians; this should delay the appearance of Barbarian Galleys a little bit. This is implemented through a new XML tag that can adjust the rate of diffusion to the Barbarians on a per-tech basis. [advc.301]
• Barbarian combat handicaps are shown when hovering over a Barbarian unit. This includes a city attack penalty that already exists in BtS but is difficult to notice because it only applies when Barbarians attack. [advc.313] Implemented just as I proposed in this post (2nd and 3rd paragraph).

UI:
Spoiler :

• Fixed problems with promotion glow and founding borders (around settlers) not being updated.
• Messages about enemy attacks include the attacker's combat odds, e.g. "While defending, your Grenadier has destroyed a Sumerian Knight (attacker's odds: 39.5%)." [advc.084c]
• Unit cycling no longer gets stuck when an order is issued to a group in which some units have moves left and others do not. [advc.001]
• Clicking the center tile on the city screen again enables citizen automation and has no effect if it's already enabled. AdvCiv 1.06 had, on mistaken assumptions, changed the behavior to toggling citizen automation. [advc.004t]

Game rule tweaks:
Spoiler :

• Decreased the land threshold for Domination victory by 7 percentage points. E.g. in a game wih 8 civs, the threshold is now 55% instead of 62%. Additionally, the victor's land percentage needs to be at least 25 points greater than the percentage of the second largest civ (same mechanism as for the population threshold). [advc.254]
• Decreased the impact of map crowdedness on distance maintenance for cities, i.e. the impact of the ratio of the initial civ count to the default civ count for the map's size and sea level. This tweak to change [advc.140] increases (compared with earlier versions of AdvCiv) the distance maintenance on undercrowded maps and decreases it on overcrowded maps. Related post (at the end)
• Decreased unit cost and supply on Marathon speed (in line with units being relatively cheap to train). Unit cost also gets slightly adjusted to map size – lower cost on larger maps, higher cost on smaller maps. [advc.252]
• Decreased the impact of the population ratio on espionage mission costs. The K-Mod formula had made the espionage points spent sometimes almost irrelevant for mission costs when one civ has far less population than the other. This tweak should reduce the frequency of spy attacks from small disgruntled civs, especially if the (large) target civs invest a little bit in espionage (against whichever target). [advc.120k] Related post 1 (under "Espionage") | 2 (in the middle)
• War no longer prevents revolts in cities under occupation. Instead, the culture strength of war enemies is halved (this essentially restores a BtS rule) and all foreign culture strength is halved under occupation. When both apply, culture strength is quartered. Previously, in AdvCiv, war had ruled out revolts, and occupation had halved the revolt probability. This did not actually make it easier to bring the probability all the way down to 0, whereas halving foreign culture strength means that half as much garrison strength is needed for 0 revolt risk. The result should be that revolts in quick succession will only affect cities that are substantially under-garrisoned and that a modest garrison will keep cities from revolting (or at least from ultimately flipping) while fighting a war. It's no longer possible to "freeze" newly conquered cities in a state of occupation by not providing a garrison. [advc.023] Related post (paragraph that starts with "Keeping Boudica alive", somewhere in the middle)
• When playing with Random Personalities, favorite civics are based on the displayed leader head, not on the secret personality. This was easier for me to implement than fixing remaining issues with BUG's "Favorite Civic Detector" – and it makes more sense. [advc.130n]
• Ranks shown on the Demographics tab (Info screen) are based only on known civs – the rank numbers had given away too much information about unmet civs. [advc.077]

AI:
Spoiler :

• Fixed a bug that had sometimes caused large AI stacks to bombard ungarrisoned cities (due to a numeric overflow). [advc.159] Bug report
• Fixed a bug that had sometimes caused the AI to assume no military build-up by civs with a very high production capacity (again, due to overflow). This had e.g. lead to the suicidal declarations of war described in this post (middle paragraph).
• Moderately decreased the rank hate ("you're getting ahead of us") between civs in the middle of the scoreboard. [advc.130c]
• Decreased the AI food weight during the Industrial era, which should mean that the AI (including the governor assisting human cities) will be less interested in growing cities. In anticipation of health problems. (This is in addition to an earlier tweak that slowly de-prioritizes food over the course of the late game as there is less and less time for extra population to pay off.) [advc.110]
• The AI stops guarding its workers toward the late game. This is based on the production cost of the units involved; will e.g. guard a single worker with a Knight but not with a Cuirassier. (Those frequent AI moves are annoying for watching humans and accomplish little.) [advc.010]
• The AI (somewhat) considers the effect of Hereditary Rule when deciding whether to cancel a deal that imports a luxury resource. This is specifically about the extra happiness from luxuries introduced by change [advc.912c]. This AI tweak should make situations in which the AI cancels a deal and immediately agrees to a new deal with the same conditions (even) less common.

Plus a fair number of minor tweaks not worth mentioning here, covered by the GitHub change history.
 

Attachments

  • AdvCiv_v1.08rc.zip
    10.4 MB · Views: 20
  • CvGameCoreDLL_48civs.zip
    2.2 MB · Views: 15
Last edited:
Better not look at the war chest actual Earth religions are sitting on then, nevermind the money they funnel into other things.
Soup kitchens and food banks and medical care and some of the finest schools around are a significant boost to a nation. Funded by religion. Reflecting that as extra income is as good a method as any.
A gold effect is fair enough, perhaps the issue is rather that most of the other effects of religions are underpowered. The other buildings, I guess – diplomacy is powerful (but hinges on AI roleplaying).
Is that a pro or con? I guess there is an inclination in the Civ4 game design that religion should not be associated with science but I don't know if that is actually historically justifiable.
I agree with Elkad:
I like the fact that a shrine city is the oddball and is better with currency buildings. Not because it's a shrine, I just like some cities to not fit in with the rest. CorpHQ works as well. It's the fact it has gold generation not dependent on the commerce slider, yet still multiplied by buildings.
If something else makes gold buildings matter, then I'd agree that commerce from trade routes is a better representation of attracted pilgrims than gold.

If a lot of trade route commerce gets concentrated in one city, then there'll be an incentive to construct all buildings that multiply any type of commerce. Pretty much as in the capital with its Palace commerce and the Bureaucracy boost. Of course, the Shrine could also be in the capital ... Also, if the Shrine only increases the commerce per trade route in the Shrine city (by a lot), then spreading the religion to just half a dozen large-ish foreign cities will essentially max out the Shrine commerce. Letting the Shrine (also) grant additional trade routes would arguably solve this problem. There may still not be much of a reward for domestic spread.

As for increasing the trade route commerce in all cities of the Shrine owner that share the Shrine religion, at some point, trade route boosts (from whichever source) will encourage city spam, so I see that as a limited game design resource.

Well, probably one can work out a trade route effect for Shrines that is well-balanced; just trying to raise some potential problems.
 
@Major Tom (quoted from the Marathon play-along thread - for greater visibility):
[...] I might chip in if there is another game coming up with normal speed and size and an unpredictable map.
I usually play the points handicap to AI as it is sensible to have the AI starting with their 2 techs and then they can buy whatever they like. Perhaps Monarch with 581 points to AI is interesting?
That should be a head start close to BtS Deity. Not actually enough to buy all the BtS freebies, but I think the AI will make up for that by spending its points a bit more wisely – the AI doesn't really need 4 Archers. Anyway, that's not a crazy head start, maybe not (much?) harder, overall, than Emperor without Advanced Start. [Edit: Might want to go down to 7 players on Normal size.] I would probably play along with this (if I've done Huge Marathon, then, apparently, I'll do anything), but a couple more players would arguably need to be on board.
 
Last edited:
Yes, close to BtS deity when it comes to fight for early space. 4 out of 5 buy extra settler and also smart distribution of rest of points. For sure, 6 AI enough on standard map size. 581 points actually come from deity’s points according to the table in manual. 581+150 for initial settler = 731. But still, monarch is gently enough for human. And the bonuses to AI is not so scary.

Hope people find this interesting.
To be familiar with what AI do on turn 0, try out starting a game and check out in worldbuilder the next turn.

By the way, thanks for the 1.08 update. Works fine.
 
So, I took 1.08rc for a spin yesterday, mainly to check out barb (galley) changes.

On my usual huge Totestra / marathon / 18 civs settings, the effect was quite noticeable. I started on a 5-city peninsula inside a Mediterranean-like ocean, so plenty of coastline all around. Was able to work-boat explore unimpeded until 860 AD, when I met my first barb galley, on the other side of the world. The first manned barb galley landed on my borders in the early 1000s. Under the old settings, I would have had to start fighting them a good 80 or so turns earlier, so this is a big difference.

Didn't notice any dfference wrt land-based barbs, but then my lands were easy to fogbust and my nearby neighbors, both landlocked, bore the brunt of barb attacks. They lost two cities to them, which happens a lot under my settings. Not sure what this means in terms of difficulty.

Personally, I'd like for galley barbs to remain a bigger threat than in vanilla civ, so my gut feel is that maybe they shouldn't be nerfed quite so much. I like that the AI now builds dedicated troops to attack barbs but have yet to see it play out. The AIs defensive response to barbarians might be more effectively improved by changing how well they identify and garrison barb hotspots . Easier said then done, surely.

Meanwhile, I just saw the advciv change to forests in your cultural borders not giving cover to enemies. I get and appreciate the intended effect - but does the AI know of this change when placing its troops to take a city?

Loved the combat odds display - one of these little things that spark joy. Thanks, too, for the espionage cost changes and the random personality favciv info display. Laslty, a very minor thing but ... could you make the mod display its version number on the main menu splash screen?

Thanks for your hard work, @f1rpo !
 
Thanks for the feedback.
581 points actually come from deity’s points according to the table in manual. 581+150 for initial settler = 731.
Oh, right, I see. Except for the 4th free Archer whose removal I forgot to point out in the manual.
On my usual huge Totestra / marathon / 18 civs settings, the effect was quite noticeable. I started on a 5-city peninsula inside a Mediterranean-like ocean, so plenty of coastline all around. Was able to work-boat explore unimpeded until 860 AD, when I met my first barb galley, on the other side of the world. The first manned barb galley landed on my borders in the early 1000s. Under the old settings, I would have had to start fighting them a good 80 or so turns earlier, so this is a big difference.
It turns out that K-Mod has adjusted Barbarian research to the game speed setting. In BtS, the Barbarians learn a tech at most 34 turns after all civs have acquired it, regardless of game speed. (If not all civs have the tech, then Barbarian research is proportionally slower.) In K-Mod, it's up to 25 turns on Normal speed, and, with the 250% tech cost modifier set by AdvCiv, up to 63 turns on Marathon. And my recent change doubles that, so the Barbarians obtaining Sailing 80 turns later than before sounds about right. That said, 80 turns prior to AD 860 (on Marathon) still seems very late. In our play-along game, the first Barbarian Galley arrived at my borders around 950 BC. So this is strange to me. Would be interesting to inspect a savegame around the start of the Christian era in Debug mode to see if the Barbarian really don't have Sailing yet or if they do already have Galleys in some remote place - and which of the AI civs have Sailing.

I've now, tentatively, dialed down the K-Mod change so that the pace of Barbarian research is only halfway adjusted to tech costs (factor 1.75). Barbarian research being slowed down by a factor of 2.5 is consistent with the research speed of the civs, but it feels too slow to me, giving the civs too much time to produce and position fog-busters before the Barbarians catch up in tech. I don't know, maybe this doesn't give a civ that has been slow to research e.g. Bronze Working enough time to catch up. Anyway, after this change, in tests on Marathon (Standard size, 8 players), the world's first Barbarian Galley was once placed around turn 200, once on t226. That's ... certainly still in the years BC. In the latter test, the first three non-Barbarian Galleys were finished on t175, t195 and t226. In tests on Normal speed, I saw the first Barbarian Galley on t71 (with only one earlier non-Barbarian Galley: on t68), t81 in another test (the first non-Barbarian Galley being finished on the same turn) and none ever in a third test. In that last one, all civs started on the larger of two continents, which made that continent pretty crammed, and some civs had inland starts, which slowed down the spread of Sailing. The Barbarians still got Sailing around t100 (only one prior non-Barbarian Galley, on t85), but the uninhabited continent was still off-limits (AdvCiv only spawns cities there) and the inhabited one had no fogged coast left. So these tests suggest that, if anything, Barbarian Galleys are still arriving too early on standard settings.
I like that the AI now builds dedicated troops to attack barbs but have yet to see it play out. The AIs defensive response to barbarians might be more effectively improved by changing how well they identify and garrison barb hotspots . Easier said then done, surely.
The AI merely guards future city sites; no logic aimed explicitly at fog-busting so far. As for conquering Barbarians cities, my hope is that they will at least manage that, eventually, in situations when there is no excuse for not doing so. In that play-along game, the AI looked very helpless being unable to reclaim its cities for millennia. The AI not looking stupid is generally more important to me than it actually being effective.
Meanwhile, I just saw the advciv change to forests in your cultural borders not giving cover to enemies. I get and appreciate the intended effect - but does the AI know of this change when placing its troops to take a city?
The AI should be aware of the change. If there's evidence to the contrary – AI preferring an attack via a Forest tile over a Hill tile despite the path lengths being the same –, then there's probably a bug, hopefully easy to fix.
Loved the combat odds display - one of these little things that spark joy.
Wish I had gotten it right too ... I've noticed that it's displaying the per-round odds of landing a hit, which are much closer to 50% than the true combat odds. Will be fixed.
Laslty, a very minor thing but ... could you make the mod display its version number on the main menu splash screen?
As far as I know, the string displayed there (by the EXE) is the folder name of the mod. Could display the version someplace else – several mods do it in the hover text of the big flag button – but that would be one more step to perform for a release. A small step - but easy to forget, and then the info isn't reliable. Not really easy to automate this. (Leoreth has just done so for Dawn of Civilization.) I'm already updating a string that gets stored in the file properties of the DLL. Maybe I shouldn't be doing that either – because I do forget sometimes and most players aren't even aware. The last-modified date of the DLL should be pretty reliable as most of my changes affect the DLL.
 
How viable do you think it is to make it so that Civ IV doesn't constantly round down everything and actually works with floats like in Civ V? Would it just be a matter of declaring formerly integer variables floats, or is there more to it?

Edit: I'm asking because I'm first trying to understand the code so that I can make changes to the AI later on, and I was wondering if there would be a way to do away with all that rounding nonsense. By the way, trying to understand the code and the changes you and previous modders did to it is quite something, there are so many terms which definition I'm having trouble understanding, especially the ones you and others introduced.
 
Last edited:
Before seeing your edit, I had assumed that you had a mind to change the rounding behavior in all places visible to the player, so that e.g. the trade route boost from Harbor doesn't get rounded to 0 most of the time. That would be a crazy effort as every division would have to be looked at individually.

AI calculations are by and large hidden from the player, so rounding in AI code doesn't have to follow a consistent pattern. Much of the AI code that I've added uses a custom type named ScaledNum and rounds as little as possible. Because I also found the "iPercent" stuff cumbersome, and because the rounding errors resulting from such low-precision arithmetic are sometimes quite relevant. And (fractional) exponentiation is very useful to have in AI code, indispensable to me, really. I had concerns about floating-point math not being multiplayer compatible. This is briefly addressed in the opening post of this thread and the first reply. I do think that floating-point math is safe enough for all practical purposes, so I probably should've used float instead. On the plus side, at least some operations are faster in fixed-point math, and I think all operations could be made faster if it were really necessary.
 
I've now, tentatively, dialed down the K-Mod change so that the pace of Barbarian research is only halfway adjusted to tech costs (factor 1.75). Barbarian research being slowed down by a factor of 2.5 is consistent with the research speed of the civs, but it feels too slow to me, giving the civs too much time to produce and position fog-busters before the Barbarians catch up in tech. I don't know, maybe this doesn't give a civ that has been slow to research e.g. Bronze Working enough time to catch up. Anyway, after this change, in tests on Marathon (Standard size, 8 players), the world's first Barbarian Galley was once placed around turn 200, once on t226. That's ... certainly still in the years BC. In the latter test, the first three non-Barbarian Galleys were finished on t175, t195 and t226. In tests on Normal speed, I saw the first Barbarian Galley on t71 (with only one earlier non-Barbarian Galley: on t68), t81 in another test (the first non-Barbarian Galley being finished on the same turn) and none ever in a third test. In that last one, all civs started on the larger of two continents, which made that continent pretty crammed, and some civs had inland starts, which slowed down the spread of Sailing. The Barbarians still got Sailing around t100 (only one prior non-Barbarian Galley, on t85), but the uninhabited continent was still off-limits (AdvCiv only spawns cities there) and the inhabited one had no fogged coast left. So these tests suggest that, if anything, Barbarian Galleys are still arriving too early on standard settings.

Thanks for the info; it's amazing how weak my factual knowledge of the numbers behind it is, considering how much time I've spent playing this game.

I checked my last save from the game I mentioned in worldbuilder and found half a dozen barb galleys out at 670 BC. Guess my late contact was due to being in an easy location for coastal fogbusting. Also, this game had 4 civs with inland starts. I'll do another game as soon as I have some free time.
 
Much of the AI code that I've added uses a custom type named ScaledNum and rounds as little as possible.
Would it be possible to contact you about the code? I'm very interested in modding it, and I have experience programming, but I'm new to C++ and because a lot of what I see is giant nests of custom classes and convoluted function calls I get a bit lost. If you're not available that's okay; I do have your manual, but for now it's not enough help for me as it doesn't specify what part of your edits change what and how.
 
Sure, I've started a Conversation with you. Some of the class templates are pretty nightmarish, EnumMap.h being the worst, I think. I place part of the blame on Firaxis's original software design. (Well, not blame exactly, it was suitable enough for their purposes.)
 
Is it possible to combine your mod with the XXL World mod? For K-Mod, I just copied the PrivateMaps folder, the file CIV4WorldInfo.xml and CIV4WorldPickerInfos.xml into the right directories and everything worked. This method did not work with your mod
 
It's not obvious to me why this wouldn't work at all. What error did you encounter?

AdvCiv specifies grid dimensions in terms of 2x2 cells instead of 4x4 cells in Civ4WorldInfos.xml. For example, WORLDSIZE_SMALL is set to
Code:
<iGridWidth>30</iGridWidth>
<iGridHeight>22</iGridHeight>
in AdvCiv, meaning 30*22*2*2=2640 tiles. This was 16x10 in BtS, meaning 16*10*4*4=2560 tiles. So, at 40x25, WORLDSIZE_XXL would only have 4000 tiles. This should not result in a crash or anything like that – though you'll probably want to double those numbers.

I've made a lot of tweaks to values in Civ4WorldInfos.xml, but those only affect the BtS map sizes, which, I assume, you don't intend to use anyway. So it shouldn't really hurt to just replace the whole file with the XXL version and then to adjust the grid sizes.

The 18-civ DLL of AdvCiv can't go past 32768 plots, but the 48-civ DLL (or attached here for the latest release candidate) should not have this limitation. That being said, the largest size that I test the mod with (and I haven't done so in a while) is the extra world size defined (but normally commented out) in Civ4WorldInfo.xml. That's 14892 tiles ("Huge" has 10240 in BtS, for reference, "XXL" in the XXL mod has 16000). If you were going to play on 16000 tiles (rather than 25600 "Giant" or even 38400 "Ultra"), then you could try just uncommenting the extra size in AdvCiv's Civ4WorldInfos.xml. This size uses values in line with the AdvCiv tweaks to the BtS sizes. Incidentally, I've named it WORLDSIZE_XXL, just as in the XXL mod.

Regarding the map scripts, maybe it's sufficient to only worry about the scripts that you actually want to use? Fractal should work without adjustments; neither AdvCiv nor the XXL mod make any changes to that script. The AdvCiv version of PerfectMongoose also does not reference any particular map sizes; however, this script could become prohibitively slow at super-Huge sizes. The XXL mod also makes no changes to Hemispheres, for example, but AdvCiv has added a function that reduces the grid size when using that map:
Spoiler :
Code:
def getNumPlotsPercent(argsList):
	[iWorldSize] = argsList
	if iWorldSize < 0:
		return 100
	sizeModifiers = {
		WorldSizeTypes.WORLDSIZE_DUEL:		95,
		WorldSizeTypes.WORLDSIZE_TINY:		77,
		WorldSizeTypes.WORLDSIZE_SMALL:		83,
		WorldSizeTypes.WORLDSIZE_STANDARD:	76,
		WorldSizeTypes.WORLDSIZE_LARGE:		74,
		WorldSizeTypes.WORLDSIZE_HUGE:		72
	}
	return sizeModifiers[iWorldSize]
Unfortunately, this does not allow for sizes greater than "Huge" – those will cause a Python exception. Actually, let me amend that right away: Git commit, updated maps attached to this post. With these changes, the scripts should be fully compatible with one extra map size that has ca. 15000 tiles – and should handle any sizes beyond that well enough. getNumPlotsPercent is intended as a replacement for the getGridSize function in BtS, but AdvCiv should also be able to work with getGridSize. For example, the modified getGridFunction of Earth2 in the XXL mod says:
Spoiler :
Code:
###===NM=====Extra World Sizes=1/3======0=== 
WorldSizeTypes.WORLDSIZE_XXL=WorldSizeTypes.WORLDSIZE_HUGE+1
WorldSizeTypes.WORLDSIZE_GIGA=WorldSizeTypes.WORLDSIZE_XXL+1
WorldSizeTypes.WORLDSIZE_ULTRA=WorldSizeTypes.WORLDSIZE_GIGA+1
###===NM=====Extra World Sizes=1/3======X===

# (...)

def getGridSize(argsList):
    "Enlarge the grids! According to Soren, Earth-type maps are usually huge anyway."
    grid_sizes = {
        WorldSizeTypes.WORLDSIZE_DUEL:      (10,6),
        WorldSizeTypes.WORLDSIZE_TINY:      (15,9),
        WorldSizeTypes.WORLDSIZE_SMALL:     (20,12),
        WorldSizeTypes.WORLDSIZE_STANDARD:  (25,15),
        WorldSizeTypes.WORLDSIZE_LARGE:     (30,18),
###===NM=====Extra World Sizes=2/3======0=== 
	WorldSizeTypes.WORLDSIZE_HUGE:		(38,24),
	WorldSizeTypes.WORLDSIZE_XXL:		(46,29),
	WorldSizeTypes.WORLDSIZE_GIGA:		(55,35),
	WorldSizeTypes.WORLDSIZE_ULTRA:		(65,44)
###===NM=====Extra World Sizes=2/3======X=== 
    }
This should be fine – assuming that Civ4WorldInfos.xml defines those three additional map sizes. The dimensions are given as 4x4 cells, and that's what the AdvCiv DLL expects too when it calls getGridSize. So those numbers can stay as they are, no need to double them.

I see no problem with the modified Civ4WorldPickerInfos.xml in the XXL mod.

The AdvCiv algorithm for choosing starting locations will disable itself on map sizes greater than 12000. Will fall back on the original algorithm, so this isn't really a problem; just thought I'd mention it. The limit can also be increased in GlobalDefines_advc.xml (SPI_PLOT_LIMIT, SPI_TIME_LIMIT_PERCENT), but it'll take a lot of extra time.
 

Attachments

  • PrivateMaps.zip
    106 KB · Views: 14
Top Bottom