[Freeciv-Dev] Re: [Patch] Watchtower version 2

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Aug 27, 2001 at 01:27:23PM +0200, Bert Buchholz wrote:
> Okay, here the second version of my watchtower patch, I hope I included
> everything that was discussed so far, but after all, I'm just a German.
> ;-)
> 
> Features:
> Well, I listed them already, no need to do this again. 

> BUT: This patch is not dealing with any "fine grained control over
> vision range" (as Raimar called it), which I think makes sense but
> makes a lot of changes necessary, that are far beyond this patch
> (and my insight into the code).

This stuff is independent of your changes.

> Up to now, following events regarding watchtowers are handled (there may
> be more to handle which I didn't see):
> - A fortress is pillaged (vr reduced)
> - A town is built upon a fortress (vr reduced)
> - A unit steps into a fortress (vr enhanced)
> - A unit steps out of a watchtower (vr reduced)
> - The necessary invention is made (all units inside fortresses get
>   enhanced vr)
> - A fortress is built (all units on that tile get enhanced vr)
> 
> *New*:
> - A unit gets killed inside a fortress (vr reduced)
> - A unit getting upgraded inside a fortress (vr mostly not changing)
> - A unit is created on a fortress, for example barbarians, or a unit is
>   being bribed (vr enhanced)
> 
> What about loading savegames? server/savegame.c, around 1126
> I'm unfogging the necessary tiles, but there's another piece of code I'm
> not sure of:
> 
>     {
>       int range = get_unit_type(punit->type)->vision_range;
>       square_iterate(punit->x, punit->y, range, x1, y1) {
>         map_set_known(x1, y1, plr);
>       } square_iterate_end;
>     }
> 
> Obiviously, the vision_range would be different if the unit was in a
> fortress, but I'm not sure what this does anyway because loading works
> without changing this. Because map_set_known() is done inside
> really_unfog_area() which is called by unfog_area(), which is being used
> in connection with the watchtower's visionrange. Hmm, slightly confusing
> :-)
> 
> Is this just for being on the safe side or has this a reason I'm
> overlooking?

I have no clue about this.

> Another issue: Having in mind this change of visionrange-"calculation"
> to a somewhat more fine grained version, it might be useful to replace
> every 
> 
> unfog_area(unit_owner(punit), punit->x, punit->y,
>                get_unit_type(punit->type)->vision_range);
> 
> with something like
> 
> unfog_area(unit_owner(punit), punit->x, punit->y,
>                get_vision_range(punit));
>                ^^^^^^^^^^^^^^^^^^^^^^^
> 
> This function get_vision_range() could include all these calculations
> and conditions, if the unit is inside a fortress or upon a mountain or
> whatever or in the swamps and return the fitting vision_range_index as
> suggested by Raimar, here a quote:
> 
> |If the pythagorean distance is used it has to be dense. This is to
> |prevent cases like if you get an increase by one and your current
> |vision is 2.
> |
> |index            | 0  1  2  3  4  5  6
> |square if radius | 0  1  2  4  5  8  9
> 
> But this can be spared for later, for now, this function could calculate
> the visionrange and return it as it is done already (simply the radius
> for the square being fogged/unfogged), because this would shorten the
> code and make it much easier to read. And, the best, it could easily be
> changed later to adapt to this fine-grain-stuff (could someone please
> find a word for that ;-) I didn't wanna put this in now already, but I
> think this is worth for being considered.

This more fine grained stuff is definitely independent from your
changes. If you make the variables in get_watchtower_vision()
adjustable and nobody objects I see no reason to not apply the patch.

> PS: I'd love to check this by using the autoplay-feature, but seemingly,
> the ai doesn't build fortresses. Is that correct?

$ grep -Iri fortress ai|wc
      0       0       0
Mhhh it looks so.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We just typed make..."
    -- Stephen Lambrigh, Director of Server Product Marketing at Informix,
                         about porting their Database to Linux