Changes in what a 3.0 ruleset can do

Contribute, display and discuss rulesets and modpacks for use in Freeciv here.
cazfi
Elite
Posts: 1789
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Postby cazfi » Mon Mar 23, 2015 5:47 pm

Caedo wrote:why this is 3.0 and not 2.7? What bigger things are planned?

As with any project that makes incremental improvements and releases somewhat regularly, there would never be a point where major version number jump could be justified by the size of the change. The linux kernel faced the same problem a couple of years ago. All the incremental changes in linux-2.6 series summed together were huge, but there never was single big release. So Linus just bumped the version number between two regular releases.
Our incremental changes since 2.0 are getting major enough to call release after the next 3.0. And like one point Linus made about Linux entering third decade, freeciv will be well over 20 years old by the time 3.0 gets released (though, if we followed this rationale all the way, it would have made more sense to release 3.0 instead of 2.6 already. But by the time we though about that, 2.6 was already mentioned in so many places it made no sense to start changing that - our time is better spent on real development than adjusting version numbers for no gain at all)

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Fri Mar 27, 2015 3:29 pm

TL; DR: Here be dragons.

Don't expect this to do more than advertised. Expect it to have severe bugs that cause it to do something else than advertised. Example: bug #23423

Techs can now have the new research_reqs requirement vector. See patch #5944

The requirement vector research_reqs controls if a player is allowed to research it. (Think req1 and req2, not root_req) For shared research it is enough that it is fulfilled for one of the research sharing players.

Requiring other techs should still be done via req1 and req2. Only requirement types like AI, Nation and NationGroup are currently supported.

In the future I hope it will replace req1 and req2, allow (other) changing requirements and allow more than two tech requirements. Currently I don't know the tech code well enough to do that. I wasn't planning to announce this yet. Then someone discovered it. A warning was therefore appropriate.

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Wed Apr 01, 2015 9:59 pm

The rule that a unit must be on terrain it can exist on without being inside a transport to found a city now lives in the ruleset. See patch #5977

The rule that a land settler can't found cities on the ocean tile it is transported over (and that an ocean settler can't found a city at the land tile it is transported over) used to be hard coded. It has now moved to the ruleset. Note that other rules, like the rule that it is illegal to found a city on terrain with the NoCities terrain flag, still are hard coded.

You can keep the old rule by adding the requirement that the actor can't be "TransportDependent" to all "Found City" action enablers. You can remove the old rule completely by removing said requirement from all "Found City" action enablers.

Example: change the alien ruleset so the wonder "Antigrav Control Center" permits its owner to found cities on terrain it can't exist on without being transported.

Code: Select all

[actionenabler_build_city]
action = "Found City"
actor_reqs    =
    { "type",   "name", "range", "present"
      "Unitflag", "Cities", "Local", TRUE
      "UnitState", "TransportDependent", "Local", FALSE
    }

[actionenabler_found_city_antigrav]
action = "Found City"
actor_reqs    =
    { "type",   "name", "range", "present"
      "Unitflag", "Cities", "Local", TRUE
      "Building", "Antigrav Control Center", "Player", TRUE
    }


The first action enabler, actionenabler_found_city_everybody, is the rule that used to be hard coded. It can be translated to English as "Founding a city is legal when the actor unit has the Cities unit type flag and aren't dependent on a transport to exist at its current location".

The second action enabler, actionenabler_found_city_antigrav, is the new rule. It can be translated to English as "Founding a city is legal when the actor unit has the Cities unit type flag and is owned by the player that owns the wonder Antigrav Control Center".

When both action enablers are added all players can found cities on native terrain but the player that has the Antigrav Control Center can also found cities on non native terrain.

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Thu Apr 30, 2015 3:40 pm

More ruleset control over the one time bonus when entering a marketplace or establishing a new trade route.

It is now possible to change the one time bonus for one of the actions but not the other by using an Action requirement with the Trade_Revenue_Bonus effect.

The reduction of the bonus when entering the marketplace in stead of establishing a new trade route is no longer hard coded. You can now give them the same bonus or even make the bonus of entering the marketplace larger than the bonus of establishing a trade route. The bundled rulesets with trade route establishing and marketplace entering have kept the old rule by adding the following effect:

Code: Select all

[effect_enter_marketplace_bonus_reduction]
type   = "Trade_Revenue_Bonus"
value   = -1585
reqs   =
    { "type", "name", "range"
      "Action", "Enter Marketplace", "Local"
    }


The fudge factor to make the one time bonus appear to be more like the one in Civ 2 is no longer hard coded. The bundled rulesets where trade route establishing and marketplace entering is possible have kept it by adding the following effect:

