News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Should adjoined wayobj always be connected?

Started by THLeaderH, June 02, 2017, 01:09:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

When we build way separately like this image, we can use the image of the edge.
However, when we build wayobj separately as we do on way, wayobj automatically connects and we cannot use the image of the edge.
I want to use the image of the edge when we build wayobj separately. This expands the possibility of the expression of wayobj. Is there any reasons why wayobj cannot do such?

Ters

As far as I know, the technical reason why wayobs autoconnect, is because they do not have their own ribis. So if the underlying way is connected, so is the wayobj. It is one and the same state.

Since wayobjs seems to exist for electrification only, allowing breaks made little sense, I guess. If you could have breaks in electrification, what would it mean? If it meant nothing, some players would complain that it should mean something: electric trains should not be able to pass. However, if it did work that way, players would have another source of "no route" errors, which would also cause complaints. The only reason ways don't autoconnect to avoid such problems (except at the ends of newly built bridges and tunnels, which I think is a recent change) is that doing so is at least equally bad at giving players what they want (which was an even bigger problem before click-and-drag construction of bridges). That's probably why it hasn't been worth it to give wayobjs their own ribis. The question therefore is whether your unstated use case is worth adding this to every wayobj and dealing with the above problem.

Leartin

Quote from: Ters on June 02, 2017, 05:25:04 AM
As far as I know, the technical reason why wayobs autoconnect, is because they do not have their own ribis. So if the underlying way is connected, so is the wayobj. It is one and the same state.

If that was the case, the wayobject would always show the same graphic as the way underneath. That's not the case, it only connects to other wayobj if they exist, not to tiles with way but no wayobj.



Quote from: Ters on June 02, 2017, 05:25:04 AMSince wayobjs seems to exist for electrification only[...]
Perhaps that was the original intention, but they evolved since then and are used for decoration all around. And perhaps will be used even more with the new 255 wayobj, since before you would need to save your one wayobj-slot for electrification on rails, but now you can use one slot for decoration without any problem. Thinking of wayobj only as means for electrification does not help much now.

Quote from: Ters on June 02, 2017, 05:25:04 AMIf you could have breaks in electrification, what would it mean? If it meant nothing, some players would complain that it should mean something: electric trains should not be able to pass. However, if it did work that way, players would have another source of "no route" errors, which would also cause complaints.

You are right, but there is a solution for that:
Quote from: Meway_objects get [...] new parameter [...] "connectivity" [...] zero if undefined.

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, since they would cut off the road at crossings or the barriers end.

To avoid the 'broken' electrification, nobody would need to do anything, any old electrification can stay as it is. Although 2 might be a valid option as well (after all, you thought that was already the case)

Quote from: Ters on June 02, 2017, 05:25:04 AMThe question therefore is whether your unstated use case is worth adding this to every wayobj and dealing with the above problem.
Adding it as the general behaviour would not be worth it. Adding variant 1 (no-connect) as an option by itself might not be worth it. But adding variant 2 is essential to use walls, and if variant 2 is added, variant 1 can be done as well.

THLeaderH

Anyway, in which files is the process of building wayobj written?

Ters

Quote from: Leartin on June 02, 2017, 06:14:54 AM
If that was the case, the wayobject would always show the same graphic as the way underneath. That's not the case, it only connects to other wayobj if they exist, not to tiles with way but no wayobj.

My point was that wayobjs probably used the way's ribi to tell what it is not connected to, not what it is connected to. But it doesn't matter anyway, since my knowledge was flawed. Wayobjs do have their own ribi flags.

Quote from: Leartin on June 02, 2017, 06:14:54 AM
Perhaps that was the original intention, but they evolved since then and are used for decoration all around. And perhaps will be used even more with the new 255 wayobj, since before you would need to save your one wayobj-slot for electrification on rails, but now you can use one slot for decoration without any problem. Thinking of wayobj only as means for electrification does not help much now.

It might explain why things are the way they are. That is a good thing to have in mind when planning for the future.

Quote from: Leartin on June 02, 2017, 06:14:54 AM
You are right, but there is a solution for that:

I was thinking the same thing, but got distracted by my sudden belief that wayobjs don't have ribis and ran out of time.

prissi

If there are two mismached wayobj I would agree. Otherwise not connection adjacent wayobjects is just confusing 99.5% of the players who use wayobjs for electrification (and maybe soon overtaking).

Ichou

Some of you seem to be afraid of the sacrifice: players who use wayobj only for the electrification will get confused. Of course, at first, they will get confused to know something is changed. However, they will soon find what was changed, and will soon get used to the new rule because it's very the same to the way's one. Thus, the sacrifice is not at all large enough to take into account because it will be transitory, given the permanent merit: the large ability in expression.

You might prefer the current system because it's better for the normal players: those who use wayobj only for electrification. However, is the current system really better for the normal players? I suspect you prefer it just because you've got used to it. To be honest, when I began Simutrans, I got confused about the difference in rule between way and wayobj. So the idea is not true of me that the current rule is better.

