Monthly Archives: August 2013

Problems with LMS 3F Jinty and Timetables

Update 2013-08-12
I contacted Meshtools and they quickly replied and gave me a workaround as well as an explaination. The problem has to do with the brakes of the Advanced LMS 3F. The easiest workaround is to hook up the locomotive to (fitted) stock from the beginning of the scenario – then the timetable is generated correctly.

I like the LMS 3F Jinty tank locomotive for Train Simulator 2013, and I wrote two scenarios for the Advanced version of it, and published to Steam. But the other day when I was writing a third scenario, I encountered weird problems with the Advanced version – the Standard version still works fine.

The problem is that the Advanced version produces a very bad timetable. That is, every move takes about 10x longer time than it should (comparing to the Standard version). It is impossible to make reasonable scenarios this way. My findings are:

  • The Advanced 3F performs normally when I drive it, just the timetable is weird
  • The “old” scenarios are not affected (I can both edit them and drive them)
  • Resetting the Game Cache (from within TS) does not help
  • Verify Integrity of Game Cache (from Steam) does not help
  • Reinstalling TS2013 completely does not help
  • The problem happens on several routes that I have tested
  • The problem happens to all ADV versions of LMS 3F, but to no STD versions
  • It is not possible to compensate by setting 750% performance
  • Using RW Tools to replace a STD version with an ADV version generates a corrupt scenario
  • The problem does not seem to affect the J94 ADV version (from the same author as LMS 3F), although I have not tried a single one of all the variants.

I believe, since TS2013 is regularly updated via Steam, some kind of update/fix to TS2013 has somehow broken LMS 3F ADV. This update should have been released the last days of July or the first days of August. I think I checked the LMS 3F files in the filesystem, and none of them seemed to be updated during this time, so I believe it was TS2013 itself. Since the LMS 3F Manual clearly states that the AI is not capable of driving the Advanced version, it makes some sense that an update to TS2013 could generate problems with this loco (perhaps the Timetable generator simply fails to release the brakes).

I have been in contact with Railsimulator support. It has so far not resulted in anything. I am now simply trying to file a bug report. I consider to contact Meshtools directly.

It would be very interesting if someone else can confirm (or deny) this problem. Just put a LMS 3F Jinty ADV anywhere on any route, and schedule it to go a few miles. If it takes a few minutes it is ok. If it takes more than an hour, you also have the problem.

Building Node.js on Debian ARM (old)

Update 20140130: I suggest you first have a look at my new article on the same topic.

I thought it was about time to extend my JavaScript curiosity to the server side and Node.js.

A first step was to install it on my web server, a QNAP TS-109 running Debian 6. I downloaded the latest version (v0.10.15), and did the usual:

$ ./configure
$ make

after hours:

../deps/v8/src/arm/ error: #error "For thumb inter-working we require an architecture which supports blx"

That is not the first time my TS 109 has been too old. However, the english translation of the above message is that you have to have an ARM cpu V5 or later, and it has to have a ‘t’ in its name (at least, this is what the source tells, see below). In my case

$ uname -a
Linux kvaser 2.6.32-5-orion5x #1 Sat May 11 02:12:29 UTC 2013 armv5tel GNU/Linux

so I should be fine. I found a workaround from which I extracted the essential part.

// We always generate arm code, never thumb code, even if V8 is compiled to
// thumb, so we require inter-working support
#if defined(__thumb__) && !defined(USE_THUMB_INTERWORK)
#error "flag -mthumb-interwork missing"



// We do not support thumb inter-working with an arm architecture not supporting
// the blx instruction (below v5t).  If you know what CPU you are compiling for
// you can use -march=armv7 or similar.
# error "For thumb inter-working we require an architecture which supports blx"

After adding the three lines, I just ran make again, and after a few hours more everything was fine. Next time I will try the -march or -mcpu option instead.