Project

General

Profile

Actions

Feature #588

closed

Unhardcode tile claimability rules

Added by Alina Lenk 7 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Server
Target version:
Start date:
05/11/2024
Due date:
% Done:

0%

Estimated time:

Description

Move rules for whether a tile can be claimed by a border source (based on terrain class, adjacency etc.) partially to ruleset effects. The goal is for anything hardcoded to be completely symmetrical in the terrain classes of the involved tiles and leave that distinction to ruleset-defined requirements. This will also include turning the "Claim_Ocean" and "Claim_Ocean_Limited" tech flags into user flags (and for most of the supplied rulesets, removing them).


Files


Related issues 6 (0 open6 closed)

Blocked by Feature #614: Tile relationship requirementClosedAlina Lenk05/13/2024

Actions
Blocked by Feature #616: MaxDistanceSq requirementClosedAlina Lenk05/14/2024

Actions
Blocked by Feature #629: Continent/ocean size requirementClosedAlina Lenk05/16/2024

Actions
Blocked by Feature #652: MaxRegionTiles requirement at C/Adjacent rangesClosedAlina Lenk05/19/2024

Actions
Blocked by Feature #654: TileRel requirement "Region Surrounded"ClosedAlina Lenk05/20/2024

Actions
Blocked by Feature #678: TileRel requirement "Same Terrain Class"ClosedAlina Lenk05/24/2024

Actions
Actions #1

Updated by Alina Lenk 7 months ago

The way this patch works to allow access to all the previous behaviors (claim nothing, claim adjacent, claim continent / lakes and bays surrounded by the continent, claim anything), without half a dozen separate boolean effects, is to have thresholds (like the Casus_Belli_* effects).

Since an effect/requirement context can only hold a single tile, I've realized this using two separate effects (Tile_Claimable_From_Same and Tile_Claimable_From_Other) to evaluate against the target tile. The decision which tile to evaluate against was mostly made on a conceptual basis; the old behavior is phrased more in terms of "claim ocean (from wherever)" than "claim (whatever) from land".
Evaluating against the target tile does open the door to future changes, like making tiles with improvements (e.g. ocean tiles with fishing boats, bridges, burrow tubes etc.) claimable sooner.
There are also good arguments for instead evaluating against the border source, e.g. to let cities claim more than bases, or some bases claim more than others, or make it so coastal cities only claim sea tiles once they have a harbor. Hm. The more I think about it, the less sure I am that evaluating against the target is actually the more reasonable option. I'd appreciate any and all comments on this.

Alien ruleset: I decided to ditch the Claim_Ocean flag and directly use a tech requirement. If there were plans to give that flag to more than one tech, better to let me know now so we don't have to change it one way now and back later.

Stub ruleset: not sure about these changes. This preserves the old behavior, but that isn't really necessary for a minimal ruleset to be functional.

Finally, if there are any fundamental changes we want to make to what the rules can do before codifying them in a way ruleset authors depend upon, we should do them soon; possibly even before merging this, possibly after; definitely before S3_3-d3f, which is still a ways off, but the sooner, the better. (For instance, claiming parts another continent across a strait, or tiny islands in a city's coastal waters, or territorial waters along the coast in general; all of which would complicate the model, but some of which might be worthwhile.)

Actions #2

Updated by Marko Lindqvist 7 months ago

Haven't thought this much, but maybe you will: would it make sense to have this via enablers, as an internal action (we have those in 3.3. See Gain Veterancy and Escape) and no unit actor (so far all our enablers have a unit, but I have plans for other non-unit actions coming relatively soon anyway). That would give you both the "actor" and "target" requirements, as well as maybe being in line with how we implement things like these in the future, with the enablers.

Actions #3

Updated by Alina Lenk 7 months ago

I had thought about that, yeah; it would be a lot nicer. The problem with that (apart from the non-unit-actor thing, which is big enough in itself) is expressing the different levels of what's claimable. We'd either need a bunch of separate actions anyway (Claim Adjancent, Claim Continent etc.), or need a way to express whether actor and target are adjacent (currently only done via action range iirc), on the same continent, etc. Which, to be fair, sounds like something we'd want anyway, but it's not something we have currently.

Bottom line being, if we want to do it that way (which we probably do), there's a bunch of stuff we need to do first; so the question is whether to push this now and then probably change it again later, or scrap this for now until we can do it the better way.

Actions #5

Updated by Alina Lenk 7 months ago

Alina Lenk wrote in #note-3:

a way to express whether actor and target are adjacent [(...], on the same continent, etc. Which, to be fair, sounds like something we'd want anyway, but it's not something we have currently.

Raised #613 and #614 about getting started on this.

Actions #6

Updated by Alina Lenk 6 months ago

Updated patch based on Feature #616: MaxDistanceSq requirement. Though I am officially pushing this back (unforeseen circumstances notwithstanding) until I've at least gotten it to the point where it can all be done via requirements; switching from effects to an internal action later is less of a hassle than switching away from a threshold-based solution again.

Actions #7

Updated by Alina Lenk 6 months ago

  • Blocked by Feature #614: Tile relationship requirement added
  • Blocked by Feature #616: MaxDistanceSq requirement added
  • Blocked by Feature #629: Continent/ocean size requirement added
Actions #8

Updated by Alina Lenk 6 months ago

  • Blocked by Feature #652: MaxRegionTiles requirement at C/Adjacent ranges added
Actions #9

Updated by Alina Lenk 6 months ago

  • Blocked by Feature #654: TileRel requirement "Region Surrounded" added
Actions #10

Updated by Alina Lenk 6 months ago

Updated patch: All requirements are now unhardcoded. I've also gotten rid of the added effects to the stub ruleset, given that they're not necessary and that ruleset doesn't have any border sources with positive radius anyway.

I'm still deliberating whether to merge it like this, or add a "Same Terrain Class" TileRel requirement to need just one effect type (and streamline the implementation in some of the rulesets), or wait for non-unit-actor internal actions.

Actions #11

Updated by Alina Lenk 6 months ago

  • Blocked by Feature #678: TileRel requirement "Same Terrain Class" added
Actions #12

Updated by Alina Lenk 6 months ago

Alina Lenk wrote in #note-10:

I'm still deliberating whether to merge it like this, or add a "Same Terrain Class" TileRel requirement to need just one effect type (and streamline the implementation in some of the rulesets)

Did that. Updated patch is going to be the final one (I think); this might be migrated to an internal action later, but I'm not doing that now.

Actions #13

Updated by Alina Lenk 6 months ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF