patchFreeciv - Patches: patch #6518, foggedborders option(s) to always...

 
 
Show feedback again

patch #6518: foggedborders option(s) to always know own borders

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sun Nov 1 13:09:19 2015  
 
Category: NonePriority: 5 - Normal
Status: Need InfoPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 3.0.0Contains string changes: None

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)

Sat Feb 27 12:00:19 2016, comment #8:

> I may give up later if d3f approaches without a convincing patch.

This isn't going to make S2_6 d3f.

Jacob Nevins <jtn>
Project Administrator
Sat Feb 6 16:01:44 2016, comment #7:

> the player knows full well are not real.


Maybe we should list these somewhere else and to keep this ticket more focused, but:
- Popup "The Romanians are no more!" + I see Romanian territories.

Marko Lindqvist <cazfi>
Project Administrator
Sun Jan 31 12:32:35 2016, comment #6:

> I'd still like to have a go


Ok.

Besides, we got the fracture generator patch, so my idea of having sort of "data format candidate" build for Windows-using modpack authors to test wouldn't happen yet even if this one wouldn't be open.

Marko Lindqvist <cazfi>
Project Administrator
Sat Jan 30 22:17:48 2016, comment #5:

(My plan is to try implementing the complex player map resolution and see if it's a terrible idea in practice.)

Jacob Nevins <jtn>
Project Administrator
Sat Jan 30 22:16:58 2016, comment #4:

I have a less-than-half-written patch (the easiest bit).
I'd still like to have a go, but I may give up later if d3f approaches without a convincing patch.

Jacob Nevins <jtn>
Project Administrator
Sat Jan 30 22:10:43 2016, comment #3:

Do you still want this to 2.6? We have the basic design undecided when there's only one other d3f ticket open at all.

Marko Lindqvist <cazfi>
Project Administrator
Sun Jan 24 16:50:41 2016, comment #2:

> I probably were worried about potential timestamp/age related issues [...]
> merging to existing information would no longer be of tile granularity


Hm, good point.

It feels like we could go a long way by using the knowledge that the donor is an authority on their own borders to resolve merges.

Before transfer, I think there are two possible cases of a player A map tile with divergent information ages:

  1. A tile currently owned but not seen by player A.
  2. A tile lost by player A since they last saw it. (Probably has recent owner=B information where B is conqueror, per comment #0.)

Let's assume we just track tile contents age per-tile as currently, and ignore border age (because per-tile per-player tracking would eat lots of memory); then on transfer to player C with newer tile contents than A, the risk is that C will fail to take advantage of A's newer border knowledge (and that mistake can then propagate on).

We can often override the merging algorithm:

  • For case 1 above: for a simple transfer from A to C, C knows A is an authority on their own borders, so if they say they own a tile, believe them.
    • For case 2 above: if A says they don't own a tile, and C thinks they do, and C has newer tile knowledge, C could take A's owner even though it might be out of date, since C can infer that C's border knowledge is clearly older than A's in this case.
  • For shared vision known-not-seen updates, it looks practical to track that knowledge on to third parties, so that player maps for players X receiving A's tile knowledge via C are updated in the knowledge that the information about A's border came from A and is authoritative.

For case 1, that just leaves a tile with divergent data from A copied to a player D who had older tile knowledge, that is then propagated on to players X with newer tile knowledge than D; they would believe the border knowledge to be old and ignore it. (Rumours

Using the negative border inference mitigates case 2, even though the information that the border knowledge in A's map is new is lost immediately. Consider:

  • Imagine B's borders have encroached on A, through unseen territory into territory seen by A. A has an accurate picture of A's border, and hence B's too, because A saw itself losing ownership of every tile.
  • On a map transfer from A to C who saw A's unseen territory since A, if C doesn't use negative knowledge, C will end up with an outer ring of supposedly-A's territory (really B's) surrounding an area of B's territory (the part A can see). However, if C infers that the outer ring is no longer A's, they can believe A's owner info and end up with the same map as A.

In many cases, I think players will be receiving knowledge about a tile from a player whose territory is near it, and will be able to use one or other inference to help them.

...it's complicated, and won't give results quite as good as per-tile tracking, but may be worth it? I'm inclined to try it.

I also considered tracking in player X's map the turn when the last time a full map transfer was contributed from each of players A, B, C, ... and propagating those dates via further map transfers. That would be sufficient information for whole-map transfers, which are the most common kind. It doesn't help with the new partial map transfers. I'm also not sure how it interacts with case 2 above. Probably not worth bothering with.

(Other unrelated stuff I considered while thinking about this:

  • foggedborders=ALL border knowledge transfer is simple, because it can't get out of sync with tile knowledge. IIRC we don't do this properly currently; I think we should implement this.
  • Extra ownership: I think this should propagate with tile knowledge in all cases, in the same way city ownership does, and not with border knowledge. That could lead to some obviously contradictory situations on recipient maps, but that's true today as well.)
Jacob Nevins <jtn>
Project Administrator
Mon Jan 18 13:56:15 2016, comment #1:

>> [cazfi] You mean also those tiles that are not actually seen
>> by the shared vision giver, but for which borders are known
>> regardless? Why? I don't think there's even implementation
>> cleanliness argument for this.


Here I probably were worried about potential timestamp/age related issues. When one receives shared vision or map, merging to existing information would no longer be of tile granularity, but it would be possible that one player has more recent (but not necessarily current) information about border, and the other more recent information about terrain etc.

Marko Lindqvist <cazfi>
Project Administrator
Sun Nov 1 13:09:19 2015, original submission:

As discussed in bug #17301, the current behaviour of foggedborders=TRUE that tiles can be within your borders without this showing on your map is a bit daft.
(See also bug #19917?)

Turn 'foggedborders' from a bool to an enumerated setting:

  • DISABLED: all players always know all borders (current foggedborders=FALSE)
  • FOREIGN: you always know where your own borders are, but don't see foreign borders move unless you see the tile (new behaviour)
  • ALL: you may have out of date info for even your own borders (current foggedborders=TRUE)

Corner cases that need resolving with foggedborders=FOREIGN:

What do you see if someone steals your unseen tile -- unclaimed tile or knowledge of claimer? I'm leaning toward the latter -- narratively, if you heard that your distant frontier is no longer 'yours', you probably also heard something about who took it. This may be the way you first learn of your neighbours, which seems reasonable; and it means that if you know full well who your neighbours are already, border gaps don't open up which the player knows full well are not real.
(Don't know how hard this will be to implement.)

More controversial is what happens with diplomatic map transfer and shared vision (between teammates and otherwise). From discussion in bug #17301:

>> [jtn] (And shared vision shares knowledge of borders.)
> [cazfi] You mean also those tiles that are not actually seen
> by the shared vision giver, but for which borders are known
> regardless? Why? I don't think there's even implementation
> cleanliness argument for this.

My belated answer:

Having no way to transfer knowledge of one's own borders without holes will be annoying, just exporting the original problem to teammates and allies -- they will end up with hole-y maps of your borders which they know full well aren't correct, and could be unable to make correct decisions (e.g. routing around your real borders if you're only at Peace and they can't go through).

Perhaps one-off map transfers and shared vision should be considered separately?

  • One-off transfers convey known-not-seen information and that could include your current (then-correct) notion of your borders.
  • Does shared vision include an implicit transfer of known-not-seen tiles, or not? If not it needn't include your correct borders. If so, and the known-not-seen information is transferred every turn, then IMO logically they should get your updated borders.

If we have uses for both behaviours, the choice could be an extra value for foggedborders, but I'd rather not have the additional complexity if we don't need it.

Change of option format + intent to embed setting in supplied rulesets => consider for S2_6 d3f.

Jacob Nevins <jtn>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by cazfi (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

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Feb 27 12:00:19 2016jtnPlanned Release2.6.0, 3.0.0=>3.0.0
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup