Topic: r7517: impossible to build a bridge

[gauthier]

It's impossible to build bridges from the two rail ends which are one tile south from the westward road, to the slopes after the river. This is probably caused by the river, as it is wide enough to be navigated.

(Simutrans 120.0.1 r7517, windows 7, pak128 2.5.2)

[Václav]

Gauthier,

hard to say why it is not possible in case of tracks that are in back (closer to the west).

But in case of tracks that are in front (closer to the east, city), there you have problem because river seems be in the same level as road in city you want to cross. And land that is barrier between river and road in city is blocking building of that bridge.

Erase that land between river and city road - and then it should be OK. Or erase tile of track that is on slope.

[Ters]

I have no problems with a set-up like this in pak64, suggesting that half-height plays a role here. (Bridges in pak64 are always full or double height, so clearance below is never an issue. Thought it might be something else than faulty clearance checks that is the issue.)

Update:
It seems that some bridges work, others don't. Could it be that it does a length check on the bridge before it figures out at which height to build it?

[Leartin]

In this scenario, you should be able to drag a bridge along the western rails, but you would need to connect to the rails, not the slope, since you need to climb up one more level to have clearance. To be able to start the bridge on the slope, you'd need to delete the navigable river, since you can not create an upwards bridge head on a downward slope (sadly)

[gauthier]

@Václav: I think there's a misundersting on the targeted height of the bridges. They are supposed to be same height as the northern pieces of tracks, so the piece of land is one half-height below, so it is not the problem.

@Ters: Good idea but it isn't the problem, the bridge which I want to build has far enough length level.

@Leartin: Yes but building a bridge that high is not desired here.

Indeed the only problem was the river, I switched to public services and downgraded it to a non navigable level, then I was able to build the bridges.

Anyway, would it be possible to change this behaviour ? I mean allowing player to build a bridge only half height above a navigable river ? This would make the river non navigable of course, but it's acceptable as the river is not placed by the player and he doesn't necessarily use it.

[Leartin]

Think of it the other way around. You already learned that the game does not allow you to build a bridge that blocks a way beneath. Then you build a bridge over the river, and your boats get stuck. Maybe you would understand that it was the bridges fault, but surely it would seem inconsistent and like a bug.

[Ters]

@Ters: Good idea but it isn't the problem, the bridge which I want to build has far enough length level.

Do you know which level the bridge builder would have considered? Or is there a very tall mountain just north of the screen shot.

Anyway, would it be possible to change this behaviour ? I mean allowing player to build a bridge only half height above a navigable river ? This would make the river non navigable of course, but it's acceptable as the river is not placed by the player and he doesn't necessarily use it.

But it is possible. Depending on how I built the bridge, or which bridge I was building, I was able to build a bridge half a height above the river.

[gauthier]

Do you know which level the bridge builder would have considered? Or is there a very tall mountain just north of the screen shot.

In pak128, rails can only have half slopes, same goes for bridge ramps, so it could not consider building the bridge higher than that.

But it is possible. Depending on how I built the bridge, or which bridge I was building, I was able to build a bridge half a height above the river.

Could you post a picture and/or a precise description of how you did this ?

[DrSuperGood]

Could you post a picture and/or a precise description of how you did this ?

Drag bridge across open water. It allows you a bridge open water at height 0.5 when in theory clearance should only allow with a ramp on both sides. Tested with current release version (not nightly where it may be fixed). Attached is a map showing what I mean.

[gauthier]

In my case the problem is not open water but a navigable river (~canal).

[Ters]

In pak128, rails can only have half slopes, same goes for bridge ramps, so it could not consider building the bridge higher than that.

My point was that maybe the game had not checked which heights it could build at yet. I don't consider it particularly likely, but still very much possible in theory, that the game checks how far there is to an opposing slope one full level up, before checking that the bridge actually has the parts for such a layout.

Could you post a picture and/or a precise description of how you did this ?

