Why Does Dtg Intentionally Delay Updates/fixes/patches?

It doesn't matter whether or not QA is free from cost. QA is necessary.

DTG no longer need to Rush Hout releases - they have cash in surplus. They can now do the necessary QA, if they choose to. (Even after the event for the old DLCs, under "Preservation"). They can now invest to save", and indeed, "invest to earn more cash".

NB: I am sure that they actually do flirt with the idea of doing some QA. It's just that whatever they do, it isn't effective.

In my opinion, all they really need to do is have a structured process for their QA. As a minimum, they could write some check-lists. And they absolutely should have a solid gate review that prevents product release without basic checks taking place, like testing the first ten minutes of play on each platform, in the shipping build, before they release for sale.

It would be nice for those on console if they did any testing or QA at all, of the shipping build, on console. And that includes third-party contributions. Run it through the DevKit for Cisco's sake...! (Oh, and maybe do it under "game memory" emulation - not with the full power of the DevKit.......). That would be nice for the customers.

But... I'd go further - in fact - forget the customers for a second..... I feel really sorry for:

- the talented Devs and Artists that are forced to release their work before it is finished, meaning that they can't take pride in their hard work;
- the Marketing guys that are made complete fools of when incomplete DLCs are streamed live on the internet in a broken state; and.....,

- the Finance guys that suffer in the long-term from less money appearing on their future balance sheets, making their future performance appear less good, and maybe impacting on their future bonuses, even if they don't yet know that:

More QA = More Money

 

I’ve suggested before that Dtg should run it’s own server for patches.
Don’t know if such would work for consoles, not having one.

No delay, no having to schedule, immediate quick fixes, happier forums etc..
Plus they have software engineers who could run it.
What’s not to like?

 

I guess the second party who made hs1 never used ue4 tools before

 

Also when players are spending $20-$30 on dlc's you would expect the money to go to these departments. Everything costs money to run and DTG are not short on cash either and in the U.K small video game companies under the Video Games Tax Relief (VGTR) can qualify for tax credits and exemptions so small companies like dtg don't have to pay so much in taxes which I personally think is a great thing to do.

The QA team at dtg is mainly there to see if the product works even if it has bugs. So for example if you can drive this service from a to b then it's good to go. QC is technically supposed to be the ones to make sure bugs aren't there before it goes to QA but luckily this process is changing because it seems that anything can get approved by QA and that QA had no sort standards as to what would be an acceptable release hence why some products seem to get released with the assumption that it wasn't properly tested like lirr for tsw2. The worst part is that we have to wait several months for an update to come out which isn't acceptable. It just doesn't make sense for products to be released with clear as day bugs and there has to be a more strict standard as to what is acceptable for release and what is not. LIRR shouldn't have been released until the bugs were fixed.

 

Still waiting for the Bakerloo Trademarks on Console since over 6 Months or the missing Sun.

 

The sun is still missing. Is that a PlayStation thing because on Xbox the sun is there

 

It might be a draw distance issue, especially since TSW is supposedly at 1:1 scale*, and the sun is quite far away IRL....... ;-p

(gah, I have waited ages for another chance to get that joke in.... ;-) )

[*although technically, I suspect it is actually at 1:1.6 scale......(except for the sun bit) ]

 

I don’t see the Sun on Xbox Series S/X.
The Heaven with the clouds looks also really strange and plastic.

 

Yeh the clouds look very plastic like. They don't have that puffy look to them

 

A few minutes??????????

 

I don't think he meant that literally

 

Ah yeah, I see what you mean. That sort of investment in testing and patching might not be economically viable...... It took me nearly ten minutes to reproduce the bug that you described, and that was without using a Dev build or any de-bugging tools, or any direct insight into how the braking systems were flow-charted in SimuGraph.

There is a possible fix that would take a few minutes to put in that would fix the base problem, but it would take a few minutes more to tweak the range of MR values that trigger the compressor to switch back on, and test it, to deal with your specific issue.

So, how many minutes/seconds do you think DTG should put into fixing the Bakerloo Line issue that you raised? And - to bring this fully back onto topic.... and if you still do think the "power loss" issue should actually be fixed.....

How long do you think it would be reasonable to wait for it to be fixed.....?

.....and if they do fix it....

.......How long should you wait for the patch to be delivered, after it has been fixed?

What's the total wait time, that you would be happy with, since it was first reported to DTG....?

[EDITED to be a bit more helpful than originally posted]

 

I'm sad that you're not expecting thanks after doing all that. As my real life thing I work at the beginning of the software lifecycle doing the architecture for a product to make sure it sits in the landscape where it belongs and connects to whatever it needs to connect to. I thank people for finding problems in my architecture before, during and after development all the time. I recognise that these people just want something better, they're not rubbing my nose in my mistakes. It makes them happy that I thank them for the efforts they've put in or for putting an idea forward. Happy application consumers are allies for the next project when you are asking your business for money.

Paul

 

Oh - don't be sad! This often happens when you help people that shout the loudest about things (*takes a quick glance in the miror...* ;-) ). When their problem is solved, they then have one less thing to shout about, and instead of thanks you just get resentment (which is the appropriate response, from their perspective, because you have taken something away from them that they value, when you help them). It's a shame. But it is to be expected - it's the modern world, and it is the world that most people currently seem to want.

Your method of constructive collaboration has always worked best in my professional line of work, if you want to end up with a quality and effective finished product. In the past I have had to actively encourage people to find holes/gaps in my work (a lot of my colleagues do not like criticism of their work, so they often don't easily offer criticism to others...). However, if I am openly publishing materials for general consumption, then I do want it to be right first time, because it can literally save years (and sometimes decades) of work if you get it right first time, at the right time - and sometimes the right opportunity might never happen again, if you fail. So, anyone that finds errors in my work (or opportunities to improve it) gets my immense thanks, whatever their motivation. An added benefit with this is that contributors (and non-contributors) can't then be critical of the final product - they absolutely get their fair chance to take a swing. ;-)

Back to topic - I think it would be very useful if DTG published a Service Standard for fixing bugs, and providing patches/fixes. It needn't be a particularly difficult standard or timescale to meet - but it should be something that puts a line in the sand - a target, if you will....?

 

Some sort of standard to fixing bugs prior to release sounds like a good idea or a more stricter qa process

 

I believe they said that the QA team approved SEHS because it was working as intended. The backlash wasn't once it was released because it was buggy, but because it didn't look right on the stream, fences etc. So the QA team weren't really to blame for that as it was a design decision that backfired. You might believe they should be checking realism etc and that is fine, but its a different debate.

What they were responsible for was making sure the big hole by the tunnel wasn't there when it did get released, although it obviously made it into the stream!

 

This was a big fail on the people responsible for quality control (separate to quality assurance) as they were the people that approved the route as being appropriate.

Also, some tunnels still don’t function properly. Why is it fine when I drive the 465 but when I drive the 375 there is a weird blue light throughout?

 

With a massive batch of patches going in today for me for TSW (2020) and TSW 2 on both PS4 and PC, my internet, PS4 and PC are completely tied up for quite a while this afternoon.... ;-O

Mind you, the RT+182 and LIRR+M3 patches for TSW 2 do look quite significant - this is a tremendous amount of work that they've done....:

https://forums.dovetailgames.com/threads/train-sim-world-update-11th-may.40099/#post-309716

 

I certainly appreciate synthetic.angel's work on the Bakerloo bug, which represents a breakthrough and apparently has pointed DTG in the right direction towards fixing it.. I guess a patch may eventually turn up. I do appreciate it.

However, SA, debugging can take time. Often a LOT of time. Even if finding a bug is relatively quick, figuring out why it's happening, and then fixing it without breaking something else, can take a very long time. Every software company on the planet, of necessity, is subject to the law of diminishing returns: pulling numbers out of a hat, it takes 90% of the available time to find and fix 90% of the bugs, and the other 90% of the time to repair the remaining 10%. And all of it = programmer time = money. No sw publisher, anywhere, operates on a 100% perfection standard because, even if attainable, the cost and delay would be fiscally unfeasible.

-----------------------
I should also point out the difference between QA and QC: QA's job is to make sure it works: that pushing the throttle makes the train go, that driving onto a bridge doesn't mean falling through the world. They aren't there to check for aesthetic matters. Poor sound, missing fences and wrong-size headlights are a matter for QC and beta, not QA.

 

So, earlier on, when I suggested a Service Standard for fixing reported bugs (significant ones - like the ones where the DLC becomes "completely unplayable"...).... the idea that a fix "may eventually turn up" is not quite what I was thinking of. I was thinking of a number, like.... 75. Or six. Or ten.

Maybe "eventually" is okay with you, but here are a couple of other (significant) examples that stand out to me, which would have become "never" if people had not continuously pushed for the fixes:

- Cement Circle in TSW 2020 - nearly a year to deploy the fix (which was well known and defined)
- DB BR 155 on RSN (in tunnels) - nearly two years to fix the sound issue (on PS4)

Funnily enough - the Bakerloo Line 72 Stock bug (and it is a serious bug) never affected me because of my driving style (whether it is good driving or not.....). But I think that bug still should have been identified (within ten minutes) and fixed within three months. I (now) think people started reporting it immediately after TSW 2 released, so maybe it should have been hot-fixed within one week of this major TSW 2 release - but it is now nearly a year.....? Is that okay with you?

Would you be okay for it to be fixed in say, three years from now? Or four...? Just how long is "eventually", in the context of a bug that makes a DLC "completely unplayable" (using your words).....?

Can you give a number - a target time - a month, three months, a year, five years...?

 

