AssignStartingPlots defaults for VP

So, @azum4roll, do you implement the changes or would you let me do it this evening?

We can go with you method for introducing variation to stacks, but let it range 60%, 80% and 100%. And I think it distributes better with 30, 40 and 30 chances.

quantity = max_amount
if rand <30 then
quantity = math.floor(0.5 + 0.6*quantity)
elseif rand >70 then
quantity = math.floor(0.5 + 0.8*quantity)
end

Iron in forest needs a dramatic reduction too.
 
Last edited:
I don't see a reason to change 80%-120% to 60%-100%, unless you want to nerf coal (6/7/8 to 5/6/7), aluminum (6/7/8 to 5/6/7), oil (5/6/7 to 4/5/6) and uranium (2/2/2 to 1/2/2) too.

Just lowering horses and iron to 3 (3/4/5 to 2/3/4) is fine. Tundra and desert horses will be (2/2/3). There will approximately be 8 iron and 8 horses per player.

I'll try to do it when I have time.
 
I don't see a reason to change 80%-120% to 60%-100%, unless you want to nerf coal (6/7/8 to 5/6/7), aluminum (6/7/8 to 5/6/7), oil (5/6/7 to 4/5/6) and uranium (2/2/2 to 1/2/2) too.

Just lowering horses and iron to 3 (3/4/5 to 2/3/4) is fine. Tundra and desert horses will be (2/2/3). There will approximately be 8 iron and 8 horses per player.

I'll try to do it when I have time.
That will do.
 
Here, try this.

The amounts still fluctuate a LOT, but the size should be as intended now. Expect 6-10 iron/horses for each player.
 

Attachments

Here, try this.

The amounts still fluctuate a LOT, but the size should be as intended now. Expect 6-10 iron/horses for each player.
Did you account for the iron created in hills? I still can read this:
Code:
    resources_to_place = {
        {self.iron_ID, iron_amt, 90, 1, 3},
        {self.uranium_ID, uran_amt, 10, 1, 2}
    };
    self:ProcessResourceList(50 * resMultiplier, 1, self.hills_forest_list, resources_to_place);
    self:ProcessResourceList(55 * resMultiplier, 1, self.forest_flat_that_are_not_tundra, resources_to_place);
    self:ProcessResourceList(65 * resMultiplier, 1, self.tundra_flat_forest, resources_to_place);
 
Did you account for the iron created in hills? I still can read this:
Code:
    resources_to_place = {
        {self.iron_ID, iron_amt, 90, 1, 3},
        {self.uranium_ID, uran_amt, 10, 1, 2}
    };
    self:ProcessResourceList(50 * resMultiplier, 1, self.hills_forest_list, resources_to_place);
    self:ProcessResourceList(55 * resMultiplier, 1, self.forest_flat_that_are_not_tundra, resources_to_place);
    self:ProcessResourceList(65 * resMultiplier, 1, self.tundra_flat_forest, resources_to_place);
It was 45/50/60. I mainly removed the chance of minors though (and gave it to coal/aluminum).
 
Played a game to early Medieval era using the map script directly above. Seems OK generally. Significantly lower horses and iron than usual (about 15% less). That's only one game though so far.

Will the map have more strategics if I add more civs, or does it depend on map size?
 
Played a game to early Medieval era using the map script directly above. Seems OK generally. Significantly lower horses and iron than usual (about 15% less). That's only one game though so far.

Will the map have more strategics if I add more civs, or does it depend on map size?
Both.
The main generator places resources every x valid tiles, so bigger maps get more resources. But also there's a function that guarantees a minimum amount of resources per player, so you can modify your setting as you please.
 
The minimum guarantee is really low, so unless you go with like 16 players in a Standard map you likely won't notice a difference.
 
Wasn't it updated to 8 per player in the last version?
Guaranteed 4, actual average 8. The minimum is for extreme mapscript/settings.
 
Small changes.

