Bumping this thread to ask if there is a way to put a hard limit on a type of unit?
I have updated the Imperialism v3 scenario, using Lua, and wish to limit each city to only three Mfg Goods unit.
Once all three are built, it could move to the first unit available on the roster or the next improvement. Or a pop up?
Wondering how feasible this would be?
One of the keys for canBuildSettings is
Code:
-- .conditionFunction = function(defaultBuildFunction,city,item) --> bool
-- if function returns true, item can be built if other conditions are met, if false, item can't be built
-- absent means no extra condition
This lets us set arbitrary conditions.
In
this lesson I count legions and tribe population, and only allow legions to be built if they can be supported by the tribe. I also deal with the fact that we can't see or change the item that a city is producing.
If you want to limit each city to 3 mfg Goods units
at a given time, the conditionFunction for Mfg Goods should be something like this (untested code)
Code:
local function limitMFGGoods(defaultBuildFunction,city,item)
local supportedMfgUnits = 0
for unit in civ.iterateUnits() do
if unit.type == object.uMfgGoods and unit.homeCity == city then
supportedMfgUnits = supportedMfGUnits+1
end
end
return supportedMfgUnits < 3
end
If the city supports less than 3 MfgUnits, true will be returned, and another one can be built (as long as the other conditions are met). If 3 or more are supported, false will be returned, so the city can't build an Mfg unit.
If you only want 3 mfg units to be built per city during the
entire game, you would use the state table. A cityProduction event would increment an entry in the state table when appropriate, and the conditionFunction would check this value. If this is what you meant, I can write it for you. It wouldn't be
that complicated, but just a little too involved to write 'off the cuff'.
Note that the code I provided above cycles through every unit on the map. That was the main reason I didn't include this type of functionality by default. One or two unit types making this kind of check is probably fine, but too many might cause noticeable lag when changing production in a large scenario. Getting around this is likely to require a scenario specific mechanism. For example, it might sometimes make sense to simply use the conditions that existed after production (and so, the calculation need only be run once per turn, then saved in the state table), but for other scenarios that might not make sense.