Stainmore Edan Valley Route By Steam Sounds Supreme

They state DTG would need to fix it. Hmmm. So DTG will have to fix my TSW cabcam mod after today's update then.

Luckily that route's not in my playlist anyway. Only their signals are affected, someone on the Steam forums detected possible memory leaks (TS now blocks execution of such as good as it can).

Ask me, it would need someone from the community completely resignalling the route with well-scripted signals.

 

That stuck out to me also. A number of people have investigated this and the consensus seems to be a flaw in the signal scripts. I suppose it is easier to blame DTG though.

 

DTG did mess up the signals in the current beta - but that effect is to be seen on all routes, which is proof that they need to revert the experimental changes. Which they'll do - but this has nothing to do with the flawed SSS scripts.

To prevent ingame OOMs, TS has become much more strict. If you don't adapt your products to this, they'll fail and you can't blame DTG for that.

Previously, it allowed a lot of bad scripts and corrupt blueprints to be running and messing up memory. People got used to do whatever they want, not sticking to dev docs. For a stable game, the price you'll pay is the bad stuff is not allowed to be run anymore.

If 99.9% of all content is still compatible, it's not hard to guess who's at fault. The game, or the 0.01% incompatible 3rd party content...

If it takes reverting stability core changes to please this single developer, no dev would go this way and adapt their engine for a single special case an unrelated 3rd party has issues with.

This route has been sold for many years, and I'm sure it paid well. How hard can it be to hire an experienced signal scripter to clean up the mess?

 

KWVR & Stainmore Signal Patches



We're pleased to say that two signal patches have been released to fix the issues loading both the Keighley & Worth Valley Railway and the Stainmore, Shap and Eden Valley routes. Note that these patches are temporary fixes. If DTG are able to fix the game code issue, then we will reverse this patch. Also be aware that by installing these patches, some ground signals in these route will no longer function as intended and will remain at danger.
Find the links to these patches under the Patches tab above

 

trev, it's the same workaround that is already known. Shunting signals are disabled - scripts removed instead of being repaired. Please read above. SSS show no intention to fix the signals, blaming it on DTG.

 

So why shouldn't they blame DTG? It was like a while ago when some virus software company released an update and everyone with that particular software couldn't run TSC. The company fixed the issue and everyone could run TSC again. I'm afraid that I completely disagree with you and this is a DTG issue that they need to fix.

 

I think what is on their site is referred to as a "patch" at the moment, but it's not an actual fix based on my reading here, just a signal disable.

I asked about this. It's up to SSS to keep up with modifications to the core. My understanding is the core is updated for newer hardware and drivers and that it would be necessary to downgrade the core to make SSS signals work, so it's on SSS to "keep up", so to speak.

 

Because the major fault is with ropey scripts...do you want the game to let LOVE coding run and fall over regularly, or do you want it as stable as possible?

 

It's the same with any game developer, if they patch or update the core then yes there's a chance it'll make older mods incompatible, it's that way with ETS2/ATS, Farming Simulator series, Train Sim and countless other games that have active modding communities, while the developers try not to cause compatibility issues sometimes they are unavoidable, I lost count over the years how many times ETS2 updates broke mods, but it was a necessary evil for the betterment of the game (and by golly it's a better game now than at launch), the SCS devs try hard to accommodate the modding community but at the end of the day it's always up to the mod author to bring their mod up to the current core version or it'll get left behind to gather dust and be forgotten, hardly what you want for all your hard work.

I think DTG have done an incredibly excellent job of maintaining compatibility over the years, no small feat I should imagine, sounds like (pun intended) the SSS guys need to take it on the chin and rework the broken signalling to meet todays standard and be proud that their product is as usable and enjoyed by many today as it was when it first released, in fact it'll be even better if the old scripts caused memory leaks or whatever.

Nobody ever said progress was easy.

Just be grateful we're not GTA V or RDR2 modders/mod users, R* hate modding, hate people scripthooking and always manage to "accidentally" break mod compatibility even if they just add an online event update.. Hmm now I suddenly feel like a hot coffee, strange..

 

Guess I will be leaving Stainmore uninstalled, then. Well at least I didn’t pay full price for it but makes me wary of trusting any products sold directly by them in future. It’s not the first time a core update broke third party content (I remember all the signals on one of my freeware routes getting nerfed some years ago). Annoying though it is if you build in a dynamic and evolving sim you need to accept you might need to update your work. Particularly if you charge a lot of money for it.

 

If the signals are scripted correctly, they will survive any core update, just like DTG's signals (and 99.9% of the rest, like Schuster and other 3rd parties doing a good job. The highly complex german signal scripts by Schuster didn't even need an update - because if you adhere to the dev guidelines you'll not run into trouble).

Still can't understand why some people claim DTG should fix content of a random author they are in no way affiliated with.

All but SSS' signals (plus some rogue freeware scripts, the manipulated newS and KMW signals) are working. It is SSS's job to make sure their DLC are compatible if they charge money. Their stuff has long paid off but they're not willing to put any work into it anymore, that's their fault. Just collecting the cash for old DLC won't work, you have to care for your products.

 

Or SSS Should get a developer to make new scripts for the signals that are DTG compliant

 

Or just amend the route to use ground signals that actually work.

 

If they are not going to update it then at least have the decency to declare “end of life” and withdraw from sale/support as AP have done with some of their older stuff.

Certainly doesn’t encourage purchase of future SSS products and to be brutally honest, I thought Stainmore a bit overrated. More like crossing the North Downs than the rugged countryside of the northern Pennines.

 

This..
Surely there's enough working signal assets out there to find and use a suitable replacement.

 

The signals are not really "their" signals, but free third-party signals by one developer ("ALGB") using scripts developed many years ago by Mark Brinton, who doesn't seem to be in the TS world these days. I'm left wondering if permission was asked of either party for use in a commercial product - neither are mentioned in the list of credits in the manual.

On another forum I read that somebody independent was working on tracing the issues (see post from "Jack.Grave" at https://steamcommunity.com/app/24010/discussions/3/4336482945456381934/ ) but all has gone quiet there.

The "patch" from Steam Sounds Supreme is better described as a "bodge" and is nothing new on what others have published elsewhere although I doubt anybody has been credited for this. either.

I have already indicated a willingness to fully re-signal the route (using Kuju scripted signals which are far from perfect but do at least work) but I'm not even going to consider starting on this until it is definitely known that other options are exhausted. It would be a massive project to make progress on and then abandon.

It should be noted that some signals never worked on this route from the start - e.g. distant signals at Stainmore Summit and Tees Valley Junction.

John

 

Whether they've done it the right way or not is a moot point, but the fact is they have issued a patch to make the route functional at least, which isn't particularly indicative of a developer keen to abandon the product or ignore issues with it. Withdrawing it from sale simply consigns it to the "never going to be fixed" pile.

Were these perhaps fixed distants? I.e. not supposed to "work" in the first place. Not often implemented in TSC but plenty of instances in the real world.

 

On a steeply rising gradient at Stainmore Summit? Not a chance! And if you respond correctly to these signals being at caution, you fail at least one scenario for bad timekeeping, because it takes so long to get the train moving after the home comes into sight. If I remember from when I fixed these for myself, the issue was with shunting discs facing traffic on the running line that weren't present in the real world.

Best regards,

John

 

If they had done the scenarios as Career that wouldn’t have been so much of an issue as so long as you hit the objective or station stop, you lose 100’s of XP for being five minutes late but still get the tick which means you don’t fail the scenario and marked off as done. I think there was more than one on Stainmore like that and prior to my big TSC clean up (complete uninstall/reinstall) to purge the LOVE, I had contemplated going in there and altering the timings on scenarios in question to make them more achievable. As I said earlier, IMHO a very over hyped route.

 

I only run a couple of regular passenger diagrams over it but it now seems to be working OK for me and sadly I'm used to compromising over dodgy semaphores in other routes. Regarding the style of scenery like pretty much every steam era route it lacks grittiness especially around shed areas but it's worth remembering that the landscape of the era portrayed was very different from today's world of trunk roads and industrial scale farming. Likewise with the track and line side environment. I get why you might personally not like the product but why deny other people the option of enjoying a unique if inevitably flawed chance to drive over a long gone route. Stainmore is also a requirement for excellent freeware routes like The Cumbrian Coast and Vale of Neath and it comes with a wide selection of locos and rolling stock which alone might make it worth purchasing in a sale. Given the gushing reviews on their sales pages for some of their withdrawn products I'm not sure that AP were just doing the decent thing by withdrawing them. The collateral damage of their commercial decision is that many free enhancements and reskins which required them are no longer available to newer players. Not AP's problem I know but still frustrating and a bit of a waste.

 

Which is the only reason I bought it tbh, I've never even loaded in Stainmore let alone ran a scenario or QD.

 

"Buzz" at https://steamcommunity.com/app/24010/discussions/3/4336482945456381934/?ctp=5 is also working on fixing the scripts concerned.

J

 

Bazz, not buzz.

 

Deeply sorry if I have insulted anybody, I have poor eyesight and find the colour scheme on that web site difficult.

Anyway, I hope the point I was making was more interesting than my error.

J

 

No, I apologise for being a wisecrack. Absolutely, and hopefully Bazz is successful. (If you ever tried to rework somebody else's code, added the difficulty to understand all the interactions between various scripts, you'll know it's very difficult.)

 

The worst bit about that thread is that it was started by somebody who should have known better.

 

How so? It reads like a genuine request for help to me.

 

Sorry...you're right Steve. My mistake, after reading it again (properly!!) I should have written that the first reply was posted by somebody who should have known better, or at least should have worded it better than a straight cut and paste without the "it's all DTG's fault" ending

 

I analyzed the lua script codes for these disc signals and didn't find any drastic errors, so I tested each of them in a basic route, everything works perfectly.

The problem on the routes (KWVR and Stainmore) could be another object conflicting with these signals or it could be due to incorrect use of them on some junction branches, which leads to crashing after loading, a real unknown at the moment. What changed in this version to the previous one in the core of the TSC game and what is causing this, I don't know exactly, when I have time I will do runtime debugging to see if I can get to the point.

Test on version v77.6b (x64).

Disc signal - 3 tracks

 

Now that is an interesting idea! You may well have hit the nail on the head.

I have just tested (with the scripts re-enabled):

1. Carinthia's Somerset & Dorset Revisited
2. Isle of Wight Network v7

Both of these appear to work fine despite extensive use of Mark Brinton's scripted signals, including shunting discs.

On the other hand, in addition to the known offenders:

1. Southampton-Weymouth v4

Definitely does not! My tests have been brief, simply by loading a scenario and watching it go bang, or not. Curious indeed that Southampton-Weymouth is distributed by Steam Sounds Supreme . . .

John

 

Excellent research. I tip my ha-...wait, I don't wear a hat, I'll salute you instead.

 

Earlier I wrote:

I need to eat my words on Somerset & Dorset Revisited - this problem DOES present itself but in a different way. Whilst scenarios seem to load OK, on a trip from Bath to Templecombe the scenario went bang approaching Templecombe. Removal of the offending shunt signal scripts does resolve that.

I haven't (yet) made any tests on the IoW, but now another problem has arisen - with John Yelland signals! On the Wycombe Lines v4 route, I am experiencing OOMs around Oxford. Not everybody might suffer this, for I have heavily modified the signalling (much of it didn't work properly) and modified some incorrect track layout.

But what I was experiencing was:

1. Up direction - crash near Wolvercote Sidings
2. Down Direction - crash entering Oxford platform

I was surprised to find these were not caused by the same thing!

Item 1 was fixed by looking at all of the scripts in the Yelland assets - things seem to be a right proper mess there caused by additional files inserted by auto-installers and RWP files. I found no less than 18 OUT files. To my knowledge, John Yelland has never used OUT files with his signals and as all of these had correspondingly-named LUA files I disabled the OUTs. Who the heck is distributing these? All now seems good, but . . .

Item 2 has proved not so simple to fix. The above did not resolve it, and even disabling all related LUAs seems not to, too. I narrowed it down to the BR(WR) signals - with those in the BR(WR)_Arms directory disabled (and thus not visible) there are no crashes. I reinstalled UKTS files 34040 and 34729 afresh and the problem arises again. This needs deeper investigation, but I am now suspecting there is a issue with just one of the signals concerned - identification will be long-winded and tedious. That's for another day.

John

 

This is why I install stuff to a dummy location, and manually copy and paste just what's needed to the game. Many have told me I'm being silly but whilst they're busy repairing things I'm quite happily playing.....

 

Reference to item 2 I mentioned above, disabling the following has proved to resolve some of the issues:
BR(WR)-3ft-ring-siding 1T.bin
BR(WR)-3ft-siding 1T.bin

The curious thing is that they don't seem to interfere with things when used extensively at other locations on the route, so I think the problem may be more complicated than it first appeared.

These files (and their associated LUA and BAN files) are original and unmodified so regrettably Mr Pedley's retrospective solution doesn't help.

The only thing that has changed since they were working fine is the recent TS update, something that I haven't yet figured out.

John

 

You had better correct the spelling of his name or else he will be on you like a ton of bricks.

 

Nah Trev, I'm only like that with idiots....

 

Testing, testing and more testing is extremely time-consuming and tedious. Especially when so many factors are potentially involved.

I believed I had discovered problems with signal scripts that were not of the Mark Brinton variety but needed to prove it. I can't ask other people to compare results when I am working with a personally modified route which involves significant changes to signalling.

So I decided to follow Torfmeister's excellent guidance at https://forums.dovetailgames.com/th...ly-install-old-ts-versions-next-to-tsc.71041/ and install an older version of TS (v72.3b) and test with that. Voila! The issues with that route have vanished!

And I have tested that route with both a set of vanilla John Yelland files and those I found on my system with additional signals and scripts. Both work fine. On that matter, I can confirm that a) John's install files do put some of the scripts in unexpected places (but I don't question they are linked to work correctly) and that most of the additions are from Steam Sounds Supreme. I have no idea of the purpose of the latter, but they are identifiable by "(SSS)" in the editor. And to give the full picture, I have modified one of JY's signals myself - a distant signal which was unintentionally configured as a stop signal allowing the classic "two in a section" - harmless with two AI trains involved but a tad dangerous if a player train is following an AI train!

Equally, I have moved my other three (so far!) irksome routes with problems and although not yet exhaustively tested, they appear to be fine too.

So something has definitely changed in the TSC software between then and the current (v77.6b). A list of changes issued by Dovetail for a recent update did mention changes to handling of scripts (the detail was in too compicated a language for my little brain) but when I mentioned that in a post elsewhere I was firmly put in my place that it was nothing to do with these signal script issues. I'm not so sure . . .

In other posts, people have said more than once that Dovetail are focussing on eliminating memory issues - could it be that this is the problem with the scripts when used in multiple occurrances, e.g. areas with complex signalling? It does seem to be that it is the bigger routes that suffer from the most problems - typically Dovetail routes do not feature complex or indeed accurate signalling and are generally quite short routes in nature. Colour-light signals are by nature provided in lesser quantities which could also explain why we seem to see these problems only in semaphore-signalled routes.

As to the argument as to whether Dovetail have "broken" things, I see both views on this. But surely Dovetail have broken something (whether deliberately or accidentally) by causing the game to just go to a blank black screen without the kindness of an error message*. Certainly we can't report an issue to Dovetail without better evidence than that the only routes affected are third party.

* - I do hope that one day. Dovetail manage to change things to provide useful error messages rather than the vanilla "Out Of Memory" too, comparable games from many years ago (I'm thinking Flight Simulator 2004) are able to tell you exactly what caused the problem.

It has never previously been my intention to stick in the past with old versions Train Simulator for recent updates have included a LOT of useful improvements. But with four (so far!) broken routes suddently working correctly I'm going to hang onto v72.3b for the time being and enjoy playing all the scenarios I have made.

Several people have kindly said they would focus on a fix, but I'm guessing frustration has overcome many of them too as the majority have gone quiet. As they all no doubt have more technical knowledge than I do, I don't seek to discredit them in the slightest and it would be a dream come true if somebody finally nails the problem. I wish you well with that, Wellington. But meanwhile, I'm going to spend some time actually playing with my digital train set.

Best regards,

John

 

The $64k question is, are SSS prepared to look at adopting this and issuing a proper patch to fix the problem once and for all?

 

Is it an SSS problem? There are two schools of thought here on this issue some are saying it is a DTG problem as they caused the problem and others are saying it is an SSS problem and they should fix it. I'm sitting on the fence with this one. As I mentioned somewhere else a few months ago a virus software company released an update and some people with this particular software were unable to run TSC so they all went screaming back to the company that released a fix now shouldn't DTG do the same here after an update? this isn't the only route from SSS that isn't working properly after the DTG update either.

 

So are you saying DTG have a vendetta against SSS?

The AV issue....Avast/AVG put out a definition update that didn't like TS, nothing to do with DTG and it was resolved by Avast/AVG. After rolling back the AV software folk found that their problems were resolved, proving the AV was at fault. If you're holding that up as being what should happen here then you're saying SSS should sort it out.

If it is a core software issue why are no other signals affected?

 

I do see some wrong assumptions made here.

Whatever the issue with Stainmore is, it is wrong to claim that TS can't handle complex signalling. (Check Weardale for example).

While the scripts do not necessarily have to be broken, the way the route is set up might be, leading to signalling interaction issues due to the improved core which for some reason detects an issue in the network.

It still might be a misplaced link somewhere that in conjunction with the scripts leads to an unresolvable clash now, due to the game being more strict now to prevent runtime crashes / memory leaks.

And as Gary said, only one single developer is affected. It's on them to seek DTG's advice and update their route. DTG might just say "check it yourself, it produces errors in Logmate. Why should we fix a 3rd party route we're not affiliated with "

What some define as DTG "breaking" things can also be considered more rationally as DTG exposing route building faults now. Which, as only SSS are affected, seems to be the most fitting answer.

In any case, you can still make a small v72.3 installation to run it on, for Stainmore and the AHS Eurostar. All the rest out there is working fine.

And my opinion is the route will need to be resignalled from scratch, just from reading this thread (I don't play it myself.)

 

I know the following is slightly off-topic but it seems appropriate to tuck it in here as it is another issue (presumably scripting again) that has arisen with a recent TSC update.

The Bossman Games 7P Rebuilt Patriot (they call it 6P) causes a crash with a message which I haven't encountered before: "Fatal error in mode DRIVE during update within AUDIO_CONSIST_MANAGER". It seems this occurs when a similar locomotive is used as AI comes (I presume) within audio range, i.e. part-way through running a scenario. I can repeatedly recreate this on the current TSC version but all works fine on an older one.

Dovetail Support have been very helpful despite third-party products being outside their remit, and I have passed the matter to Bossman Games for them to look into. As it doesn't seem to occur with other locomotives of theirs I have, it could just be a tiny typo in the scripting. All beyond my little brain, I'm afraid.

All in all, this latest round of "improvements" have turned out to be a bit of a nightmare but it is so useful to have the good ol' 24069 version to hand.

John

 

John, let LogMate.exe -SetLogFilters="All" run in the background. I'd be interested if it throws an error (I have seen some non-critical flagging of audio files in the logs).

 

Thanks, but I tried that - not sure why why but it came up blank. The inverted commas should be omitted, according to Dovetail:
https://dovetailgames.freshdesk.com/support/solutions/articles/80000895937
At any rate my version of Windoze seems to automatically delete them.

Another day perhaps, I've spent enough hours on this for now. Despite having a soft spot for it in real life (that shows my age!) I don't find this particular engine satisfying to drive for a number of reasons, so its out on its ear for now. It is Bossman's problem now, but I'm not expecting a quick answer.

Best regards,

John

 

As I don't have the Patriot, I'm gonna set up a test scenario using the BMG Black 5.

 

Will be interesting to hear how you get on. I substituted their Royal Scot (their previous release) and all went well with that.

Good luck (if that's the right words!) and best regards,

John

 

I reprogrammed the disc signals optimizing the code complexities, everything works now in version 77.6b (x64), if Steam Sounds Supreme is interested, please contact me, as I don't work for free, or wait for DTG to solve their problems by reverting the core coding.

With the new programming optimized, the disc signals work differently and better, green signals where the junctions are connected correctly and not all red as before where it is released by the approach of the train only.

 

So DTG should change their coding as it affects a Third Party Add-on?

 

I think he is trying to say that if you are waiting for DTG to change its coding, its not going to happen.

 

He also expects people to pay for his work as the Signature says Only fools work for free.
By that he is calling anyone who has made Freeware a Fool.