Tile orientation

Contribute, display and discuss art and tilesets for use in Freeciv here.
Wahazar
Hardened
Posts: 224
Joined: Mon Jul 02, 2018 1:49 pm

Tile orientation

Postby Wahazar » Sat Jan 19, 2019 11:09 pm

I have a water lock coded as an additional base, currently it is one image, is it possible to define other images and force their orientation to match coast line?
For example, water lock on the right should be rotated:
waterlock.png
waterlock.png (101.86 KiB) Viewed 1381 times


Something similar works with rivers, but not sure is it is possible with base, and how it exactly works.

nef
Hardened
Posts: 160
Joined: Mon Jun 25, 2018 5:01 pm

Re: Tile orientation

Postby nef » Mon Jan 21, 2019 2:33 pm

Change it to a road. The .tilespec can then select images based on what connections can be made. From memory there is a specific feature to do just this with connecting with sea but if that doesn't work then you may need to create artificial 'roads' on the nearby ocean tiles. I will take a closer look during the week and report if no one else has sorted it out by then.

nef
Hardened
Posts: 160
Joined: Mon Jun 25, 2018 5:01 pm

Re: Tile orientation

Postby nef » Mon Jan 28, 2019 1:48 pm

The only one that looked promising was

Code: Select all

[extras]
  styles =
      { "name",          "style"
        "road",          " RoadAllCombined"
       }

    RoadAllCombined : One sprite is drawn to show roads in all directions.
    There are thus 256 sprites (64 for a hex tileset).
I am not sure that 64 is quite what you want, but I am also not sure what you want to do when there is more than two tiles to connect. If you can just limit it to 2 then you would only need 3 sprites. The rest could be just blank. But the issue becomes how to specify the Lua script to place the connecting "roads".

Wahazar
Hardened
Posts: 224
Joined: Mon Jul 02, 2018 1:49 pm

Re: Tile orientation

Postby Wahazar » Mon Jan 28, 2019 4:18 pm

What I need is proper orientation against coast line. This waterlock can be located only on coast, I don't want it to allow access deeply inland due to gameplay balance.

Rivers have river_outlet sprites, how to assign it to the waterlock?

And is it possible to have background and foreground image for feature, which is not classified as a 'base' ?

cazfi
Elite
Posts: 1710
Joined: Tue Jan 29, 2013 6:54 pm

Re: Tile orientation

Postby cazfi » Tue Jan 29, 2019 10:36 am

Wahazar wrote:Rivers have river_outlet sprites, how to assign it to the waterlock?
I can't check the details just now, but you should be able to use just the same set of sprites as rivers do by assigning the same "extrastyle" ("River"?) for your extra in the tilespec.

nef
Hardened
Posts: 160
Joined: Mon Jun 25, 2018 5:01 pm

Re: Tile orientation

Postby nef » Mon Feb 04, 2019 12:24 pm

Wahazar wrote:What I need is proper orientation against coast line. This waterlock can be located only on coast, I don't want it to allow access deeply inland due to gameplay balance.

Rivers have river_outlet sprites, how to assign it to the waterlock?

And is it possible to have background and foreground image for feature, which is not classified as a 'base' ?

River and 3Layer are in the same namespace as RoadAllCombined (i.e. "style" in the [extra] section). so you have to choose one and only one for each type of extra. I can see no indication that style is related to the extra type as defined in the ruleset (base, road, mine, irrigation, etc.).

Using caz's suggestion I think you would need a heap of tags in the spec file which connect all 'cardinal' combinations which in the case of hex is all connections (= 64 same as RoadAllCombined for hex) PLUS 6 more for the outlet sprites. The latter may be exactly what you want. If you require no actual inland connections, the former (=64) could be compacted to just a single central sprite in the png that then connects to all possible combinations of the 6 "sea" connections, making a total of 7 sprites. Look at tileset spec file for the conventions on naming suffixes for the 64 plus 6. The first 64: <tag>_s_<direction_combo>; the next 6: <tag>_connection_<simple_direction>. While there appears to be well defined rules defining the suffixes that are added for each extra "style", the prefix system <prefix>.<tag> is still mysterious to me. Mostly it looks like they are optional (in matching between ruleset and tileset), but this may be about to change because "road.<roadtype>" is now used in both. In any event the prefixes used within the tileset must be consistently used - as I read it.

caz may be able to sort out these details for both of us.

