bugFreeciv - Bugs: bug #16385, Consider changing how base...

Show feedback again

bug #16385: Consider changing how base ownership works to avoid problems with buoys

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sun 08 Aug 2010 12:22:44 PM UTC  
Category: generalSeverity: 1 - Wish
Priority: 1 - LaterStatus: Duplicate
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Release: Operating System: None
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun 08 Mar 2015 10:27:49 AM UTC, comment #14:

> Ok to close this ticket?

Nobody disagreed.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Thu 22 Jan 2015 10:14:51 PM UTC, comment #13:

This has been rewritten in S2_6, though not the way described in this ticket. Ok to close this ticket? Even if further redefinement is to be made, it's cleaner to start discussion in a new ticket based on current implementation, than to continue on a ticket based on old implementation.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sun 29 Dec 2013 12:55:56 PM UTC, comment #12:

I haven't been paying attention. What's the current state of developments in this area?

I see on trunk we have a separate extras_owner field in data structures and on network (added in patch #3630, some use made of it in patch #3870).

However, I guess it's still a work in progress, as I think the client ignores PACKET_TILE_INFO.extras_owner, and calls tile_set_owner() which sets both fields in the client data structure from PACKET_TILE_INFO.owner. So in effect I think it's a server-only notion at the moment.

Are there pending tickets I've missed?

Jacob Nevins <jtn>
Project Administrator
Tue 26 Jun 2012 11:56:12 PM UTC, comment #11:

I don't think I have anything worth looking at. If I ever pick this up again, I expect I'll be starting from scratch (albeit with the same basic design). Go ahead.

(For the record: I have a git stash off r17934, 2010-09-04, and I think the state is as I said in comment #4: "I've got a mess of code changes but nothing that compiles yet, and I've been getting a bit bogged down in the border code." The changes I have look to be mostly dull ruleset/network plumbing rather than the core logic. Hopefully some of the changes to border code in the past >18 months will mean I get less bogged down...)

Jacob Nevins <jtn>
Project Administrator
Mon 25 Jun 2012 04:14:02 PM UTC, comment #10:

I'm about to work on related code. Have you any code to share so I would not break what you've done so far / reinvent the wheel.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Fri 03 Jun 2011 09:18:41 PM UTC, comment #9:

see also bug #14236 bases claiming territory

Matthias Pfafferodt <syntron>
Project Member
Fri 03 Jun 2011 08:18:07 PM UTC, comment #8:

See also bug #18179 for another reason why reworking this is a good idea.

Jacob Nevins <jtn>
Project Administrator
Sun 10 Oct 2010 06:43:59 PM UTC, comment #7:

I wrote:

> Buoys act as "sea bases" for the purpose of reducing unhappiness in representative governments

I hadn't actually tested this, and I'm now not sure it's true; I now realise that the happiness effects only apply to unit classes in the base's native_to list, and buoys don't have any classes i that list. (Still haven't tried it, though.)

(This patch is currently a bit stalled as I haven't had time to work on it, although I'd really like to sort this lot out for 2.3.x.)

Jacob Nevins <jtn>
Project Administrator
Mon 06 Sep 2010 09:40:29 PM UTC, comment #6:

> By the way, about the code, an important function for removing
> a base properly is missing in my opinion.

I already have a separate patch 95% complete for factoring that out. I should finish it.

Jacob Nevins <jtn>
Project Administrator
Mon 06 Sep 2010 09:39:09 PM UTC, comment #5:

That's sound very great to me. For bug #16613, I will make new tests using autogames on custom rulesets (because I didn't have test bases enough), but it should be ready in about 1 week.

For patch #1864, it's not ready, there are probably big problems because of the borders removals when creating and removing a base. I can wait you do your change, it would help for that. Also you could handle it if you wish.

By the way, about the code, an important function for removing a base properly is missing in my opinion.

pepeto <pepeto>
Project Member
Mon 06 Sep 2010 09:24:00 PM UTC, comment #4:

Here's where I've got to:

First, after some work, I've more or less changed my mind about having a single "owner" field + borders flag in the tile; see below for reasoning. I'm now thinking about separate per-tile "tile owner" and "base owner" fields (both pointing to players).

Add new base flags "ownable" and "capturable". Make the existing "border_sq", "vision_main_sq", and "vision_invis_sq" properties require "ownable" to be set.

An "ownable" base is one that (usually) has an owner.

  • The initial owner is that of the unit who created it.
  • Once created, by default, an "ownable" base doesn't change owner. (Such a base can end up un-owned if a player is killed/removed, but this is rare. It could also happen with scenario/editor.)
  • An "ownable" base doesn't necessarily act as a border source (only if "border_sq" is set).

A "capturable" base is an "ownable" base that changes hands when occupied by a unit at war with the current owner.

  • Can't have a mixture of capturable and ownable-but-not-capturable bases on the same tile, so that's an automatic "conflicts" when loading rulesets.

[Edited: I hadn't seen bug #14236. While we're in there, it probably wouldn't be hard to add another option that controls whether a base remains owned when it contains no units. Would need to think a bit about details e.g. allied stacks.]

A fortress would thus be "ownable", "capturable", and have "border_sq" set -- this should result in no change from current behaviour.

A buoy would be "ownable" but not "capturable", and have the vision fields set, by default. Consequences:

  • It doesn't claim any borders (not even the tile it's on). This fixes most of the problems originally raised.
  • It can't be captured. The only way to stop the owner seeing with it is to pillage it (which is cheap and easy, if the owner isn't defending it).
  • In particular, my buoy can be inside someone else's borders and still provide vision to me.

The last point is more or less why I changed my mind about having a single owner; when documenting "ownable" it seemed unnecessarily dirty to say "this can't change owners (unless you build a city nearby)". I don't think having two owners changes the design much, in fact. (Obviously border claiming bases must have the two owner fields the same...) It also makes the necessary changes to the editor much cleaner, I think.

Something I've had in the back of my mind while designing this is a sort of capture-the-flag scenario -- this would use ownable capturable "flag" bases which have no particular effect (no border source, etc).

One thing I haven't quite worked out is whether capture-by-unit and capture-by-borders should both be controlled by the "capturable" flag, or whether they need separate options. (I'm assuming the former, for now.)

As far as client UI is concerned, I was thinking of an "ownable" base displaying a flag like a city does (when citybar is disabled), but having this be overridden by shields if there's a unit on the tile. This has the advantage of not requiring new graphics :)

I've got a mess of code changes but nothing that compiles yet, and I've been getting a bit bogged down in the border code. I'll probably wait for bug #16613 and patch #1864 to land before taking this up again.

Assuming everyone's happy, I'd like to get it in 2.3.0, which is why I'm working on it now (since it changes packet formats etc), but it probably shouldn't be a blocker.

Jacob Nevins <jtn>
Project Administrator
Mon 06 Sep 2010 08:57:02 PM UTC, comment #3:

another related question: should bases claim ownership of neighbouring tiles without a unit present? (see bug #14236)

Matthias Pfafferodt <syntron>
Project Member
Mon 06 Sep 2010 08:34:52 PM UTC, comment #2:

Related question: An empty bases (not protected by units) could be captured by enemy units?

pepeto <pepeto>
Project Member
Mon 06 Sep 2010 08:33:34 PM UTC, comment #1:

I follow you in your brilliant analysis. However, I am not sure of what do you propose as rules changes.

pepeto <pepeto>
Project Member
Sun 08 Aug 2010 12:22:44 PM UTC, original submission:

Something I've been thinking for a while, but been reminded about by a discussion on the forum:

Buoys provide vision to a specific nation, so it's necessary to somehow track who they belong to. This is currently implemented by re-using the border/ownership mechanism: the tile with the buoy on becomes part of the nation's territory (likely an isolated tile).

This implementation causes various gameplay issues:

  • Nations at peace with the buoy owner can't move into the buoy square. This allows obstructive nations to block off arbitrary parts of the ocean or straits with lines of buoys (which are cheap to build).
  • Buoys act as "sea bases" for the purpose of reducing unhappiness in representative governments; buoys can be built at will anywhere in the world, and sea units and transported land units can use that tile as a base from which to carry out an aggressive campaign without the usual penalties.
  • Unless playing with foggedborders, all players can deduce the location of a nation's buoys as soon as they are built.

I assume these are all unintended consequences.

IMO it would be better if there were a separate way to track ownership for bases without creating borders.

I don't think this new ownership concept needs to be per-base -- it's OK for all bases on a tile to have to "belong" to the same nation, and change ownership en masse -- so this probably means a change to the per-tile structure (which probably rules out changing this in S2_2).

I also don't think it makes sense for a base to be inside one nation's borders but "belong" to another, so continuing with a single "owner" field should suffice; an additional per-tile flag "borders" stating whether "owner" claims borders or is merely deriving benefits from any bases will suffice, I think.

I haven't thought this through exhaustively, but some implementation thoughts:

  • The definition of borders will be changed to treat tiles with a zero "borders" flag as unclaimed territory, regardless of who "owner" is (currently this is signalled by a null "owner");
  • When borders recede (e.g., city destroyed), the owner field is not cleared.
    • So a buoy near a city that is destroyed continues to give benefits to that city's erstwhile owner.
    • This leaves some "dead" but client-visible information in tiles without bases (effectively, the last claimant of that tile). If that's undesirable, the borders code could instead carefully clear owners except on tiles with all relevant bases, with the same effect.
  • Pillaging an owned base on unclaimed territory will not automatically be an act of war against the owner as far as diplomatic states are concerned; it's undefended and in international waters, thus fair game. (But of course, in the case of a buoy, they probably saw you coming, and are free to take exception to that.)
    • Slightly unsure about this, but I think something of the sort is necessary for balance. Perhaps it could at least be a diplomatic incident (excuse for war) like certain Diplomat/Spy actions.
  • The client UI would need to distinguish base and tile ownership in the tile middle-click popup.

Comments? Objections?

Jacob Nevins <jtn>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


   patch dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by syntron (Posted a comment)
  • -unavailable- added by pepeto (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 08 Mar 2015 10:27:49 AM UTCcazfiStatusPostponed=>Duplicate
      Assigned toNone=>cazfi
    Thu 22 Jan 2015 10:14:51 PM UTCcazfiCategoryNone=>general
    Sun 29 Dec 2013 12:55:56 PM UTCjtnAssigned tojtn=>None
      Dependencies-=>Depends on patch #3630
    Tue 26 Jun 2012 11:56:12 PM UTCjtnStatusIn Progress=>Postponed
    Wed 15 Sep 2010 10:47:40 PM UTCjtnDependencies-=>Depends on patch #1970
    Mon 06 Sep 2010 08:05:39 PM UTCjtnAssigned toNone=>jtn
    Sat 04 Sep 2010 06:09:44 PM UTCjtnStatusNeed Info=>In Progress
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup