Topic: (wishful thinking) two way_objects on one tile

[Leartin]

way_objects are a great way to add eye candy for streets. However, even though I often thought about doing something as a way_object for rails (like bushes, noise barriers, telegraph poles, elaborated bridge design), those do not work, since railways almost always get electrification sooner or later. What's more, those way_objects auto-connect if the way beneath them is connected - that's great for electrification, but bad for most eye candy.

I noticed that with tramways on streets, you could add two way objects (one for the road, one for the track) - I would like to be able to do that normal rails as well.

What I am thinking about:
way_objects get two new parameter, something like "position" and "connectivity" both of those are zero if undefined.

position can be 0 (inside) or 1 (outside) - each way tile can have one inside way object and one outside way object at the same time. For drawing purposes, the order ist outside backimage - inside backimage - vehicle - inside frontimage - outside frontimage. [electrification will almost always be inside, since it's directly on or above the road, while most eye candy would be on it's side(s)]

connectivity decides on how the auto-connection works.
0 is obviously the current behaviour, which is to not care about the directions the way goes, but if two way_objects are next to each other, they connect if the tiles are connected with a way already.
1 is "no auto-connect", which as far as I am aware already was the standard behaviour once. This can be useful for elaborate bridge design. For example, you could create an arch spanning three tiles with only one way_object.
2 is "same as way" - this means that the way_object will always use the same ribis(?) as the way beneath it. This would be useful for walls or everything that runs beside the way, since it will automatically leave an opening wherever a way goes. currently, you could not do noise barrier even for streets, since they would cut off the road at crossings or the barriers end.

[prissi]

Well, this also poses the question how to delete the second way-obj. Also not autoconnecting wayobj defies somewaht the porpose of wayobjs. You could work around using unsused waytypes elevated way fo put on top of ways too.

[Leartin]

Deletion would be outside first, then inside (with single tile deletion tool) and for the multi-tile deletion tool, I don't know if you could do the same - I guess a second deletion tool would be viable.

Maybe i poorly defined what I meant by auto-connect. If there is a 4-tile long way and you build any way_object on the first two tiles, and another (or the same) way object on the other two tiles, the middle will connect automatically, so the way object spans all four tiles. Especially with different way objects, this can look strange. Electrification might expect a pole on the next tile, but there is only a street lamp, leaving the wire hanging in the air.

Elevated ways are a workaround, I did not really think about that. They are not perfect, since they would easily lead to levitating decoration, but at the moment, they are probably the best choice for eye candy on rails.

[Ters]

I guess a second deletion tool would be viable.

You mean a third? Or maybe even higher. Simutrans has many tools for deleting things already.

[Leartin]

You mean a third? Or maybe even higher. Simutrans has many tools for deleting things already.

I mean a second deletion tool for way_objects per way. The programming should be almost the same, it's not like every deletion tool works completely different.
For players... well, either there is no eye candy in a pakset, and the new deletion tool is not needed, or there is eye candy, but it's currently removed be the "overhead wire removal tool", which does not make a lot of sense. Having an additional "decoration removal tool" would be a good thing.

So why is the deletion tool even an issue?

[Ters]

So why is the deletion tool even an issue?

Complexity. Simutrans is very complex with a steep learning curve already. That this tool is for this particular circumstance is another thing they must learn and remember. For someone that doesn't know the implementation, it's not obvious that bushes and telegraph wires have anything in common, so that they have a common remover tool. (Although, as long as there are very few types, one could depict all in the icon.) It's not much on it's own, but these things sum up. The comlexity doesn't really start with the removal tool, because it's complexity that causes the apparent need for another removing tool.

What might be easier on the players is if the concept of type-specific removers available for ways was also available for wayobjects. One would then pair up the build and remove tools. If the icon for the latter is the icon for the former with a red cross or somthing, it should be obvious enough. It will easily clutter up the toolbars, though. One might also want a common remover for objects that are really just different versions of the same thing, which would likely mean that a change in the dat and pak formats is needed.

[Fabio]

If the purpose is eye candy only and you don't need it on every tile, you could also use signs bidirectional and with min speed =1


Sent from my iPhone using Tapatalk

[Leartin]

Complexity. Simutrans is very complex with a steep learning curve already. That this tool is for this particular circumstance is another thing they must learn and remember. For someone that doesn't know the implementation, it's not obvious that bushes and telegraph wires have anything in common, so that they have a common remover tool. (Although, as long as there are very few types, one could depict all in the icon.) It's not much on it's own, but these things sum up. The comlexity doesn't really start with the removal tool, because it's complexity that causes the apparent need for another removing tool.

This complexity comes as soon as anyone includes a way_object that is not electrification, none of the things I proposed is needed. Which means it's not an argument against my proposals, it's an argument against the option to choose whether a way object is actually electric. It's an argument against the use of way_object as objects at the way instead of electrification. Two things which already exist, and are used in pak192.comic.

For the player, no complexity is added. Everything functions exactly the same, so all the "old" stuff can be used exactly the same.
Additionally, the player can now plant bushes or a noise barrier for decoration purpose, and delete them with a new deletion tool. He might have to learn that there are elements in the game which have no function, but he already learns that, when he chooses which station extension to use (quite often, there are some with the same stats and different design)

Furthermore, it's less complex then paks which have decorative way_objects now.

One would then pair up the build and remove tools. If the icon for the latter is the icon for the former with a red cross or somthing, it should be obvious enough.

Isn't that actually possible already? "general_tool[33],X,,noise_barrier" should create a button specifically for removing the object "noise_barrier". (At least that's how I understand it should work based on how it should work with building objects, which did not actually work for me)

If the purpose is eye candy only and you don't need it on every tile, you could also use signs bidirectional and with min speed =1

If it's only placed on straight ways with no height change, and you don't need different tiles at the "end", yes, you could do that. You wouldn't have a removal tool, though, which seems to be quite the issue.

[Ters]

Additionally, the player can now plant bushes or a noise barrier for decoration purpose, and delete them with a new deletion tool. He might have to learn that there are elements in the game which have no function, but he already learns that, when he chooses which station extension to use (quite often, there are some with the same stats and different design)

That the player already must learn something does not mean that we can expect the player to keep learning ad infinitum. If an option is available, users will eventually try it, and may then find they have built something they don't know how to remove (except through the generic removal tool, which might remove other things first).

[Leartin]

Sorry, but that's just too silly. I guess way_objects which are not electrification are just evil and not supported.

[Ters]

Most developers seem to have taken a summer vacation from this forum. Give it some time. Maybe someone with less negative experience with (supposedly professional, trained) users presented with more than ten toolbar buttons will show up. Or maybe someone can find another path to the same goal.

[prissi]

Different connection rules for wayobj will probably not come. Actually I would rather introduce an eyecandy object, which may inherit from wayobj (the good things of OOP). There are still 33 id unclaimed ...

[Isaac.Eiland-Hall]

There are still 33 id unclaimed ...

Claim yours today! Only $99.95¹ and it's yours! Act now, they're going fast! Well, okay, maybe not so fast considering that Simutrans is 17 years old. But still!

_______
¹ plus seventeen easy payments of $249.95, billed monthly

[Fabio]

If the "problem" is to fill up the unused ids, I always wished one or two additional way types with road logics (i.e. Bidirectional, although limited in length)


Sent from my iPhone using Tapatalk

[prissi]

This is something else, way ID are almost used up.

Bidirectional, although limited in length

does not translate to me.

[Fabio]

Sorry, I meant bidirectional as roads, even if this implies that the convoys are limited in number of cars


Sent from my iPhone using Tapatalk

[Ters]

I wasn't aware that Simutrans imposed a maximum length on convoys. Another road-ish waytype has been proposed before, but no one wanted to implement it until someone could explain what they needed it for. Please look up the discussion for that (your searching is probably as good as mine), so we do not to derail this further.

[Isaac.Eiland-Hall]

I believe road convoys are limited to four (i.e. a rig and three trailers). I wished previously for more to simulate Australian road trains, but it wasn't approved. At least there's four, though. I always use trucks... and there's a set of road trains on the Japanese forum for pak128.....

[Leartin]

Sorry, I was a bit annoyed and left this forum for a few days so I wouldn't write something nobody want's to read ^^°

I would rather introduce an eyecandy object, which may inherit from wayobj (the good things of OOP).

Isn't the best eyecandy object actually the ground_object? I mean, beside trees, that's the only object that has no function. Even citycars obstruct ways and therefore influence gameplay, but I don't think anyone builds around woods or groundobjects to save cash. And if it is an object to be placed on ways, it would simply be a way_object, even if you call it differently (because the "old" wayobject which is then probably no longer meant for eyecandy would be electrification. Although I understand that, for compatibility reasons, you can't change the name of those)

Another road-ish waytype has been proposed before, but no one wanted to implement it until someone could explain what they needed it for.

Aerial lift. Especially in paks with double height instead of half height, aerial lifts as elevated ways which can climb steep slopes might be interesting. However, they'd probably need additional rules to really work fine.
If crossed with tram, so that you can have both roadlike ways on the same tile, maybe an extra bike/horse lane? (but if copying the tram code was easy, it should be implemented in the other rails anyway)
Any kind of Sci-Fi vehicle might be bidirectional (and any pak can have sci-fi stuff in the future)
Any "national" pak of a nation that has no access to the sea might choose to use a second bidirectional way as channel for ships.
Footwalks. I mean, if you copy the road code, you can copy the citycar-code as well. If you then use people as vehicles of length 0 or 1, you could have more vivid cities. Or just manually place them as vehicles that have no graphic when empty, but look like people when occupied with one passenger, to even decide on the amount of people individually.

There are possible uses, so if it existed, I would definitely use it in some way or other. But none of these uses is really enough to require it, just a minor nice to have.