When they release TSW 7, they better have the core and bugs fixing on all routes honestly. The more I see problems on each routes I play, the more I’m being disinterested on playing TSW moving forward. They can’t keep doing this honestly. We pay for contents that are not up to standards and we keep playing routes that are not done correctly and leaving out routes that are not done or being fixed for patches. Honestly DTG they have to understand that when we play these routes and contents, we just want a good routes with good quality not BS undone products that brings with bugs and mismatched components that are within the routes that we buy. We just about had it
We are talking about Dovetail here. The Direct will be another stage managed PR event. The people at the top of the company and their philosophies are the same. The people running the “Trains” department and their philosophies are the same. So lip service might be paid to the major issues but fundamentally nothing will change, unless they are planning to bury TSW and bring forth an entirely new train game.
DTG seem to be picking up the pace on bug-fixes, but it is still slow. I am fairly sanguine about TSW, as I have an iron rule to only buy content that's 80% or more discounted. I am therefore a bit more accepting of faults than full-price players.
They have issued quite a few fixes recently. Maybe not enough or quick enough in some cases, the "DTG never fix anything" crowd are just factually incorrect.
I was impressed by your point. I also feel like I wasted my money by buying it right when it was released. I had high hopes that things would be different this time, but not only were the issues left unfixed, there’s been absolutely no word from the developers. With this series, the Steam reviews get reset every time a new annual installment comes out, you know? And depending on the specific route, the actual gameplay doesn't really change all that much. I think I was somewhat misled by that.
I'm just speculating here, but as someone who has some in depth knowledge about how this sim was coded (from my own modding and coding work) - I'm going to throw this out here and let you digest it as you will: When they made the switch to TSW from TSC and created the new architecture on UE4 I think they were really in over their heads. You can see it in the code, you can see it in how features were layered on top of broken code. You can see it in the final product. Had they scoped this out during the development of CSX Heavy Haul and build a proper foundation (game logic, systems, etc) and hired proper UE developers as opposed to an inhouse team from their previous TSC devs, then maybe MAYBE we would be having different conversations today. I don't believe they did, and instead we have a luxury apartment built on quicksand. It is what it is. At this point, now almost a decade since CSX Heavy Haul, the bugs and bad code are deep in the machine and will never be repaired. Keep dreaming.
If you are indeed correct, then I fear this is why issues such as stuttering and sound squelching or better save game with more slots will never become a reality. They just don't know how to do it!
Of course, we also need to consider Fishing Sim World (which I believe was their testbed for UE4). They made that game so that they could learn the expertise needed to create Train Sim World. Also, didn't Matt once say that while they did make a few mistakes, they also got a lot of things right early on in development? Or am I just misremembering/delusional?
Pretty sure he did. I also don't think it's very reasonable to say that DTG should have somehow known what the game would look like 10 years later and built the initial core with that in mind. That's like saying it's a poor author who can't write their novel in one draft start to finish.
I see. So the developer has quite a history behind them. Ideally, things would change for the better, wouldn't they? A few years ago, on a London commuter line—I think it was a station starting with "T," located two or three stops before East Croydon on the Victoria side; specifically, the platform used by Brighton-bound trains on the local line—I encountered a bug. A kind person on a forum actually sent me a ticket for it, but to this day, it still hasn't been fixed. The bug involves a departure signal—something absolutely essential for a station—being completely missing. (In reality, it's hidden from view, enclosed by the brick station building.) The solution? Just knock down the wall. But they simply won't do it. As for the developer... If an acquaintance asks for a recommendation, I’m honest about the fact that it’s a bit of a mixed bag. (You have to decide if you can accept that bug fixes are slow—or ignored—compared to other games, and realize that reviews aren't always reliable.)
It's a poor author who has a story idea and then doesn't map out the arcs and the characters before they start. Case in point, SimuGraph is a systems sim, not a train sim. It's genuinely good at what it does, and you can model a Class 66's brake plumbing valve by valve, but all that lives inside one locomotive. The bit where fifty cars push and pull each other is handled by Bullet, and DTG have said as much themselves: Bullet is a general purpose rigid body solver. It's iterative, so a force applied at the head end takes many passes to reach the rear, and it never quite gets there in one tick. What you get is mush. And slack is tiny, an inch or two of free travel per coupling. UE4 runs floats in world space, so 20km down the route you've got maybe 2mm of precision, a few percent of the thing you're trying to simulate, and it gets worse the further you drive. Physics ticks at 60Hz, so a car can eat its entire free slack between two frames. You cannot simulate a run in you never sampled. And that's why they build UK and European passenger routes, where trains are short, consists are fixed, and slack is basically zero. Nobody's asking them to model a hundred car drag with six feet of slack in it, traversing the grades of the Rocky Mountains. They allocated their engineering where their market is. Fair enough. But they've limited what can be achieved with long consists, simply because they limited their design choices in the beginning (incompetence?) and the architecture they built means it can't just be bolted on later. You'd have to rip out the foundation. Signals are the same story in a different hat. There's no unified signalling engine underneath, nothing route-agnostic that models blocks and interlocking and derives every aspect from what's actually occupying the track. It's authored per route, signal by signal, region by region, and it behaves like it. What you read off a signal isn't the output of a simulation, it's a prop that's been scripted to display something. Usually close enough. When it isn't, there's nothing beneath it to catch the error. Drive one and the seams show. The game barely knows a signal exists until you're on top of it: pass one and it reports nothing at all until the next gets into range. The upcoming-signal feed thins out or thickens depending on the country because it counts main signals and quietly skips repeaters and distants. And you'll get sequences that can't physically happen, a green right in front of you and a red five kilometres out with clear track and no distant between them, which in Ks signalling is a flat contradiction, because a proceed aspect is a promise about the next signal. You want examples, take a look at my screenshots. It's an overlay, i'm coding in Electron. It uses httpapi and lua calls through UE4SS, you can see the blank signal aspects in a live session in action. This bug kept repeating and repeating and I couldn't source it, until I realized the game itself doesn't hold a continuous picture of the signals ahead. It only reports a signal when there's one within about 4km, and the moment you pass one it reports nothing until the next comes into range. On a route where signals are spaced a kilometre or more apart, that's a long stretch of the game telling my overlay there's simply no signal out there. The overlay wasn't dropping the aspect, the game was. And the "distant" signal the API hands you is worse: it's a hollow slot, no position and no ID behind it, so there's nothing real to read even when it shows up. So, you decide. I mean I see a lot, and I mean A LOT of copium on these forums by people who don't have a clue how to code a simple html page let alone an entire complex simulation in an advanced graphics engine, asking for absolutely ridiculous features to be added to a base game that simply can't handle it. It's not the frame its the foundation thats broken. Moreover, as the post I am responding to shows - there is a certain "base" to this community that refuses, either out of loyalty or blind trust - to criticize this development team for its failings. But what do I know, cue up tsw7 and open your wallets.
Thats why I think they will never fix the blurry texture issue because the base code is so messed up at this point it would take a complete rework of the base game to fix it. And at that point might as well just start development on the next iteration and band aid what we can for this one.
Yes, but will the next "iteration" suffer from the same symptoms as this iteration? If the level of fidelity was this poor in UE4 with this team, what should we expect in a far more complex engine like ue5? I'll do you one better, UE6 is early access in 2027 - UE5.8 was the last major update for this build. Why would they release on ue5 when ue6 is around the corner, with full MCP integration? I think it will be at least 4 years until you see a new engine, and by that time some enterprising individual (cough, cough) will cash out 50k from their investment portfolio and start crowd sourcing a legitimate train sim, with the systems and logic fidelity that we see across the top tier fligh sim payware scene.
twobuss#1580 How would you say the underlying core of TSC compares with TSW. Yes, I know it's a lot older and doesn't do some things well, but I always feel it was more holistically designed, even if its scope was more limited.
I think for its time, it was very good. I spent countless hours making timetables and messing around in the editor. It was a frustrating experience, and what I take from it is that the poor engineering and architecture from that sim was used as a blueprint for this one. I think these guys at DTG get a lot of heat, and probably rightfully so for a lot of the criticism, but don't forget what they have accomplished here is impressive, but it's - in my opinion, a lot like Pimp My Ride. You've got this awesome looking car that has all these visually appealing bells and whistles, but they never actually bothered to you know, fix the engine, the transmission or the chassis. Its just a pretty shell on a disappointing core. And to be fair I'm going to walk back part of my criticism in my previous post, I actually have spent the better part of the evening trying to implement a solid signal display system on my overlay (german signalling was throwing me) There IS a real signalling system under the hood, and it's more serious than I gave it credit for. I just uncovered this tonight, signals are three layers: a data "model" that holds the signal's true aspect, a "view" that places it in the world, and the head with the actual lamps. A dispatcher assigns routes, the model picks the correct aspect from a catalog of 800-plus defined aspect types, and that feeds the head you see. And it's genuinely per-region as in, German Ks, the US Northeast Corridor and NJ Transit each ship their own aspect vocabulary. This was tested on three different routes in each region: I could pull the exact aspect each signal was showing, live and by its real internal name, the German "Hp0" stop, the NEC and Morristown stop aspects; updating in real time as they changed. Describing it as a "prop" was wrong and I'll own up to that. However, what keeps my broader point alive, though: the game surfaces almost none of this. The official data feed collapses that 800-aspect richness down to three buckets: clear, approach, stop. The detail's all there in the engine; it just never reaches the player or any external tool.
