[Freeciv-Dev] [patch #3870] New base to base_owner(), not tile_owner()

[Marko Lindqvist]

Follow-up Comment #2, patch #3870 (project freeciv):

Yes, though the main reason I'm working on this area is to provide ownership
for bases even if terrain is not owned at all. See bug #16385 for example
(there's other related tickets)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3871] Control airlift nativity with EFT_AIRLIFT

[Emmet Hikory]

URL:
  

 Summary: Control airlift nativity with EFT_AIRLIFT
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 03:10:53 PM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

The current code restricts airlifting to UMT_LAND units, which is annoying
for ruleset authors who might want to define a unit that happens to only move
on land but is unsuitable for airlift (e.g. continental assault engine) or
some unit that can move on both land and sea that is suitable for airlift
(e.g. frogmen).  The attached patch removes the hardcoded restriction,
replacing it with ruleset definitions for the "Airlift" effect: units that may
be airlifted are now controlled by the reqs/nreqs of the effects, so ruleset
authors may control this with any of UnitType, UnitFlag, UnitClass, or
UnitClassFlag.  Ruleset adjustments are included for all rulesets in source
control to retain prior behaviour (all using UnitClass for simplicity).




___

File Attachments:


---
Date: Mon 22 Apr 2013 03:10:53 PM JST  Name: control-airlift-nativity.patch 
Size: 9kB   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3870] New base to base_owner(), not tile_owner()

[Emmet Hikory]

Follow-up Comment #1, patch #3870 (project freeciv):

Do I read this correctly as providing a framework for a future feature
allowing one player to own a base in another player's territory?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3870] New base to base_owner(), not tile_owner()

[Marko Lindqvist]

URL:
  

 Summary: New base to base_owner(), not tile_owner()
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 22 Apr 2013 03:45:01 AM EEST
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.5.0

___

Details:

Fix creation of non-terrain-claiming bases to get claim base for base_owner(),
not tile_owner().
At the moment this makes no functional difference as base_owner() is just
wrapper for tile_owner().



___

File Attachments:


---
Date: Mon 22 Apr 2013 03:45:01 AM EEST  Name: BaseOwnerClaims.patch  Size:
495B   By: cazfi



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3869] Place partisans based on nativity

[Emmet Hikory]

URL:
  

 Summary: Place partisans based on nativity
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 09:28:49 AM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

The current logic assumes L_PARTISAN units are native to all tiles that
are either TC_LAND or T_UNKNOWN, which may not be correct for rulesets with
complex nativity.  Fix this by using is_native_tile rather than
is_ocean_tile.




___

File Attachments:


---
Date: Mon 22 Apr 2013 09:28:49 AM JST  Name: native-partisans.patch  Size:
915B   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3868] Refactor unleash_barbarians() terrain analysis loop

[Emmet Hikory]

URL:
  

 Summary: Refactor unleash_barbarians() terrain analysis loop
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 09:27:29 AM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Avoid calling is_ocean() and is_non_allied_terrain() twice separately for
is_free_land() and is_free_sea().  Instead, drop the helper functions, and
consolidate the logic in the terrain analysis loop, with a short-circuit to
never call is_ocean() when is_non_allied_terrain().




___

File Attachments:


---
Date: Mon 22 Apr 2013 09:27:29 AM JST  Name: refactor-unleash_barbarians.patch
 Size: 3kB   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3867] Drop map_move_cost_ai()

[Emmet Hikory]

URL:
  

 Summary: Drop map_move_cost_ai()
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 09:26:18 AM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

This function checked for moves involving sea tiles, but otherwise behaved
precisely like map_move_cost().  The only remaining caller
(aiferry.c:combined_land_sea_move()) contains parallel logic ensuring that
map_move_cost_ai was never called with either source or destination as an
ocean tile.  As a result, it is safe for combined_land_sea_move() to call
map_move_cost() directly, so this function may be removed.




___

File Attachments:


---
Date: Mon 22 Apr 2013 09:26:18 AM JST  Name: drop-map_move_cost_ai.patch 
Size: 4kB   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3866] Drop is_cardinally_adj_to_ocean()

[Emmet Hikory]

