TRS19 SP1 Now LIVE

Hi pware,

re:

Speaking from direct experience, going from ... to ... is never a simple step and some of the descriptions you used in your "human readable version" are vague and may still be incomprehensible to many.

Thank you for your perspective. If we look at developers at large, this is common practice, to produce release notes:

https://developer.microsoft.com/en-...rm/changelog/desktop/18204/?compareWith=17713
https://www.mozilla.org/en-US/firefox/72.0.2/releasenotes/
https://vivaldi.com/blog/snapshots/desktop/update-to-chromium-80-vivaldi-browser-snapshot-1800-5/

As a paid software developer, he/she is expected to take that step as part of their conformance to their industry's practice. Even freeware updates have release notes. Its a hallmark of good quality assurance.

With Trainz, at this point users have so much sweat equity invested in their projects, and I dare say now take trepidation in walking into a familiar room, which was just rearranged, with the lights out.

I don't subscribe to the points of vagueness and non- comprehension in this arena. If the release notes were to say "An option to merge a layer is now available when the user chooses to delete a layer" the majority of us would understand what that is and where to expect it.
 
Last edited:
I agree with your point "An option to merge a layer is now available when the user chooses to delete a layer" being clearly understandable by the majority of Trainz users, but what about "compatibility mode spinner" and "reduced overhead for string edits". During my later years in work I made a significant career out of deciphering techno-jargon for the uninitiated.

Your links to release notes from well known, large and well funded software developers (Microsoft, et al) were interesting and clearly demonstrated best practice. I have no doubt that both Microsoft and Google have large and well resourced technical publications departments that specialise in producing documentation suitable for all levels of the industry, from the technical experts employed by their corporate clients to the home user. Smaller developers do not have these resources and, you could easily argue, all too often the task of "translating" for the "masses" is an after-thought and if it is done it is often not done well.

In an earlier post (this thread??) Tony mentioned that they need time to "filter" the technical descriptions of the changes from their server and that it is a matter of priorities. Time spent doing the "filtering" which would benefit some of us is time not spent doing things that benefit more of us.

My thoughts.
 
Last edited:
Until now I have only tried two routes in TRS19 and both have objects that cannot be removed. The get object tool does not work on them, the move tool does not work on them and the delete tool does not work on them. This is the latest one I have found just after leaving Haymarket station bound for North Queensferry. Obviously this building is not meant to be there.


https://imggmi.com/full/2020/1/30/4296d0f8c6e4e9eaf0346b2570ab8801-full.jpg.html

What can be done about this and when?

Bill69
 
Speaking from direct experience, going from … to … is never a simple step.
Even the developers could not tell from that description what the reason for it was, so trying to 'sanitize' that list would be impossible. Somewhere there must be a list of tasks that the developer was provided with, in a form sufficient to enable them to identify the cause, fix and test it. When an item is fixed then it is simply moved from that task list to the fixed list, and that's what gets distributed. Then people know what to test. Without that sort of list then beta testing is incredibly inefficient, with people testing stuff that hasn't changed, or what has already been tested many times over.
 
Without that sort of list then beta testing is incredibly inefficient, with people testing stuff that hasn't changed, or what has already been tested many times over.

You are right. Beta testing is much more like a "scatter gun" than a highly accurate sniper rifle (sorry to use gun analogies). However, both approaches are useful and are needed.
 
Hi pware,

I agree with your point "An option to merge a layer is now available when the user chooses to delete a layer" being clearly understandable by the majority of Trainz users, but what about "compatibility mode spinner"

Maybe if you hadn't truncated it, it would lend to better understanding. It read: "Introduced Compatibility Mode spinner on Dev Tab of Settings module." That means we all (N3V QA and end users) go to to the Dev tab and look for something new, an item that says "compatibility mode". Now the testers and the users are aware of something new. Also, such "Release Notes" can be used to identify the need to update he Wiki to address this new item. Release Notes is also an opportunity to tell us what the four settings mean and their use. Isn't all the above much better than just keeping it all in the dark? Of course.

and "reduced overhead for string edits". During my later years in work I made a significant career out of deciphering techno-jargon for the uninitiated.

That was a summary of Tony's sample work item in post #336: "* Use CXStringEdit instead of std:string in order to reduce allocation load". It tells the testers there is a new string handling item to review. To the users, it only tells them N3V did an optimization, and shouldn't impact them, so they pass over it. This isn't hard. As for the second sentence, sorry if I inadvertently drew attention to an old battle wound.

Your links to release notes from well known, large and well funded software developers (Microsoft, et al) were interesting and clearly demonstrated best practice. I have no doubt that both Microsoft and Google have large and well resourced technical publications departments that specialise in producing documentation suitable for all levels of the industry, from the technical experts employed by their corporate clients to the home user. Smaller developers do not have these resources and, you could easily argue, all too often the task of "translating" for the "masses" is an after-thought and if it is done it is often not done well.

The Vivaldi link in fact demonstrates a single developer is making release notes for his QA and his users. That organization is probably smaller than N3V.

And pware, you know full well that almost every piece of software from single person developers, smaller than N3V, has release notes.

In an earlier post (this thread??) Tony mentioned that they need time to "filter" the technical descriptions of the changes from their server and that it is a matter of priorities. Time spent doing the "filtering" which would benefit some of us is time not spent doing things that benefit more of us.

I can certainly appreciate with finite resources, he has to pick his battles. My request is in line with this environment - to do release notes speaks to the core of the commercial viability of the Trainz franchise. Testers knowing what is new so they can formulate their test procedures / criteria. In this way, releases do not frustrate away non-technical users and charter users are not kept in the dark.

My thoughts.
Thank you, appreciate the feedback...
 
G'Day Deneban.

You raise some good points but I still have some "quibbles". For example, your expanded point

"Introduced Compatibility Mode spinner on Dev Tab of Settings module." That means we all (N3V QA and end users) go to to the Dev tab and look for something new, an item that says "compatibility mode". Now the testers and the users are aware of something new. Also, such "Release Notes" can be used to identify the need to update he Wiki to address this new item. Release Notes is also an opportunity to tell us what the four settings mean and their use. Isn't all the above much better than just keeping it all in the dark? Of course.

I still have no idea what a "spinner" is.

And pware, you know full well that almost every piece of software from single person developers, smaller than N3V, has release notes.

Guilty as charged. Having been a one person software developer myself for a major project ("major" in terms of the time I spent on it) for the organisation I worked for. I spent as much time writing the documentation (a full manual for the tech staff and another for the end users) as I did writing and debugging the code. But I was under no real time pressure and the project was the only thing I worked on, unlike the experiences of those working for a gaming software developer.

I appreciate the time you have spent responding to my post.
 
Traditional Hard Disk Drive with a motor, spinning platters and moving heads, commonly referred to as a spinner since the arrival of SSDs. ;o)


Love it!

Here in Oz we have a traditional gambling game called "Two Up" where two coins (old pennies) are placed on a wooden spatula and then tossed into the air. The punters bet on the outcome (Head-Head, Head-Tail, Tail-Tail). "Come in spinner" is the call given by the game manager when all bets are placed and the coins are ready to be tossed.
 
As previously stated, we provide Changelists most of the time. Generally when we don't is because I've done my 60 hours for the week and have decided to have a beer instead of spending an hour or more working out the changelist. Yes this is far from ideal, but then that's the trade-off.

Improving the test case/bug tracking/user suggestions/visibility of what we're working on has been high on the To Do list for years, along with features like "Add a proper scheduling system" (thanks Vern for reminding me regularly) of getting the SP4 update finalised etc.

Quite simply if everyone who owned TANE bought TRS19 we could expand the team and fix all the problems much more quickly. Since that is unlikely to happen, things will take longer, and certain things we'd like to do won't get done at all.
 
The kuid is kuid2:154322:100063:15 It's the built in route ECML Edinburgh to Dundee. The item is not far west of Haymarket station.

Can you provide the name of the nearby junction/signal as I can't spot it here.[/COLOR]

It is <kuid2:64038:370004:2> FreightShed Spline by jkeenan and it is a spline object. I thought I recognised it from long ago. The layer it is in, named Layer2, is locked and that is probably one reason why you could not deleted it.
 
Last edited:
Thanks pware - I was looking in 100596 (where it is working fine). I suspect this is related to a recently fixed bug with spline heights near digholes (but then again, it just appears to be twice as long in 105100 as in 105096, so perhaps a different issue). Will get it investigated further.

Note that the issue appears fixed in the latest Trainz Plus beta 105624.
 
Last edited:
Generally when we don't is because I've done my 60 hours for the week and have decided to have a beer instead of spending an hour or more working out the changelist.

Is it something decent like "150 lashes" or do they still drink that illiterate "XXXX" stuff up in Queensland?

Just asking!
 
About to crack a Little Creatures Pale Ale while tidying up all the loose ends for the week :)
 
As previously stated, we provide Changelists most of the time. Generally when we don't is because I've done my 60 hours for the week and have decided to have a beer instead of spending an hour or more working out the changelist. Yes this is far from ideal, but then that's the trade-off.

Improving the test case/bug tracking/user suggestions/visibility of what we're working on has been high on the To Do list for years, along with features like "Add a proper scheduling system" (thanks Vern for reminding me regularly) of getting the SP4 update finalised etc.

Quite simply if everyone who owned TANE bought TRS19 we could expand the team and fix all the problems much more quickly. Since that is unlikely to happen, things will take longer, and certain things we'd like to do won't get done at all.

Hi Tony,

Thanks, - Wish I could be there to volunteer some time.
 
Back
Top