Code: Select all

[effect_bonus_fudge_factor]
type   = "Trade_Revenue_Bonus"
value   = 1585

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Sun May 03, 2015 4:28 pm

The rule that a unit can't join a foreign city is no longer hard coded. See patch #6059

The added population has the nationality of the unit ordered to join. No mechanism that allows the city owner to reject the immigrants exists yet. A unit must still be inside a city to join it. (It is still only possible for a unit to enter cities owned by its owner or an ally of its owner)

Usage idea stolen from Jacob Nevins:
JTN wrote:Could be an interesting peacetime dynamic -- receiver immediately gets the benefit of an extra citizen, but donor gets reduced incite cost, increased migration chance (etc) should relations between the nations change.

JTN wrote:certain government types allow this kind of immigration

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Wed May 13, 2015 2:24 pm

The rules that a unit can't join or found city when out of moves are no longer hard coded. See patch #6084 and patch #6085

Possible uses:
  • allow a unit to join a city even if the last move fragment was spent moving into the city.
  • the "Hab Tank" unit. Can't move on its own. Can join a city. Can be transported by a "Large Former" unit. Can found cities while transported.

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Fri Jun 05, 2015 3:15 pm

The ruleset now has more control over when an action cause a diplomatic incident. See patch #6099, patch #6100 and patch #6107

A diplomatic incident gives a casus belli against the player ordering the action to be performed. The senate won't block a war declaration when it is shown a casus belli.

Two new effects have been added to control when an action will cause an incident. The effect Casus_Belli_Success makes successfully performing the action cause an incident. The effect Casus_Belli_Caught makes getting caught while trying to perform the action cause an incident. (Getting caught during a diplomatic battle can't cause an incident. I'm considering to change this)

The following rules are now possible:
  • Getting caught while trying to steal a tech, steal gold, have a city change side or sabotaging a city will cause an incident.
  • Ordering a Settler to join an allied city will cause an incident.
  • Successfully sabotaging a city is consequence free. Getting caught trying is reason for war. (The senate wants evidence, not accusations)
  • Bribing a unit will only cause an incident if its owner is an ally.

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Wed Jul 08, 2015 12:33 am

I just added Steal Maps, a new Spy action. See patch #6120

When successful about 50% of the victim's world map is transferred to the thief's owner. The spy must defeat any defending diplomats and beat the diplchance odds. (Rationalized as the spy stealing the local maps for some regions but not the full world map)

You can rename it using ui_name_steal_maps.

To add it in your ruleset you must create at least one action enabler for it.

Example: Allow all spies to do Steal Maps as long as they are on livable terrain and have some movement left, Stealing the map of barbarians is illegal.

Code: Select all

[actionenabler_steal_maps]
action = "Steal Maps"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "Spy", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }
target_reqs  =
    { "type",   "name", "range", "present"
      "NationGroup", "Barbarian", "Player", FALSE
    }

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Mon Jul 20, 2015 8:55 am

Bombardment is now action enabler controlled. See patch #5610, bug #22713 and patch #6133

Bombardment is enabled by the "Bombard" action rather than by the "Bombarder" unit type flag. The "Bombarder" unit type flag has been retired. The rule forbidding bombardment of ocean tiles isn't hard coded any more. The rule forbidding transported units from bombardment isn't hard coded any more. You can add the "Bombarder" flag back as a user unit type flag and require it in your "Bombard" action enablers. You can add the rules that use to be hard coded to your "Bombard" action enablers.

You can now
  • change the name and mnemonic of the bombard action. Controlled by ui_name_bombard
  • allow oceanic tiles to be bombarded
  • allow transported units to bombard
  • add new rules controlling when bombardment is legal. (Example: Nations with a democratic government can't bombard cities after radio is discovered) The action to enable is "Bombard"

sveinung
Elite
Posts: 491
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Tue Jul 21, 2015 5:03 pm

I just added Suitcase Nuke, a new Spy action. See patch #5536

When successful a nuclear explosion occurs in the victim city. The spy must defeat any defending diplomats and beat the diplchance odds.

You can rename it using ui_name_suitcase_nuke

To add it in your ruleset you must create at least one action enabler for it.

Example: Allow the owner of the Manhattan Project to use his spies to suitcase nuke enemy cities. (The spy must have movement left and be on terrain he can live on without being transported)

Code: Select all

[actionenabler_suitcase_nuke]
action = "Suitcase Nuke"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "Spy", "Local"
      "DiplRel", "War", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
      "Building", "Manhattan Project", "Player"
    }