Various Revisions Of The Same Type Of Train In Tsw

After watching the steam tonight, it seems DTG are adjusting the physics to the legacy ECW 377, instead of just porting in the BML 377.

That means we're going to stick with that ugly block text type of PIS for the front display, as well as no side display functionality (was no mention of that coming). No mention of new sounds which the BML features, either. It also means a fix for the passenger interior lighting bleeding into the cab will now need to be made to two separate models.

DTG, why do you struggle so much with consistency? We've already got various revisions of the same train on multiple routes. The GWE and ECW Class 66 for example. Time to bite the bullet and just use one model (if appropriate) for all routes.

Not only is this taking up extra hard drive space, it also means that things like bug fixes and updates will be a lot harder to do as it involves applying it to two separate models, thus limiting consistency as well as keeping things up to date.

 

You can see that especially in german content. We have like 3 or 4 different entities of the BR 143 which is totally needless and just uses drive space for no reasons. Also the Dosto Cab Cars are a more extrem thing here. With the exception of the DRA version with the VVO Livery there is literally 0 reason to have all this different entity versions cluttered in the game. Fusion it into 1 entity. It will make devs work and life much easier since you only need to update 1 entity of a model.

 

Meanwhile the 800 dosto variants we have:



Anyway, I've asked this question before, and it seems the reason is changing the locos requires retesting how it performs with the timetable. So, in your case, if the BML 377 was put on ECW, then any change to the loco would require testing both BML and ECW to make sure the timetable still works. I understand the dev challenges, but this is lazy IMO. It also doesn't seem to have an effect on substitution...

