A Sad End to an Epic Run for Me with Trainz.

[pware]

Don't forget the many, many thousands of Trainz users who agree with me but don't read these forums

It is all very easy when you are not the CEO/owner/manager of a small software company with a single niche product. Who do you listen to?

I encourage everyone to post about the problems they are having with Trainz, the things that they would like to see fixed (and I have a few items in a list of my own), the new features that they would like to see added (there is a survey page at https://roadmap.trainzsimulator.com/tabs/2-planned and a forum thread at https://forums.auran.com/threads/trainz-roadmap.180101/). Unfortunately not every issue can be fixed or every suggested new feature implemented - I doubt even M$ could do that (there are bugs in MS Excel, for example, that go back to the earliest days that will never be fixed because "the fix" will break many current spreadsheets). So it becomes a matter of priorities - new features bring in new customers while issuing SP/HF updates to fix old issues cost money/time/resources but do not necessarily generate new sales. It is new sales that pay the wages, rent and keep the product on the market.

My opinions.

 

[Kaufantrainz]

haven't had any problems with Trainz plus until sp5 (version number 5.6). Still love trainz and will never let it go.

 

[blueodessey]

This is the exact reason why so many of us have stayed with TRS19 and won't have a bar of the later SP versions of TRS22 in any shape or form.

Well said Lady Kotanga, I too have TRS2019 PE and to this day,, yesterday, I have several Routes that do not play well on 22 Platform, so I delete them, and do a reinstall on 19.

Even better yet, I did keep all my old Rte's etc on 19, with a good off site bk-up to boot.

And this is for the newbies, when you migrate a Route in 19 to 22,,, make changes, you cannot revert to my knowledge, backwards compatible from 22 version into 19.

Peace

 

[pware]

Route in 19 to 22,,, make changes, you cannot revert to my knowledge, backwards compatible from 22 version into 19.

Correct. TRS19 SP5, which has a maximum allowed asset build number of 5.0, will not load any assets (e.g. routes/sessions) built or saved using TRS22 (Trainz Plus) SP1 (asset build 5.1) to TRS22 (Trainz Plus) SP5 (asset build 5.6).

 

[AdvancedApproach]

Don't forget the many, many thousands of Trainz users who agree with me but don't read these forums

It is all very easy when you are not the CEO/owner/manager of a small software company with a single niche product. Who do you listen to?

I encourage everyone to post about the problems they are having with Trainz, the things that they would like to see fixed (and I have a few items in a list of my own), the new features that they would like to see added (there is a survey page at https://roadmap.trainzsimulator.com/tabs/2-planned and a forum thread at https://forums.auran.com/threads/trainz-roadmap.180101/). Unfortunately not every issue can be fixed or every suggested new feature implemented - I doubt even M$ could do that (there are bugs in MS Excel, for example, that go back to the earliest days that will never be fixed because "the fix" will break many current spreadsheets). So it becomes a matter of priorities - new features bring in new customers while issuing SP/HF updates to fix old issues cost money/time/resources but do not necessarily generate new sales. It is new sales that pay the wages, rent and keep the product on the market.

My opinions.

It costs money to create and implement the new features too, you know. While that might bring in new customers, improving your products will help retain current customers. They too are considered new sales when they by a newer version of the product due to its reliability and new features that don't cause trouble with current/older ones. Old customers also help pay the wages, rent and keeping the product in whatever market it occupies. In fact many new customers come there due to old one raving about how good it is. Word of the mouth and positive ratings help out a lot. How do you think new customers come about? It's not all about showing new features. It's also about marketing the current or older ones and how reliable they are. Moreover show how new features give greater operational reliability or enhance older ones. Just some food for thought.

 

[martinvk]

Anyone remember the puzzle game that they once played in advance of a new Trainz? Every so often a new piece of the puzzle was revealed and we had to guess what it was all leading up to.
Seems to me that all the changes we've seen which seem random and unconnected might actually be part and parcel of a bigger thing, might even be required in order to pull it off. Without inside knowledge, we'll just have to wait and see.

 

[blueodessey]

My daughter is skilled at writing code and was a consultant software trouble shooter for a while until the stress of the job made her toss it away. Bone head management who haven't a clue about computer coding and want everything done instantly are the bane of good well written code. She often told me that she could not believe how much some businesses had paid for a load of utter garbage that was never tested properly and was as buggy as hell.
She still does some code trouble shooting from time to time for friends who are Indie gaming developers. In her opinion there's no excuse for using your customer base to find problems with software that was pushed out the door in too much of a hurry. Some of you have said that the problems with SP5 were easily resolved, - well lucky old you for knowing how to do that. For other folk who lacked such skills it was a horror show and brought them to the edge of binning Trainz and walking away from it forever.

Ally Oop Lady Kotanga,

You have much to be proud of, not everyone can Write Code, that is so cool. Sad that it caused your Daughter to have leave. We need more people like her dedicated to Job well done, and Done right!

I worked with one Software Coder, young lady, who was great help to me, we worked different Company's One day after working together for 3 yrs or so, she came and told me, she would be leaving her Company, for similar reasons as your Daughter. Off to better working conditions.

Historically I unfortunately have had to deal with DOS 2.0 (BW) Before Windows, and all the Windows issues, in my 20 some or more years of IT when I was working for a large entity.

All of us Software admins said the same thing with Windows and in house software Creators who could not finish their work with the Scale of Time for Projects they dealt with.


And then there is Greed.

Then there is AI that is scary for me.

But I will get off my Soap Box, and just hope things improve.


Bid you a nice evening Lady Kotanga

 

[pware]

Just some food for thought.

We clearly eat at different restaurants.

 

[AdvancedApproach]

We clearly eat at different restaurants.

My restaurant is clearly superior. With that in mind I'd like to offer a fix since you brought up how you want users to voice what they want fixed here's one thing EVERYONE would like seeing repaired. The tracks are bugged due to SP5. So now any trackside items you want to add the game claims incompatible spline. Now there's a fix for that but we shouldn't have to go through the inconvenience of reverting built-in tracks to original or deleting and reinstalling DLS or third party tracks. Service Packs as I've stated before are supposed to fix bugs not create them.

 

[martinvk]

We clearly eat at different restaurants.

Some go for à la carte while other like table d'hôte.

 

[pware]

Service Packs as I've stated before are supposed to fix bugs not create them.

Make sure that you also tell that to Microsoft, Apple, Adobe, etc who all have a history of SPs requiring HFs and more SPs.

Its good that you have pointed out the "Incompatible Spline" problem with SP5 tracks. I have certainly experienced that issue myself. If you have been following the threads by @n3v_laurence in the Trainz TRS22 & Trainz Plus beta forum, then you would see the testing that is going on with the help of beta testers, myself included. It is a slow process but preferable to a "rushed job" which would almost certainly contain more bugs. Software development is far from an exact science.

 

[KotangaGirl]

I worked with one Software Coder, young lady, who was great help to me, we worked different Company's One day after working together for 3 yrs or so, she came and told me, she would be leaving her Company, for similar reasons as your Daughter. Off to better working conditions.

The software industry chews up good code writers so it's no surprise that nobody seems able to write bug free code anymore.

A pleasant evening to you as well Blue.

 

[pware]

nobody seems able to write bug free code anymore

Unless you are referring to small code segments (usually 100 lines or less), then "bug free" has never existed. The British mathematician, Alan Turing, predicted back as far as the late 1940s (before the digital revolution) that it was impossible to predict if a sequence of computer code would terminate or run indefinitely. You cannot mathematically analyse a normal sequence of computer code to determine if it contains bugs.

 

[KotangaGirl]

Unless you are referring to small code segments (usually 100 lines or less), then "bug free" has never existed. The British mathematician, Alan Turing, predicted back as far as the late 1940s (before the digital revolution) that it was impossible to predict if a sequence of computer code would terminate or run indefinitely. You cannot mathematically analyse a normal sequence of computer code to determine if it contains bugs.

I'm talking about real world coding like my daughter writes for her Indie gaming friends. I don't know how many lines that is, but it certainly fills up her computer screens when she's working on it.

 

[pware]

I'm talking about real world coding

Whether your coding is for the control system for a nuclear reactor or for a computer game, the same principles apply. But obviously the effects of bugs can be far more serious in one of those two examples.

It has, in the past, been stated in these forums that Auran/N3V should never release any new version, patch or update unless it has been thoroughly tested and is totally free of bugs. If that was the case then no version of Trainz (or any software for that matter) would ever be released.

 

[pcas1986]

Unless you are referring to small code segments (usually 100 lines or less), then "bug free" has never existed. The British mathematician, Alan Turing, predicted back as far as the late 1940s (before the digital revolution) that it was impossible to predict if a sequence of computer code would terminate or run indefinitely. You cannot mathematically analyse a normal sequence of computer code to determine if it contains bugs.

Actually there is and its called "proof of correctness". For some discussion see here. I did a unit of this at Canberra Uni way back in about 1988, I think. It was tough going and I was happy to scape through with a pass.
The reality is that it is expensive, in dev time, and probably few do it except, I hope, in the avionics or rail safety industries.

But you can do it in ordinary coding such as tests for nulls, for example. I see an absence of this a lot in Trainscripts I repair.

If you give it some consideration, Trainz is a very complex beast. The problem is that a small change in one bit of code can affect something elsewhere with cataclysmic results. This was demonstrated in the recent SP5 to TRS22. I'm still struggling to understand why upgrades to TLR could affect track object additions. Obviously N3V didn't have enough testers, or testers doing ordinary everyday route building activities in random tests. Unit testing, such as TLR, is fine but one also needs testers doing the everyday stuff as well.

Note. I don't consider myself an expert in the software testing field but I do have the scars of trying to support systems that had to run 24/7. One thing I did learn was never to introduce a change on a Friday unless you want your weekend ruined.

 

[sw1500]

Actually there is and its called "proof of correctness". For some discussion see here. I did a unit of this at Canberra Uni way back in about 1988, I think. It was tough going and I was happy to scape through with a pass.
The reality is that it is expensive, in dev time, and probably few do it except, I hope, in the avionics or rail safety industries.

But you can do it in ordinary coding such as tests for nulls, for example. I see an absence of this a lot in Trainscripts I repair.

If you give it some consideration, Trainz is a very complex beast. The problem is that a small change in one bit of code can affect something elsewhere with cataclysmic results. This was demonstrated in the recent SP5 to TRS22. I'm still struggling to understand why upgrades to TLR could affect track object additions. Obviously N3V didn't have enough testers, or testers doing ordinary everyday route building activities in random tests. Unit testing, such as TLR, is fine but one also needs testers doing the everyday stuff as well.

Note. I don't consider myself an expert in the software testing field but I do have the scars of trying to support systems that had to run 24/7. One thing I did learn was never to introduce a change on a Friday unless you want your weekend ruined.

If you mean the Beta testers, I was one of those testers and we do the everyday stuff too. The inability to attach trackside objects was not a bug during the last beta version. That appeared in the production version. I have noticed that a new bug usually appears during the step between the last beta and the production version.

 

[pcas1986]

If you mean the Beta testers, I was one of those testers and we do the everyday stuff too. The inability to attach trackside objects was not a bug during the last beta version. That appeared in the production version. I have noticed that a new bug usually appears during the step between the last beta and the production version.

I've been a beta tester for Trainz as well and particularly during the TANE testing. It's curious that N3V chose to issue a version different to the last beta tested by those who participated.

 

[Railroader1970]

This is the exact reason why so many of us have stayed with TRS19 and won't have a bar of the later SP versions of TRS22 in any shape or form.

Well I haven't updated anything yet myself. I still use TS12 and plan to get a new computer hopefully in the summer so I wondering about TRS22 and if it will even play my own routes and rolling stock that has some kuids (inside the asset) that have a Trainz Build of 2.9 or lower.

I was told that newer assets aren't TGA's and are unable to be reskinned which if that is the case would be a deal breaker for me because that was one of the chief attractions to Trainz for me -- reskinning assets (via permission) to bring my fictional rail company to life from just being HO and N scale models.

- RR70

 

[pware]

Actually there is and its called "proof of correctness".

The "proof of correctness" that is used in computing, according to the link you gave (interesting reading by the way) is actually only a "proof of partial correctness" and is considered "good enough" as computing still suffers from the "halting problem" as described by Alan Turing, where you can never prove that an algorithm will actually terminate and deliver a result - and therefore that it contains no bugs.

One thing I did learn was never to introduce a change on a Friday unless you want your weekend ruined.

I have certainly experienced that myself when working on a coding problem for my employer. I have noticed that some recent Trainz updates were released on Fridays so the prophesy may be correct.

I have noticed that a new bug usually appears during the step between the last beta and the production version.

Another known hazard of programming. Management insists on a "last minute minor change" that cannot be adequately tested because it would delay the promised release and chaos follows. But also beta versions often contain coding that is specifically there to enable testing and to produce data logs. This code must be removed from the production version and sometimes that is where bugs can creep in.