I'm actually having more problems coming up with a pecise description of how to reliably get that error you are getting. The version of pak128 that I have is 2.5.0, so that might have something to say. But I have managed to get the error on occasion. With a canal, not a river. And never when dragging.

[gauthier]

The version of pak128 that I have is 2.5.0, so that might have something to say.

I don't think so, these parts of the pakset have not changed since 2.5.0.

My point was that maybe the game had not checked which heights it could build at yet. I don't consider it particularly likely, but still very much possible in theory, that the game checks how far there is to an opposing slope one full level up, before checking that the bridge actually has the parts for such a layout.

I see what you mean. Anyway this map is very flat and there's no other slope behind those ones.

[TurfIt]

Anyway, would it be possible to change this behaviour ? I mean allowing player to build a bridge only half height above a navigable river ? This would make the river non navigable of course, but it's acceptable as the river is not placed by the player and he doesn't necessarily use it.

Pak128 is not explicitly specifying the way_height_clearance setting. Hence it's based off height_conversion_factor which pak128 is setting to 2.
Change way_height_clearance to 1 if you want to build that bridge. In the settings dialog, it's strangely hiding under the 'Economy and cities' tab.
The river remains navigable - ships will happily clip through the bridge.

I'm actually having more problems coming up with a pecise description of how to reliably get that error you are getting. The version of pak128 that I have is 2.5.0, so that might have something to say. But I have managed to get the error on occasion. With a canal, not a river. And never when dragging.

It's hard to see, but in the original picture, the tracks south of the road are at the same height as the river, one level below the north side tracks...
You need to have way_height_clearance=2, and the river (or canal) way must have a speed > 0 for the height restriction to be enforced. Open water doesn't have a way, so it also lets you build low as DrSuperGood described.

[Ters]

It's hard to see, but in the original picture, the tracks south of the road are at the same height as the river, one level below the north side tracks...
You need to have way_height_clearance=2, and the river (or canal) way must have a speed > 0 for the height restriction to be enforced. Open water doesn't have a way, so it also lets you build low as DrSuperGood described.

Yes, but I saw and recreated that. And I also did get the error message sometimes. But it appears something isn't quite right with the settings in startup map, which I usually use for quick testing.

[DrSuperGood]

A check for water under bridges should be added. It should make sure that at least clearance heights are between a water climate tile and intended bridge height similar to what it does currently with ways and structures. This is both for consistency and visual correctness.

[gauthier]

A check for water under bridges should be added. It should make sure that at least clearance heights are between a water climate tile and intended bridge height similar to what it does currently with ways and structures. This is both for consistency and visual correctness.

I would rather say that it should display a warning instead of completely preventing players from building such bridges. I often build bridges half height over water as I rarely use boats. Anyway the other problem is that boats should not be able to navigate under half height bridges.
I think that fixing this by preventing half height bridges over water would annoy many players.

[Ters]

I would rather say that it should display a warning instead of completely preventing players from building such bridges. I often build bridges half height over water as I rarely use boats. Anyway the other problem is that boats should not be able to navigate under half height bridges.
I think that fixing this by preventing half height bridges over water would annoy many players.

It doesn't help much to get a warning after the bridge is built. Simutrans doesn't do confirmation dialogs. This is mostly a design principle, but that might have led to some technical aspects as well.

[gauthier]

Yes it would help, so, if after that, the player gets a boat which does not find its route, he will know the reason.

[Leartin]

Maybe it would help if the game does not allow you to build such a bridge per se, but allows it if you pressed shift while building it? After all, worst that can happen with such a bridge is a clipping error. Which, at least in the case of ships, happens anyway when players decide that the Titanic oughts to be a river boat.

[Ters]

Maybe it would help if the game does not allow you to build such a bridge per se, but allows it if you pressed shift while building it?

Another "secret" key combination for newbies to learn. Since pre-existing rivers will exists, they will have the need to build bridges over them, and going up two heights can be prohibitively expensive.

[Leartin]

