forum.freeciv.org

Been busy, just had a realization that you'll need unmouthed shore tiles to properly test.

Along with this realization, I remembered the other thing: shouldn't irrigation be drawn as a river?
That is to say, with its own river mouths in addition to the way it is currently drawn.
It would look rather off for a tile to be irrigated from a lake or ocean, but there be a strip of shore between the source and irrigation.
It's not an issue on isometrically blended tiles(where you can simply draw out-of-bounds), but on unblended sides (up, down, left, right) this is an issue.

[images deleted]

cazfi wrote:As for the offsets stuff, we're slowly approaching point where we can freeze S2_6 datafile formats. BUT we've not done that yet, so now would be the time for making any simple requests, like adding those offsets was, regarding the formats. We are unlikely to add any big changes to our lists that would postpone the freeze, but I'm interested of any low-hanging fruits to improve tileset support while waiting those remaining other issues to get solved. Once the formats have been frozen, any new changes will need to wait freeciv-3.0.

I recommend Windows users to test with the 2.6-alpha1 build: http://forum.freeciv.org/f/viewtopic.ph ... 5&start=20
While it's only a alpha of freeciv-2.6, it's probably the last windows installer build before the datafile formats freeze, and thus you last opportunity to test (and comment) the formats before they get frozen.

One of the new features in 2.6 is new drawing of the goto line (code patch, open art ticket). This will need new graphics in all tilesets.

I've done some awful programmer-art to illustrate what this is about.

(tileset files for Amplio2 in trunk r30502: terrain1.png, terrain1.spec; I haven't checked but these might be usable with the 2.6 Windows test build mentioned above; as shipped, current code uses some other existing sprites as placeholders, not these ones)

There are four new sprites:

• "path.step" is drawn in the middle of a path where a unit will end its turn (here: solid cyan diamonds)
• "path.exhausted_mp" is drawn at the end of the path (under the cursor) if and only if the unit will have no movement points left when it finishes its journey (here: hollow diamond with red/blue fill)
• "path.normal" is instead drawn at the end of the path if the unit will have movement left (here: hollow diamond)
• "path.waypoint" is drawn whenever the player sets an explicit waypoint that the path must go through (here: little cyan flag)

There are also up to three sets of number sprites for path drawing. I haven't changed those in my example. These could for instance be used to make the turn numbers at the "step" points smaller than the final one under the cursor.

Some other considerations:

• You can't have different sprites for different directions, so sprites need to be omnidirectional (can't use an arrowhead, for instance)
• Goto line drawing is still a solid coloured line, not sprites; colour is under tileset control but is conventionally cyan

(I haven't thoroughly tested the behaviour of this new mode. There may be bugs.)

thanks a lot for the link and the useful data...

cazfi wrote:

GriffonSpade wrote:On the tileset side, the only thing that comes to mind is river outlets on the flat(unblended) sides of a hex tileset. I doubt it's an inconsequential change if it hasn't been done yet by this point, though.

Do you happen to have art that could be used for testing this while developing it? I don't promise it to 2.6, but we'll check the feasibility. patch #6351

Patch to fix this has been made, but cannot be committed because of the fact that supplied isophex tileset doesn't have required sprites and would fail to load with the fix in place: patch #6832.

Code-side support for hex river outlets fix now committed to TRUNK, S2_6, and even to S2_5 (considering it a bug that these sprites were not properly handled). Those "new" sprites are left optional for now (obviously the code fix does nothing if the sprites are missing) to avoid breaking tilesets that have grown to expect the bug. Plan is to make them mandatory in 3.0.

JTN wrote:One of the new features in 2.6 is new drawing of the goto line (code patch, open art ticket). This will need new graphics in all tilesets.

I've gone with more-or-less the concept I posted previously. We now have graphics for all supplied tilesets that should be adequate.

Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?

louis94 wrote:Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?

It's not too late to file a bug report: http://gna.org/bugs/?func=additem&group=freeciv

cazfi wrote:

louis94 wrote:Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?

It's not too late to file a bug report: http://gna.org/bugs/?func=additem&group=freeciv

Done : https://gna.org/bugs/index.php?24373