But I wholeheartedly agree, this need to change. It's not only impacting our experience as players (making sure we are selecting the right train, getting the same experience, etc.) but it's also impacting the devs too:
- The expansion pack BR 423 isn't in the LD and creators club liveries for the 423 aren't applied to the expansion pack one.
- Each variant of the dostos gets progressively worse. I swear the original in TSW1 for MSB had A/C interior audio - now it's just silent. I don't much like cab car driving, but I don't even touch the dosto cab car any more.
- IIRC, the 143 in DRA originally selected the wrong/old version in the menu (I think that's been resolved)

 

This post x1000. I remember a past stream with Matt saying that this was intentional as it enabled the game to have some sense of versioning and make changes without affecting past dlcs (each dlc effectively being a game in itself). Fast forward today, and this idea is not just limited to locomotives, but shared scenery and plugin versions (e.g. dispatchers).

Whilst I can understand slightly the case for plugin versioning... duplicating art-assets is a major step backward. Larger install sizes (which they should've forseen with the PS5). It also makes the work to fix legacy versions significantly harder without significant financial motivation to implement the same fix x2/x3/"insert number here" times

 

This is why updating old content is so difficult for DTG, one fix for a route doesn't necessarily work on a different route, it might break something instead. Its a spaghetti junction of code by the sounds of it. Version control would be very useful indeed.

 

Frankly I agree. This is already having a impact with creators club. Honestly it just seems lazy not to make the change. DTG just copy, paste and tweak. Ever since i downloaded Dresden Chemeniz, I got several different versions of a dostos for crying out loud.

I thought DTG had Object Oriented Design. If your gonna make improvements to one loco, those improvements should apply for all the routes the train runs on. Also you wouldn't have to update two models again and again. It shouldn't be Copy, Paste, Tweak only for one route. It makes no sense

 

Why aren’t they listening to the community feedback. It’s like we say something and it basically go out the other side. This is crazy DTG

 

Good point but the devs need to listen to the community by using the BML 377 physics for ECW 377. This also affects the Ruhr Sieg Nord 143 too and if Physics needs to be fixed on that version just copy and paste the Riesa-Dresden version & Dresden Chemnitz version to it. so is the Main Spessart Bahn 146.2 just use Riesa-Dresden version physics for 146.2 Main Spessart Bahn when upgrades are needed

 

If the change was just bringing over the BML 377 to the ECW 377 I fail to see why they'd need to test London again, as that change would (or at least should) only affect ECW. Likewise any major change to the physics of the 377 should really require a test of the route, even if it is the ECW version. Also it's not like they'd truly be the same engine, ECW still needs to be separate for players who don't own BML, so they could still theoretically do a patch for just one version if they needed to. At least when it came to the Talent 2's there was differences between them that didn't make that ideal, but this case really seems like needless busy work.

I know this isn't what DTG are doing, but it almost comes like DTG use OOD just enough to shut people up about it, and that's about it. Yes it's great and all that you started to use the same skybox and passenger systems across multiple routes. But doesn't change the fact that there's a lot of use cases which OOD would clearly be fairly helpful on, but isn't used.

 

DTG does use object-oriented design; we have had this discussion before and the answer is the same. That doesn't preclude having multiple different versions of one locomotive, and there are good reasons, from DTG's perspective, for that to be the case. Changing the skybox does not require rewriting old tutorials (and all of that entails) because now the skybox has one more or fewer fiddly levers. If you think the QA bottleneck is bad as is, attempting to replace an older locomotive model in a DLC automatically with a newer one will lead to a nightmare.

Cheers

 

Thank you for creating this thread london midland.

This is a 100% perfect example of a failed development process. I call it like that because dtgs problem not being capable of upgrading locos in a efficient way to all the other routes the same type of locomotive is using, reaches the customer with the fact, he has to distinguish between them in the entire mess.

The point of creating certain processes in development is to prevent unnessecary costs and loss of time before they occur.

In easy words, things like the 4 car - 3 car substitution and loco upgrades should have been adressed as core priority before tsw even released.

How many hours dtg would save when they can just swap a 3 car unit woth a 4 car unit. The fact they have to create an entire timetable new speaks for it self.

About the upgrade of locos and rolling stock, now with all the addons & dlcs already out good luck with solving that issue. Dtg had a chance to make this from the begin, they didnt and waste a giant amount of time now when it comes to make things easier. And 1 Loco version in technical features would be easier for dtg and for the customers.

Believe it or not, in many factories & production companies this exactly problem existed in other situations. Contracts were not profitable before the first screw got touched because inefficient internal processes.

It was "solved" (adressed) by lean management. This focusses on eliminate the waste on your way from a to b and results in safing money in the end.

Preventing a mess like we have now in tsw goes also in the direction of saving money. (From a dev perspective)

 

Imho it's just too late to do anything. There might be a chance for change with TSW 3, but only if we avoid porting the preserved collection once more.

 

The good thing is that more people are starting to realise this with the creator's club so hopefully there is more pressure to fix this issue.

The most ludicrous example so far is the BR143.

I have 3 completely different BR143 models installed on my xbox right now.

• The one coming with Ruhr Sieg Nord (substitution with the DRA one is possible)
• The one coming with DRA (which subs on all other german routes*)
• The one coming with DCZ, for some reason the DRA one does not sub, so all the liveries made for the DRA one do not work.

Another excellent example is the talent, apart from the RT Talent subbing on DCZ they are all indipendent, and there are 3 distinct models.

This can't go on for much longer. Trains need to get separated from routes for good, and it has to happen before the heat death of the universe.

 

This is one of the biggest issues of TSW2. It's just a mess. 100% agree with this.

 

If you really think about it though. DTG would only have to retest 3 routes. MSB, RSN and East Coastway. Frankly using testing as an excuse is just a notion of pure laziness. Plain and simple. Who really thought at dtg that it was a good idea to make improvements to the 143, 146 and 377 for seperate routes but not the routes in which they originally came from. It would've made more sense to have a base model and any improvements to the base would apply to all the dlc the base originally came from. Yeh you would have to test it, just like how a skybox would be tested, but a player wouldn't have to keep scrolling to find the updated train. This would've also saved dtg some time before the bottleneck. The testing would probably be similar to how they would have to test a loco dlc for a old route.

Why would you have to rewrite old tutorials? The switches and leavers on the ECW 377 is the same as the BML 377. The 143 and 146 is the same situation. Dovetail is the only one to blame for this mess. Frankly they seem to enjoy making messes and this needs to be resolved. Creators club is a prime example of why. It's an unnecessary burden on players and could've been avoided. Testing is just a lazy excuse

 

I hope they don't port preserved routes again. They will just make another mess of things

 

What should of happened from day 1, is DTG should of just took the ECW 377 and made improvements, what I don’t get is why we cannot select the LBN 377 in ECW, like you can with all the other versions of duplicate units across other routes.

The biggest irony of this is that DTG seemingly go out of their way to re-use or make variations of the same train as often as they can.

I can only imagine the issue is related to some deep seated development practice that they aren’t able to work around now.

Unfortunately, this issue is one and the same as most of the other technical issues, DTG just don’t think ahead, and they aren’t taking a modular approach with their rolling stock development.

 

Luckily, if you’re on PC, there’s a mod for this here

 

Better than losing all the DLC you had, anyway this is purely academical, I am fairly sure Matt said there won't be TSW3 for a while.

 

What a terrifying thought!

 

This was acknowledged back in the TSW days (note the lack of 2)
Because rolling stock has to have a base route they're restricted if they then want to include that same stock in a different route. Because everything DTG sells has to work standalone and out of the box they can't just say "We'll use the BML 377 on the ECW" because those people who don't have BML but do have ECW wouldn't have the file structure required on their machines.
This was an issue addressed ages ago when people raised the query, and I believe at the time Matt did say it's something they would have to address somewhen down the line, but the problem now is there's so many assets that would have to be ported and so many timetables would have to be amended and tested that the whole thing would essentially grind to a halt.

So we're going to end up in a similar situation to TSC where upgrading anything in the core, or any asset beyond cosmetic will end up with so many issues and problems that it becomes untenable

Unfortunately this is the problem with working in a closed fashion, where every item needs individual programming and individual testing. If they worked in an open fashion it would bypass all of that, but they don't so that's what we live with...

I'm sure I'm probably oversimplifying somewhere

 

+1000

It's beyond frustrating. Even on the routes where you CAN choose multiple versions, the descriptions give no hint as to which version is the "good" one.

Since this seems to be a year of refining core systems, I hope this is on their roadmap (haha).

 

I can't be the only one but i have not touched the ecw 377 since lbn because I've realised how inaccurate it is with the sounds and PIS display

 

At least, in my opinion, they should add a little icon or description of the route the loco is originated from when selecting for the timetable mode. When I play a new route and have three different BR 143s, I'd like to know which is the newest without having to load in all three and then compare them each time just to figure out which is it.

 

I think what is more important than the slightly higher download size, is the quality difference. I can understand that two dosto cab cars have to be two models if for example a different version of the cabcar is represented (with different interior layout, for example). What I do not understand is why we have the excellent sound of the DRA Talent 2 and the SKA one as well but the RT one is still as it was before. I'm not an expert but how hard can it be to copy the scripts for physics and sounds to a nearly identical train.

 

You and me both. I initially thought we were going to get the upgraded BML 377 in ECW as part of the pres update, but it seems this won’t be the case.

It’s a major step backwards going from the BML 377 to the ECW 377, both in terms of sounds and PIS functionality and visuals.

 

This issue is magnified because the UI in the game makes it either difficult or impossible (depending on the train) to know which version goes with which route.

 

The solution here would be to include as part of the core game an invisible dummy "route," just a placeholder, which serves as the 'depot' for all the rolling stock in the game, and whenever one loads any route then the appropriate rolling stock is summoned from the common motor pool.

In this case, there would only be one 377; both ECW and BML would "summon" it from the pool (not unlike the way routes 'summon' layered locos from their home routes). At the time BML was released, a core update would have silently replaced the older version with the newer one. I am not buying the "tutorial" argument, since I can think of no case where a newer version of a loco has disabled any functionality present in the older one (with the single exception of the fuel filler cap on the Class 66).

 

There's a mod for that.

 

This would also negate the need for loco DLCs to have a home route owned and allow the loco to be used with in Creator Clubs and off the rail, thus increasing sales and ultimately profits.

 

The 66 is what I was thinking of when I wrote that. You're right, there are few other examples I can think of with respect to specific locomotive functionality, except perhaps the DB BR 182 being incompatible with BRD's Dostos (though that is a bit different of an issue).

But there is the other issue of physics. There have been many examples locomotive substitutions or changes that break the timetable due to different physics. That would be the greater issue, thinking about it now. We witnessed how painstaking it was for Adam's crew to remedy that in MSB when they upgraded the DB BR 146.2 physics, and supposedly changing the Class 166 physics would also require redoing GWE's timetable. Ideally, TSW's timetables wouldn't be so fragile and scripted as they are now so that this wouldn't be an issue (better dispatcher, DTG? nudge).

Cheers

 

Yes, the answer to that would be, and should have been all along, using RW timetables rather than constructs built from running AI trains.

 

Couldn't have said it better myself. I can see why changing a train's physics could result in issues, but at the same time it's crazy how fragile the timetable is.

I imagine the solution would be a smarter (or even human - Multiplayer) dispatcher and using REAL timetables with REAL timings so that if you don't reduce a train's acceleration the whole timetable suddenly becomes impossible to follow, not that it has ever stopped a timetable being considered fit for purpose before.

Correct me if I'm wrong but didn't they say that they didn't even have the option to simulate the timetable faster than real time until relatively recently?

 

I'd just wish DTG would actually say why it is they're not bothering to update the 377. I asked several times in the chat on the roadmap stream but was ignored. It's so incredibly frustrating that we need to put up with a poor version of a train that we know can be better, because they've already made it!

To be honest the updated 377 was the only real thing I was looking forward to in the ECW update. If they can't be bothered to change it I'll just stick to driving the 313 on it, which effectively means I'll only be playing on one half of the route on services to Seaford and Lewes.

 

creating timetables to follow AI trains is just backwards. The AI shuold run to the timetable not the other way around.

The AI needs serious work IMO, it doesnt follow PZB or in some cases even maximum speeds of locos it seems, so many times on German routes Ive been over taken by an AI train whilst doing 60km just for the AI train to come to an abrupt stop at a red signal.

 

I wonder why they don't use real world timetables?

 

Because AI trains use a simplified version of Simugraph and therefore dont fall under the player experienced circumstances as of using PZB etc. Iirc there is an ini command that enables the AI to run the full simugraph like the player BUT it has severe consequences as tanked FPS since Simugraph is CPU-heavy. In the CSX Heavy Haul beta, the AI had the full Simugraph and the FPS were a mess back then. Also you would see a lot more AI running into spads since they brake too late or the AI isnt programmed to follow the "full" physics and simugraph stuff. So there are several good reasons for the AI not running under full physics.

Why dont they use real world timetables? Because sometimes they either dont have them available OR they are too heavy on the dispatcher, e.g. Bakerloo and LIRR. I dont mind DTG taking artistic freedom as long as the timetable feels realistic (dont mistake it with "like reality").

 

I imagine real life timetables also take longer to implement and are far more research intensive. With AI centred timetables you just get the start times and click go (I have no idea how it actually works but that's my simpleton's assumption at least).

 

Exactly, the a.i. uses simplified physics. So the thing with the "timetable retesting" sounds more of an excuse to cover the fact, that the locos are programmed in a way to cause problems when upgrading with scenarios and archievments, and all stuff is related to the single contained dlc.

DTG, to me this looks like you bought a car and didnt think about the fuel. Its a huge mess and extreme time consuming to find the "updated" version im looking for, when making a scenario.

 

Even if they can't get actual timetables it still doesn't excuse the way they've implemented them. It doesn't take rocket science to know giving Class 101's only a minute of tolerance on a 80's schedule is not even slightly realistic. Even if you can't get actual timetables you can still make educated guesses as to how much leniency they had in real life. And barring some Japanese trains pretty much no real network has the tight schedules the AI tends to make.

 

Personally I don't like this whole "it's a different unit as you can see by the window seals" that we've seen before .

I never think to myself let's buy it straight away on that basis

 

Just a note to vocalise my disappointment in hope 'another person' helps raise the profile of the issue. It's so frustrating that we are unable to get the best versions of rolling stock on routes which should use them.

Sadly, I fear that the likely solution will be just to simply not change, improve or bug fix rolling stock in future.

 

This was the suggested method previously (and indeed is basically how TSC works, by having a completely separate repository for assets than routes) but Matt said years ago TSW wasn't configured for that.
It seems that there were design choices made (either by DTG or because of restrictions of UE used back then) which have caused snowballing dev issues even years further on

It's crazy how fragile the signalling system is. The timetable shouldn't actually have that much of an impact. If the signalling worked as it should (ie the signals guide the trains not the other way round) then there wouldn't be an issue at all. One train being delayed wouldn't then crash the whole system out

I can see why AI may not run at the same physics as a player would but there should surely be a better way of setting up an AI rather than "full speed" or "full brakes" and nothing else, some form of "25% brakes from half a mile out" or something similar would be better than what we have now. And there's no reason why AI should SPAD IF the physics and track limits are set correctly. I don't ever see a train stopped at 1m before a signal for example, so AI should always be stopping say 10m before the signal...? Add in the braking dynamic above and it would be "truer", even if full "true" would cause issues

If the timetables are recent or even realworld now in the UK then network rail provides an API so DTG could literally download the whole UK network timetable without lifting a finger (It's how RTT gets their data). So long as the route pathing in TSW can be setup either the same or via a transform getting live timetables would take one day and a few days data processing.

 

I'm not an expert on timetables, but this I feel is also foresight into how irl dispatching works. Each locomotive has a set time per stop, but trains don't always follow this. It might be a busy urban line like Bakerloo where doors are only really open for 15 secs tops, or it could be WSL where trains could stand for a few minutes. To make it worse, trains are suspect to either environmental conditions or a human "lag time". So in this case, dovetail are only testing timetables to locomotives that

a) Do not account for subtle variations in dispatch
b) Do not account for human response times and/or pre-cautionary actions e.g. slowing down as a pre-caution to a yellow.

So to make a particular timetable dependent on a single "version" of a locomotive was never going to go down well, and there are now a few timetables that are near impossible to keep to time to.

 

IIRC, the difference is that in TSC, locos exist as their own entities independent of any route, but that can't be done in TSW because either UE or consoles (can't remember which) won't allow locos to exist on their own like that, they have to be "children" of a route. What I am suggesting is instead of the current system, to create one parent route for all rolling stock, a dummy container with no actual landscape or track, but which can replace the parental role currently taken up by individual routes.

 

Why is preserved content getting updates when I thought the original intention of it being 'preserved' was to keep the features the same as was present in TSW2020?

 

Yeah, roundabout what I was saying. I don't know whether thats a situation that's still in place though, and as I say they've dug themselves a hole (or found themselves in one)

The preserved crew had two mandates. Bring over the TSW content to TSW2 and then to bring those routes up to TSW2 spec. Unfortunately TSW2 spec is a moving goalpoast and every time they bring something new in it seems to break something old

 

Sometimes it seems like DTG are chasing their own tails with updates and bug fixes

 

This is one of the main "issues" with rolling dev, people want all the latest toys on all their routes and locos, but obviously where newer routes and locos are built in a more robust way (one would hope) this often means that old tech doesn't mesh well with new.

 

All I can say is that SimRail is just around the corner. They released a Devlog update today about the final graphics engine. It´s on Steam if you want to check it out.
Maybe it´s time to catch the next train...