forum.freeciv.org

JTN wrote:(I haven't thought hard about why amplio2hexbig needs a list of all the nations and whether it can be avoided.

Can't check now, but maybe it's for different offsets? Then we may want to split freeciv flags.spec like we did nations.ruleset/nationlist.ruleset. Can't do in 2.5, but 2.6 is open for such a change.

cazfi wrote:

JTN wrote:(I haven't thought hard about why amplio2hexbig needs a list of all the nations and whether it can be avoided.

Can't check now, but maybe it's for different offsets? Then we may want to split freeciv flags.spec like we did nations.ruleset/nationlist.ruleset. Can't do in 2.5, but 2.6 is open for such a change.

It's because i use the 'little' flags for 'shields', so all the 'f.' entries have to become 'f.shield.' entries. That being said, I'm about to put up 2.5.00.

Edit: Apparently did not actually save the flags in 2.5.00, so released 2.5.01.

2.5.01 .tilespec files list has lots of files from "misc/" that do not exist in freeciv.

cazfi wrote:2.5.01 .tilespec files list has lots of files from "misc/" that do not exist in freeciv.

Alright, 2.5.02 is up and removed those references. Was stuff leftover from when I was making the icons and seeing how they looked in game, back before I even started working on 2.5.00.

v2.5.03 up. Mostly icon work, including adding in icons for saltpeter, aluminum, and uranium.
(saltpeter being color inverted and reoriented coal, aluminum being color inverted, lightened, and reoriented iron, and uranium being greyscale gold)
Also added instructions on how to maintain/update amplio2hexbig/flags.spec if new nations are added. (copy misc/flags.spec, put it in amplio2hexbig, and replace all the f. entries with f.shield. entries)

Attached is a flags.spec suitable for the 2.5 nations. You probably want to bump the version to 2.5.04 for this.

Ooh, more nations in beta1 huh? Neat.

Currently working on Hill versions for arctic, tundra, and desert. I've finally figured out a process that works well for converting them, and just need to work on the details. Sadly, my attempts to make a set of mountains for them has thus far come up as can only be described as 'abject failure'.

Edit: Decided to go back and rework how beach/iceshelf/etc tiles are generated, to streamline it...This is going to be a daunting task and might take a few days to get the spec file laid out correctly. It's one of those unfortunate changes that can't be half-done and tested to make sure everything is going correctly, but instead complete it, THEN hope everything works right (Or at least close enough that it can just be tweaked). Hopefully with the help of my assistant OpenOffice Spreadsheet Concatenate Function I'll get this banged out in a reasonable timeframe.

GriffonSpade wrote:Ooh, more nations in beta1 huh? Neat.

Yes, I pulled up the latest few from trunk shortly before release.
There won't be any more nations in 2.5 now -- we can't safely add them after beta1 -- so this should be the last flags.spec update for this version of the tileset.

Arrrrrrrgh. So, after spending hours deconstructing the tileset to find out why they aren't showing...

Adding a second match_with entry promptly causes it to stop using the tiles at all, yet it doesn't crash. Is there some kind of syntax change to the spec entries when there are multiple match_with entries?

Edit: Alrighty, to clarify, I'm trying to put all the shore types into one layer using sprite_type = "corner". This layer is layer 1 (second layer).

With a single match_type, it works fine. The entry looks kinda like this:


layer1_match_type = "water"
layer1_match_with = "ice"
layer1_sprite_type = "corner"

and the syntax looks like this in the spec file:

0, 0, "t.l1.lake_cell_u_w_w_w"

It's a lake, in the 'up' corner, and the 3 matches are all water.

In addition to 'u' (up), 'd' (down), 'l' (left), and 'r' (right) corner directions are used.
In addition to 'w' (water), 'i' (ice) match is used.

And it works just fine. However, change the entry to this:

layer1_match_type = "water"
layer1_match_with = "ice", "shore"
layer1_sprite_type = "corner"

u, d, l, r corner directions are the same.
w and i matches are still used, but also add 's' (shore) as a possible match.

And it doesn't draw anything. Even the above example syntax doesn't draw the water/water/water tile anymore. There's no documentation any further on this subject, and I don't see any logical reason why the syntax would change (or for that matter, if the syntax DOES change, why it would have changed from 'u000' to 'u_w_w_w' when the match_with is nonsame as the match_type).

Updated to v2.5.04. (I shelved the merging of coasts into one layer, but a small image edit I made for a difference reason seems to have greatly improved the problem anyway.)

Here's a test ruleset if anyone is interested in seeing the pavement, monorail, hill variants and taiga (tundra pine forest).
Goes into /data/ directory. I'll probably play around with making Trench and Airstrip graphics next.