Summary: Getting rid of move_type dependency on unitselect
Submitted by: cazfi
Submitted on: Tue 19 Feb 2013 09:27:44 AM EET
Priority: 5 - Normal
Status: Ready For Test
Assigned to: None
Discussion Lock: Any
Planned Release: 2.5.0
Unit select dialog uses unit move_type, which we've tried to retire from
non-ai code almost a decade already (since gen-movement development begun).
Attached patch replaces individual checks for move types with generic
This changes behavior in many ways. It's probably matter of taste if these
behavioral changes are for better or worse:
- "Both" selection type removed entirely. In most rulesets "Both" units mean
air units, in some also amphibious units. So you no longer be able select just
that selection of units.
- "Land" and "Sea" selection methods required both tile to be of the selected
type, and the unit to have that move type. Terrain is still limited the same
way, but units are subject to above mentioned can_unit_exist_at_tile() -> 1)
Also "Both" units belong to selection 2) tile must really be native to unit,
e.g., wheeled land units are not in selection in roadless tiles, alien ruleset
native terrain limitations apply
- "World" used to select all units. Now units are subject to
can_unit_exist_at_tile() so transported units are not part of the selection
If this is not sufficient, we may use some other property of units than
move_type to make the decision what selection groups they belong to. Unit
class is one possibility, but suffers from that separate classes like
"Trireme" and "Sea" could then not be combined. Maybe we need to introduce new
ruleset field for ruleset author to classify units, either to hardcoded
categories or dynamic ones.
If we accept this patch to TRUNK (I'd go with it at least as temporary
solution), should it go also to S2_4?
Date: Tue 19 Feb 2013 09:27:44 AM EET Name: UnitselectNativity.patch Size:
4kB By: cazfi
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list