Transport Tycoon Forums

Posted: **17 Jun 2007 22:13**

Coxx wrote:It seems to have something to do with this Nightly, ...

what nightly ? Nightlies have a release ID, like r10145. I've tried yesterday with r10145 and had it working properly, although with many more sets loaded. But now it does not work anymore with the 2 selections of yours.

... With the warning with the cansetw.grf, wich is about `tracktypecostdiff`, ...

You can ignore these warnings and the triangle. If it does not disable the set it will work. The warning relates to TTDPatch and that is not relevant in OpenTTD.

... let's try again ...

Why NGRails gets disabled I don't know, but there seams to be a bug in NGRails anyway. Adding Pikka's Viaduct to the list makes it work, but gets you an incorrect message. Ignore that message.

Make sure your set list looks like below ... Don't forget the parameter. Also, you must access the NewGRF settings window from the title screen and not in game. Once you have a disabled set you cannot fix the problem from within a game; at least I cannot.

BTW, if nobody objects, I'll have a look at NGRails maybe an update is required.

Posted: **17 Jun 2007 22:22**

OzTransLtd wrote:
... let's try again ...
BTW, if nobody objects, I'll have a look at NGRails maybe an update is required.

mart3p is your man. He did the last update.

Posted: **18 Jun 2007 07:38**

I've allready reported similar problem to mart3p:

My post to mart3p wrote:...
Some problems occur: Narrow Gauge rails are disabling under various Nightly versions. I tried them under Nightly from 9946 to 10048.
...

NG GRF is with red square, and Serbian set is with green square and triangle, so it's not disabled, but instead NG rails, there are Maglev rails.
Under Patch everything is OK.

Posted: **18 Jun 2007 07:40**

Uh, mart3p isn't actually a developer.

http://bugs.openttd.org/

Posted: **18 Jun 2007 08:36**

peter1138 wrote:Uh, mart3p isn't actually a developer.

http://bugs.openttd.org/

Fair enough, but his name is on this file. Should it be removed and replaced by "developer"? The end users do not know wherein lies the problem and the first line of contact usually is the author who's name appears on a file. If the author feels that his code may not be the issue but rather lies with the application on top of which his code runs, then would it not be up to the author to communicate with the developers?

Posted: **18 Jun 2007 10:30**

wallyweb wrote:
peter1138 wrote:Uh, mart3p isn't actually a developer.

http://bugs.openttd.org/
Fair enough, but his name is on this file. Should it be removed and replaced by "developer"? The end users do not know wherein lies the problem and the first line of contact usually is the author who's name appears on a file. If the author feels that his code may not be the issue but rather lies with the application on top of which his code runs, then would it not be up to the author to communicate with the developers?

or ask the original bug reporter to submit a report themselves.

Posted: **18 Jun 2007 10:55**

robotboy wrote:
wallyweb wrote:
peter1138 wrote:Uh, mart3p isn't actually a developer.

http://bugs.openttd.org/
Fair enough, but his name is on this file. Should it be removed and replaced by "developer"? The end users do not know wherein lies the problem and the first line of contact usually is the author who's name appears on a file. If the author feels that his code may not be the issue but rather lies with the application on top of which his code runs, then would it not be up to the author to communicate with the developers?
or ask the original bug reporter to submit a report themselves.

... as in kick it back and say "Its not my problem. Try the shop down the hall." ?

Posted: **18 Jun 2007 11:06**

Not necessarily. They reported the bug so they should be the one to report it, and they may know more about the bug than the grf author.

Posted: **18 Jun 2007 11:59**

robotboy wrote:Not necessarily. They reported the bug so they should be the one to report it, and they may know more about the bug than the grf author.

in which case it logically would not be a grf bug but something that also affects other files, in which case the devs would, I agree, be the proper route to get a resolution. However, if a bug is first observed with a particular grf, then that grf's author is most definitely the first recourse for resolution. Until the author confirms that the problem lies outside his works, the problem belongs to him. If the devs determine that the author messed up, I am sure that they would send it back forthwith, a step in the route to resolution that could have been avoided.

Posted: **18 Jun 2007 12:12**

Ok, I just wasn't aware that mart3p had anything to do with the GRF (Yes, I can't read...)

Posted: **18 Jun 2007 12:18**

It seems no, because it worked with older RCs and Nighties.

EDIT: I've just tested with OTTD Nightly r10183 and all is OK.

Posted: **18 Jun 2007 21:23**

Wile E. Coyote wrote:I've just tested with OTTD Nightly r10183 and all is OK.

Yes, it was fixed by maedhros at r10178.

A second (non-critical) problem still occurs though. As shown in OzTransLtd's screenshot, the message "Error: ngrails.grf must be loaded after pb_viaduct.grf" is shown even when the files are loaded in the correct order. I think this is also an OTTD bug, it was working ok and it works in TTDPatch. I will investigate this further and post a bug report.

Posted: **18 Jun 2007 22:59**

