AmplioHexBig Tileset 2.4

[GriffonSpade]

Spec File Changes 1.5-1.6
(So that those working with 2.5 don't have to redo all the 2.4-2.5 spec file changes manually)

unitextras.spec:
Added Convert Icon to the tileset(but not spec file) at 3,6

terrain2.spec:
the t.l2.floor cells should be replaced with these (deep/ocean use the same blending mask now)

Code: Select all

;Deep Ocean blended with Shallow Ocean
15, 0,  "t.l2.floor_cell_u_f_f_f"
15, 1,  "t.l2.floor_cell_u_c_f_f"
15, 2,  "t.l2.floor_cell_u_f_c_f"
15, 3,  "t.l2.floor_cell_u_c_c_f"
15, 4,  "t.l2.floor_cell_u_f_f_c"
15, 5,  "t.l2.floor_cell_u_c_f_c"
15, 6,  "t.l2.floor_cell_u_f_c_c"
15, 7,  "t.l2.floor_cell_u_c_c_c"

16, 0,  "t.l2.floor_cell_d_f_f_f"
16, 1,  "t.l2.floor_cell_d_c_f_f"
16, 2,  "t.l2.floor_cell_d_f_c_f"
16, 3,  "t.l2.floor_cell_d_c_c_f"
16, 4,  "t.l2.floor_cell_d_f_f_c"
16, 5,  "t.l2.floor_cell_d_c_f_c"
16, 6,  "t.l2.floor_cell_d_f_c_c"
16, 7,  "t.l2.floor_cell_d_c_c_c"

17, 0,  "t.l2.floor_cell_l_f_f_f"
17, 0,  "t.l2.floor_cell_l_f_c_f"
17, 2,  "t.l2.floor_cell_l_c_f_f"
17, 2,  "t.l2.floor_cell_l_c_c_f"
17, 4,  "t.l2.floor_cell_l_f_f_c"
17, 4,  "t.l2.floor_cell_l_f_c_c"
17, 6,  "t.l2.floor_cell_l_c_f_c"
17, 6,  "t.l2.floor_cell_l_c_c_c"

17, 1,  "t.l2.floor_cell_r_f_f_f"
17, 1,  "t.l2.floor_cell_r_f_c_f"
17, 3,  "t.l2.floor_cell_r_c_f_f"
17, 3,  "t.l2.floor_cell_r_c_c_f"
17, 5,  "t.l2.floor_cell_r_f_f_c"
17, 5,  "t.l2.floor_cell_r_f_c_c"
17, 7,  "t.l2.floor_cell_r_c_f_c"
17, 7,  "t.l2.floor_cell_r_c_c_c"

terrain1.spec:
Added monorails, I used 'mono' as the stem(to fit in with road/pave/rail) (Suggested placement just below the ;railroad section)

Code: Select all

;monorails
 9, 0, "r.mono_isolated"
 9, 1, "r.mono_n"
 9, 2, "r.mono_ne"
 9, 3, "r.mono_e"
 9, 4, "r.mono_se"
 9, 5, "r.mono_s"
 9, 6, "r.mono_sw"
 9, 7, "r.mono_w"
 9, 8, "r.mono_nw"

The ocean blend tile (this section is located at the bottom of the specfile) has been changed from the desert tile(0,0), to a mutilated desert tile at (1,11) (Part of the edit that removed 'sand' from appearing near the edge of the map or unexplored areas)

Code: Select all

1, 11, "t.blend.coast"
 1, 11, "t.blend.ocean"
 1, 11, "t.blend.floor"
 1, 11, "t.blend.lake"

[cazfi]

terrain1.spec:
Added monorails, I used 'mono' as the stem(to fit in with road/pave/rail) (Suggested placement just below the ;railroad section)

Great! You know that 2.5 which has gen-road (generic roads defined in ruleset) support, has Maglevs in experimental ruleset.

[cazfi]

Spec File Changes 1.5-1.6
(So that those working with 2.5 don't have to redo all the 2.4-2.5 spec file changes manually)

Thanks. That was really nice thing to do, but I think I got it as easily as diffing 2.4 version 1.5 and 1.6 to create a patch of the spec changes, and then applying that patch to 2.5 version - there was only one minor conflict (same line of the specfile had been changed by both 1.5 -> 1.6 update and freeciv-2.4 -> freeciv-2.5 update). I hope to get the updated version available on freeciv-modpack before tomorrow morning.

[JTN]

Something I've noticed is that some sprite isn't sufficiently "hexified", as overlapping rectangles show up in a couple of situations:

2.4.2 with (a) View > Terrain disabled (b) city workers shown (shift-alt-right-click on city)

boxy.png (22.04 KiB) Viewed 22903 times

One thing that shows this is showing city workers with shift-alt-right-click on city, which puts a coloured overlay on the city's surroundings. Another is disabling Terrain from the View menu. (And with terrain disabled, "Unit Solid Background" also shows boxes.
I haven't worked out which sprite(s) need work, but I can figure it out from the code if that would help.
(I've checked this still happens with 1.6.)

[cazfi]

There's a problem being solved in tilesets supplied with freeciv that mine_sprite has not been defined for all terrains. That's a problem with custom rulesets that enable building mines to those terrains.
bug #21559. You may want to fix this in amplio2hexbig too.

[GriffonSpade]

Hmmm, I thought the boxes were carried over from isophex, but on checking, they're not. I'll have to go back through and see what's different. Maybe it's just the fog tile or something. (I certainly don't remember translucent colored tiles )

Edit: The boxes themselves seem to come from data/misc/overlays.png & *.spec. Both amplio2 and isophex use this file, without this problem, so I'll have to do some more searching to see what the problem is, as it doesn't seem to be overly obvious.

Edit2: Was a simple incorrect reference: mask.tile was looking at the black tile with the Windows 'outside corners' rather than the black tile.

[GriffonSpade]

version 1.7 up, along with an experimental patch for 2.5 (do not know if it will work)

Full height in non-iso Hex tilesetsEdit
Non-iso Hex tilesets had excessively high Full height meaning that origin of some sprites was far above the tile's top and thus tilesets needed a lot of transparent padding on top part of those sprites. Now Full height in non-iso Hex tilesets is same as Normal height defined in .tilespec. The old formula was 3 * normal_tile_height / 2. If you had origin of the sprites set to match old code, you should now remove 1/2 * normal tile height pixels from the top of them to make their height match normal tile height. Remember also change grid dy value to match in .spec file. For example hext2 tileset with normal_tile_height defined as 72 in the tilespec needed 36 pixels cut from the affected sprites that earlier were 108. Sprites affected are cities and all the smaller icons such as hitpoint bars, unit activity icons, city size indicators. Units and terrains are not.

Does this mean that things won't be able to be placed above/below the top/bottom on these anymore? It's the only change in my preliminary/experimental 2.5 patch that I didn't do, as it looks like just png editing rather than spec. (No 2.5 beta to test either way though)

There's a problem being solved in tilesets supplied with freeciv that mine_sprite has not been defined for all terrains. That's a problem with custom rulesets that enable building mines to those terrains.
bug #21559. You may want to fix this in amplio2hexbig too.

How?

[cazfi]

Full height in non-iso Hex tilesetsEdit
Non-iso Hex tilesets had excessively high Full height meaning that origin of some sprites was far above the tile's top and thus tilesets needed a lot of transparent padding on top part of those sprites. Now Full height in non-iso Hex tilesets is same as Normal height defined in .tilespec. The old formula was 3 * normal_tile_height / 2. If you had origin of the sprites set to match old code, you should now remove 1/2 * normal tile height pixels from the top of them to make their height match normal tile height. Remember also change grid dy value to match in .spec file. For example hext2 tileset with normal_tile_height defined as 72 in the tilespec needed 36 pixels cut from the affected sprites that earlier were 108. Sprites affected are cities and all the smaller icons such as hitpoint bars, unit activity icons, city size indicators. Units and terrains are not.

Does this mean that things won't be able to be placed above/below the top/bottom on these anymore? It's the only change in my preliminary/experimental 2.5 patch that I didn't do, as it looks like just png editing rather than spec. (No 2.5 beta to test either way though)

Short answer: That doesn't affect amplio2hexbig. I have to do some more documentation on the hex/isohex issue, but amplio2hexbig is of the not-affected kind.

There's a problem being solved in tilesets supplied with freeciv that mine_sprite has not been defined for all terrains. That's a problem with custom rulesets that enable building mines to those terrains.
bug #21559. You may want to fix this in amplio2hexbig too.

How?

Make sure every (at least all land terrain) [tile_xxx] -sections in .tilespec has mine_sprite -entriy. See the patch in the ticket to see how it was done for supplied tilesets.

[GriffonSpade]

Short answer: That doesn't affect amplio2hexbig. I have to do some more documentation on the hex/isohex issue, but amplio2hexbig is of the not-affected kind.

Yeah, upon waking up and thinking about it on a new day, I thought to check the orientation of hex2t's pngs (instead of just specs) and realized this.

There's a problem being solved in tilesets supplied with freeciv that mine_sprite has not been defined for all terrains. That's a problem with custom rulesets that enable building mines to those terrains.
bug #21559. You may want to fix this in amplio2hexbig too.

Make sure every (at least all land terrain) [tile_xxx] -sections in .tilespec has mine_sprite -entriy. See the patch in the ticket to see how it was done for supplied tilesets.

Oh, okay, this is just a 2.4 change then, not 2.5!

As a final note, I need to ask Ngunjaca yet if his roman diplomat (and a few others that I didn't put in) is GPL.
Edit: took the roman diplomat out until i get a reply from Ngunjaca

Version 1.7a released with mines for all terrains. (just curious, but is the mine_sprite even used in 2.5? the HT2.4-2.5 doesn't mention it being removed, but it's controlled completely by terrain.ruleset in 2.5 isn't it?)

[GriffonSpade]

I just realized, that while buildings.spec has wonders referenced, buildings-large.spec does not. I'll have 7.1b up in a minute which will reference wonders-large.spec.