As for foreground/ background sprites (with 3layer) the three suffixes used are _fg, _mg, _bg and therefore only three sprites (max). It is fairly clear that this affects the layering when rendered by the GUI. Once again I find some of this layering stuff poorly defined so someone who knows may be able to help.

nef
Hardened
Posts: 160
Joined: Mon Jun 25, 2018 5:01 pm

Re: Tile orientation

Postby nef » Mon Feb 04, 2019 12:41 pm

As an afterthought, I am still not convinced that you do actually want all 6 sprites. If I were to guess, you may just want a sprite chosen that connects to only (any) one of the sea tiles, which in practice may mean just three sprites. If this is true then my mind takes me back to RoadAllCombined and a Lua script that assigns a connecting road extra to each coastal tile.

Wahazar
Hardened
Posts: 224
Joined: Mon Jul 02, 2018 1:49 pm

Re: Tile orientation

Postby Wahazar » Mon Feb 04, 2019 7:25 pm

Exactly, 3 sprites are enough. Can I use bg/fg for sprites other than base?

Wahazar
Hardened
Posts: 224
Joined: Mon Jul 02, 2018 1:49 pm

Re: Tile orientation

Postby Wahazar » Thu Feb 07, 2019 11:00 am

I tied waterlock to the river style, but it is not working correctly. waterlock_outlets need to be blank pictures, because they are drawn on the sea (eventually waterlock doors can be used for that).
There is plenty of river variants, and I doubt I can manage them properly.
For example, I expect that waterlock would be oriented perpendicular to the cost, it works in case of single waterlock:
waterlock1.png
waterlock1.png (60.94 KiB) Viewed 1157 times

but when another waterlock is on the adjacent tile, first waterlock would rotate because it mimic river behavior:
waterlock2.png
waterlock2.png (54.24 KiB) Viewed 1157 times


Beside this, overloading lot of sprites with same graphics or blank graphics is not crappy.

The only viable solution is using lua script, unfortunately I know nothing about how it works.

nef
Hardened
Posts: 160
Joined: Mon Jun 25, 2018 5:01 pm

Re: Tile orientation

Postby nef » Sun Feb 10, 2019 10:46 am

Wahazar wrote: Can I use bg/fg for sprites other than base?
I read that all styles can be used with all types of extras, but I have NOT tested all combinations (in fact not even many) so there may be a gotcha. Just to be sure, 3Layer is INCOMPATIBLE with other styles such as RoadAllCombined (or River) so you could use it only for some other purpose. Its purpose in fc is for bases (forts etc.) where you want the lower part overlaying a normal feature, and the upper part being overlaid. I can see NO USE for it in this particular application.

Using Lua to create the 'road' type extras on coastal tiles comes with a caveat. Because there is currently no callback for terrain alteration, you would be courting trouble if you used terrain transform to convert sea <-> land. If push comes to shove this can be done with a call back using turn start/end but it's a little messy. The simple case can be modelled on my scripts for the civ1 rulesets using the map generated callback to do a map iterate to find 'coastal' tiles and create an extra on the tile. It is this road extra that would (should?) connect to your lock which itself would need to be a connecting road type extra.

I've had this on the shelf for another purpose but you can use it if you like:

Code: Select all

  if  tile.terrain:class_name () == "Oceanic"   
      for adj_tile
      in  tile:square_iterate(1)
      do
     
        if   adj_tile.id ~= tile.id
        and  tile.terrain:class_name () ~= "Oceanic"
        then
             edit.create_extra (tile, "Coastal")
             break
       end
       
      end   --    end iterate
  end  -- end if

Add it into the 'insert active code here' point in the Lua 'shell' described in this post

Based on this comment in terrain.ruleset for [road_*]

Code: Select all

; integrates              = list of road types that are suitable next steps
;                           for travel from this road type; such steps are
;                           possible for units native to both roads and don`t
;                           get cost from underlying terrain; graphics are
;                           drawn accordingly
you would "integrate" your 'lock' road extra to the "Coastal" road extra. Use the "Grass_Shield" road/extra pair in http://forum.freeciv.org/f/viewtopic.php?f=15&t=597&start=20#p100657 changing the name to match the name used in the Lua script (in this case "Coastal" - which you can of course change). I suspect that the "integrates = <road_type> is only needed in one of the pair of roads ("Coastal" and <lock name>) but I would try both. I have NOT tested this combination, but there is a good chance it will work. Note that "Coastal" does NOT need a graphic so you should not (could not) provide an entry in the tileset styles list.

Don't forget: you will need 64 tags mapping down to your three sprites (plus a 'dead' one for no connection case).