mart3p wrote: ... A second (non-critical) problem still occurs though. As shown in OzTransLtd's screenshot, the message "Error: ngrails.grf must be loaded after pb_viaduct.grf" is shown even when the files are loaded in the correct order. I think this is also an OTTD bug, it was working ok and it works in TTDPatch. ...

Looking at that code :

Code: Select all

  531 * 9      09 88 04 0A 44 44 02 01 00
  532 * 9      09 88 04 06 44 44 02 01 01
  533 * 54     0B 02 1F FF "ngrailsw.grf must be loaded after pb_viaduct.grf." 00

I would say, sprite 531 should not skip the grf, but skip number of remaining sprites instead. That was the problem we first had and although this is now fixed with R10178.

Sprite 532, seems to be the problem it does not skip the message, which points to a bug in OpenTTD. However, I would say, checking during initialisation is incorrect, as at that stage the viaduct grf is not (yet) activated. I did change it to an action-07, but it did not correct the problem either.

My 2 cents ...

Posted: **03 Jul 2007 23:36**

Not a very acute problem any more, as OzTransLtd was so kind to offer a hotfix for the Canadian Station Set in record time, and this seems to be the only GRF implementing snow in temperate at the moment to my knowledge.

Still it might be helpful to have it in the right thread: While anything seems to work perfectly well in the arctic climate, NG-Rails and snow in the temperate climate don't work together. The rails turn into maglev ones as soon as they reach the snowline.

First noticed in r1599, reproduced and the same result in 2.5 beta 9 and 2.6 alpha r1590 by OzTransLtd.

Occures even when the only two entries in newgrf.cfg are ngrailsw.grf and canstnw.grf.

ttdpatch.cfg here: http://www.tt-forums.net/download.php?id=73159

Some more info and the hotfix (solving the problem for the Canadian Station Set) in grf-format can be found here: http://www.tt-forums.net/viewtopic.php?p=600213#600212

NG-rails work with snow in temperate already by replacing the NG-Rails-GRF by the hotfix. To get the Serbian-Narrow-Gauge-Set working proper, it needs putting both, (the hotfix should be above) in the newgrf.cfg - what also get's Pikkas stonebridge to work in the patch.

Best regards,

Carlo

Posted: **11 Jul 2007 22:02**

Ben_K needs permission to use the narrow gauge rails so that he can do a narrow gauge version of his BKTunnels.

Can somebody help him with this?

Posted: **20 Jan 2008 00:54**

New Version of Narrow Gauge Rails (v0.93)

I’ve done some updates to the Narrow Gauge Rails grf; download the new version from here.

New features

- Support for TTRS3 added. Narrow gauge level crossings for all TTRS3 road types.
- German translations added.
- French translations added.

Bug fixes

- When used with grfs that add snow in the temperate climate, snowy tiles where shown with the wrong track type.
- Sprite offset problem with some bridge ramps fixed.
- Sprite offset problem with NW facing long depot fixed.

OpenTTD support

- Narrow gauge button and cursor sprites for OpenTTD are now working again. Note, requires version 0.6.0 r11433 or greater.
- Adjusted rail costs now working for OpenTTD. Note, requires version 0.6.0 r11265 or greater.

I've not been able to test the DOS version (ngrails.grf), could someone let me know if it works?

Thanks to Zimmlock for the TTRS3 narrow gauge level crossing sprites and Csaboka for information on their usage. Thanks to Carlo Ghega and wallyweb for the translations and for testing.

Posted: **20 Jan 2008 19:36**

Very nice! Do you have a list which sets use or are compatible with the NG rails? (I can only think of the Canadian and US sets, but there might be more.)

Posted: **20 Jan 2008 19:40**

Serbian set is good for NG stuff too.

Posted: **20 Jan 2008 22:37**

MJS wrote:Very nice!

Thanks

MJS wrote:Do you have a list which sets use or are compatible with the NG rails? (I can only think of the Canadian and US sets, but there might be more.)

The Canadian train set has narrow gauge rails built-in and does not require this grf. It is possible though, to load ngrailsw.grf after the Canadian set to use some of the extra features (viaduct bridge, ttrs3 support act.).

The US set afaik, does not use narrow gauge rails.

The only set that currently needs ngrails.grf is the Serbian Narrow Gauge set (as Ameecher said).

There is also the UK Narrow Gauge set but I don't believe it has been released, apart from some test versions.

Other sets planning to include narrow gauge trains are the French set and the Swiss set .

Posted: **23 Jan 2008 16:30**

I found a couple of bugs:

3rd parameter of TTRS3 was ignored, causing TTRS3 road crossings to appear even when TTRS3 roads were disabled.
Incorrect operation with the grf parameter =1. As no currently released train sets use this setting, I doubt that anyone has noticed.

I have corrected these problems and posted an update: ngrails(w).grf v0.93a.

Transport Tycoon Forums

Narrow Gauge rails - updated release!

Re: Narrow Gauge rails - updated release!

Re: Narrow Gauge rails - updated release!

Re: Narrow Gauge rails - updated release!

Re: Narrow Gauge rails - updated release!

Re: Narrow Gauge rails - updated release!