[MODCOMP] Beyond 40 Civs.

[Somebody613]

Yes, it's an old question.
Yes, it has been answered.
No, I don't recall ANY of that answer, blame my "perfect memory".
So...
I do recall that there is a way to mod for more than 40 Civs (current request: 100 Civs; best option: variable).
Would anyone care to not just remind me how to do it, but also to waste a bit (hopefully) of their time and actually post a working [ModMod] that does it?
I have some great ideas how I could use it for my own personal gaming, and you shouldn't worry about it "breaking the game" anyways - it's MY game, lol.
Pweetty pweese?

 

[raxo2222]

You need github repository, or at least download source code from github and compile it.
And you need to compile it every time new SVN is out.

That is it is coded in c++ and you need to edit many files.

 

[Somebody613]

You need github repository, or at least download source code from github and compile it.
And you need to compile it every time new SVN is out.

That is it is coded in c++ and you need to edit many files.

Damn, I felt like that was the "answer".
So, would making a modular "slider" (implemented in whichever way you'd like) for this particular option be too much of a nuisance to bother adding to begin with?
Because, like I said, it could be rather useful in certain [scenarios], where "memory overflow" can be controlled via in-game specifics (and thus not break the game).

 

[raxo2222]

Damn, I felt like that was the "answer".
So, would making a modular "slider" (implemented in whichever way you'd like) for this particular option be too much of a nuisance to bother adding to begin with?
Because, like I said, it could be rather useful in certain [scenarios], where "memory overflow" can be controlled via in-game specifics (and thus not break the game).

Maybe @Toffer90 is creative enough to make it a XML global define, if civ team and player ID can be changed in existing save
Otherwise it would break saves every time you change it.

 

[Somebody613]

Maybe @Toffer90 is creative enough to make it a XML global define, if civ team and player ID can be changed in existing save
Otherwise it would break saves every time you change it.

I was pretty much wishing for a XML variable, indeed.
And who cares about save breaks, if the entire goal is to make specific scenarios in the first place?
I could simply ask for a fixed change as well, but I see that... wait a second!
There is a BUG option to control this in regards to emerging civs (from "DLL max" to some rather low values).
So, for those who find it being a problem of MEMORY CONSUMPTION - then just put that variable at "40" (or whatever), and that's it.
Whereas those (like myself) who would like to be able to use higher values for specific scenarios and cases could put it on "DLL Max" and enjoy the results.
UNLESS, of course, like you said - it'd botch some OTHER calculations that are happening all the time REGARDLESS of the currently existing number of civs.
Is that maybe true, huh?
Then, yeah, tough luck for my wish, ehehe.

 

[Thunderbrd]

I was pretty much wishing for a XML variable, indeed.
And who cares about save breaks, if the entire goal is to make specific scenarios in the first place?
I could simply ask for a fixed change as well, but I see that... wait a second!
There is a BUG option to control this in regards to emerging civs (from "DLL max" to some rather low values).
So, for those who find it being a problem of MEMORY CONSUMPTION - then just put that variable at "40" (or whatever), and that's it.
Whereas those (like myself) who would like to be able to use higher values for specific scenarios and cases could put it on "DLL Max" and enjoy the results.
UNLESS, of course, like you said - it'd botch some OTHER calculations that are happening all the time REGARDLESS of the currently existing number of civs.
Is that maybe true, huh?
Then, yeah, tough luck for my wish, ehehe.

The dll has to be compiled with the limit - it's too fundamental in the underlying exe architecture to vary and will cause crashes if we attempt to make it player adjustable. Think of it like part of the ingredients that need to be baked into the cake and cannot be later adjusted like our options with icing and sprinkles. With enough memory freeing we might be able to later expand it, but for now, we haven't just freed up memory to allow for folks to get through the whole game just so we can re-expand the player limit to the point of putting us back where we started on needing to find more for the stability we've earned. Once the 'game' design is more where we are wanting it to be, we will revisit the question of how many players we can get away with having. Had we had core architectural control, we might've been able to build it out so that we could change the max, but firaxis figured that the staging room would give you that control for a game and we set the current limit for the sake of not inviting insanity in game setup.

 

[Somebody613]

The dll has to be compiled with the limit - it's too fundamental in the underlying exe architecture to vary and will cause crashes if we attempt to make it player adjustable. Think of it like part of the ingredients that need to be baked into the cake and cannot be later adjusted like our options with icing and sprinkles. With enough memory freeing we might be able to later expand it, but for now, we haven't just freed up memory to allow for folks to get through the whole game just so we can re-expand the player limit to the point of putting us back where we started on needing to find more for the stability we've earned. Once the 'game' design is more where we are wanting it to be, we will revisit the question of how many players we can get away with having. Had we had core architectural control, we might've been able to build it out so that we could change the max, but firaxis figured that the staging room would give you that control for a game and we set the current limit for the sake of not inviting insanity in game setup.

Once again, I'm confused.
So can or can't you brute-force it to be, say, 100 - and then leave it as "the player's problem" to actually PLAY the result?
Basically, just compile TWO versions of that file - one with 40 civs and one with 100 (or even 200).
That way we (me, lol) can play "normal" games as usual - and "scenario" games with Infinite Civs, loool.
Case in question being Eternity Prehistory, which is slow enough to NOT get too affected by the number of civs on the map.
Better yet, and this is in correlation with my [Ryes-C2C] idea in Scenarios:
It's very much possible to have 100 civs, and only 20 of them be PLAYABLE in the first place, keeping the rest as placeholders of sorts.
This is what I've seen being done with Barbarian cities in other mods - but it's be way better to do it via actual separate civs (that still would be forced to not do much beyond existing as cities).
Basically, this would be mostly useful only for "conquer a civ" events and so on - the major difference between Barbarian cities and actual separate civs cities.
I'm obviously NOT intending to play a full-scale game with 100 civs in any other case, loool - that's just CRAZY.
But to use them as stand-alone city-states, now THAT would be a great application, indeed.
Well, just my thoughts, ya know.

 

[Thunderbrd]

So can or can't you brute-force it to be, say, 100 - and then leave it as "the player's problem" to actually PLAY the result?

The problem is that the memory expenditure is the same whether the player chooses 100 or 50 at that point. The memory expenditure is determined when the dll is compiled and whether the player is accessing those memory slots or not, there's a ton allocated to those extra players either way. So whether you play it with the cap or not, it will allocate as if you are - obviously it makes it even MORE draining if you do because of all the things that would then later build up underneath that player allocation, but it's not an insignificant amount what the game sets aside just to have a possible player. We also have numerous options that can later add more players to the game if there is room for them within that cap and under those options, even 100 would regularly become what the game has defined.

There are too many dll updates to keep up on having to set up the file system to house both versions and it's likely too confusing to explain to players how to switch use from one to the next for that to be feasible.

 

[Somebody613]

The problem is that the memory expenditure is the same whether the player chooses 100 or 50 at that point. The memory expenditure is determined when the dll is compiled and whether the player is accessing those memory slots or not, there's a ton allocated to those extra players either way. So whether you play it with the cap or not, it will allocate as if you are - obviously it makes it even MORE draining if you do because of all the things that would then later build up underneath that player allocation, but it's not an insignificant amount what the game sets aside just to have a possible player. We also have numerous options that can later add more players to the game if there is room for them within that cap and under those options, even 100 would regularly become what the game has defined.

There are too many dll updates to keep up on having to set up the file system to house both versions and it's likely too confusing to explain to players how to switch use from one to the next for that to be feasible.

Well, it's a bit sad, lol.
I'm still "dreaming" (not really, but it'd be cool) of a Civ game that would allow for literally ALL existing countries to be separately playable at once, loool.
Basically, 40 civs is also quite a lot - it's just that the Earth Map is big enough to make even that number a bit "too spread out", as strange as that sounds.

 

[Thunderbrd]

I get it... I've had that dream myself. Unfortunately it's going to be tough for the CivIV engine to manage that, probably ever but you never know what further wizardry lies in our future.

 

[Somebody613]

OK, downloaded GitDesktop and all the stuff, including the repository, also compiled it (provides somewhat less files than SVN, like no C2C.exe).
Sooo, which file (in the Git Rep, obviously) do I need to edit for the number of civs - and how exactly?
Ah, I had to run Launch from Git first, so it build those files.
Damn, this is counter-intuitive in many senses.

EDIT:
Never mind, randomly found it - it's CvDefines.h, apparently.
Well, let's see what I can mess with in there, mwahahaha!!!
And... done - now compiling, then gonna test the result, lol.
And if it works, let's see how I can make a 100-civ Earth Map, mwahahahahaha!!!!!
(I know it's gonna lag like crazy, don't worry. But IF. IT. WORKS. loool!!!)

Speaking of which:
I definitely see the math behind City Plots (so I can recalculate and add lines for, say, 4-width city) - but would it work, or I'd need to trace and edit how each width layer is enabled in the first place?

EDIT:
Weird, for some unknown reason the game closes each time I try to run a map with more than 40 Civs.
I first tried 100 on Standard (for faster map generation), which could've been too many, but it also broke on 50 civs as well (which definitely isn't too many, since it can easily cram 40 civs even into a Duel map, for a fact).
And I'm not sure this is memory-related.

