Class 156 problem

[gptech]

Locos running out of fuel when they're swapped items happens, I've come across it before particularly if it's a double headed consist (essential what a 2 car 156 is)
Easy fixed in the scenario editor: double click each car and move the fuel slider in the properties slide out box

[clivejames1st]

Don't think Oovee are into TS any more. They are more into a game called Spintires.

I too have experienced same problems, maybe it's time DTG pulled the plug on this one and created their own version. Not good for those of us who have lots of reskins I know but, if the Ovee version can't be fixed, what other alternative is there. DTG can't continue to sell an item that is obviously faulty and it seems neither they or Ovee are going to fix it. I for one having read all the posts on this would not buy this. Just my own thoughts of course, but how do other people feel?

David

I quite agree and will mention it to DTG when they reply. Puzzling as to what has caused it though as it has been fine up until two days ago.

[clivejames1st]

Locos running out of fuel when they're swapped items happens, I've come across it before particularly if it's a double headed consist (essential what a 2 car 156 is)
Easy fixed in the scenario editor: double click each car and move the fuel slider in the properties slide out box

I have never come across no fuel problem before so I forgot about the slider. I guess the Oovee problem and no fuel problem are some how connected. The class 166 does, however, seem to be fine. Thanks for the slider reminder.

[Timex]

Update: I've found a permanent fix for the crash for stopping at a station earlier than the scheduled arrival time.
You need to edit the scenario and click the 'unload passengers' box at the stations where the box is not ticked.

I have a problem at one station though , Hough Green on a Liverpool-Manc scenario which I subscribed from the workshop.
What I'm going to do is rebuild it exactly the same and see what happens, I'm beginning to think the scenarios are not compatible with the current version(s) of TS.

I will report back.

[clivejames1st]

I have heard from DTG and this is the reply:-

I have just taken a look here in the office and it appears this is a bug in the game, as the same strange
issue is occurring on my copy of the game too. I have made the developers aware of this and hopefully
they can get a fix figured out down the line.

So, nothing else we can do at this stage but await a fix.

[Clemmo47]

We'll wait for ever for a fix from Oovee. The HST buffers pack still has the blurred windscreen afaik .
And it's surprisingly still on sale on Steam.
We had to fix that ourselves.

[gptech]

When the 156 was first released we didn't have these various issues, so it's not entirely the fault of the model itself; updates to the core game since then are obvious candidates for changing something within the game which has resulted in a *conflict* with the 156. Think back to the time when it was nice and new and shiny and lauded in these very pages for being the bee's knees when it came to realism.

It would seem to have developed a propensity for falling over when driven round corners, though personally I've had to lay track with stupidly tight curves and drive at a stupid speed to replicate this--perhaps it's always been a little 'close to the edge' and when now used on routes with very tight curves and/or super-elevation applied it just proves that little bit too much for it. There is an edit for the .bin files documented in this thread, or if not, in another recent thread about the 156 so that should no longer be a great problem.

Because the coaches don't feature their own individual numbering, just a set number, when prototypically used with both the DMS and DMSL displaying the same number (156001 for example) only the doors on one coach open. This holds true for any DMU (and possibly coaches) with duplicated numbers so once again isn't a *fault* specific to the 156.
Easy enough to work round, just renumber one of the coaches to have a different number---cries of "Oh no!! THAT'S wrong" ......but is it?
The number assigned to a coach doesn't mean it will be the number displayed;
if you have a texture named x.TgPcDx but the *picture* of the texture is a number 1 then a coach numbered as x56001 shows in the game as 156001.
Yes, x is a bit daft as it looks nowt like a 1 and could be confusing---try !
Copy the texture for the 1, rename it to have ! instead of 1 and edit the digits.bin file to also now point to that new texture:

primarynumber_1.TgPcDx is copied, and the copy renamed to primarynumber_!.TgPcDx

Code: Select all

			<cNamedTextureSetBlueprint-sTextureEntry d:id="81426132">
					<TextureName d:type="cDeltaString">!</TextureName>
					<TextureID d:type="cDeltaString">Oovee\BRClass156Pack01\RailVehicles\Diesel\BRClass156\ScotRail\Engine\Textures\Numbers\[00]primarynumber_!</TextureID>
				</cNamedTextureSetBlueprint-sTextureEntry>

(edited where applicable of course to suit the livery it's for) is added to the digits.bin file.

Renumber one of the coaches in scenario editor to use the ! instead of a 1 and the problem of only one set of doors opening is alleviated and when given a quick glance in the editor the *real* number of the coach/set is still apparent.

Whether this will have the knock-on effect of curing crashes to desktop at subsequent stops/door openings remains unanswered, but worth looking into.

[sroberts001]

Hi All,

Sorry to stir this all up again but I've been following this thread and everyone seems to think that the door issue is new and only applies to 2015. I reported this back in March 2014, in fact it was class 156 scenario "Class 156 Driving Tutorial" which runs on the TestTrak scenario... having reported this to DTG and after a 28 email thread the last of which was exactly the same as the first (I only ever had a track layout like that with my first Hornby set!) I did what they wanted me to do....give up - The only thing I could see that they had done was to remove the said scenario in a later update.

However I wanted to give it another try, after all I'd bought this thing, so created a simple free roam scenario on The Kyle Line and the same issue occurs unless you do the stop, wait 10 seconds, open doors (this quick fix someone in this thread mentioned so thanks for that). As for the door issue I sit in teh cab, wait for the timer to finish and go, watching people get on or off doesn't really interest me.

So whatever the door issue is its not new and all DTG seem to have done is bury their heads in the sand hoping that its gone away - well while they are still selling the DLC it isn't going to unless they buckle down and fix it.

[gptech]

They may not be able to fix it------the model isn't theirs.
The door issue also isn't affecting everyone, as long as just a single person doesn't have to wait at stations it can't be seen as proven that it's a fault with the model. As a quick test try numbering one coach to make the pair unique and test again.

[sroberts001]

If they can't fix it then perhaps its time to pull it from the Steam site.

[gptech]

If they can't fix it then perhaps its time to pull it from the Steam site.

Once again....... as not everybody has the problem or problems under discussion it can't be classed as in desperate need of a fix.

[clivejames1st]

Hi All,

Sorry to stir this all up again but I've been following this thread and everyone seems to think that the door issue is new and only applies to 2015. I reported this back in March 2014, in fact it was class 156 scenario "Class 156 Driving Tutorial" which runs on the TestTrak scenario... having reported this to DTG and after a 28 email thread the last of which was exactly the same as the first (I only ever had a track layout like that with my first Hornby set!) I did what they wanted me to do....give up - The only thing I could see that they had done was to remove the said scenario in a later update.

However I wanted to give it another try, after all I'd bought this thing, so created a simple free roam scenario on The Kyle Line and the same issue occurs unless you do the stop, wait 10 seconds, open doors (this quick fix someone in this thread mentioned so thanks for that). As for the door issue I sit in teh cab, wait for the timer to finish and go, watching people get on or off doesn't really interest me.

So whatever the door issue is its not new and all DTG seem to have done is bury their heads in the sand hoping that its gone away - well while they are still selling the DLC it isn't going to unless they buckle down and fix it.

It is certainly new to me as I did not have the problem until about 10 days ago. In fact I was running the 156 fine on the same route until then. This is what makes it all the more puzzling.

[gptech]

Anybody want to share a slice of humble pie with me?...as a special treat you can have ice cream with it!!

(note that I did say "share"...I'm still not accepting that there's a fundamental issue confined to the 156 here)

A couple of days ago the question was asked in the 'older versions of TS' sub-forum of whether a scenario for the free Port Road route would port over to the full DLC version. Because I like to help where I can (OK, love sticking my nose in) I had a look; and yes, with a wee bit of tweaking here and there it loaded just fine.
Accordingly, full of that nice warm glow you get when you've done something you think is right I posted that it would port over...then I played it...

Instant lock up when opening the doors of the 156....

First thing to suspect then was the .bin for the reskinned model, so a quick swap with RW Tools for a known good version was in order...

Instant lock up when opening the doors of the 156....

Tried the next livery in the list....

Instant lock up when opening the doors of the 156....

...and so on.....no matter which livery I chose the game instantly froze when opening the doors.

Tried creating a new scenario, same result---no matter which livery.

However..... creating a new scenario in WCMLN, no matter which livery was used worked perfectly

I'd had enough by then, so haven't tried another route yet nor have I gone back to WLoS and tried a different starting location, but if anybody...or better still a few anybodies... could have a bash at creating a simple standard scenario on a couple of routes we could soon build up a *picture* of what/where it goes wrong. It might not help in the long run, but then again it just might provide a clue that gives somebody some flash of inspiration and brings forth a fix/work round/recommendation---maybe even enough for an official edit of whatever is 'iffy'.

EDIT:

I reported this back in March 2014, in fact it was class 156 scenario "Class 156 Driving Tutorial" which runs on the TestTrak scenario...

I'll forgive the wee error about TestTrak being a scenario and not a ROUTE but this one works perfectly for me---so there's more to this than just a straightforward 'yeah, the 156 is broken' attitude.
You would actually be a perfect tester, having experienced these issues, so would you care to knock together a simple Standard scenario on a route, or even a couple of routes? Doesn't have to be overly complicated; pick a starting point, end at the next station but start off with an instruction to load passengers. There may be something amiss that's a combination of route and stock here.

[gptech]

Created more test scenarios this morning; SECML, Dundee-Montrose (Aberdeen Angus), Edinburgh - Glasgow and all worked perfectly.
Back to WLoS and tried again but with the same results as last night...complete lock up when opening the doors. However, in WLoS using just a single coach worked, pointing towards a conflict with 2 coaches sharing the same animation files.
Gave the DMSL it's own copies of the animations but once again, freeze on door opening...

I've been using the little 'bodge' I outlined earlier to enable both sets of doors to open; DMS numbered as 156xxx and DMSL as !56xxx so tried with the DMSL re-numbered to 156xxx. Success!...or at least no freeze but only one coach's doors opened.

Conclusion?... no idea, a 'fix' (or bodge) should be universal, and if it works for the 156 on one route it should work on all so why the renumbering idea works on the half a dozen or so other routes but not WLoS I've not a clue---there's nothing peculiar (as far as I can see) about the WLoS configuration that could explain it.

[TrainBloke]

Sorry for the bump, but just wondering if any progress had been made with the Class 156 door issue?

I'm thinking of buying the Class 150, 156 & 158 packs on Steam as they're currently running another TS sale. Though it looks like i may be better off skipping the Class 156 if even DTG don't seem to interested in providing a fix.