New Rail Types

[Snail]

Tunnels:

Why not "only" use VarAction2 variable 23 or 24? They will update over time tho, and not on when they are built, but with some trickery they may not change all at once...

Well, if they're updated over time, you won't be able to tell old tracks from more recently built lines... while it would be nicer and more realistic to keep the "old look" for historical lines' tunnel portals.

[peter1138]

Tunnel graphics are a sticking point, and are what held up railtypes for a long time, so a compromise was made; currently tunnel graphics are actually provided by the landscape, and railtypes can pick from one of the three. The railtype provides an overlay which is drawn underneath the tunnel sprite.

We could allow totally custom tunnel graphics, however it would then not be landscape-agnostic. The NewGRF would have to take care of that.

[Eddi]

since tunnels and bridges are so similar, it should be technically possible to build different tunnel types for the same railtype

[planetmaker]

We could allow totally custom tunnel graphics, however it would then not be landscape-agnostic. The NewGRF would have to take care of that.

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

[Zephyris]

We could allow totally custom tunnel graphics, however it would then not be landscape-agnostic. The NewGRF would have to take care of that.

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

Which is intentionally impossible.

[HackaLittleBit]

We could allow totally custom tunnel graphics, however it would then not be landscape-agnostic. The NewGRF would have to take care of that.

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

Maybe with some kind of openttd/ttdpatch newGRF certificate you could solve this.

[Yexo]

We could allow totally custom tunnel graphics, however it would then not be landscape-agnostic. The NewGRF would have to take care of that.

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

Maybe with some kind of openttd/ttdpatch newGRF certificate you could solve this.

This has nothing to do with TTDPatch at all. Different basesets means "original windows graphics" vs "original dos graphics" vs "OpenGFX". NewGRFs can't check which baseset is in use because that could cause desyncs in multiplayer.

[michael blunck]

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

If something like this would be needed we already had it, given the vast numbers of newgrfs "blending nicely".

regards
Michael

[planetmaker]

That's very difficult... you'd have to check for the base set present in order to make it blend in nicely in all cases...

If something like this would be needed we already had it, given the vast numbers of newgrfs "blending nicely".

Exactly. But there's very good reason to insist on NOT having this feature: Desyncs. A Newgrf then would or could do A, if base set one is present and B, if base set two is present. Voila you'd have the nicest divergent game state.

[DJ Nekkid]

easy solution, remove the posibility to use original gfx

[cmoiromain]

But that's not an option. Many people still prefer the original graphics, and you could also imagine some new base sets being created in the future.

[michael blunck]

Many people still prefer the original graphics [...]

Ladies and Gentlemen: the understatement of the year!

SCNR
Michael

[Zephyris]

A specific action to replace a set number of real sprites (and real sprites only) according to base set might be a nice grf feature though, eg.: an action which essentially states "the next x sets of y real sprites should be used according to the mapping of set 1 - base graphics, set 2 - OpenGFX, etc."

By restricting the usage to real sprites only and forcing the sets of sprites to contain the same number of real sprites you can guarantee (in a well-formed grf) it will not cause desynchs.

[Rubidium]

Problem with such an action is that you need to insert it between the action A/5/1 (and whichever I forgot) and the real sprites. As those actions 'announce' the real sprites to come it would mean massive changes to basically everything that has to do with NewGRFs.

[peter1138]

One possible answer is use the slope sprites of the base graphics as the ground tile, then overlay that with the 'background' part of the tunnel (rails and rear wall) and then with the foreground part (front wall and roof). But shading the slope would be tricky.

[FooBar]

Been thinking about that one as well and was about to suggest it, but then I figured: if you want the tunnel to blend in with the landscape, then you have to use semi-tranparent sprites. While it's no problem to create such sprites, the problem is that the train will show through as well...

So unless there's a solution for that, normal slope plus two overlays is not ideal either. It gives more freedom though in having different tunnel entrances for different track types.

[peter1138]

Yes, you're right. The final overlay sprite must cover the area where the vehicle should be hidden.

[michael blunck]

Again, some suggestions for this feature:

- cost factor for a new track system should include depots, signals, etc

- level crossings in town centers are lacking "town style". In the original game, level crossings are two different sets of sprites. Specifying them as overlays in rail types lacks this feature, there are also problems with the road graphics underlay (e.g. the center line comes out quite ugly, depending on used road graphics),

- we need that query tool enhancement with <name of rail type> <max speed> at least.


Peter, a very nice feature you provided:


http://www.tt-ms.de/forum/showthread.ph ... 4#pid62324

regards
Michael

[maquinista]

I have a question: It's possible to create a new rail type with the properties of the monorail?

For example, I want create a second monorail called "MON2", with de default monorail graphics and overhead and different depots.

In new houses this could be done if You don't override the default house.

Maybe, I could try to create a vacuum tube maglev, replacing only the catenary graphics, without drawing ground sprites.

[DJ Nekkid]

I have a question: It's possible to create a new rail type with the properties of the monorail?

For example, I want create a second monorail called "MON2", with de default monorail graphics and overhead and different depots.

That should not be a problem, you just need to take the track gfx from Opengfx (or original gfx if that is what you prefer).

Maybe, I could try to create a vacuum tube maglev, replacing only the catenary graphics, without drawing ground sprites.

Should not be a problem i think. Altho, im not sure you can make them "glassy".


Take a look at the NuTracks repo if you need any hints or tips.