Follow-up Comment #21, patch #3829 (project freeciv): This was only in my 2.5 list because I thought I would be able to write my ruleset for 2.5. Given that the ruleset I want to write has no units that are either native to all land tiles or all water tiles, and many of the "air" units cannot reach all tiles, there's far too much nativity work to do to the engine for me to expect anything to work (I was seduced by some of the content in NEWS and scattered bits in the SVN logs moving towards 2.5). Additionally, I needed the BaseFlag/RoadFlag stuff, which has already been pushed to 2.6. I'm not sure that my ruleset would be "high quality" when first published anyway: there are far too many possible balancing issues that need to be worked out, and I still have some conceptual issues to resolve (e.g. Should Neritic units be native to Lakes without dredging? What combination of combat_bonus entries best models depth charges for better rock/paper/scissors interaction of units? Should borax be a bonus resource without a strip mine? If not, how can the AI be convinced not to transform the tile?) anyway.
On movement, I think that for compatibility, it makes sense to just arbitrarily choose one of source, destination, minimum, or maximum cost to use for integrated roads (and I'm not sure which either). For future direction, it probably makes sense to use some general game parameter that chooses from different move modes, and then either set a callback for different implementations of tile_move_cost_ptrs (or portions thereof), or find a low-cost way of considering multiple solutions in the same implementation. I don't think that longer-term plan belongs as part of this ticket, as it has wider scope, really, but rather that we ought just pick something and use that (potentially including the slowest of the mixed roads). Another thing I realise reviewing this ticket is that I never answered the question about sprites and integration. At least for the tileset I use, there are separate sprites for each direction, which are all layered into the final image. In the case where road A integrates with road B, but road B does not integrate with road A, and tile X has road A and tile Y has road B, the current code will draw a connector for road A on tile X towards tile Y, but not draw a connector from tile Y towards tile X (for either road type), which looks a bit odd if we gain the movement benefit of road B (but may provide the right visual feedback if we select another move_cost to use). And as an aside, with this and roadflags, we can drop TF_BRIDGE, RF_REQUIRES_BRIDGE and potentially RF_PREVENTS_OTHER_ROADS, because we'll be able to describe the behaviour associated with those in terms of integrates[] and reqs{} (and those with interest in making everything very pretty can then even have different graphics in place for bridges, if they so desire). _______________________________________________________ Reply to this item at: <http://gna.org/patch/?3829> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev