Build 44 of Standardized Tsection

[Steven]

Just to let everyone know that build 44 is in the file library.

This one should be correct

[derekmorton]

Thank you for your ongoing support for the tsection.

Cheers
Derek

[oakpalms]

Steven, just what is meant by "this one should be correct"? Does this mean that the problem with signals set at a different distance than previous versions has been reverted back to the original distances so that activities made for the original setting will now work with the settings that are provided in build 44? Many of us reverted back to build 38 just to make sure we did not have problems with our activities when using builds 39-43. Does this mean that we do not have to use build 38 in order to make sure that our previous activities will work?

Thanks for futher explanation so that we all understand what has been done.

Bob Edwards

Just to let everyone know that build 44 is in the file library.

This one should be correct

[Steven]

Steven, just what is meant by "this one should be correct"? Does this mean that the problem with signals set at a different distance than previous versions has been reverted back to the original distances so that activities made for the original setting will now work with the settings that are provided in build 44? Many of us reverted back to build 38 just to make sure we did not have problems with our activities when using builds 39-43. Does this mean that we do not have to use build 38 in order to make sure that our previous activities will work?

Thanks for futher explanation so that we all understand what has been done.

Bob Edwards

Build 43 fixed that but I had uploaded the wrong file that had errors in it.

[mestevet]

Basically (and please correct me if I'm wrong), Build 43 is Build 38 plus only the NEW sections that were added between 38 and 42 (such as the ones I had added in Build 42, but those weren't the only ones).

Steve

[kingconrail76]

Thank you Mr. Masters, for the time and effort you put into keeping this core piece of MSTS organised and available.

[tonyhap]

To increase effective communication and eliminate questions as to what is included in each build, could not a procedure be used that is used in keeping manufacturing drawing changes up to date?

That is, at the top of each build dat file, a detailed list is added that itemises changes, additions and deletions in that build? This would create a history for everyone to see. I would have thought that such a list could make life much easier for everybody.

Regards,
Chris

[mestevet]

To increase effective communication and eliminate questions as to what is included in each build, could not a procedure be used that is used in keeping manufacturing drawing changes up to date?

That is, at the top of each build dat file, a detailed list is added that itemises changes, additions and deletions in that build? This would create a history for everyone to see. I would have thought that such a list could make life much easier for everybody.

Regards,
Chris

Using the "Context" editor, it's a pretty simple process to bring up a new version of a file and do a "compare" with a previous version (in my case, I checked 044 vs both 042 and 038 to see what the differences were). My point being that anyone who cared to, could pretty readily see the differences between this version and the earlier ones.

I can't speak for Mr. Masters, but I understand the engineering change process all too well. Doing an "Is:" "Was:" list would be a pretty long document in and of itself in this case, and I think the number of people looking at that information would be minimal. Given that it's easily done for yourself, I'm not sure if there's a lot of value in Steven preparing that information for inclusion. Steven was kind enough to let me look through a pre-release of 044 and doing a comparison of all the changes as I stated above, there were a LOT, but as I summarized above, it's basically putting it back to 038, which is what was being asked for because of the uproar about changing all the ClearanceDist parameters.

The other thing I would point out is that in a typical "Engineering Change" process, there is also typically a list of reviewers who must "approve" the change (typically something like the "Responsible Engineering Authority" for different areas involved in the design and manufacture of a product). I'm not exactly sure how you would go about doing that for a Tsection.dat. As I pointed out in an earlier post on this subject "There isn't some sort of MSTS Ruling Council of Elders that decides on these things".

Steve

[tonyhap]

there were a LOT.

Was not the reason "there were a lot" was because 43 to 44 inadvertently picked up past changes?

Did not 42 to 44 only picked up the UK requested changes? Which, incidentally, we are very grateful for. So is using the reason that there "is a lot" a little bit excessive?

Where do you get the idea that I am suggesting a full blown "Engineering Change " process?! No where have I implied that there has to be a community review panel before changes can be made. All I am suggesting is that the changer publicly document the changes so that anyone can see what changes have been made rather that asking for and interpreting an explanation, or doing their own comparisons.

Regards,
Chris

[mestevet]

I'm guessing you're friends with "gswindale" - he was also argumentative when I simply pointed out a few facts. My comment about the "Engineering Change Process" since YOU brought it up, was that the process only works properly because there is a system of review. Simply documenting changes does nothing but document changes, it doesn't prevent mistakes.

An engineering review process is designed to catch errors and prevent releasing things with obvious errors. What you're suggesting a) does NOT prevent release with errors, it just documents changes b) seems punitive against Mr. Masters c) is pointless since using a commonly available free editor allows you to look at the abundant changes for yourself (http://www.contexteditor.org/ - I have no connection with Context other than being a satisfied user).

And I am suggesting that you take some initiative, download and run a simple, free tool that many developers already have, that will tell you what you're asking him to provide.

Steve

[gswindale]

Steve,

I think what Chris has suggested, is not entirely unreasonable.

The list of changes does not have to be included in the tsection.dat but as a separate change-log. This method would give builders an "at a glance" view of the changes and given that it is so easy to do (according to your post above); what is the rationale behind objecting to this idea.

I take exception to your view that myself and Chris are being overly argumentative. We are simply trying to understand the process and come up with a solution that works for all. It becomes argumentative when people don't interpret that in the right way.

As it stands, we do appear now to be making some progress back towards harmony and we are grateful to Steven for that.

[GoGoran]

I think what Chris has suggested, is not entirely unreasonable.

The list of changes does not have to be included in the tsection.dat but as a separate change-log. This method would give builders an "at a glance" view of the changes and given that it is so easy to do (according to your post above); what is the rationale behind objecting to this idea.

This actually would make a lot of sense, gswindale, it is easy to do , as the user "mestevet" assured us, and it would nevertheless make things much more transparent for all users and route-builders.

By the way, it is interesting that my first post on this thread somehow - may I say: mysteriously ? - disappeared into the void of the web. Constructive criticism does not seem to be welcome here.

[mestevet]

Again, you're all missing my point.

A list of changes DOES NOTHING to assure quality. It's "closing the barn door after the horse is already out".

Peer review before release does help assure quality.

Talk about not hearing constructive criticism...

Last post in this thread.

Steve

[gswindale]

Steve,

It was my understanding that there is peer review - I've seen references to test (beta) versions of previous tsection.dat files.
However listing the changes to the public shows an element of transparency which means that if the review fails to find a glaring bug (all too common with software etc!); then an end-user might stand a chance of working out why their route no longer works as expected.

Quite frankly; creating a new file and sending it to a few people to test without a list of changes is completely pointless as it does not assist with testing. The change-list is VITAL so that in any testing environment people know what they are looking for; although in the case of the tsection.dat the only changes should be elements added with no changes to existing elements.

However if you feel that the file should be released without any review/release notifications, then fine!

[mdeming]

Here is an idea. Since YOU feel so strongly about a list of changes made, why don't YOU do it.