Changes in what a 3.1 ruleset can do
Re: Changes in what a 3.1 ruleset can do
InNativeExtra unit state property See Feature #854185
You can now create a rule than an action only can target a unit in a base, like only allowing the player to bribe a plane (on the ground) in an airbase.
You can now create a rule than an action only can target a unit in a base, like only allowing the player to bribe a plane (on the ground) in an airbase.
Re: Changes in what a 3.1 ruleset can do
A requirement that a city is currently owned by its original owner.
This is implemented as a new CityStatus requirement type, that will in future be able to check other kind of city statuses too, but for now "OwnedByOriginal" is the only legal status to check. (Feature #858238)
This is implemented as a new CityStatus requirement type, that will in future be able to check other kind of city statuses too, but for now "OwnedByOriginal" is the only legal status to check. (Feature #858238)
Re: Changes in what a 3.1 ruleset can do
MinForeignPct requirement type. At least given percentage of city's citizens must be foreigners for the requirement to evaluate true.
(Feature #857904)
(Feature #857904)
Re: Changes in what a 3.1 ruleset can do
Requirement type "Activity" for depending on unit's current activity. (Feature #870905) See updated README.effects for the list of activities.
This alone is less useful than it may sound. For example "Move_Bonus" effect can't depend on properties of an individual unit. This patch was implemented as dependency for unhardcoding Fortifying rules.
This alone is less useful than it may sound. For example "Move_Bonus" effect can't depend on properties of an individual unit. This patch was implemented as dependency for unhardcoding Fortifying rules.
Re: Changes in what a 3.1 ruleset can do
Hardcoded defense bonuses for fortifying or being within city has been replaced by new Fortify_Defense_Bonus effect. (Feature #867744)
This moves both the requirements for getting fortify bonus and the amount of the bonus to ruleset. The old discussion of whether those units that are unable to fortify still to get fortify bonus when they are within a city is now under ruleset author's control.
This moves both the requirements for getting fortify bonus and the amount of the bonus to ruleset. The old discussion of whether those units that are unable to fortify still to get fortify bonus when they are within a city is now under ruleset author's control.
Re: Changes in what a 3.1 ruleset can do
Clean Pollution and Clean Fallout action enablers See Feature #850507
You can now create more complex rules for when a player can remove an extra by "cleaning" it.
The action "Clean Pollution" controls the CleanPollution removal cause. The action "Clean Fallout" controls the CleanFallout removal cause.
You can now create more complex rules for when a player can remove an extra by "cleaning" it.
The action "Clean Pollution" controls the CleanPollution removal cause. The action "Clean Fallout" controls the CleanFallout removal cause.
Re: Changes in what a 3.1 ruleset can do
More configurable map theft See Feature #873390
The new effect Maps_Stolen_Pct allows you to configure the probability that the map of a tile is stolen when successfully performing "Steal Maps" or "Steal Maps Escape". The ruleset setting steal_maps_reveals_all_cities allows you to configure if the map of all tiles with cities can be stolen.
You can now make "Steal Maps" and "Steal Maps Escape" steal the map of a different amount of tiles. You can also stop those actions from revealing cities.
The new effect Maps_Stolen_Pct allows you to configure the probability that the map of a tile is stolen when successfully performing "Steal Maps" or "Steal Maps Escape". The ruleset setting steal_maps_reveals_all_cities allows you to configure if the map of all tiles with cities can be stolen.
You can now make "Steal Maps" and "Steal Maps Escape" steal the map of a different amount of tiles. You can also stop those actions from revealing cities.
Re: Changes in what a 3.1 ruleset can do
Tile owner exported to Lua See Feature #874440
A tile inside a player's borders is owned. You can now find a tile's potential owner from Lua the same way you already could for a city and a unit.
Example: log all tile targeted actions
A tile inside a player's borders is owned. You can now find a tile's potential owner from Lua the same way you already could for a city and a unit.
Example: log all tile targeted actions
Code: Select all
function action_started_callback(action, actor, target)
local target_owner
if target.owner == nil then
target_owner = "unowned"
else
target_owner = target.owner.nation:plural_translation()
end
log.normal(_("%d: %s (rule name: %s) performed by %s unit %d on %s"),
game.current_turn(),
action:name_translation(),
action:rule_name(),
actor.owner.nation:plural_translation(),
actor.id,
target_owner)
end
signal.connect("action_started_unit_tile", "action_started_callback")
Re: Changes in what a 3.1 ruleset can do
"Conquer City" and "Transport Disembark" have been fake generalized. See Feature #850550, Feature #850551 and Feature #848684
"Transport Disembark 2" and "Conquer City 2" have been added. They are identical copies of the action they are named after. Each can have different ruleset defined properties like enablers, ui name and cost from the original.
You can now recreate the slow_invasions rules with your own twist or use the new fake fake generalized actions for something completely different. (You can of course also use them to implement the old slow_invasions with BeachLander exception rule, but that isn't a new ruleset ability.)
"Transport Alight", "Transport Unload", "Transport Board" and "Transport Embark" are currently not fake generalized. If you need one of them to be fake generalized head over to Feature #848708 and request it.
"Transport Disembark 2" and "Conquer City 2" have been added. They are identical copies of the action they are named after. Each can have different ruleset defined properties like enablers, ui name and cost from the original.
You can now recreate the slow_invasions rules with your own twist or use the new fake fake generalized actions for something completely different. (You can of course also use them to implement the old slow_invasions with BeachLander exception rule, but that isn't a new ruleset ability.)
"Transport Alight", "Transport Unload", "Transport Board" and "Transport Embark" are currently not fake generalized. If you need one of them to be fake generalized head over to Feature #848708 and request it.
Re: Changes in what a 3.1 ruleset can do
Configurable unit shield worth See Feature #874806
The new effect Unit_Shield_Value_Pct allows you to change how many shields the unit is valued when performing the actions "Recycle Unit", "Help Wonder" and "Upgrade Unit". The unit's shield value determines the amount of shields contributed to "Recycle Unit" and "Help Wonder". It determines the number of shields you must pay compensation for during "Upgrade Unit".
"Recycle Unit" and "Help Wonder" supports unit state like hit points as conditions. "Upgrade Unit" doesn't.
You can now
The new effect Unit_Shield_Value_Pct allows you to change how many shields the unit is valued when performing the actions "Recycle Unit", "Help Wonder" and "Upgrade Unit". The unit's shield value determines the amount of shields contributed to "Recycle Unit" and "Help Wonder". It determines the number of shields you must pay compensation for during "Upgrade Unit".
"Recycle Unit" and "Help Wonder" supports unit state like hit points as conditions. "Upgrade Unit" doesn't.
You can now
- make units capable of "Help Wonder" keep the same amount of their shield value during "Upgrade Unit" as during "Help Wonder"
- make "Help Wonder" contribute 85% of the shields used to build it rather than 100%
- make "Recycle Unit" give 50% of the shields used to build it if the recycled unit has less than 5 hit points and has a unit flag that means the unit type has 10 hit points