[UNIV] New Tram Tracks Development

[stevenh]

I've just had Lakie test it for me and it's working fine... I'll get it checked into 2.5 and the Alpha ASAP.

I've just checked the 'diff' that was used for Trams in OTTD and it seems they used the exact same variables (but of course constructed for C); so it should be a very quick fix for them. Unfortunately that thread is locked in the OTTD Dev area.

[FooBar]

This is great news, Steven! Thanks A LOT!

As for OTTD: I'll post an error report (flyspray?), if not done already.

/me will draw some new poles

[Rubidium]

It's fixed in OTTD (applied stevenh's table change).

[FooBar]

Thanks, I'll check out tonights nightly to see if it works as intended.

EDIT:
I couldn't resist to wait till tonight, so I compiled the latest version of ottd (r10507) myself. The results are FANTASTIC. As you can see in the first image attached: the correct sprites are used (numbers according to ttdpbasew.grf).
And because Rubidium used Stevenh's table change, everything should work out good for TTDP too.

The second image shows a sneak preview of my idea. Look good in my humble opinion. Any comments are welcome.

Do I have a last question: Who created the original tram track graphics? I'd like to ask permission first, before I release a new version, because I reuse most part of the original graphics.

[OzTrans]

... TTDP/OTTD updates ...

Thank you everybody for the updates ...

... The second image shows a sneak preview of my idea. ...

You should now be able to do that; although I would make the poles only 1 pixel wide.

[PikkaBird]

Do I have a last question: Who created the original tram track graphics? I'd like to ask permission first, before I release a new version, because I reuse most part of the original graphics.

Me, and go for it. They were never works of art, more a proof of concept.

[FooBar]

You should now be able to do that; although I would make the poles only 1 pixel wide.

I am! The screenshot above is not a mockup

I'll consider 1px wide poles. Although it seems a bit thin to me. If you have a look at this picture for example, you can see one big fat pole, a thin horizontal bar and wires nearly invisible.
I'll see how it looks.

[m3henry]

it is best if there are large poles, but this must be implemented so that the single sided poles are only used when there is no road below them (to save trouble with junctions and corners)
about the corner off-road
I think it should be two poles 1/4 of the way round the corner with a few more wires

[FooBar]

Thanks for your comments. Your suggestion for the corners sounds good. I don't completely understand what you mean by this:

but this must be implemented so that the single sided poles are only used when there is no road below them (to save trouble with junctions and corners)

Please keep in mind that there's only one set of wires that will be used everywhere. On-road and off-road.

__________________

Do I have a last question: Who created the original tram track graphics? I'd like to ask permission first, before I release a new version, because I reuse most part of the original graphics.

Me, and go for it. They were never works of art, more a proof of concept.

Thanks, PikkaBird.
Shouldn't you be credited on this page? If you look under 'graphics' is says MB drew everything. Which is not true apparently. (Yeah, I did my research )

They were never works of art, more a proof of concept.

I'll credit you anyways

[OzTrans]

I'll consider 1px wide poles. Although it seems a bit thin to me. ...

They would be a bit thin, but we prefer to see the trams more clearly ...

[stevenh]

This update has been applied to both the trunk (the Alpha) and the Beta...

I think I've beaten todays Alpha build (usually around 2pm my time, which is in 4 hours time...) So you should be able to play with it this afternoon

[FooBar]

It works very nice indeed!

Haven't had time for those thinner poles though, I'll look into that right now.

EDIT:
Had time now
Personally I think it's too thin, but I see why one would like it: it's less 'busy' (is there a proper English expression for that?).
I can always make it a parameter option. And maybe I should be awarded for "smallest set with most parameters". I count three already: 1. Road set compatibility; 2. Terrain set compatibility 3. Pole style.

[PikkaBird]

Personally I think it's too thin, but I see why one would like it: it's less 'busy' (is there a proper English expression for that?).

Yes, "busy" is proper English.

[FooBar]

Ah. My knowledge of English is better than I imagined.

Are there more people who think those fat poles are busy?


Another question:
When I have a sprite like the one shown below, is it better to reduce the height of the sprite and position it correctly trough nfo? I can imagine that a bigger sprite consumes more memory and less memory consumption is better, but maybe the difference is small, only noticable on old computers, and not worth the effort. For me it's far more easier to have sprites with the same size as much as possible.


And yet another question:
There's an Action7/9 to skip sprites if one's using the wrong patch version (var 8B). I'm using that because my set only works properly in version 2.6 r1651 or higher.
Is there a similar technology to skip the grf-file if someone is using the wrong version of OTTD?
The problem now is that OTTD disables my grf because of the Action9, so I have to skip that Action9 if the platform is OTTD, but then there's no version check anymore.
Is it just a matter of trial-and-error to figure out what value I have to put in? (It's obvious now that I need to have two checks: one for patch and one for open).

[PikkaBird]

When I have a sprite like the one shown below, is it better to reduce the height of the sprite and position it correctly trough nfo?

If you compile with -c, recent versions of grfcodec will automatically crop the extraneous blue from around sprites.

Is there a similar technology to skip the grf-file if someone is using the wrong version of OTTD?

Not as far as I'm aware.

[m3henry]

Thanks for your comments. Your suggestion for the corners sounds good. I don't completely understand what you mean by this:

see attachment

but this must be implemented so that the single sided poles are only used when there is no road below them (to save trouble with junctions and corners)

Please keep in mind that there's only one set of wires that will be used everywhere. On-road and off-road.

this ound like a new feature perhaps? detection of what is below?, it is already done for the ground sprites, no?

[OzTrans]

... And maybe I should be awarded for "smallest set with most parameters". I count three already: 1. Road set compatibility; 2. Terrain set compatibility 3. Pole style. ...

Pole style, yes ... but for the other 2 you don't need parameters. You can auto-detect other sets.

[athanasios]

Thinner poles are more scale suitable, but do not look so nice as fat ones. Also they are not well visible in front of farm tiles.

[FooBar]

I'll reply to you all in one go. Thanks for your comments!

@PikkaBird:
[grfcodec]
I'll check my version of grfcodec (and update if required). The next release will be compiled using -c!
[ottd]
That's too bad. I'll see if I can figure something out myself. If not, I'll add a warning for OTTD users.


@m3henry:
Thanks for your clarification. That's a really nice idea.

As for the ground sprites. There's indeed some kind of detection because there are two sets of ground sprites, so it should also be possible to have two sets of catenary.


@OzTransLtd:
There's goes my award
It's indeed possible to autodetect (using that same Action7/9). How often do sets change their grfid? I don't think it's useful to change it every update, but what do others do (you, for instance)?

@athanasios:
Thanks for your reply. I think it's best to create both versions and make it an option. Maybe random if no parameter is set

[OzTrans]

... [version checking in OTTD] ... That's too bad. I'll see if I can figure something out myself. If not, I'll add a warning for OTTD users.

It'll run with OpenTTD nightly only anyway and by the time you release your set, most players will have a compatible version. You should be ok and a note in the ReadMe should help too.

... How often do sets change their grfid? ...

They should only change the GRFID when absolutely necessary; and that is rare. The only GRFIDs I ever change is for the Canadian Stations Set, because there are significant changes between releases, such as changes to station IDs.