Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Xyon]

So, we all know it currently goes [POPULATION_CAP:#], and quite a few player have differing opinions about migration wave size causing their fortress to grow too fast, or maybe rarely they think its too slow.  I have seen suggestions that players actively change the population cap in d_init to indirectly control migration waves, but I have an idea.

Lets change how population cap is inputted in d_init to a multi-step input.

Generic input argument  [POPULATION_CAP:#1:#2:#3:#4:...:#n:#n]

How does this work? The game will change the population cap on graduated steps that are fed as inputs.  It will base migration and population related stuff off of the first number being the pop cap, and then once the first pop cap is reached, it will read the next input value and change the pop cap to the new value.  It keeps doing this until it reads the next pop cap as being the same as the last pop cap, at which point the pop cap is set at the final value.

Example [POPULATION_CAP:10;20;30;30]
How this would play: Population cap is set for 10,  once you get 10 pop, it will switch to population cap 20, once you get 20 it will switch to population cap 30,  once you get 30, it will read the next population cap as 30, which was same as the last population cap, which will then set the final cap at 30.

I can see this perhaps being less elegant than any other solution for migration waves, and may be more trouble than its worth. But it could be interesting, and would certainly allow for "dwarven society" to set more strict rules or ritual in how many dwarfs should be put in a fortress before any more dwarfs are considered to be placed into a fort.


Second alternative generic input  [POPULATION_CAP:S:N:E:F]
How this would work,  population cap starts at the value listed in S,  it will increase in steps of N, up to a final population cap size of E, the population cap increases at a frequency of F.

Example  [POPULATION_CAP:10:20:150:4]
How this specific example would work.  Population cap starts at 10,  after the population hits 10, the population cap would increase up by 20 to 30 total, this would happen at frequency 4, so from how I imagine it, this would mean that after 4 seasons being at population 10, the cap would then increase to 30. This keeps happening in steps of 20 to the population cap, each time the population reaches the cap it would stay that size for 4 seasons, and this ends with a final population cap of 150.

[bloop_bleep]

The first version of POPULATION_CAP you showed doesn't really make much functional sense... isn't it equivalent to just setting the cap to 30 in the current system?

[Xyon]

From what I've heard, the way migration waves work, is that any migration wave you get will at most have your population cap minus your current population minus one, or something like this, so I've heard.

So if your population was 20, and your cap was 30, you'd only get 9 max possible migrants in a population wave.   So the first example of a pop cap system would be a way to set up micro-caps on migration waves.

So lets say you start with 7 dwarfs, and the first pop cap is 10,  you'd get maybe 2-3 dwarfs in your first wave, bringing you up to your cap,  then your new cap would bump up to 20, limiting your next migration wave to 9-10 dwarfs max. 

In essence, this would just be a nice way to control migration wave size from being too big, if migration waves are indeed controlled by the difference between your current population and your max population cap. 

[GoblinCookie]

I think the long-term plan is to have migrants generated by actual world-gen factors, rather than having migrant waves created to order. 

[Xyon]

I guess, but that still wouldn't really stop people from editing the ini files to change their pop cap to control migrant wave size if they wanted to. At least it could be easier by adding in additional input options for it.

[GoblinCookie]

I guess, but that still wouldn't really stop people from editing the ini files to change their pop cap to control migrant wave size if they wanted to. At least it could be easier by adding in additional input options for it.

It would if the migrant waves are not created to be of a given size to begin with.