EDIT (just to show the whole process, sorry for self-talking at you, lol):
Aha, finally, it works.
I guess I randomly chose a wrong map script, so there wasn't enough land to put so many civs on, lol.
Pangea works just fine, though.
Now gonna add the Civs Mega Modpack and go for 100 civs, just to prove that it can be done.

EDIT:
Aaand...
DONE!!!
Check the screens (1-3) and the save file (which isn't gonna work for you, oopsie, but I'll leave it to show that it exists, lol).
All contacts added via WB, obviously.
YYYEEESSS!!!

Now, whether this is PLAYABLE, is a different story - for a different time.
So far, I'm happy with what I've already achieved, loool!

Still waiting for the City Radius Editing question, though.

Oh, and one more question. (c)
How (and whether) can I enable a One-Unit-Per-Tile rule?
This would IMMENSELY reduce the memory avalanche caused by countless units, ya know.
And I don't even mind playing that way, if I can literally edit the Earth map for, say, 200+ civs.
As in, putting ALL existing (real world) civs from the MEGA PACK onto the Earth map in an actually playable manner.
Yes, it would destroy some of the new Combat Modes - but, well, sacrifices-shmacrifices.
LOOOL!!!

 

[Somebody613]

So far:
1. No way to edit the total number of civs AND keep functional animals (sad, but not entirely game-breaking).
2. No problem to edit the number itself into whatever I want.
3. Barbarians always work anyways.
4. I'm so blind - there's literally a BUG option for "the number of units per tile" (so there's the easy "prevent the units from overcrowding the map" feature right there in the plain sight).
To sum up:
Be ready for a whooping All Existing Civs (200+) Earth Map soon-ish enough.
Unless I get even more lazy, hehehe.

 

[BlueTemplar]

[...]
There is a BUG option to control this in regards to emerging civs (from "DLL max" to some rather low values).
So, for those who find it being a problem of MEMORY CONSUMPTION - then just put that variable at "40" (or whatever), and that's it.
Whereas those (like myself) who would like to be able to use higher values for specific scenarios and cases could put it on "DLL Max" and enjoy the results.
[...]

FYI, my game (which should use the default values for 41(.2?)) gives me these :

 

[Somebody613]

FYI, my game (which should use the default values for 41(.2?)) gives me these :

View attachment 640423

Where did you get this from, lol?
Anyways, this means you have some values not at max, because I definitely recall getting the full 40 civs out of emerging Barbies, 100%.

 

[BlueTemplar]

From the C2C options popup through Ctrl+Shift+Q.

 

[Somebody613]

From the C2C options popup through Ctrl+Shift+Q.

I see.
But I definitely recall playing a game with zero initial civs and Barb Civs (and "max Barb civs = DLL"), which eventually ended up with a map full of 40 emerged civs.
So either you have different options, or this info is a lie bug, lol.