With all those different Dutch sets popping up, the lines between them are getting a bit vague for me
![Razz :P](./images/smilies/icon_razz.gif)
Moderator: Graphics Moderators
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.FooBar wrote: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
I think you could include them in both sets...Purno wrote: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)Purno wrote: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
No, I can't do a quick code change at this momentPurno wrote: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.
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.Purno wrote:Could we add a parameter to keep things very simple? I don't like these advanced gameplay mechanisms
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 wheelTransportman wrote:template
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?FooBar wrote: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 wheelTransportman wrote:template
Ok, so that is the magic I was missing.Michi_cc wrote:Do not use sprite cropping in grfcodec/NML when aligning sprites (or make sure the source sprites have no unneeded magic blue).
-- Michael Lutz
Found it indeed, but was indeed a bit hidden in the mess.FooBar wrote: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).
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.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 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.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.
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.Transportman wrote: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.
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 wrote:It is in the Track type files that it is missing?
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.FooBar wrote: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.Transportman wrote: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.
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 wrote:It is in the Track type files that it is missing?
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.Purno wrote: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...
Users browsing this forum: Bing [Bot] and 4 guests