patchFreeciv - Patches: patch #2951, Generalise RoadNative/RiverNative

 
 
Show feedback again

patch #2951: Generalise RoadNative/RiverNative

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat 03 Sep 2011 11:49:08 PM UTC  
 
Category: generalPriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 

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)

Tue 14 May 2013 11:40:10 AM UTC, comment #6:

Regarding the original ticket, a simple implementation would be to have a vector for roads/bases that made a given terrain non-native for a set of unit classes, so that, for example, "Big Land" would not be native to "Grassland" if there was a "River" present. In a first-brush attempt to do this as a quick evening patch, I realise that it is complicated by interaction between multiple roads/bases.

If you have a road "River", and a road "Bridge", and a unit class "Large Boat" that is native to the NativeTile road "River", you could presumably define a "blocks_native" vector for "Bridge" that includes "Large Boat" so that the unit class cannot enter the tile. At first, this seems sensible.

Now, consider the case where there is a road "River", a base "Fortress", a unit class "Big Land", and a terrain "Grassland". If "River" has "blocks_native" "Big Land", and "Fortress" is native_to "Big Land", can the "Big Land" unit use the "Fortress"? Given the logic for "Bridge"/"Large Boat", the answer would be no, but the ruleset author may expect that Fortresses are useful for Big Land even on Rivers.

Whether the implementation waits for extras or not, there would be value in discussion of a sufficiently flexible ruleset notation to provide the described behaviours, and greater specificity about the specific behaviours desired.

Emmet Hikory <persia>
Project Member
Tue 19 Feb 2013 03:02:24 AM UTC, comment #5:

> But as everything is just transitional phase to next, in a
> decade we may be able to combine bases and roads back to one
> "specials" concept. ;-)


Updating my plans here once more, even this is going a bit off the original ticket.

In 2.6 there will be concept of tile "extras" (term already made its debut to codebase in patch #3638 introducing function tile_extras_defense_bonus() ) At first separate road/base/special implementations will remain as they are, extras just providing upper level functionality; extras structure will have "extras_class" (road/base/special) and union of classes. Over time class type specific values will be drawn from the union to part common to all extras.
For performance reasons, it's probably better to keep some parts of the separate extras classes. For example, if we want check some roadish behavior, we should be able to "road_type_iterate(proad)" rather than "extras_type_iterate(pextras) { if (pextras->class == EXTRAS_ROAD)"

Marko Lindqvist <cazfi>
Project Administrator
Fri 30 Mar 2012 11:47:38 PM UTC, comment #4:

> I'm playing with the idea of retiring simple specials
> completely. They all could be made in to bases (ones that cover
> single tile) or roads (ones that connect between tiles).


That's the mid-term plan. But as everything is just transitional phase to next, in a decade we may be able to combine bases and roads back to one "specials" concept. ;-)

Splitting bases and roads from specials to separate concepts instead of developing all specials at once was simply necessary for the size of the task. Dragging all aspects of all specials along would have made every single step too huge to control.

Marko Lindqvist <cazfi>
Project Administrator
Sat 18 Feb 2012 09:42:00 PM UTC, comment #3:

> Although I'm not sure whether it should be just road-like
> specials for this feature or any kind of special; it wouldn't be
> much more work to allow e.g. units that can't move into
> fallout/pollution squares.


I'm playing with the idea of retiring simple specials completely. They all could be made in to bases (ones that cover single tile) or roads (ones that connect between tiles).
Your desing of telling for each unit where it can or cannot go would be required with current specials for which ruleset cannot provide any information. But if pollution and fallout would be bases (with concept of bases probably renamed by the time), we could define units that cannot enter the tile in base structure. They already have list of native unit classes, and with combination of "NativeTile" flag that allows units to enter tile regarless of terrain. Having list of unit classes that base prevents from entering tile would be quite natural extension to that, and one I've wanted to do for bases for some time.

Marko Lindqvist <cazfi>
Project Administrator
Sun 04 Sep 2011 09:30:07 AM UTC, comment #2:

> You should take gen-roads in to account in the design, not to
> speak about just two specific road types.

Yes, I had half an eye on gem-roads.
Although I'm not sure whether it should be just road-like specials for this feature or any kind of special; it wouldn't be much more work to allow e.g. units that can't move into fallout/pollution squares.

> I take it that you just wrote this down so it's not forgotten.
> Or are you going to implement it soon?

Mostly the former, although I don't promise not to get round to it ;) Do your thing first, I reckon. (Yours also enables RailNative, it sounds like.)

Jacob Nevins <jtn>
Project Administrator
Sun 04 Sep 2011 06:34:42 AM UTC, comment #1:

You should take gen-roads in to account in the design, not to speak about just two specific road types.

I take it that you just wrote this down so it's not forgotten. Or are you going to implement it soon? If not, I'm going to first implement gen-roads as I had planned; retiring RoadNative and instead adding native_to -field to road definitions just like bases work.

Marko Lindqvist <cazfi>
Project Administrator
Sat 03 Sep 2011 11:49:08 PM UTC, original submission:

In bug #16383, tirolalira requests:

"1- I'm testing also the "big land" units that can't move to some terrain unless roaded (using roadnative), and I would like to be able to create a land class that can't cross rivers unless roaded (to recreate the importance of bridges for tanks in ww2).

I think it would also be realistic to have sea units that can enter rivers except if roaded (to recreate big ships stoped by bridges)."

Another, simpler thing that's missing is RailNative (not that anyone's asked for it).

Here's a sketch of a design that would allow the above rulesets and more:

  • Retire RoadNative/RiverNative unit class flags.
  • Instead, have a unit class parameter in the ruleset which consists of an ordered list of terrain features, each possibly negated. When determining whether terrain is native to a unit, the list is scanned from left to right, with the underlying terrain "native_to" being considered after all features in the list. Examples:
    • "Big Land" units that can't cross rivers unless roaded: "road,!river". This means: native if roaded, else not native if river, else check underlying terrain (plains, !mountain, etc).
      • (If road weren't implicit in rail, this would be "rail,road,!river", with the order of "road" and "rail" not mattering.)
    • Riverboats that can't pass under bridges: "!road,river": not native if roaded, else native if river, else check underlying terrain (oceanic).
    • RailNative is just "rail".
  • Could possibly include bases in this list, moving them out of terrain.ruleset. Otherwise they'll be considered at the end of the list, like terrain.
  • An arbitrarily long list is awkward to send over the network and search in the code. If that's an issue, we could retain the expressiveness of the ruleset definition, but implement it with a small number of "layered" bitmasks, which could be expanded in future if necessary.
    • To implement the above examples would require just three such bitmasks: "POS1", "NEG", "POS2".
      • Land example: POS1={ROAD}, NEG={RIVER}, POS2={} (or {ROAD|RAIL}, {RIVER}, {})
      • Sea example: POS1={}, NEG={ROAD}, POS2={RIVER}
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:
   

No files currently attached

 

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
  • -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):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 03 Sep 2011 11:49:21 PM UTCjtnCarbon-Copy-=>Added tirolalira
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup