[UNIV] New Tram Tracks Development

[FooBar]

New Tram Tracks for TTDP and OTTD
New Tram Tracks is a tramway replacement set featuring grass embedded off road tracks and single-sided wire supports for the overhead wires.

Downloads are available in the Release topic. Bugs and requests should also go in that topic, not here.

[RK]

- Maybe: poles for overhead wires between tracks: something like

This won't work without changing the programcode:
- You must use different poles for roads/non-roads
- You must change the sprite's 3D-Bounding-Box, because the poles in the foreground are over all vehicles and the poles in the background vice versa.

[OzTrans]

... You must use different poles for roads/non-roads ...

So that is what those other sprites are for ... those that never get used anywhere. The same pole and wire sprites are used for tracks on road and off road. Here is proof ...

[stevenh]

I'd imagine he meant that you can't really have the poles down the middle of the road... hence that you'd need poles on the outsides for on-road and poles down the middle for off-road?

Hence a reasonable code-change... but nothing massive; as long as you know assembler and feel up for a challenge

[Purno]

When making poles in the middle, I guess you'd get problems with roadvehicles incorrectly drawn over or under the poles.

[FooBar]

Thanks guys. Poles in the middle is indeed not possible without changing the game itself. And I don't feel like doing that.

I have another idea now: single-sided poles

[Hertog-Dixi]

single-sided poles

Thats my view every morning when i wake up

[m3henry]

for the tracks to have grass in between you need to have the track sprites have the transparent blue inbeween
or mabeyt even have some off colour grass

[OzTrans]

Technical question ...

Looking at ttdpbase.grf, sprites 393 to 444 are the poles and wires for tram tracks. I have identified that sprites 393 ... 413 are used for tracks, same for on-road and off-road tracks. 414 ... 429 are the northern tunnel exists. And 433 ... 444 are for the bridges. Now where are sprites 422 ... 432 used ? Can we simply ignore them ?

[FooBar]

@m3henry:
Transparent blue doesn't work, because off-road tram tracks are an overlay for road tiles. There's still road underneath! Using transparent inbetween tracks reveals the road. It's also exactly the first thing I tried making this set.

EDIT:
@OzTransLtd:
I quickly put a grf together, default sprites, but the sprite's number added to sprites 422-432. I don't see any numbers in the game, so my quick conclusion is that those sprites aren't used.
New question: why are those sprites unused?

[OzTrans]

.. I quickly put a grf together, default sprites, but the sprite's number added to sprites 422-432. I don't see any numbers in the game, so my quick conclusion is that those sprites aren't used. ...

That is what I did too. Having now all sprites accounted for, except 422 ... 432 and 384/385; I assume they were planned initially and then remained unused. So we may just ignore them.

Unfortunately, there are a few missing :

. Construction Cargo (truck) tram stop icon.
. Custom cargo tram stops.
. Track sprites for the NE/NW (door) tram depots, that would show in transparent mode.

[FooBar]

Too bad we have to ignore them. I need 'em for my new idea!

Sprite 393 is used as background-sprite in for all 'foregrounds' 394 to 400. Same for 401 and 402 to 405. This means that my idea doesn't work out (see image attached below).
The pole can't be in the middle of a tile without having it in the middle of the road in certain track combinations. That could be solved by sprites 394 to 400 having their 'own' background sprites (possibly the intended use of sprites 422-428), but that's just not how the game works right now.

Seems all my ideas are impossible. Pole between tracks, single-sided pole... What's next?

[OzTrans]

Yes, I know. I think we need to stick pretty close to the 'original' implementation, i.e. poles are placed where 2 tiles meet, but they can overlap each other exactly, thus reducing the number of poles in the forest.

If those (422...432) sprites are not used. It would be pretty simple to change one of them to be the counterpart of 393, for the NE-SW direction [patch support required though]. Then, you could do what you want, but you would need to place your single pole, where the tiles meet.

[DaleStan]

Steven? Care to expound on the uses of the various sprites?

[stevenh]

*digs up an old post*.... it's here somewhere...

Oh, here it is:


I've no idea how up to date this is... and of course; all the offsets are wrong since this is from when it was in it's own tramtrkw.grf

I need to get home and decode the base GRF to tell you exactly how it's all laid out.

[FooBar]

If that's the actual situation, there's no problem at all. Anyhow, as far as I can tell, it's like in the images attached below.

First image is from ttdpbasew.grf.
Second image is form a testgrf I quickly put together. The numbers refer to ttdpbasew's sprite numbers. See for yourself

[OzTrans]

... sprite usage ...

May be that is how you intended it to work; we just discovered a little bug.

In my screenshot (further up) all those little yellow sprite numbers refer to the sprites actually used. #1 is #393 in ttdpbase or #37 in your sprite sheet. #1 is clearly used with every straight track including all intersections. This is also shown in FooBar's screenshot.

[Lakie]

The Tram draw code was orignially meant to be replaced by the newRoutes draw code...
So it was only temporary however with the delay in newRoutes it might need fixing, but at the end of the day, I believe Steven wanted Trams to become part of newRoutes in parts (such as drawing and store I guess).

(Correct me if I'm wrong though Steven),
~ Lakie

[stevenh]

Let us not talk of the future (of which you are spot on) and attempt to correct the past.

I hereby promise to have this issue corrected (and since the extra sprites still exist in ttdpbase [but aren't getting used]) to have those in use by the end of Sunday.

Code: Select all

var     tramfrontwiresprites,   db 0h, 37h, 37h, 3Fh, 37h, 37h, 43h, 37h, 37h, 3Fh, 37h, 37h, 3Fh, 37h, 37h, 37h
var     trambackpolesprites,    db 0h, 38h, 39h, 40h, 38h, 38h, 43h, 3Eh, 39h, 41h, 39h, 3Ch, 42h, 3Bh, 3Dh, 3Ah

...it should be a simple change to:

Code: Select all

var     tramfrontwiresprites,   db 0h, 54h, 55h, 5Bh, 54h, 54h, 5Eh, 5Ah, 55h, 5Ch, 55h, 58h, 5Dh, 57h, 59h, 56h
var     trambackpolesprites,    db 0h, 38h, 39h, 40h, 38h, 38h, 43h, 3Eh, 39h, 41h, 39h, 3Ch, 42h, 3Bh, 3Dh, 3Ah

...heh.... it seems that I definately use sprite 37h for each one (see my original post for the numbering.) This should be pretty straight-forward then... I just need to renumber that top line (and even funnier is that the variable names are backwards... but that's minor.)

[OzTrans]

I hereby promise to have this issue corrected (and since the extra sprites still exist in ttdpbase [but aren't getting used]) to have those in use by the end of Sunday.

Thank you, we shall wait patiently ...

@OpenTTD Developers : Now, the same occurs in OpenTTD, could we have that corrected there as well ?