Another "secret" key combination for newbies to learn. Since pre-existing rivers will exists, they will have the need to build bridges over them, and going up two heights can be prohibitively expensive.

You missed the point here.

If you want to play a pakset where you don't have to go up two heights, you can play one with "double heights" like pak64, or you could play one with steep bridge slopes. Both allow you to build over the river, not only technically, but also without clipping errors (for ships of reasonable sizes). But due to graphical reasons, some paksets decided to go half height without steep bridge slopes, and even added the conversion factor so you can't build half height bridges over other ways. You may not agree with this decision, but it was made by those responsible for the respective paksets.
I'm totally fine with the inability to build low bridges over ways, even rivers, and don't see why it would need to be changed completely since, again, it leads to graphical errors. For those who are willing to still build those bridges on their own risk of graphic glitches, a secret key combination is fine. It's like typing about:config in Firefox, all of the stuff you can do there is "secret" and not in the normal options, because it's not intended to be changed if you don't know what you are doing.

[Ters]

You missed the point here.

If you want to play a pakset where you don't have to go up two heights, you can play one with "double heights" like pak64, or you could play one with steep bridge slopes.

If I missed the point, it was the fact that you did not want to build a bridge over that river at the height of ground north of it. I think it's most likely that we have problems communicating heights.

I'm totally fine with the inability to build low bridges over ways, even rivers, and don't see why it would need to be changed completely since, again, it leads to graphical errors. For those who are willing to still build those bridges on their own risk of graphic glitches, a secret key combination is fine. It's like typing about:config in Firefox, all of the stuff you can do there is "secret" and not in the normal options, because it's not intended to be changed if you don't know what you are doing.

People shouldn't have to open "about:config" just to build a simple bridge, or level half a village to build a small hill to start the bridge from. Even an experienced player like gauthier expected such a bridge to work. To **** with the ships! There might not even ever be any ships there. They haven't been very common in the screen shots I've seen around here.

[gauthier]

Anyway, regarding newbies, most people who try Simutrans give up quickly since this is a complex game but without tutorials or anything like that. I know there are some resources out there to explain the game to newbies, the problems is that when you are begining a game, you usually don't bother searching tutorials outside of that game.

So, coming back to our problem, at that point a special key won't hurt so much.

If a tutorial is to be realized in game (most likely in each pakset), such special key would be explained there.

[Ters]

You also have to remember them. I know the following keys in Simutrans: +, -, b, #, %, ", Shift for alternative way building and Ctrl for tunnel entrance only.

[gauthier]

I don't find that remembering keys is problematic. If a key is useful enough, it will be used often enough and remembered without effort. Moreover, ctrl and shift are frequent modifier keys so even easier to remember. In the case of this thread, using ctrl or shift would be okay.

[Ters]

In the case of this thread, using ctrl or shift would be okay.

I disagree. Not that I don't remember a lot of hot keys, but I spent a long time learning them. And virtually none of absolutely necessary, but just a faster way of doing something that can be done slower by bringing up a menu or tool bar. (So I'm clearly not a vi user. I probably still have to switch off the machine to exit it if I ever accidentaly start that program.)

[gauthier]

I spent a long time learning them

You are taking this very far, especially regarding shift and ctrl. It takes something like two minutes to learn that these two keys can make your dreams come true, and coffee too :p Anyway, maybe you bothered learning all the hot keys in the world, in case I agree that many are useless for most people and then you wasted your time, but if you learn only the hot keys that are necessary it would be okay. Most of the time, people learn a hot key when they feel that they could use it repeatedly and gain time. And when something feels usefull, it can be learned easily.

Regarding Simutrans, these two keys don't even have to be used along with other keys for what we are talking about.

(So I'm clearly not a vi user. I probably still have to switch off the machine to exit it if I ever accidentaly start that program.)

Sorry but I don't understand what you are talking about, and I don't get the point here.

Well I'm not sure to really get the point in your message (are you upset because you have to learn too much hot keys or because the feature we are talking about would not have its own icon in a toolbar ?). Could you clarify please ?

[DrSuperGood]

When you select a tool and your cursor changes to the brush for that tool then it should display somewhere on screen a list of available hotkeys which can modify the brush mechanics. For example I had to ask other players in-game how to make tunnel entrances instead of full length tunnels since that mechanic was not obvious and there was no indication of such a hotkey combination existing.

An alternative would be to list all hotkeys that modify a tool brush as part of the tool selection tooltip. So when you hover over a rail tunnel it shows "Ctrl: Tunnel entrance only".

Both ideas aim at brining the information closer to the user. They should not need to look for it or have to ask. Instead it should be given to them on a literal silver platter.

[Isaac Eiland-Hall]

So I've been a little bummed at this topic and one other where tempers have flared a little, although I'm hoping it's a mild flare. :(

On the topic itself and various bits:

1. The "vi" reference - vi is (pardon to those who know) a text editor used in Linux (originally, now there are ports) commandline mode. Most text editors give you immediate control over the text, and use command keys do to various things. vi, on the other hand, starts you out not in a text editing mode, but in a command mode, and you have to hit a key to edit a line of text. It's very heavy on commands. To do nearly anything, you have to learn a particular key sequence. Once you do this, it's very fast and has many people who swear by it. But the learning curve is steep. So it's a valid argument to be made against a lot of key sequences being added to Simutrans. (Whether or not we're at that level is another argument that I won't address)

2. I think part of our problem is that we *are* a small community with an even smaller number who can/do contribute to development and playing resources. We have a lack of good tutorials (which is not to say that the work that people have done to make them is wasted, mind), a lack of presentation for new players.... People have worked on this and spent real time - but it always needs updating and tends to lag behind. I think it's just a natural consequence of our small community.

I do see a point to both sides of the argument. On the one hand, the more undocumented special keys needed to do things in the game, the fewer people will know about them, and new players will be more likely to give up. On the other hand, as much work as has gone into Simutrans, the icon system is still not all that great as compared to some games that have lots of money to spend on polish.... There's ways to fix, but it takes a lot of time and we're all volunteers; or rather, specifically in this case, all coders are volunteers, and spend time doing what they think is a best use of their time - already they fix bugs and do things that aren't fun; and touch on various features already.

So how to fix this problem? I'm not sure it can be fixed easily. Either we need more volunteers, which means attracting more players as a small percentage of players might get interested in coding; or we need more money - which is not practical and would cause lots of strife, probably.... So... more players? Well, maybe better documentation might help retain more players.... I dunno. But even that comes down to a huge time investment.

I'm not sure what would help the most.

So any new ways of trying to get documentation out would either require lots of work making documentation, or even more work adding funtionality to the game (like some games have a pop-up the first time you do something - so when you activate a tool, it could pop up info about that tool with a "don't show this again" already checked, so when the closed, it went away for good unless they unchecked the "never show"...) But that, if it was considered a good idea, would require more coding to implement............

Every solution involves work.

The only strong opinion I have is that I've long been a supporter of control keys to add functionality that the majority might not want, but is supported for the oddballs like me who benefit from something. Although I think some mainstream-useful functionality (e.g. tunnel entrances) has snuck in there, so maybe a valid argument that a better system is needed - either to share info or to make these functions available in the icon system somehow (like a little popup that has radio buttons to select the tool's mode or something)......

I only hope that as we talk it out in the community, we can all remain not merely friendly (i.e. on the surface), but truly friends, even where we all disagree. Talking it out is part of the solution; eventually, something has to be decided; but hopefully it won't be seen as winners/losers, just the simple fact that something has to be chosen from hopefully the majority view, which hopefully reflects the better choice, but it doesn't always end up that way, just because we're all human and we're such a small community, and even smaller with those who can contribute to coding (who will of course have more influence on what gets coded since they're the ones that volunteer to do it!)

[prissi]

My personal opinion would be to allow bridges even if they are to low to fit a vehicle under them. If road bridges can be double height, then doubleheight should be preferred.

[gauthier]

I only hope that as we talk it out in the community, we can all remain not merely friendly (i.e. on the surface), but truly friends, even where we all disagree. Talking it out is part of the solution; eventually, something has to be decided; but hopefully it won't be seen as winners/losers, just the simple fact that something has to be chosen from hopefully the majority view, which hopefully reflects the better choice, but it doesn't always end up that way, just because we're all human and we're such a small community, and even smaller with those who can contribute to coding (who will of course have more influence on what gets coded since they're the ones that volunteer to do it!)

First of all, sorry if I sounded unfriendly in my last posts. That was not intended.

I should try VI, sounds amazing. I'm used to gedit but it has some bugs sadly ...

I entirely agree with DrSuperGood about documenting special key combinations in game.

About beginners, I still think that the best way to help them is adding a tutorial with each pakset. I don't know much about these scenario stuff, could it be used to make such tutorials ?

You are right about the too-much-hotkeys argument. If I understood Ters well, he wants to have only unnecessary features accessible only with hot keys, mostly because of beginners that can't guess that these hot keys exist. But if hotkeys are documented in game as DrSuperGood said, would it be okay ? In my opinion, hotkeys are the only true good solution to add functionalities without overloading the interface, which is already quite heavy.

(like some games have a pop-up the first time you do something - so when you activate a tool, it could pop up info about that tool with a "don't show this again" already checked, so when the closed, it went away for good unless they unchecked the "never show"...)

This kind of mechanism, like a warning mechanism, is worth being coded, isn't it ?

[Ters]

I should try VI, sounds amazing. I'm used to gedit but it has some bugs sadly ...

Those that understand it seems to love it, others hate it. There's a bit of a religious war between adherents of vi (mostly vim in reality, from what I understand) and adherents of Emacs (which is also very hotkey driven).

I entirely agree with DrSuperGood about documenting special key combinations in game.

It is a very good idea.

If I understood Ters well, he wants to have only unnecessary features accessible only with hot keys, mostly because of beginners that can't guess that these hot keys exist. But if hotkeys are documented in game as DrSuperGood said, would it be okay ? In my opinion, hotkeys are the only true good solution to add functionalities without overloading the interface, which is already quite heavy.

That's correct. I just considered building a simple bridge very fundamental, that should just be a single click. If only Simutrans could accurately report why ships no longer could operate on the river.

[gauthier]

If only Simutrans could accurately report why ships no longer could operate on the river.

A good intermediate solution would be warning messages that can be disabled.

[Ters]

A good intermediate solution would be warning messages that can be disabled.

If it is doable. It's possible the bridge building algorithm can only return success or failure. Which makes me curious about another thing: How will the AIs respond to this. I don't know if the AI players are clever enough to build, but didn't the cities learn to bridge rivers a while back. How will they deal with this problem? They will probably only be capable of building bridges that are low, potentially causing greif for any players trying to operate ships on that river.

[DrSuperGood]

If it is doable. It's possible the bridge building algorithm can only return success or failure. Which makes me curious about another thing: How will the AIs respond to this. I don't know if the AI players are clever enough to build, but didn't the cities learn to bridge rivers a while back. How will they deal with this problem? They will probably only be capable of building bridges that are low, potentially causing greif for any players trying to operate ships on that river.

Like how all bridges are built. They first try building them low, and if that fails (blocked) they build them higher. That logic is built into the actual bridge building code.

The special modifiers allow you to build steeper bridges when they are not required. This feature is useful for players who plan to build one line now, and later run another under a bridge. Without the modifier they would not be able to reserve the clearance for the way underneath so have to demolish and re-build the bridge later.

Mind you both AI and cities build bridges terribly so I doubt if open water is given path-ability based on clearance that their building is a concern. That said one must also remember that it should apply to elevated ways as well. Currently they force clearance above the water but if you allow bridges without clearance they should also have no clearance.