- Guaranteed 7 strategics per player (1 may come from a few players taking statecraft).
- Iron density halved in forests.
- Improved this code for efficiency
Code:
                                    -- added by azum4roll: give some variance to strategic amounts
                                    local quantity = math.floor(res_quantity[use_this_res_index] + 0.5)
                                    local rand = Map.Rand(10000, "ProcessResourceList - Lua") / 10000
                                    if (rand >= 0.75) then
                                        quantity = math.floor(quantity * 1.2 + 0.5)
                                    elseif (rand < 0.25) then
                                        quantity = math.floor(quantity * 0.8 + 0.5)                   
                                    end
                                    --
 

Attachments

Now you're relying on a fallback code to do the work for you. That part of the code should never be run on a standard mapscript because it ignores terrain rarity. 7 coal per player is also too many.

Your optimization makes horses on tundra and desert 2/2/2 instead of 2/2/3 (I passed a 2.1 into the function to make it possible). They aren't identical.

No one's complaining there are too much iron in my version. Let's wait for more feedback before making changes. (Standard map only feedback, since Communitu_79a needs different rarities)
 
Last edited:
I'm happy to do more testing, but ideally it would be nice to have more info from people who play different settings. In my games (Huge map) the amount of resources each player has will largely be determined by map amounts, because there's lots of space. I think I'd have to add a lot of civs to increase how much there is overall.
 
Your optimization makes horses on tundra and desert 2/2/2 instead of 2/2/3 (I passed a 2.1 into the function to make it possible). They aren't identical.
Can fix.
How about this?
Code:
                                    -- added by azum4roll: give some variance to strategic amounts
                                    local quantity = res_quantity[use_this_res_index]
                                    local rand = Map.Rand(10000, "ProcessResourceList - Lua") / 10000
                                    if (rand >= 0.75) then
                                        quantity = quantity * 1.2
                                    elseif (rand < 0.25) then
                                        quantity = quantity * 0.8                 
                                    end
                                    quantity =  math.floor(quantity + 0.5)
                                    --
Thing is, in 50% of the cases you don't need to change the value twice in this form. Since there are problems with rounding, rounding can be done last.
Now you're relying on a fallback code to do the work for you.
No, the code is there in case the density of players is high. Usually the strategics placed by the main generator is about right.
No one's complaining there are too much iron in my version.
My last two maps showed cramped iron formations in boreal forests, even after your reduction. The analysis of the values suggest the same. It can be a corner case, twice, but unlikely.
 
Last edited:
I've asked people to playtest this on the main thread. We should wait for feedback before changing anything.
 
I've asked people to playtest this on the main thread. We should wait for feedback before changing anything.
Agreed. Let's keep the halving iron on forest in the wardrobe for a while and wait for feedback.

The optimization to the code above I am certain it does not change anything and it is still faster.
About the use of the failback code, I understand that there is a risk of relying on it, if we were at the early development stages. But we are not. The amount of strategics works well for most cases, so the failback code would be just for setting with cramped players or very corner cases. If we needed to balance it again, we only have to create maps with just 2 players to negate its function.

EDIT Anyways, we should send Gazebo the last working code, in case he launches a new version.
 
Last edited:
Agreed. Let's keep the halving iron on forest in the wardrobe for a while and wait for feedback.

The optimization to the code above I am certain it does not change anything and it is still faster.
About the use of the failback code, I understand that there is a risk of relying on it, if we were at the early development stages. But we are not. The amount of strategics works well for most cases, so the failback code would be just for setting with cramped players or very corner cases. If we needed to balance it again, we only have to create maps with just 2 players to negate its function.

EDIT Anyways, we should send Gazebo the last working code, in case he launches a new version.

I agree!
 
Here, try this.

The amounts still fluctuate a LOT, but the size should be as intended now. Expect 6-10 iron/horses for each player.

This version seems good. I've played a couple of games with it and I'm not seeing any obvious issues (although I haven't had a lot of late-game play yet).
 
Back
Top Bottom