URL:
  

 Summary: Drop is_cardinally_adj_to_ocean()
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 09:25:14 AM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

This function has become an alias over time, and was intentionally named
awkwardly to prevent reuse.  Removing it and placing the relevant logic inline
does not affect program flow, and ensures that it will not be used in the
future in preference to is_ocean_near_tile (which appears to no longer exist
anyway).




___

File Attachments:


---
Date: Mon 22 Apr 2013 09:25:14 AM JST  Name:
drop-is_cardinally_adj_to_ocean.patch  Size: 3kB   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3865] Drop tile_clear_unsupported_infrastructure()

[Emmet Hikory]

URL:
  

 Summary: Drop tile_clear_unsupported_infrastructure()
 Project: Freeciv
Submitted by: persia
Submitted on: Mon 22 Apr 2013 09:23:55 AM JST
Category: general
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

This function used to be important for clearing roads and the like, but as
the code has evolved, the only remaining infrastructure_specials are
S_IRRIGATION, S_FARMLAND, and S_MINE, all of which are special-cased later in
tile_change_terrain(), which was the only remaining caller of
tile_clear_unsupported_infrastructure().



___

File Attachments:


---
Date: Mon 22 Apr 2013 09:23:55 AM JST  Name:
drop-tile_clear_unsupported_infrastructure.patch  Size: 2kB   By: persia



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [task #7668] Tracking release 2.5.0

[Marko Lindqvist]

Update of task #7668 (project freeciv):

  Depends on: => patch #3864


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3864] Update scenario files format to 2.5 format

[Marko Lindqvist]

URL:
  

 Summary: Update scenario files format to 2.5 format
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 22 Apr 2013 02:42:07 AM EEST
Category: rulesets
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.5.0

___

Details:

Once savegame format for S2_5 has been frozen, all supplied scenarios should
be updated to new format.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3350] Add Alien World files to POTFILES

[Marko Lindqvist]

Update of patch #3350 (project freeciv):

Category:None => general
  Status:None => Ready For Test 

___

Follow-up Comment #3:

- Updated against svn head

(file #17796)
___

Additional Item Attachment:

File name: AlienPo-2.patchSize:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19846] Closing unit select dialog asserts or crashes

[Marko Lindqvist]

Update of bug #19846 (project freeciv):

 Summary: Closing unit select dialog asserts => Closing unit
select dialog asserts or crashes


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3651] Setting TRUNK for 2.6 development

[Marko Lindqvist]

Update of patch #3651 (project freeciv):

  Status: In Progress => Ready For Test 
 Assigned to:None => cazfi  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3652] First commit to S2_5

[Marko Lindqvist]

Update of patch #3652 (project freeciv):

  Status: In Progress => Ready For Test 
 Assigned to:None => cazfi  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3863] Document gtk3-client unit selection dialog crash

[Marko Lindqvist]

URL:
  

 Summary: Document gtk3-client unit selection dialog crash
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 22 Apr 2013 01:09:38 AM EEST
Category: docs
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0-beta2

___

Details:

Add note about gtk3-client's CRASH bug to README.packaging so packagers know
to select gtk2-client rather than gtk3-client if their distribution happens to
be affected.

The Crash is blocker for final 2.4.0. It's not regression since beta1 so we
can release beta2 with it, but it must be documented there.



___

File Attachments:


---
Date: Mon 22 Apr 2013 01:09:38 AM EEST  Name: Gtk3CRASHDoc.patch  Size: 781B  
By: cazfi



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3829] Allow compatible roads

[Marko Lindqvist]

Update of patch #3829 (project freeciv):

  Status:None => Ready For Test 
 Assigned to:None => cazfi  
 Planned Release: => 2.5.0  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20753] "is_available" in nation rulesets does nothing

[Marko Lindqvist]

Follow-up Comment #1, bug #20753 (project freeciv):

btw. Is it possible to have nation that one cannot select in the beginning,
but which still can appear through civil war during the game?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()

[Emmet Hikory]

Follow-up Comment #5, bug #20744 (project freeciv):

I think it's safe either way: I just tend to avoid having unused arguments or
functions if possible, to ease later reading of the code (but given the volume
of testing to which this was subjected, there is a strong argument for leaving
it intact).

