bugFreeciv - Bugs: bug #21437, Autosettlers ignoring special...

 
 
Show feedback again

bug #21437: Autosettlers ignoring special resources (mining hills without coal when coal is available)

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat 04 Jan 2014 04:27:24 PM UTC  
 
Category: aiSeverity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Release: trunk r23942Operating System: GNU/Linux
Planned Release: 2.6.0

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)

Fri 18 Jul 2014 07:45:47 AM UTC, SVN revision 25612:

Autosettlers calculate tile improvement value differently depending on
whether tile is currently being worked by the city or not.
For already worked tiles, we look for greatest delta (improvement to
city). For future tiles we look for having greatest total output from
the tile we're going to work next.

Needs to improvements in this area reported by Jacob Nevins

See bug #21437

(Browse SVN revision 25612)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Mon 14 Jul 2014 11:49:29 PM UTC, comment #10:

- Apply WORKER_FACTOR to value of improving currently unworked tiles

(file #21424)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat 05 Jul 2014 11:22:58 PM UTC, comment #9:

> Currently it always looks for biggest improvement, primarily
> among the worked, and with halved want among non-worked tiles.
> That's correct way to go with worked tiles. City gains more
> from +2 to one tile than +1 to another tile, no matter what are > their totals.
> However, with non-worked tiles it should look for making best
> total so that next tile to get worked produces as much as
> possible. Improvement of +1 on top of 3 would produce better
> total than +2 on top of 1.


Untested patch to achieve these different modes depending on if tile is worked or not.

Taking this ticket for this improvement as there's no other clearly defined goals.

(file #21283)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sun 30 Mar 2014 12:16:30 AM UTC, comment #8:

This is caused by the benefit given for tiles that produce at least one of something in city_tile_value().

Under Despotism with no techs in classic ruleset, tiles have the following values:

Hills: 1/0/0 == weighted score 37 (25+12)
Hills/Mine: 1/2/0 == weighted score 107 (25+12+56+14)
Hills/Coal: 1/2/0 == weighted score 107 (25+12+56+14)
Hills/Coal/Mine: 1/4/0 == weighted score 163 (25+12+112+14)

So, the autosettler sees the improvement from Hills to Hills/Mine as providing 70 points of goodness, and the improvement of Hills/Coal to Hills/Coal/Mine only providing 56 points of goodness. Unless there is a significant time difference involved that affects the amortization of the goodness, then the worker thinks it is obviously better to improve the non-coal hills, because this makes the shield value greater than 0, while providing the same total benefit otherwise.

Note that this isn't quite enough to override the working flag. If the city isn't working the tiles, the points are halved, so 35 and 28. Since 35 is less than 56, a worked coal tile would get mined before an unworked non-coal Hills.

For comparison, irrigation of grassland goes from 2/0/0 to 3/0/0 under the same conditions, so 62->87 (25 points), so won't be done until all the hills are mined (even if they remain unworked). Adding a road to grassland is similarly unappealing (2/0/0 to 2/0/1 is 62->84 (22 points), and would happen only after all the mines are in place, and irrigation done for all worked tiles (preference is mine(non-coal), mine(coal), irrigation(worked), road(worked), irrigation(unworked), road(unworked)).

As a result, given a city with the classic ruleset given a mix of grassland and hills, autosettlers would always choose to work the hills, regardless of whether they were used, and prefer to work the non-coal hills to the coal hills, except in the event that the city governor happened to decide to work a coal hill before all the non-coal hills were mined, in which case that coal hill would be mined before continuing to other non-coal hills. That said, if at least one non-coal hill has been mined before the city governor decides it needs shields, the city governor won't see any difference between the mined non-coal hills and the unmined coal hills, so there's even chances of selecting either.

To address this, the weightings can be adjusted more again, the benefit of giving at least one of something to a tile can be reduced, or the city governor can be hinted to prefer tiles with greater future capacity to tiles without (so in this contrived case, the governor would always choose unmined Coal over mined non-Coal). My thought is that it would be good to reduce the benefit of having at least one point enough to encourage autosettlers to irrigate worked grassland before mining unworked hills, and to adjust the city governor to consider the future potential benefit of tiles when they are otherwise equivalent when selecting which tiles to work, while leaving weighting the same.

Emmet Hikory <persia>
Project Member
Sat 11 Jan 2014 05:37:00 AM UTC, comment #7:

Still haven't checked the savegame, but one thing that needs changing would be logic in deciding which non-worked tile to improve.

Currently it always looks for biggest improvement, primarily among the worked, and with halved want among non-worked tiles.
That's correct way to go with worked tiles. City gains more from +2 to one tile than +1 to another tile, no matter what are their totals.
However, with non-worked tiles it should look for making best total so that next tile to get worked produces as much as possible. Improvement of +1 on top of 3 would produce better total than +2 on top of 1. +1 on top of 2 could still be thought to be less effective use of worker than +2 on top of 1, but given that +1 vs +2 in practice is often result of Despotism penalty cutting the first one and there being more non-Despotic future potential in it, one can't tell which way is better, and should not special-case it at all.

This affects especially Despotism, as the penalty cuts down high yield often making autosettler to select between (+2 - 1) = +1 and +2 causing it to always select lower yield tile where +2 takes place.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat 04 Jan 2014 06:58:52 PM UTC, comment #6:

> How is it determined which AI is used for autosettlers? It
> doesn't show up in "/list players".


-> new ticket?

Maybe "/list players" should show AI type associated to human players too, as it affects advisors. AI type associated with player cannot be changed after player has been created, so rest assured that mere "/aitoggle" (or "/away") retains it.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat 04 Jan 2014 05:15:28 PM UTC, comment #5:

> btw. This is the first bug report ever where one should specify
> AI type used. :-)

:)
FWIW, I do actually have threaded AI built in (--enable-ai-static=classic,threaded), just because.
But when I start a game with aifill (unlike this one), /list players says "classic", so I assume it defaults to that.
(How is it determined which AI is used for autosettlers? It doesn't show up in "/list players". But if I /aitoggle, then it says "classic".)

Jacob Nevins <jtn>
Project Administrator
Sat 04 Jan 2014 05:08:15 PM UTC, comment #4:

btw. This is the first bug report ever where one should specify AI type used. :-)
But I just assume you're using classic AI, and not threaded one, which does this part a bit differently.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat 04 Jan 2014 04:52:39 PM UTC, comment #3:

> you may want to correlate which tiles city is currently working
> to ones autosettler starts to improve

Missed this in previous tests, but I just redid trunk, and city was only ever working a grass tile; worker built road to it and then they moved on to other things. City never worked hills so that shouldn't have influenced workers' choice.

I don't think it's that worker is preferring the tile they're on, either -- I've seen workers walk over coal to get to a worksite without it.

Jacob Nevins <jtn>
Project Administrator
Sat 04 Jan 2014 04:49:00 PM UTC, comment #2:

The scenario editor lets us be a bit scientific with this. Savegame attached where half the world is hills, the other half grass (so that there's something to eat), and half of the hills within the city radius have coal.

After loading this, I build a city with the two settlers, set it to Coinage, research to Pottery, sentry the Explorer, and set the two workers to auto, and watch what they do.

On S2_4, the workers seem to ignore the presence of coal but not avoid it.

On trunk, the workers mined all the hills without coal before starting on hills with coal. This could have been coincidence.

(file #19666)

Jacob Nevins <jtn>
Project Administrator
Sat 04 Jan 2014 04:46:36 PM UTC, comment #1:

> I'm not sure what useful diagnostics I can provide.


Savegame is enough for me to check myself, but with future autosettler problems you may want to correlate which tiles city is currently working to ones autosettler starts to improve (the useual ai-considers-only-one-step rule here means that it doesn't consider both improving the tile and changing city worker placement)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat 04 Jan 2014 04:27:24 PM UTC, original submission:

I played a test game with classic ruleset on trunk recently, and one thing I noticed was that my automatic workers were tending to mine hills without coal when there were hills with coal in the radius of the same city.

Unless the workers attach importance to their current position, I can't think of a reason they should have preferred the coal-less hills.
(In fact I never noticed them choosing to mine coal, so they may have been actively avoiding it, but I don't have evidence for that.)

I don't know whether this is a recent regression, or longstanding, although I think we have fixed bugs of this kind in the past.

I'm not sure what useful diagnostics I can provide. I've provided a savegame from much later just in case it's useful (although I observed the behaviour right at the start).

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:
   

Attached Files
file #21283:  TwoModeAutosettlers.patch added by cazfi (7kB - text/x-diff)
file #19666:  coaltest24.sav.bz2 added by jtn (7kB - application/x-bzip - S2_4 test game with hills/coal)
file #19665:  teamgame.sav.bz2 added by jtn (40kB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 18 Jul 2014 07:46:02 AM UTCcazfiStatusReady For Test=>Fixed
      Assigned toNone=>cazfi
      Open/ClosedOpen=>Closed
    Mon 14 Jul 2014 11:49:29 PM UTCcazfiAttached File-=>Added TwoModeAutosettlers-2.patch, #21424
    Sat 05 Jul 2014 11:22:58 PM UTCcazfiAttached File-=>Added TwoModeAutosettlers.patch, #21283
      CategoryNone=>ai
      StatusNone=>Ready For Test
      Planned Release=>2.6.0
    Sat 04 Jan 2014 04:49:00 PM UTCjtnAttached File-=>Added coaltest24.sav.bz2, #19666
    Sat 04 Jan 2014 04:27:24 PM UTCjtnAttached File-=>Added teamgame.sav.bz2, #19665
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup