The International Simutrans Forum

Development => Extension Requests => Topic started by: walsjona on September 08, 2017, 08:26:55 PM

Title: Way and wayobj dependent retaining walls
Post by: walsjona on September 08, 2017, 08:26:55 PM
Essentially as stated in the subject, allowing the retaining walls to be set by the way or wayobj that is placed in the adjacent tile. This would be mostly for aesthetic reasons, so can appreciate it would be low priority. However, with the decorative wayobj currently in the pipeline this seemed like a complementary feature, if its at all possible.

From my side of things, I have been going back through my various bits of concept art and I have a few assets that could potentially work as way dependent retaining walls as shown below. These were coded as ways in order to display them in game, but this does restricts rotation of the map.

(https://s6.postimg.org/bgizgj32p/simscr68.png) (https://postimg.org/image/cit5z2lvx/)

(https://s6.postimg.org/h5z80u98x/simscr69.png) (https://postimg.org/image/eongtkpcd/)

If this can be done then fantastic but if not no worries.

Thanks

Jonny
Title: Re: Way and wayobj dependent retaining walls
Post by: Leartin on September 11, 2017, 06:38:34 AM
I agree that retaining walls need some love. Eg. they could be climate and timeline dependent, and the way they are created might change as well (have one structure per side, masked to the area needed, plus "top" and "bottom" overlays that are placed over them to alter the top edge and bottom edge)

But let's talk "realistically". I think currently, walls take up only one bit per tile, defining whether it's rock or basement, perhaps not even that and it just looks up whether there is a building on the tile. More options would require more bits, obviously, and you'd have to start considering how many different walls should be available. But note how currently, all four walls of a tile use the same texture - so in order to be able to change only one face, you'd need four times as much information stored.
Just 'looking up' other information should work if it is simple information easily accessed. Whether there is a building on the same tile is quite simple. Similarly, it would be easy to ask the climate on the same tile, or the current game-time. Looking up if there is a way on an adjecent tile in that direction that links to a different wall-pak is, in comparison, quite difficult I imagine.


Though it seems quite clear that what you are trying to achieve might be better done by allowing assymetric ways and wayobjects, such that the rotation would no longer be an issue - something discussed a few times by now. These walls could go with any way of any type, so making them a decorative wayobj that can be placed on every way makes a lot of sense.
Title: Re: Way and wayobj dependent retaining walls
Post by: walsjona on September 25, 2017, 07:48:36 PM
Quote from: Leartin on September 11, 2017, 06:38:34 AM
Though it seems quite clear that what you are trying to achieve might be better done by allowing assymetric ways and wayobjects, such that the rotation would no longer be an issue - something discussed a few times by now. These walls could go with any way of any type, so making them a decorative wayobj that can be placed on every way makes a lot of sense.

While I definitely advocate the implementation of asymmetric ways and wayobjects, my real frustration here is slopes and tunnels. Having individual way or wayobjs for each slope type is impractical as the menu would fill up rapidly! It is a bit of a balancing act and while yes this is mostly an aesthetics issue, I have to be honest it looks odd just using full height retaining walls with no cover on the slopes! Similarly some of the tunnel portals I am working on are set back slightly, thus in deep trenches they have a bit of the default retaining wall showing through and here again it would be useful to have some control over what retaining wall is used.

Quote from: Leartin on September 11, 2017, 06:38:34 AM
But let's talk "realistically". I think currently, walls take up only one bit per tile, defining whether it's rock or basement, perhaps not even that and it just looks up whether there is a building on the tile. More options would require more bits, obviously, and you'd have to start considering how many different walls should be available. But note how currently, all four walls of a tile use the same texture - so in order to be able to change only one face, you'd need four times as much information stored.
Just 'looking up' other information should work if it is simple information easily accessed. Whether there is a building on the same tile is quite simple. Similarly, it would be easy to ask the climate on the same tile, or the current game-time. Looking up if there is a way on an adjecent tile in that direction that links to a different wall-pak is, in comparison, quite difficult I imagine.

This is where I show my ignorance as I don't know how this bit of the code actually works, but I do take your point that increasing the number of retaining walls would increase the amount of memory required per tile (if the current system uses a simple boolean variable). That said a bit more variety here is sorely needed so the memory hit might be warranted.

While ideally it would be nice to vary each face individually I personally would be happy enough with just being able to just set it per tile. However, if you did go down the route of individual retaining walls for each face, would you really need to store the retaining wall to be display if two grid are on the same level or one slopes up to the other? Surely you could just store the preferred retaining wall then when a face is exposed the actual retaining wall used ? Thus your actual increase in memory would be more along the lines of nbit*(#tiles+#retainingwalls), though this may be a gross oversimplification.