Looking at the most recent revisions of the patch, I wonder if
unit_list_iterate_safe(remaining, pcargo){} should be guarded with a check to
ensure unit_list_size(remaining) > 0 (this would apply to either S2_4 or trunk
patches).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3721] Getting rid of move_type dependency on unitselect dialog

[Emmet Hikory]

Follow-up Comment #2, patch #3721 (project freeciv):

I don't think it is safe to use !can_exist_at_tile() as the filter if
we're looking to exclude transported units: that implies an assertion that at
any time the client is sufficiently idle to take a new command, no
untransported unit cannot exist on it's tile, which wouldn't be thread-safe if
units are drowning, or possibly in certain transport situations (I haven't
reviewed the client code sufficiently to confirm this: it may be that the
client already group-moves units the server permits to move, or similar). 
Additionally, units in nested transport may be selected if they are native,
even if they cannot be used (e.g. Cruise Missile in Mech. Inf. in Transport). 
If the intent is to find units that are both transported and unable to
disembark, we should be using something like:

ptrans = unit_transport_get(punit);
if (ptrans != NULL
&& !(can_unit_unload(punit, ptrans)
 && can_unit_exist_at_tile(punit, utile))) {
  return FALSE;
}

Using tile_city(utile) != NULL in both conditions causes any units in
cities to appear twice.  Perhaps these conditions could depend instead on the
local terrain+infrastructure, so:

LAND: (!is_ocean(utile) && is_native_tile(unit_type(punit), utile)))
SEA: (is_ocean(utile) && is_native_tile(unit_type(punit), utile)))

This still causes some duplication (some units may be native to both,
either inherently, or due to roads/bases/etc.), but doesn't automatically
select all sea units in harbour when selecting LAND.  On the other hand, it
will make non-native (e.g. BuildAnywhere) units unselectable, which may be
confusing.

The above said, I don't use this selector other than for tile range, so
these opinions may be ill-informed.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3851] Remove extra files from gui-gtk-3.0 theme directory

[Marko Lindqvist]

Update of patch #3851 (project freeciv):

  Status:  Ready For Test => Done   
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3842] Ensure use of boolean TRUE/FALSE in reqs specifications

[Marko Lindqvist]

Update of patch #3842 (project freeciv):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3852] Lua 5.2.2

[Marko Lindqvist]

Update of patch #3852 (project freeciv):

  Status:  Ready For Test => Done   
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()

[Marko Lindqvist]

Update of bug #20744 (project freeciv):

 Planned Release: 2.4.0, 2.5.0, 2.6.0 => 2.4.0-beta2, 2.5.0, 2.6.0

___

Follow-up Comment #4:

Correction: Had to make new version anyway due to other changes to codebase,
so removed S2_4 helpless while at it.

(file #17791, file #17792)
___

Additional Item Attachment:

File name: WipeUnitLists-2.patch  Size:8 KB
File name: WipeUnitLists-S2_4-2.patch Size:8 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()

[Marko Lindqvist]

Follow-up Comment #3, bug #20744 (project freeciv):

As we're heading to beta2, I'll commit this with extra argument intact. That's
what's been extensively tested (like in: several autogames (on multicore
system) constantly running almost from the day trunk patch was first
introduced). We may cleanup it away from S2_4 version after the beta, if
someone bothers.


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20753] "is_available" in nation rulesets does nothing

[Jacob Nevins]

Update of bug #20753 (project freeciv):

  Status: In Progress => Ready For Test 

___

Additional Item Attachment:

File name: trunk-nations-is_available.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3860] Nations ruleset: allow terrain checking against explicit compatibility list

[Jacob Nevins]

Additional Item Attachment, patch #3860 (project freeciv):

File name: trunk-nations-allowed-terrains-bis.patch Size:11 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3859] Nations ruleset: move government compatibility checking to nationlist.ruleset

[Jacob Nevins]

Additional Item Attachment, patch #3859 (project freeciv):

File name: trunk-nations-allowed-govs-ter.patch Size:10 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20753] "is_available" in nation rulesets does nothing

[Jacob Nevins]

