Diagonal Bridges and Tunnels

[Svartypops]

Any chance of Bridges and Tunnels that run across the diagonals of the squares, please?

[jfs]

It's harder than it might sound.

(In the "Suggestions commonly asked for" thread pinned in this forum, it's in one of the first replies, since 2005. And there still hasn't been a technical solution suggested that everyone can agree on is good enough.)

[Redirect Left]

Any chance of Bridges and Tunnels that run across the diagonals of the squares, please?

Is it possible? Yes of course it is, that's the entire idea of programming, anything is possible. within reason.
Will the devs ever put it in the main game? I would be banned if i put my actual opinion here on all of that.

Your best bet is either figuring out how to do it in a very basic manner yourself and just doing it locally, or trying to convince a patch pack creator to add it to theirs, as jfs said above, its a lot harder than it seems in text.
But without the chance of it being pushed to main, i doubt there is much motivation for anyone to really look at doing it 'properly', as it'd just be a bit of pipe dream, and I've looked into doing it, its a whole heap of work for not much reward given it won't go in the real deal at the end.

[peter1138]

Yeah, everyone knows the developers are sitting on piles of diagonal bridges and tunnels implementations, and refusing to add any of them. Sure.

[Svartypops]

Any chance of Bridges and Tunnels that run across the diagonals of the squares, please?

Is it possible? Yes of course it is, that's the entire idea of programming, anything is possible. within reason.
Will the devs ever put it in the main game? I would be banned if i put my actual opinion here on all of that.

Your best bet is either figuring out how to do it in a very basic manner yourself and just doing it locally, or trying to convince a patch pack creator to add it to theirs, as jfs said above, its a lot harder than it seems in text.
But without the chance of it being pushed to main, i doubt there is much motivation for anyone to really look at doing it 'properly', as it'd just be a bit of pipe dream, and I've looked into doing it, its a whole heap of work for not much reward given it won't go in the real deal at the end.

Why won't they put it in the "real deal", if someone's done it for them?

[odisseus]

The development team has very high standards regarding edge cases and backward compatibility. However, had there been a promising solution, it probably would have been included in the JGR's patch pack.

[kkidslogin]

Any chance of Bridges and Tunnels that run across the diagonals of the squares, please?

Is it possible? Yes of course it is, that's the entire idea of programming, anything is possible. within reason.
Will the devs ever put it in the main game? I would be banned if i put my actual opinion here on all of that.

Your best bet is either figuring out how to do it in a very basic manner yourself and just doing it locally, or trying to convince a patch pack creator to add it to theirs, as jfs said above, its a lot harder than it seems in text.
But without the chance of it being pushed to main, i doubt there is much motivation for anyone to really look at doing it 'properly', as it'd just be a bit of pipe dream, and I've looked into doing it, its a whole heap of work for not much reward given it won't go in the real deal at the end.

Why won't they put it in the "real deal", if someone's done it for them?

It's probably in a patch, so the code may not be compatible with OpenTTD code if it depends on other features in the patch (This is especially important if it's part of a patchpack, most notably JGRPP). Every now and again, you see code backported into vanilla from JGRPP, but it's not all that common. It's also a bit of a niche case, so it doesn't take precedence over current projects like NotRealTime, Area-Based Ship Pathfinding, and Automatic Unbunching, or fixing/finding bugs and inconsistencies.

[kamnet]

It's probably in a patch, so the code may not be compatible with OpenTTD code if it depends on other features in the patch (This is especially important if it's part of a patchpack, most notably JGRPP). Every now and again, you see code backported into vanilla from JGRPP, but it's not all that common. It's also a bit of a niche case, so it doesn't take precedence over current projects like NotRealTime, Area-Based Ship Pathfinding, and Automatic Unbunching, or fixing/finding bugs and inconsistencies.

OpenTTD is open source, it's code is on GitHub where not only can it easily be forked, but it is also open to all code contributions which then go through a code review process to ensure that the code quality meets or exceeds that of the project and that it works consistently without causing conflicts with other parts of the code.

Much of the improvements in OpenTTD over the last few years is because the move to GitHub made it even more open and accessible to others. If ANYBODY out there has the inkling to try to cover the code to implement diagonal bridges and tunnels, then all they have to do is fork the code into their own repository and start hacking it, once they've got it working on their end submit a PR to the dev team through GitHub and then go through the process of officially merging it. It's tedious, but if it work and it works well, the devs are going to accept it, especially if they don't have to put in the extra work and brain power that they can't spare.

Extra hands make light work.

BTW, on a similar tangent, Aegir (aka Reldred) has been working through this process in development of diagonal roads for the last few years. Graphics are drawn and some of the code is working, some is not. So it may take forever but it's proof that things are not impossible.

https://github.com/JGRennison/OpenTTD-patches/pull/603

[kkidslogin]

It's probably in a patch, so the code may not be compatible with OpenTTD code if it depends on other features in the patch (This is especially important if it's part of a patchpack, most notably JGRPP). Every now and again, you see code backported into vanilla from JGRPP, but it's not all that common. It's also a bit of a niche case, so it doesn't take precedence over current projects like NotRealTime, Area-Based Ship Pathfinding, and Automatic Unbunching, or fixing/finding bugs and inconsistencies.

OpenTTD is open source, it's code is on GitHub where not only can it easily be forked, but it is also open to all code contributions which then go through a code review process to ensure that the code quality meets or exceeds that of the project and that it works consistently without causing conflicts with other parts of the code.

Much of the improvements in OpenTTD over the last few years is because the move to GitHub made it even more open and accessible to others. If ANYBODY out there has the inkling to try to cover the code to implement diagonal bridges and tunnels, then all they have to do is fork the code into their own repository and start hacking it, once they've got it working on their end submit a PR to the dev team through GitHub and then go through the process of officially merging it. It's tedious, but if it work and it works well, the devs are going to accept it, especially if they don't have to put in the extra work and brain power that they can't spare.

Extra hands make light work.

BTW, on a similar tangent, Aegir (aka Reldred) has been working through this process in development of diagonal roads for the last few years. Graphics are drawn and some of the code is working, some is not. So it may take forever but it's proof that things are not impossible.

https://github.com/JGRennison/OpenTTD-patches/pull/603

I know, I have been watching the GitHub for a long time. However, there are clear people who are the current devs; I don't know their forum usernames because I just created an account here, but they are: JGRennison (Of the infamous patchpack), 2TallTyler, PeterN, Kuhnovic, TrueBrain, LDPL, Rubidium42, frosch123, glx22, and SamuXarick. It's a rare PR that isn't by these people. And, as aforementioned, they have their own projects for 14.0 in development, or other projects entirely. If somebody wants diagonal bridges, they'll have to implement it themselves, so the maintainers can merge it---and there are very few other people know know the codebase well enough to implement it, given how large of a change diagonal bridges are in lower-level code; it would be a very slow process for most people.

In addition, there are the inevitable NewGRF incompatibilities that might cause any diagonal bridge implementation to be taken down anyway for not matching the project goals.

I'm not against any sort of diagonal bridge implementation. If it is not aesthetically weird, and the bridge GRFs I use support it, I might make occasional use of it. Admittedly, current bridges are better in most use cases. But it would be very cool and might just get me out of a bizarre track routing deadlock sometime.

I'm also not against the devs---I understand why niche projects like this don't get their attention and thus don't usually get implemented. They're humans spending their free time to work on projects that they don't have any obligations toward; they're allowed to have their own pet projects. This is just an opportunity to get more people to start working on the codebase

[jfs]

To be technical, one of the major obstacles for diagonal bridges and tunnels is that bridges and tunnel don't really "exist": Only the entry and exit tiles for the tunnel or bridge are really, properly stored on the map.
For the rest of the tiles a bridge crosses over they just have a single bit set indicating that "a bridge is crossing this tile", and nothing else. To actually draw the bridge over those tiles, the game has to search for one of the bridge heads to get all the remaining information about the bridge, such as its height and its type.
This is also the reason that signals-on-bridges and stations-on-bridges are not really possible. JGR's patchpack has some "hacks" to make it as-if there are signals on a bridge or in a tunnel.
When a vehicle is traveling across a bridge, or through a tunnel, the game puts the vehicle into a special "wormhole mode", where it just keeps traveling at the same height and same direction, until it hits the bridge/tunnel exit, and then it gets changed back to normal travel mode.

All of this is really a bunch of special cases that make many things kind of annoying to work with, and trying to add diagonal bridges into the mix would only add even more special cases to it all. I think most of us who have worked on the code for a long time would rather do something much bigger and much more flexible. That would be a massive overhaul of how the entire map data for a game is stored, and make it possible to genuinely have things-over-things, in a similar manner to how Roller Coaster Tycoon and Locomotion do it.

[ebla71]

When a vehicle is traveling across a bridge, or through a tunnel, the game puts the vehicle into a special "wormhole mode", where it just keeps traveling at the same height and same direction, until it hits the bridge/tunnel exit, and then it gets changed back to normal travel mode.

Thank you very much for the technical insight - that also solves the mystery I have wondered about for a long time why road vehicles cannot turn around on bridges.

[Eddi]

turning, overtaking, and potentially other stuff only happens at tile borders, but the road vehicle is technically on the same tile all the way through the bridge/tunnel. (i believe it's the tile at the end of the bridge, from the vehicle's perspective. but it's been a while since i've been anywhere near that part of the code)