[OpenTTD] NuTracks - Dev Thread
Moderator: Graphics Moderators
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: [OpenTTD] NuTracks - Dev Thread
If real-looking tracks have too large gaps between them, is that my department? What I'm tempted to do at this time is simplify things even more by not actually coding any graphics into the main NuTracks GRF. They would instead be provided by separate "adapters" that could be chosen by personal preference, I think Swedish Rails already has an option to do something of the sort.
I wouldn't be messing around with loads of extra parameters, and there only would need to be a single boilerplate for tracks, depots, fences and possibly signals that everyone could use to add their personal graphics.
Edit: Release of the "new" unintrusive catenary GRF.
I wouldn't be messing around with loads of extra parameters, and there only would need to be a single boilerplate for tracks, depots, fences and possibly signals that everyone could use to add their personal graphics.
Edit: Release of the "new" unintrusive catenary GRF.
- Attachments
-
- uicw.grf
- GPL v. 2+, based on work by uzurpator placed in the public domain.
- (2.38 KiB) Downloaded 264 times
-
- uicw_source.zip
- (12.02 KiB) Downloaded 142 times
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
- coalroads artist
- Traffic Manager
- Posts: 254
- Joined: 29 Oct 2004 05:49
- Location: Australia
Re: [OpenTTD] NuTracks - Dev Thread
Thanks for the praise oberhümer, haha. There's even more of the original dirt now to distinguish the very low speed...
I think the idea of just having some base tracks that can be changed is a great idea, especially if other infrastructure is included.
I toned down the red/ brown one level for everyone. I won't be doing anything much different as in real life most rails are a shade of brown due to the high iron content, except the head of the rail, which in most cases is cleaned each day..
http://www.railpictures.net/viewphoto.p ... 00&nseq=81
First three speeds knocked over, just the last two which should be easier...
I think the idea of just having some base tracks that can be changed is a great idea, especially if other infrastructure is included.
I toned down the red/ brown one level for everyone. I won't be doing anything much different as in real life most rails are a shade of brown due to the high iron content, except the head of the rail, which in most cases is cleaned each day..
http://www.railpictures.net/viewphoto.p ... 00&nseq=81
First three speeds knocked over, just the last two which should be easier...
- Attachments
-
- nutracks3types.PNG (180.99 KiB) Viewed 9017 times
Re: [OpenTTD] NuTracks - Dev Thread
having a problem with the new grf. it keeps telling me theres a sprite messing. wondered if anybody else has this problem
Everton F.C The pride of merseyside
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: [OpenTTD] NuTracks - Dev Thread
SwedishRails allows to select the railtype label which its graphics shall be provided for. By default the two default railtypes, RAIL and ELRL are replaced. The other options were basically only provided so that it could work well together with NuTracks and be shown instead of any of the rail and electrified railtypes it provides. These options might meanwhile be outdated a bit, so that it doesn't work properly any longer with new(er) NuTracks due to railtype label changes therein.oberhümer wrote:If real-looking tracks have too large gaps between them, is that my department? What I'm tempted to do at this time is simplify things even more by not actually coding any graphics into the main NuTracks GRF. They would instead be provided by separate "adapters" that could be chosen by personal preference, I think Swedish Rails already has an option to do something of the sort.
For NuTracks I'd not advise to actually become only an empty railtype NewGRF as there's no real point for such set. But it's moderately easy to provide a parameter for each tracktype as to what label it shall replace. But on the other hand NuTracks tracks are unique enough so that this approach makes not much sense either: it provides several rail and several electrified rail types which necessarily need to be distinct.
My personal suggestion for a nice configuration of NuTracks would be (I've always been overwhelmed by its huge amount of tracktypes):
parameter for railtype label scheme:
- default: use of a railtype scheme as also discussed in the context of CETS like http://dev.openttdcoop.org/issues/2763 or https://docs.google.com/spreadsheet/ccc ... li=1#gid=9
- legacy: use of the old railtype label scheme
parameters for the amount of railtypes where 'simple' means few and 'advanced' means more detailed distinction:
- rail:
* simple (default) (2 types)
* advanced
- erail:
* simple (default) (2 types)
* advanced
- 3rdrail:
* none
* simple (default) (2 types)
* advanced
- maglev:
* none
* MGLV (default)
- Narrow gauge:+
* none (default)
* simple (2 types: normal + electrified)
* advanced (?)
- other:
* none (default)
* rack
Something like this would give 7 railtypes by default and could end up using all again when all adv. options are used.
Make it easy for yourself: screw backward compatibility to OpenTTD <= 1.2, it's of little gain. People with older versions can use the existing NuTracks after all. Start with the "simple" option only and add that additional parameter only when "done"
Keeping it GPL you definitely should take a look at the railtype support of the DutchTrainSet code by FooBar - it's IMHO the prototype implementation for good railtype support on the vehicle side and uses the advanced track classification scheme as discussed for CETS.
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
-
- Tycoon
- Posts: 2781
- Joined: 22 Feb 2011 18:34
Re: [OpenTTD] NuTracks - Dev Thread
I'm not sure if the railtype scheme as discussed in those links is entirely up to date, the wiki shows the current state of things (and is also the way it is implemented in the Dutch Train Set).planetmaker wrote: parameter for railtype label scheme:
- default: use of a railtype scheme as also discussed in the context of CETS like http://dev.openttdcoop.org/issues/2763 or https://docs.google.com/spreadsheet/ccc ... li=1#gid=9
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: [OpenTTD] NuTracks - Dev Thread
The following code does not allow steam/diesel "low speed" trains (ID: RAIL) to run on medium speed electrified tracks (SCAE, position 26) and some others specified afterwards. Might the list be too long? There's no mention of a limit in the NML or NFO specs, but...
Besides that, no trains at all are purchasable on electrified very low speed track (ID: SAAE) even though the same compatibility list is included.
Code: Select all
compatible_railtype_list: ["RAIL", "RLOW", "RMED", "RHIG", "SAAN", "SABN", "SACN", "SBAN", "SBBN", "SBCN", "SCAN", "SCBN", "SCCN", "SDAN", "ELRL", "3RDC", "ELOW", "CLOW", "EMED", "CMED", "EHIG", "HSTR", "SBAE", "SBBE", "SBCE", "SCAE", "SCBE", "SCCE", "SDAE", "SEAE", "3RDR", "3LOW", "3MED", "SAA3", "SAB3", "SAC3", "SBA3", "SBB3", "SBC3", "SCA3", "SCB3", "SCC3", "SAAZ", "SABZ", "SACZ", "SBAZ", "SBBZ", "SBCZ", "SCAZ", "SCBZ", "SCCZ"];
Last edited by oberhümer on 25 Dec 2012 18:58, edited 1 time in total.
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
-
- Tycoon
- Posts: 2781
- Joined: 22 Feb 2011 18:34
Re: [OpenTTD] NuTracks - Dev Thread
You also need to include "SAAE" in the powered_railtype_list of "ELRL" and there I don't see it in the list. Now your code says that "ELRL" trains are not powered on "SAAE", so then OpenTTD thinks that it doesn't make sense to allow buying the "ELRL" train in a "SAAE" depot.oberhümer wrote:Besides that, no trains at all are purchasable on electrified very low speed track (ID: SAAE) even though the same compatibility list is included.
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: [OpenTTD] NuTracks - Dev Thread
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.
- Attachments
-
- nutracks.zip
- (3.51 MiB) Downloaded 215 times
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
-
- Tycoon
- Posts: 2781
- Joined: 22 Feb 2011 18:34
Re: [OpenTTD] NuTracks - Dev Thread
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]
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:
Code: Select all
if(param_force_3rd_rail) {
param[20] = 1;
}
Code: Select all
if(param[20] == 1) {
Some code
}
Code: Select all
if(param_force_3rd_rail == 1) {
Some code
}
- Attachments
-
- Tracklimittest.zip
- Test
- (14.93 KiB) Downloaded 151 times
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
- coalroads artist
- Traffic Manager
- Posts: 254
- Joined: 29 Oct 2004 05:49
- Location: Australia
Re: [OpenTTD] NuTracks - Dev Thread
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...
- Attachments
-
- finalnewtracks.PNG (152.11 KiB) Viewed 10568 times
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: [OpenTTD] NuTracks - Dev Thread
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.
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
Code: Select all
if (0 == 1) {
#include track_type_X_code.pnml
}
Good news about the graphics, but have you thought of narrow gauge tracks? They're now in too.
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
-
- Tycoon
- Posts: 2781
- Joined: 22 Feb 2011 18:34
Re: [OpenTTD] NuTracks - Dev Thread
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.oberhümer wrote:The bug now: Even when I write the code as, it makes a difference whether the include is commented out or not.Code: Select all
if (0 == 1) { #include track_type_X_code.pnml }
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
Re: [OpenTTD] NuTracks - Dev Thread
something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: [OpenTTD] NuTracks - Dev Thread
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!Transportman wrote: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.oberhümer wrote:The bug now: Even when I write the code as, it makes a difference whether the include is commented out or not.Code: Select all
if (0 == 1) { #include track_type_X_code.pnml }
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
-
- Tycoon
- Posts: 2781
- Joined: 22 Feb 2011 18:34
Re: [OpenTTD] NuTracks - Dev Thread
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).
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
- coalroads artist
- Traffic Manager
- Posts: 254
- Joined: 29 Oct 2004 05:49
- Location: Australia
Re: [OpenTTD] NuTracks - Dev Thread
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
Re: [OpenTTD] NuTracks - Dev Thread
Very very nice tracks... very much like them!coalroads artist wrote:All done now
As most of my time is spent in arctic can I/or we see arctic shot too?
Thank You!
Last edited by ISA on 28 Dec 2012 01:01, edited 1 time in total.
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
- coalroads artist
- Traffic Manager
- Posts: 254
- Joined: 29 Oct 2004 05:49
- Location: Australia
Re: [OpenTTD] NuTracks - Dev Thread
Thanks! Sure.
- Attachments
-
- artictracks.PNG (82.33 KiB) Viewed 10424 times
Re: [OpenTTD] NuTracks - Dev Thread
Also very nice!
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
Re: [OpenTTD] NuTracks - Dev Thread
The only thing that catch my eyes at first too - any planning to correct this ?Eddi wrote:something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...
At least, good graphics, it'll match pikka's finescale track - nice small thing !!
YNM = yoursNotMine - Don't get it ?
「ヨーッスノットマイン」もと申します。
「ヨーッスノットマイン」もと申します。
Who is online
Users browsing this forum: No registered users and 37 guests