[OTTD] Dutch Tracks Development (0.1.0-Alpha1 released)

[Purno]

On a side note, I drew a few Dutch railway crossings a week ago; would those belong in a trackset or in the Dutch Rail Furniture set?
With all those different Dutch sets popping up, the lines between them are getting a bit vague for me

[jor[D]1]

Ah bummer, I must've been sleeping
One indeed would need an AC/DC track type in order to be able to define trains for that. Oh well.

I don't know of any of those switchable power supply things in NL, we generally just stop the catenary and continue with another a bit further. I know such a gap isn't possible in OpenTTD, as trains stop instantly at the end of the wire

They do exist in venlo. Also on the border stations Bad bentheim and Emmerich there are switchable tracks. At the Belgium border this isn't needed as belgium trains can handle 1500V DC, they only have half their normal power.

DC highspeed lines are technically not useable, and do not exist. (220 km/h is the max I thought)

Switchable tracks are not realy needed for EMU, but Loco hauled train need to be able to do some shunting.
PS. I think the slovakian and austrian border the austrian trains roll into the station with lowered panto and are later pushed back.
Could also be an other crossing but i remeber seeing pictures of it.

My preffered list:

• Yard rails (80km/h? or 40km/h??)(Very cheap)
• unelectrified (160km/h)
• Classical Lines (160km/h)
• Betuwe route AC (120km/h)(high axle load? or Cheap AC version?)
• high speed AC (unlimited, expensive)
• Switchable AC/DC(80km/h? or 40km/h (Station speeds))(Very expensive, so it's not possible to make a whole network with this)
• Metro(speed is already reduced by trainset)

would like planning as in nutracks too, but don't know if other really use it. I like to create abandoned railways with it.

On a side note, I drew a few Dutch railway crossings a week ago; would those belong in a trackset or in the Dutch Rail Furniture set?
With all those different Dutch sets popping up, the lines between them are getting a bit vague for me

I think you could include them in both sets...
Yard --> AKI crossing
Classical/unelectrified --> AHOB crossing
Others --> No crossings
Metro --> AHOB???(randstadrail Line E (part of r'dam metro) has some level crossings)

[Transportman]

On a side note, I drew a few Dutch railway crossings a week ago; would those belong in a trackset or in the Dutch Rail Furniture set?
With all those different Dutch sets popping up, the lines between them are getting a bit vague for me

They can be in both. There can be a lot of overlap between the track set and the Furniture set that needs some consideration, because I can (not saying I will) define the graphics for level crossings and catenary in the track set. Don't know how nicely OpenTTD plays along when I only provide sprites for the tracks at level crossings, there is a warning that can be read in two ways in the spec: provide all/no sprites for a * marked entry or provide all or none of the * entries. Don't know what happens when I only provide the rail sprites (haven't done that part in my local test grf before I said I would start development on this, added to the issue about figuring out the order of sprites I have to provide)

On a separate side note, I just pushed the first code to the Devzone. It is mostly a rename of the El rail to HSL, but I have to start somewhere.

[Purno]

Well, if you have any chance to do a quick code of the level crossings, I wonder how they look ingame, especially if the animation works out as intended.

[Transportman]

Well, if you have any chance to do a quick code of the level crossings, I wonder how they look ingame, especially if the animation works out as intended.

No, I can't do a quick code change at this moment , I have to figure out sprite order, offset stuff and switches. All 3 are knowledge I don't have at this moment. Sprite order I assume that it should be the order as given in the spec for NFO, offset stuff will need some thoughts (and maybe a bit of guessing) and for switches I should look at the tutorial (found a switch block in the tram part). So if all this information is correct, it should be doable relatively quick.

[Transportman]

Could we add a parameter to keep things very simple? I don't like these advanced gameplay mechanisms

I will of course add parameters to allow keeping it simple. For example, I just pushed the code to the devzone for disabling speed limits, but it doesn't have any effect yet, because there are no speedlimits in the code yet. When I actually fill in the values for the speedlimits, I will make sure the parameter will have the intended effect.

I will soon* look into the development of a template so that people who would like to provide sprites to this set can work on that.

*Somewhere in the coming weeks.

[FooBar]

template

Have a look at either Swedishrails or the Metro track set. The first is already in NML and uses multiple smaller graphics files. The latter is not in NML (but you can copy the offsets etc. just fine) and uses a few big graphics files. Dunno what you prefer, your choice, but either way there's no need to reinvent the wheel

[Transportman]

template

Have a look at either Swedishrails or the Metro track set. The first is already in NML and uses multiple smaller graphics files. The latter is not in NML (but you can copy the offsets etc. just fine) and uses a few big graphics files. Dunno what you prefer, your choice, but either way there's no need to reinvent the wheel

Thanks for the pointer, but got the template almost finished using a track from NuTracks and taking all the tracks out of it, leaving only the transparent blue and pure white behind. Also have the offsets for most of them now, but for some reason OpenTTD makes something different of those offsets. I determined those offsets with the sprite aligner, filled them in into the code, made a grf of it and suddenly the offsets are different ingame. Is there some magic that I should take into account when filling in the offsets for tracks or something?

But if I just add those differences, it ends up well, so I will just do that for now.

Edit: Found the offsets in the NuTracks code. So templates will be done some time soon.

[Michi_cc]

Do not use sprite cropping in grfcodec/NML when aligning sprites (or make sure the source sprites have no unneeded magic blue).

-- Michael Lutz

[FooBar]

If you used the NuTracks graphics files from source, you can also copy the offsets from source. No need to sprite-align yourself. Nutracks source may be a bit of a mess though, if the 2cc source is anything to go by (hence my recommendation of the two others).

Note that when copying NFO offsets to NML that the offset columns have changed orders. In NML everything is first x, then y. In NFO the offsets are first y, then x with the rest first x, then y.

And if the sprite-aligner offsets don't match, then sprite cropping may be active. Thought I commented that out though for this very reason before committing the basic repo setup. Maybe you reactivated it locally or something? Without cropping the offsets from the aligner should match with the ones you need to put in the code.

Looking at the current source revision, may I recommend code indent? Basically increase the indent after each { and decrease with a }. Myself I use the "Compact Control Readability style" in terms of where the brackets go, which is slightly different from the OpenTTD code guidelines, but for NML code that doesn't matter anyways. What matters is that indent makes your code more readable as you can more easily see what block a piece of code belongs to.
Also my apologies for not including Makefile.nml; it got ignored by .hgignore due to bad choice of file extension.

[Transportman]

Do not use sprite cropping in grfcodec/NML when aligning sprites (or make sure the source sprites have no unneeded magic blue).

-- Michael Lutz

Ok, so that is the magic I was missing.

If you used the NuTracks graphics files from source, you can also copy the offsets from source. No need to sprite-align yourself. Nutracks source may be a bit of a mess though, if the 2cc source is anything to go by (hence my recommendation of the two others).

Found it indeed, but was indeed a bit hidden in the mess.

And if the sprite-aligner offsets don't match, then sprite cropping may be active. Thought I commented that out though for this very reason before committing the basic repo setup. Maybe you reactivated it locally or something? Without cropping the offsets from the aligner should match with the ones you need to put in the code.

I was working with some local (test) code, were I indeed used sprite cropping. Is something I need to keep my eye on when pushing graphics code to the devzone.

Looking at the current source revision, may I recommend code indent? Basically increase the indent after each { and decrease with a }. Myself I use the "Compact Control Readability style" in terms of where the brackets go, which is slightly different from the OpenTTD code guidelines, but for NML code that doesn't matter anyways. What matters is that indent makes your code more readable as you can more easily see what block a piece of code belongs to.
Also my apologies for not including Makefile.nml; it got ignored by .hgignore due to bad choice of file extension.

I will make a note of it and fix it somewhere in the future. It is in the Track type files that it is missing? Just to be sure we are talking about the same files.

No need to apologize, things like that happen. It did force me too look at those files once, that can't hurt.

[FooBar]

I was working with some local (test) code, were I indeed used sprite cropping. Is something I need to keep my eye on when pushing graphics code to the devzone.

You can enable it in Makefile.config, and then disable it again in Makefile.local. That way everything built on the server will be cropped with smaller grf size. Everything you build yourself will not be cropped so that you can easily work with the offsets. Or use bash build.sh, which doesn't crop either.

It is in the Track type files that it is missing?

In rail.pnml and HSL.pnml. I'd fix it like the attached patch, but I guess that doesn't apply any more if you have local changes made, so I also included the changed files so that you can have a look.

[Transportman]

I was working with some local (test) code, were I indeed used sprite cropping. Is something I need to keep my eye on when pushing graphics code to the devzone.

You can enable it in Makefile.config, and then disable it again in Makefile.local. That way everything built on the server will be cropped with smaller grf size. Everything you build yourself will not be cropped so that you can easily work with the offsets. Or use bash build.sh, which doesn't crop either.

It is in the Track type files that it is missing?

In rail.pnml and HSL.pnml. I'd fix it like the attached patch, but I guess that doesn't apply any more if you have local changes made, so I also included the changed files so that you can have a look.

Those files aren't changed yet. r8 is still the most recent version of all files. With local (test) code I meant some old tracktype code I made before starting this and I still have sitting around for testing outside the code of this set. But I will change the rail.pnml and HSL.pnml. I indeed agree that it looks nicer. Your text files show not all the indents nicely, but it looks more ordered than the current state, so I will certainly use the idea.

[Transportman]

Templates are almost done. I am not entirely happy with the overlay template, a number of sprites don't line up with sprites in the next tile (and changing the offsets doesn't really help), so those will get another look. It appears like 1 or 2 pixels are missing at the top of those sprites, so that shouldn't be too hard to change.

More of a license question now: I based my template on NuTracks, so I have to place a notice in every file I generated using those images/code, but do I only need to state that it was based on NuTracks or do I also have to provide exactly who coded/drawn it?

[FooBar]

In every file that you copied you must state where you got it from and that you modified it.
For bits of code copied it generally suffices to comment at those code pieces where you got it from.

It doesn't make the whole thing based on NuTracks, just the bits you used from it.

If the specific files you used from NuTracks don't state who drew/coded it, it's enough to reference the NuTracks project as a whole. If the individual people who worked on it cared about specific attribution, they would have put their names in the files. However, the NuTracks readme has pretty detailed info on who did what, so it isn't too hard to give the right people the credit they deserve.

[Transportman]

I just uploaded the templates to the DevZone. I am not entirely sure about the bridge offsets/template, I think it should be some px wider or the offsets different.

Also the lights for the level crossings are not yet templated, because NuTracks used single barriers to close the whole road, while the Dutch barriers most of the time only close half the road.

[Purno]

I discovered I need to do minor tweaking on my AHOB sprites. The lights on the barrier and the lights on the traffic sign are blinking in opposite order, they should blink in the same order, silly me.

It's just a matter of recoloring 2 pixels per barrier, but it's something I forgot to do, so far...

[Transportman]

I discovered I need to do minor tweaking on my AHOB sprites. The lights on the barrier and the lights on the traffic sign are blinking in opposite order, they should blink in the same order, silly me.

It's just a matter of recoloring 2 pixels per barrier, but it's something I forgot to do, so far...

I didn't notice it when I made my quick and dirty code to get them ingame for you. They are also not yet included in the attached GRF.

The attached GRF has the Template Test Rail, so people can check out the bridges, I think I should make the template a bit wider (2 or 3 px), but would like some other opinions too. Maybe some changing in the offsets to get it in the middle would be fine too. The GRF has almost the same code as on the DevZone, but with added Template Test Rail.

[Transportman]

I'm currently looking at which railtypes to include, and I made the following list (based on the discussions and what actually is in the Netherlands):

Yard rail (Low speed Universal)
Unelectrified* (Medium speed NO Cat)
Classical lines* (Medium speed DC)
Betuwetoute (Medium Speed AC)
HSL* (High Speed AC)
Metro*
Futuristic high speed line (No speed limit Universal)

The items marked with a * are the ones that will be in the set for sure (unless you have a very good argument to not include them) and have the highest priority in my opinion, while those not marked are open for discussion and have a lower priority to include. Am I missing railtypes or are there on the list that shouldn't be?

[FooBar]

I agree with your list.
Mind you that there needs to be a dual current tracktype (possibly very expensive) for if we want dual-current locomotives. Otherwise those are just not possible.