Well, the topic has shifted a bit from what it was. Then we were talking about 100% bug-free releases, the effective impossibility of which I was addressing.

Patch timing is another matter, and here I think we are much closer to agreement. Yes, it is MUCH too long. I think DTG do need to re-assess the structural matter of human-resource allocation, where at present they have a team of just four people responsible for the post-release debugging of everything in the TSW universe. And this is an area where it is indeed costing them money, because I am just one of many players who have commented on Steam or these forums that they simply will not buy DLC X until it gets fixed. Adam's team is not in fact a non-revenue activity.

(DTG might look at an example from real-world railroading: a major reason EMD so completely dominated the US locomotive market from the 40s through the 70s was because they offered tremendous post-purchase customer support)

 

Okay - so how long a wait would you think is both satisfactory and reasonable, for your Bakerloo Line bug report to be addressed in a patch.....? How long would it take for you to thing "Hmmm... that's a bit too long, now...!".....?

Oh, and have you had feedback from DTG? You said that my bug reproduction notes had given them a pointer - did they say this to you?

 

90 days

Yes

 

I've been involved in the software industry for over 30 years. Technology has changed. The pace of development has changed. But one thing has not, commercial viability requires harsh choices. There is no economic benefit from trying to find and squash every single bug. Everyone follows the 80/20 rule. Test the things that are most important and used 80% of the time. The last 20% might get touched briefly or it might not get looked at during a test cycle. In a complex system like a game even with automated and robotic testing it would take literally years if not decades to test every possible combination of factors that could influence game play. The amount you test is governed by the ISO Software standards. Software is set with a criticality from 1 to 4. 4 is reserved for things like auto pilots and nuclear power stations. 4 gets the highest degree of testing where everything gets a pass through. Yet planes still crash and nuclear power stations still go boom. Game software could rate a 2 on the scale but only because of the mental anguish from playing for hours only to lose your progress otherwise I'm afraid it would be 1 (no useful purpose).

Paul

 

The bottom line is that TSW has more bugs than any other game that I have ever paid for ... It wouldn't be such a big deal if DTG had a track record of fixing them in a timely fashion, but they don't do that either.

I'm not expecting perfection, but they aren't even meeting the standard set by other developers.

 

I’m guessing you didn’t buy Cyberpunk 2077, or that you’ve ever played a Battlefield or Bethesda game at launch

 

I agree with all of this - and ultimately, Train Sim World is a leisure pursuit conducted from the safety of your own home (although, as it happens, most accidents that involve injuries occur in the home....). I have some expertise in safety critical systems (railways, and beyond....), and you obviously do not need to control risk in hazardous industries/processes in the same way with a computer game. But... that said.... it will be very interesting to see how SimRail turns out - because that is being made by a company that does make train driving simulations as part of (what I would argue) is a real safety critical system (train driver training). My guess - and it is a guess - is that it will be stunningly free from bugs.... but then again, so far, their real train simulator software has only been tested in a fairly closed system.... They are taking a massive reputational risk (for their real world market) by making a train simulator game - so I reckon they'll square it off nicely.

For me, the thing that I find most disappointing about TS 2012 and Train Sim World is that poor design and critical bugs become apparent to anyone that tries the software for the first time, and within minutes of playing. And this often occurs in the featured primary content, like scenarios. And this is often demonstrated live on the internet, streamed by the people that are responsible for making and marketing the products. That could be the WCML DLC for TS 2012, or SHS for TSW 2... etc... it seems to happen almost every time...

And I then find it difficult to understand how those with the insight and tools to debug the software often can't pin down intermittently reported bugs, despite there (often) being easily enough information to track then down very quickly (confirm they exist.... takes me ten minutes), and then isolate them (can take me a couple of hours for complex ones, with no special tools available to me).

And then I find it difficult to understand why it can take two years for work to commence to fix known bugs that make DLCs genuinely completely unplayable (as was the case with the DB BR 155 on PS4).

But the (strict) topic in this thread, as described in the OP, is the intentional delay to deliver fixes that have already been produced. An added delay. And this is where I fear that the 90 day benchmark set by solicitr will be severely breached (by an order of magnitude), because the Bakerloo Line might not get another turn for "Preservation" review for another three years (say, 1000 days...). It could be years before the next batch of fixes are deployed, and that is even if the Bakerloo Line issue gets back onto the (bizarrely specific, and not very strategic) "Roadmap". It might be longer than three years - because the standard being deployed currently is, indeed the "eventually" standard, as can be seen by this comment here:

https://forums.dovetailgames.com/threads/fix-it.33934/page-5#post-310047

I do not think that DTG is contractually bound to fix game breaking bugs according to the "eventually" timescale (that seems to be so popular with some) especially when they are bugs that break software that previously worked.

 

There is plenty of truth there synthetic.angel although I should put out I've crashed my share of real train simulators (the software, not the train!).