[Freeciv-Dev] Re: [Patch] Exploring triremes getting lost (PR#961)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Sep 16, 2001 at 12:38:21PM -0700, Gregory Berkolaiko wrote:
> Well, subject says it all.
> Sometimes exploring (X-mode) triremes boldly go out into the open sea and
> die.  I hope it ain't no feature.
> 
> So I submit the below patch.  Few comments:
> 
> -- Since explorer managing is done on the server side, we must be careful
> to avoid peeking into unknown tiles.
> -- Sometime you can tell that there is a shore nearby because part of the
> land tile actually goes over onto the ocean tile.
> 
> the above aims are achieved by "is_coast_seen" function.
> 
> -- If trireme somehow gets into the open sea and doesn't know where to go
> next, it will cancel explorer mode.  At this point it should have enough
> movepoints to be taken back to shore.  This is an improvement I think.
> -- In the above, if it's AIs trireme, it will not ask for help and will
> probably sink. There is no improvement here, but AI is more careful with
> letting triremes explore.


> -- I also did little cleaning up in gotohand.c.  Sorry if it confuses
> those few who'll be reading the patch.

It would be nice if you can seperate this.

It also looks like you have some knowledge about how the methods
work. Can you add some comments to the code?

>       if (unknown) {
> -       if (is_sailing_unit(punit))
> +       if (is_sailing_unit(punit)) {
>           unknown += 9 * (threshold - warmap.seacost[x1][y1]);
> -       else
> +         if (afraid_of_sinking && !is_coast_seen(x1,y1,pplayer))
> +           unknown = 0;
> +       } else

What is unknown? What means 0 here?

> diff -ur -Xfreeciv/diff_ignore freeciv/server/gotohand.c 
> freeciv_mod/server/gotohand.c
> --- freeciv/server/gotohand.c Sun Sep 16 20:20:04 2001
> +++ freeciv_mod/server/gotohand.c     Sun Sep 16 21:09:23 2001
> @@ -182,6 +182,7 @@
>        freelog(LOG_DEBUG, "returned before. getting next");
>        return get_from_mapqueue(x, y);
>      } else {
> +      warmap.returned[*x][*y] = 1;

Why this change?

> +/***************************************************************
> +Can pplayer conclude (at least by circumstantial evidence) that
> +(x,y) is on coastline?  Remember, coastline ocean tiles have a 
> +small stripe of land in them, even if the actual continent is 
> +not seen.
> +***************************************************************/
> +int is_coast_seen(int x, int y, struct player *pplayer)
> +{
> +  square_iterate(x, y, 1, x1, y1) {
> +    enum tile_terrain_type ter = map_get_terrain(x1, y1);
> +    if (ter != T_OCEAN) {
> +      square_iterate(x1, y1, 1, x2, y2) {
> +     if (map_get_known(x2, y2, pplayer)) {
> +       return 1;
> +     }
> +      } square_iterate_end; /* around x1,y1 */
> +    }
> +  } square_iterate_end; /*around x2,y2 */
> +  return 0;
> +}

I don't understand why you use two square_iterate here? If (x,y) is
known and (x,y) is a coastline ocean tile this method return 1. What
other cases do you try to handle?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "How about the new language C&? No, that's not 'c ampersand', 'c reference', 
  'reference to c' or 'c and'. It's pronounced 'campersand', to confuse the 
  hell out of people who are unfamiliar with it, and it will, of course, 
  have no pointers."
    -- Xazziri in comp.lang.c++ about C#