Ters

The problem is that it all adds up for new players. People already find Simutrans awfully complicated.

Leartin

Quote from: Ters on June 12, 2017, 02:17:30 PM
The problem is that it all adds up for new players. People already find Simutrans awfully complicated.

Not true. New players encounter ways before wayobjects. They learn ways don't connect. If wayobjs don't connect either, that's already learned and just expanding the same principle. On the other hand, if ways don't connect but wayobj do, then a new player has to learn the two different behaviours as seperate informations. So technically, the current behaviour is more complicated than changing the behaviour to no-autoconnect.
...though I don't think it really makes much of a difference in complexity either way, unless you could end up with electrification on neighbouring tiles which is not connected, does not allow electric vehicles to pass, but does not show a gap since the end-graphics are too close to continuous graphics. But so far we only talked about changing the graphic, so it would rather be that you'd have something that does not look connected but allows vehicles to pass. Which, according to you, would not be an issue, since it's something people don't expect to work, but works anyway, rather than something they expect to work, but doesn't.

If you think it's two complicated how about solving actual complexity issues instead? Eg. the chicken-egg-problem of electrification - players don't know electric trains exist until they build electrification to the depot, but why would they build electrification at all if there are no electric trains, and especially into the depot, after they learned that electrification auto-connects - shouldn't the depot connect to electrification running past it by itself?`
I'd think a large chunk of complexity for new players could be avoided if
  • depots could be buildt on any ground, placing their way beneath and one tile in front on it's own (obviously rotating towards a waytile if it already exists)
  • depots would be more prominent in the menus (pakset-issue, but it's usually somewhere in the middle and impossible to find for a new player)
  • depots should always show the electric tab if any electric vehicles and any electrification of the waytype exist at any time, showing new players there is more.
  • Clicking  on the electric tab on an unelectrified depot should not show vehicles, but instead a message "Electrification for this depot is not yet available" (if it isn't) or "This Depot is not capable of using electric vehicles, [electrify now]" - the latter button would place electrification on the depot and the tile in front of it.
  • if an electrification exists on the tile in front of the depot, the depot should become electrified automatically.

    Has that anything to do with auto-connecting? Nope, not at all. But if complexity creep is a reason to not add useful stuff that does not add much complexity in the first place, then any suggestion that reduces complexity for players should be welcomed with open arms. And let's face it - who wouldn't like to build depots with two clicks (Icon + map-placement) rather than eight (way, 2x to place, electrification, 2x to place, depot, placement)?

Ters

Quote from: Leartin on June 13, 2017, 07:05:04 AM
They learn ways don't connect.

Knowing that ways don't connect and knowing that a way isn't connected are two different things.

Quote from: Leartin on June 13, 2017, 07:05:04 AM
If you think it's two complicated how about solving actual complexity issues instead?

That is kind of what I'm doing, by being skeptical about introducing another source of needle-in-the-haystack situations. Not to mention that having wayobjs always autoconnect was solving an actual complexity issue.

However, a solution to all of this is already on the table: different types of wayobjs must have different auto-connect rules. In fact, I can't see how wayobjs controlling one-way rules can function without it. (One-way roads, unlike electrification to some degree, is not something one has to learn to play the game properly.) As far as I can tell, this issue is just waiting for a developer to find it worth their time to code.

Ves

I would support there to be an option in the datfile to specify wether the wayobj should autojoin or not. I myself bless the feature as it currently works, as I often come into the situation where a looong piece of track has been laid and then two pieces are not connected which is a pain to find. Imagining having to do the same for the catenary, especially through all joints in a complicated trackwork... :-[

Vladki

Leartin, Iike your suggestions about depots.

I think that Autoconnect should be preserved. If the roads are connected, so should be the wayobjects.

The only problem I see is with wayobj on crossroads where only some of the roads are electrified or decorated. In that case it should have the same ribis as the underlying road.

Sent from my ONEPLUS A3003 using Tapatalk


Ichou

I understood many of you want the current rule because you want to avoid the confusing, so the solution seems to be Leartin's suggestion:
Quoteway_objects get [...] new parameter [...] "connectivity" [...] zero if undefined.

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, since they would cut off the road at crossings or the barriers end.

However, the truth is that this is the most confusing system for the new players. Once they see the electrification auto-connected, they will have an assumption that wayobjs connect automatically. Then when they encounter non-autoconnected ones, they will definitely confused.

So my suggestion is that they don't connect automatically when built with the Shift key. Normal players or new players don't worry about the new source of the error because they usually construct them without the Shift key. And those who want terminal images can easily get them. Since they might do it with the Shift key by mistake, it might be better to show a tooltip that "The connecting rule depends on the Shift key."(There must be better English than it) when they try to construct wayobj with the Shift key.

THLeaderH