Transport Tycoon Forums

Thanks, that and more fixed. However, I've found an OpenTTD or NML bug now - if I have more than 16 track type definitions included in the code, there's always an "Attempt to use invalid ID" error, even if most of the definitions are skipped and some are sharing IDs (so no reason at all to count double). Code with full bug documentation in the attachment.

I'll try to reproduce it with a simpler code (just 15 tracks in the code, but let 14 and 15 depend on a parameter setting).

A note on your code: why do you use introduction dates for all tracks? Now tracks can become available without a train for it. It is better to use introduces_railtype_list, the moment a train then becomes available, the track becomes available and all other tracks that are in that list also become available. So if an electric train becomes available, ELRL is introduced, and by putting all other electric tracks for the different speeds in the introduces_railtype_list those also become available at that moment, instead of depending on introduction date.

[EDIT1]Tested, and there is a bug in your code, somewhere your code does result in more then 16 track definitions. In the attached archive is a simple NewGRF+code that introduces 12 tracks with the parameter set to off, 13 with the parameter set to on. Together with the 4 default tracks, setting the parameter to on will result in 17 track definitions, triggering the error upon starting a game, but when set to off no error occurs.[/EDIT1]

[EDIT2]I looked through your code, couldn't find where it went wrong yet, but another comment on it. You have a number of pieces like this: And then later things like: You can also use param_force_3rd_rail in the second statement and remove the first in which you define param[20]. So the result would then become: This does exactly the same and I think it will increase readability of your code, or is there a specific reason why you do it the way you do it?[/EDIT2]

All done now, just have found one copy and paste alignment to fix but after that will forward it on and then I've done my part I do have a working version using 1.1.2 though...

Current status: All code finished except for that one bug. One graphics set (the old graphics from 1.1.2, with narrow gauge taken from the Japan Set tracks) also coded. Planning on three more: 1. the narrow tracks by coalroads_artist, 2. OpenGFX style from the Japan Set, 3. OpenGFX style from the Japan Set (narrow).
Changing to automatic introduction of associated track types will be easy. About the second bit, I'll just give all parameters names.

The bug now: Even when I write the code as , it makes a difference whether the include is commented out or not.

Good news about the graphics, but have you thought of narrow gauge tracks? They're now in too.

oberhümer wrote:The bug now: Even when I write the code as

Code: Select all

if (0 == 1) {
#include track_type_X_code.pnml
}

, it makes a difference whether the include is commented out or not.

The if-statement is only checked by OpenTTD, so the final grf-file will contain the code you include through track_type_X_code.pnml, even if the if-statement can never be true.

something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...

Transportman wrote:

oberhümer wrote:The bug now: Even when I write the code as

Code: Select all

if (0 == 1) {
#include track_type_X_code.pnml
}

, it makes a difference whether the include is commented out or not.

The if-statement is only checked by OpenTTD, so the final grf-file will contain the code you include through track_type_X_code.pnml, even if the if-statement can never be true.

The whole point is that if everything inside the statement is skipped, what actually is there or not there shouldn't make a difference in-game - but it does!

IIRC the content of an if-statement is loaded, but are only considered when it evaluates to that section. So the spriteviewer contains the sprites that should be loaded according to the code in the if-statement, but the label is not loaded, since the if-statement does not evaluate to that part of the code. But I'm not 100% sure about it, a dev should confirm it (or correct me).

I could do some narrow gauge tracks but probably only three versions - wooden/dirt, wooden/ballast and concrete. Just can't commit to another 5 different tracks.. I would then be able to play an Australian scenario

coalroads artist wrote:All done now

Very very nice tracks... very much like them!
As most of my time is spent in arctic can I/or we see arctic shot too?

Thank You!

Thanks! Sure.

Also very nice!

Eddi wrote:something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...

The only thing that catch my eyes at first too - any planning to correct this ?
At least, good graphics, it'll match pikka's finescale track - nice small thing !!

I don't plan on changing the ballasted areas for junctions as in real life ballast is often dumped and spread over a large area around junctions so works for me.

coalroads artist wrote:I don't plan on changing the ballasted areas for junctions as in real life ballast is often dumped and spread over a large area around junctions so works for me.

Hmm, I thinks its a bit too excessive in your case...

Yoursnotmine wrote:

coalroads artist wrote:I don't plan on changing the ballasted areas for junctions as in real life ballast is often dumped and spread over a large area around junctions so works for me.

Hmm, I thinks its a bit too excessive in your case...

Well I'm sorry if they're not to your taste.. Well considering it's TT scale graphics we're talking about and the fact that real life junctions have ballast cast between makes it just your personal opinion on judgement of sizes, and since you've already stated what you think of the size, you don't need to keep reiterating, it won't make me (or indeed anyone here) want to spend hours of their own time to remove those blue outlined areas just to please a few. You'll be left with 'unsightly' ballasted areas anyway due to the base sprites allowing for extra tracks I like it they way they are, plus it's easier to use the original template. You can alter them if you wish. Constructive criticism is alright, but if you're given a reason leave it at that as people volunteer their time and don't need to be told.

Random google image of junction ballasting :http://www.masterfile.com/stock-photogr ... ad%20track



Narrow gauge sprites will come after some well earned game play

coalroads artist wrote:I could do some narrow gauge tracks but probably only three versions

Only two are needed.

So timber and concrete then?

Fine. Anyway, nailed down the bug, will report it to the NML developers in a minute.

Tried to work around the bug and failed, so it's all up to the NML developers for the time being.