URL:
  

 Summary: "is_available" in nation rulesets does nothing
 Project: Freeciv
Submitted by: jtn
Submitted on: Sun Apr 21 15:36:45 2013
Category: None
Severity: 2 - Minor
Priority: 5 - Normal
  Status: In Progress
 Assigned to: jtn
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: Any
 Planned Release: 2.5.0

___

Details:

It's always overwritten by init_available_nations() before use.

It doesn't seem very useful to be able to specify a nation that's never used
for anything, so let's just remove it.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] Nativity restrictions in clients

[Emmet Hikory]

Marko Lindqvist wrote:
> On 21 April 2013 00:21, Emmet Hikory wrote:
> > unitselect_common.c:usdlg_check_unit_location()
> 
>  patch #3721?

Yes, precisely.  Thank you.

-- 
Emmet HIKORY

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3448] "Nation sets": allow set of nations that will ever appear in-game to be chosen

[Jacob Nevins]

Update of patch #3448 (project freeciv):

  Status:   Need Info => In Progress
 Assigned to:None => jtn


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20751] assertion 'normal_player_count() <= game.server.max_players' failed

[Jordi Negrevernis i Font]

Follow-up Comment #4, bug #20751 (project freeciv):

It seams to correct the issue. At least, it doesn't assert.

Thanks


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] Nativity restrictions in clients

[Marko Lindqvist]

On 21 April 2013 00:21, Emmet Hikory  wrote:

> The client code seems to use UMT_*, TC_OCEAN, is_foo_unit(), and
> is_ocean() in several places for which I don't really understand the
> correct behaviour to support complex unit nativity.  Suggestions,
> opinions, and pointers to open bugs or patches welcome.
>
> climisc.c:unit_color_type()
> This function uses UMT_* as a guide to set the correct background
> color for a unit, which seems only to be used in the Xaw client.  I
> would think that with complex nativity, it makes sense to assign the
> background color for tiles based on terrain, player knowledge, etc.  I
> don't have much familiarity with Xaw, so I don't understand if we can
> use logic like that used for the gtk2/3 clients' create_overlay_unit()
> (or some analog thereto) to initialise to black and then modify based on
> terrain/tileset definitions.
>

 This was used in other clients too, but has now been cleaned away from all
but xaw-client.



> unitselect_common.c:usdlg_check_unit_location()
> This function has support for selecting units based on move_type
> explicitly.  I've never used this feature, so don't know common use
> cases. For complex nativity, I suspect that these become less useful:
> various amphibious units are inherently excluded, which may be
> unfortunate for rulesets with many ocean depths that allow most land
> units on the shallowest of oceans (which might not be particularly deep,
> and may not permit access by most seaworthy units).  Units with
> restrictions within classic nativity (only some land, only some oceanic,
> only roads, etc.) may be selected inappropriately, as they might be
> unsuitable for use for the intended purpose (e.g. cannot move to some
> target).
>

 patch #3721?

>
> Those client uses of is_ocean() and TC_OCEAN not mentioned above
> seemed sane to me (and safe for complex nativity), although I wonder if
> the code ought standardise on one or the other representation of this
> idea (changelogs suggest general migration to is_ocean(), but some of
> the calls that use TC_OCEAN might need refactoring for this).  The idea
> of selecting coastal cities may also be slightly less useful for
> rulesets with particularly complex nativity, as some "coastal" cities
> might not support many "sea" units, etc.  Similarly, the current
> "coastal" check happens to also select all Oceanic cities that aren't
> built on a lake.
>

 The differences are probably explained by what the terrain code has been
like at the time of writing the code in question. Terrain class in its
current form (where it's sensiblle thing to check TC_OCEAN directly) is
just a couple of months old, is_ocean() used to check for terrain flag.
With the idea that we may some day have more terrain classes than just
"Land" and "Ocean", I think boolean is_ocean() should be avoided in new
code.


 - ML
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20751] assertion 'normal_player_count() <= game.server.max_players' failed

[Jacob Nevins]

Update of bug #20751 (project freeciv):

 Planned Release: 2.3.5, 2.4.0, 2.5.0 => 2.3.5, 2.4.0-beta2, 2.5.0


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev