Transport Tycoon Forums

When NRT was developed, it opened a wonderful world of opportunities such as being able to have more than one NRT set active in a game.There was however an orphan that could have used some love. Tunnels are not set specific. If I use Action A to alter a tunnel's graphics in one NRT set, every tunnel in every other NRT set gets the same new tunnel graphics even though they might not fit in with their style or theme. Is there a way to alter one set's tunnels without trashing every other sets' tunnels?

wallyweb wrote: ↑07 Feb 2021 05:34Is there a way to alter one set's tunnels without trashing every other sets' tunnels?

Nope. There is no good way to resolve that tiles can have both tram and road, from separate grfs. Which leaves a conflict about things like tunnel sprites: which grf will provide them? There is no good solution.

The current iteration of NRT is fundamentally flawed by design, I did a bad job with the original spec.

I seriously regret (a) writing the original spec (b) campaigning for it to be merged.

I wanted to prove we could still make major changes to grf spec and gameplay, but in doing so I have damaged OpenTTD.

We have lost a few core contributors due to NRT, and for that, I am sorry.

andythenorth wrote: ↑07 Feb 2021 07:58 ...

Don't beat yourself up. It's really quite remarkable what has been accomplished. There haven't been any failures, just interesting opportunities for further developments.
Meanwhile I shall make do with object based tunnel overlays.

andythenorth wrote: ↑07 Feb 2021 07:58

wallyweb wrote: ↑07 Feb 2021 05:34Is there a way to alter one set's tunnels without trashing every other sets' tunnels?

Nope. There is no good way to resolve that tiles can have both tram and road, from separate grfs. Which leaves a conflict about things like tunnel sprites: which grf will provide them? There is no good solution.

The current iteration of NRT is fundamentally flawed by design, I did a bad job with the original spec.

I seriously regret (a) writing the original spec (b) campaigning for it to be merged.

I wanted to prove we could still make major changes to grf spec and gameplay, but in doing so I have damaged OpenTTD.

We have lost a few core contributors due to NRT, and for that, I am sorry.

I wouldn't let theoretical perfection get in the way of proposing/implementing something workable.

The cases of interest are:
1. A tunnel with only road or only tram. The sprites could be provided by the given road or tram type. This is the easy case.
2. A tunnel with both road and tram, where both are from the same GRF. It wouldn't be that difficult to write a spec which permitted this. But it would also be fine to just not bother with this case and use default/generic sprites.
3. A tunnel with both road and tram, where the two types are from different GRFs. This would be more complicated and also far less likely to actually occur in real games. It would also be perfectly acceptable to simply not bother with this case.

A solution which only provides 1, or 1 and 2, would be fine.
Further proposals could be made for cases 2 and/or 3 at a later date if there was sufficient interest.

Having something useful in a finite timespan with the prospect of further refinement/iteration later is better than waiting indefinitely for the perfect solution to arise.

OpenGFX provides separate tunnel graphics for rail, monorail, maglev and road, respectively.
NRT already provides for catenary tunnel graphics with ELRD and ELRL.
With my current work in progress, I can build the Suspended Monorail tramtype catenary over another set's roadtype (ROAD) graphics.
All we need is to extend tunnel portal graphics into NRT. perhaps in a manner similar to what was done for depots.

I brought this issue up on GitHub almost a year ago: https://github.com/OpenTTD/nml/issues/79

It didn't sound like there would be much support for implementing any kind of intermediate solution (my last-ditch suggestion to salvage something out of it went unanswered), but maybe someone with more pull in the community could be more persuasive

I can make a game case to support this.
In my work on the Suspended Monorail, I designed it so that the catenary/track were high enough so that a ground level RV could pass below the suspended tram, as happens in real life applications.
The only issue was where the monorail catenary/track met up with a tunnel portal. An Action A proved that I could accommodate this graphically, BUT all other road/tram types had to live with my solution.
NRT supports depots modifiable according to road/tram type via cargo-type 08.
Cargo-typea 03 and 07 seem to be unused and available for tunnels.
Both tunnels and depots use the same number (6) of realsprites in the same order and purpose (front and back)
Tunnels already support a player's choice of road or tram or both.

The git-hub posts cite bridges and stations as an argument.
We have 13 (16 in jgrpp) modifiable bridges to work with.
We have a world of non-track railroad stations and adjacent station tiles to accommodate a NRT station solution.
The NRT stations already have a cargo-type (0A) for the road stop surfaces.

Good evening!
To build automobile tunnels instead of tram tunnels, will conflict. So I think, if possible, you will need to add additional tram sprites that are superimposed on the road in the tunnel. Tunnels for roads and tunnels for tram tracks are separate sprites. When you put tram tunnels on a road tunnel, the tram replaces it with another sprite "tram_tunnels + tram_tunnels_overlay" to move on to the next stage "tram_overlay_tunnels". If you delete the road, the tram remains, then the sprites go to the previous one "tram_tunnels + tram_tunnels_overlay". If there is such a possibility?

ufiby wrote: ↑08 Feb 2021 17:37 Good evening!
To build automobile tunnels instead of tram tunnels, will conflict. So I think, if possible, you will need to add additional tram sprites that are superimposed on the road in the tunnel.

With only OpenGFX and RoadHog, then using the sprite aligner I compared the road tunnel with the tram tunnel. Both used exactly the same sprites as verified by the sprite numbers, with the tram tunnel adding catenary and track overlays.

With only OpenGFX and RoadHog, then using the sprite aligner I compared the road tunnel with the tram tunnel. Both used exactly the same sprites as verified by the sprite numbers, with the tram tunnel adding catenary and track overlays.

Yes, that's right, really. However, the Tram tunnel does not have a "native", what can't be made more functional. This is bad In this picture, this simply does not exist.
If I wanted to make something tunnel road and tunnel tram different sprites. What happens if they are different from the sprites to avoid a conflict of tram tunnel sprites overlaid with road tunnel sprites. I think the NRT can handle it, if possible. Just need to add "Native" tram tunnel sprites

here's my very straightforward approach:

in case of both tram and road providing tunnel sprites, tram always wins.

(can do the same with catenary. or level crossings. or other complications)

it won't be "optimal" for all thinkable combinations, but it will be clearly defined, and people can work with it.

Yes I think it's a reasonable assumption that a tram tunnel will always have larger clearances than a road-only tunnel, so if a tunnel fits trams it also fits any regular road vehicles.

NRT already handles the differences between ROAD (12) and RAIL(13) quite elegantly.
All I'm looking for is for NRT to have the ability to handle custom tunnel graphics in the same manner as it handles custom depot graphics.

Wouldn't solve the issue of multiple GRFs, but does nearby_tile_... work with tunnels? And is there a TILE_CLASS_TRAM or something? Since tunnels have fixed orientations you could then presumably do a nearby_tile_class variable to check the tile in front of the tunnel to switch graphics between road-tunnels and tram-tunnels without any spec changes accordingly.

Or maybe there's another "hacky" way. Random switches and just keep overbuilding it until the right one shows up?

... or maybe that sort of stuff doesn't work with tunnels.

Pyoro wrote: ↑18 Feb 2021 11:41 Wouldn't solve the issue of multiple GRFs, but does nearby_tile_... work with tunnels? And is there a TILE_CLASS_TRAM or something? Since tunnels have fixed orientations you could then presumably do a nearby_tile_class variable to check the tile in front of the tunnel to switch graphics between road-tunnels and tram-tunnels without any spec changes accordingly.

Or maybe there's another "hacky" way. Random switches and just keep overbuilding it until the right one shows up?

... or maybe that sort of stuff doesn't work with tunnels.

Road/tram tunnel entrances don't currently have NewGRF action 1/2/3 resolution or anything fancy like that, it's just a sprite.
Random switches do not make sense in the context of tunnels because there are no random bits. Landscape random bits only exist for airports, rail stations, houses, industries, water and objects.

To clarify what this is really about, the issue is the complete absence of any path for custom portal sprites in the non-rail case: https://github.com/OpenTTD/OpenTTD/blob ... 1302-L1314

JGR wrote: ↑19 Feb 2021 13:12

Pyoro wrote: ↑18 Feb 2021 11:41 ...

...

Road/Tram tunnels can be replaced with an ActionA. I've done this and it works quite nicely.
The problem is that in NRT, all Road/Tram type tunnels use the same sprites. My ActionA replaces all Road/Tram type tunnels.
I have a case need for a unique Road/Tram type tunnel.
I have noticed that this is similar for depots, where the case need for unique depots was satisfied via the NRT Action3 cargo-types.
Not being a developer, I am not able to extract the appropriate NRT source code to test my suggestion.

My current work-around (hack) is to use object overlays. I have done this for drive-through road stops and it works quite nicely (no nasty glitches/clipping).

Later this weekend (or shortly thereafter) I hope to be able to post my NewGRF NFO tunnel object code.

So the developers are not working with tunnels or I do not know exactly when to start. I have my own opinion. So don't just make a perfect tunnel right away. And gradually move to the best, at each step.
The first step:
{tunnel_overlay} Don't do it yet and don't touch it. Let the tunnel be shared, so is the road and so is the tram.
{tunnel} There is such a tunnel at the rail. Sprite is overlay for road and tram in existing tunnel graphics. Add Action and add 4 Sprites SW, NW, NE, SE.
Second step:
In the future project-at the discretion of the developer
Well, that's your opinion.

ufiby wrote: ↑16 Mar 2021 16:40 ...

I agree with all that you say.
But just to be clear, when I say "overlay", I do not mean to replace the tunnel graphics. Those are still there. My overlay is merely a mask that covers the existing graphics and can only be applied via the object menu GUI.