[roeter]

I'd like to draw your attention to this bug report.
Apparently, gradient forces calculated for flipped cars are now wrong.

But this begs believe. For a very long time things work quite well : downhill you had to brake, uphill you had to apply power - flipped engines or cars or not.
So how can this now suddenly be so very wrong? What change has recently been made that introduced this basic error?

At the moment, I'm seriously worried about the progress of OR. We're not moving toward 1.0 at all - we seem to be moving away from it.
For a long time I used an 'old' version (some months old) because of pending timetable updates. Last week this update was committed. So I moved to the latest version. Since then, there have been a series of problems which were not present in the old version. And these are not just minor problems - but main problems effecting the actual running of trains.

I'll not mention certain controversial warnings, but apart from that :

• Incorrect errors because sound-files were not properly looked for (only in route directory, not MSTS sound directory).
  
• Error in power settings which caused brake problems as compressor was put out of action.
  
• Error in force calculation which apparently calculates wrong force for flipped cars.

I'm quite sure this last error did not exist in the old version. So I would dearly like to know what change has caused this error, and why that change was made.

Regards,
Rob Roeterdink

[captain_bazza]

Sadly, I have to agree with Rob's assessment of the current situation. OR version 1.0 is slipping back further from its official release [although still a date not yet decided].

Version 1.0 should not be rushed, that temptation has to be avoided, and community expectations modified to face that reality. No pressure, team, remember MSTS.

This situation was going to happen at some stage, probably from time to time, too.

How to fix it - more communication amongst the developers would help - more dedicated testing of new features, etc.

These comments are based on neutral observations, slighly biased in favour of the OR concept and admiration of work done by an enthuiastic and dedicated international team of volunteers.

Cheers n kudos
Bazza.

[Eldorado.Railroad]

From 06 February 2015 - 06:33 PM:

How to fix it - more communication amongst the developers would help - more dedicated testing of new features, etc.

Oh...and some attention to those of us who test and find the show stoppers would be nice too! This also means...stopping development and doing the TESTING, and moving that result into 1.0 to release AFTER the bugs have been dealt with.

[Man runs for cover as the tomatoes and eggs begin to fly!]

[captain_bazza]

Quite right, peg V1.0, fix and test, fix and test, etc, before release.

Cheers Bazza. http://www.elvastower.com/forums/public/style_emoticons/default/curiousPC.gif

[R H Steele]

:bigboss: :I-Agree: :I-Agree: What they said! I'm quite content to keep using any one of the versions I've download. Better to get to the goal later, in a well designed machine, then arrive quicker in a bucket of bolts (so to speak).

[Csantucci]

Rob,
this is the situation:
- cars rolled correctly up to release 2783;
- the author of release 2784 (with whom I had correspondence yesterday, by the way an extremely valuable OR contributor, like you too are) was misled by the Gravity force signs he saw in the force HUD (notice the "appear" in the comment below) and inserted these lines

-            // Flipped cars appear to invert the elevation and Gravity force so this next "if" block aligns flipped cars with the rest of the train for GravityForce and Elevation
-            if (Flipped)
-            {
-                GravityForceN = -GravityForceN;
-                CurrentElevationPercent = -CurrentElevationPercent;
-            }

y
- these lines caused flipped cars and locomotives behaving incorrectly
- the reporter of the bug noticed the anomaly in running flipped locos
- I have investigated the problem and removed the above wrong lines in release 2841, 6 hours after the bug was reported
- release 2841 runs correctly, as was until release 2783.

You just corrected in release 2844 a bug you introduced few releases before: so, before criticizing others, remember that everyone makes errors (not myself in this case) when trying to improve OR .

[gpz]

Referring to HUD display thread, I see now that the code is strange a bit in Train.cs (and also copied to TTTrain.cs):

                car.TotalForceN = car.MotiveForceN + car.GravityForceN - car.CurveForceN - car.TunnelForceN;
                massKg += car.MassKG;
                //TODO: next code line has been modified to flip trainset physics in order to get viewing direction coincident with loco direction when using rear cab.
                // To achieve the same result with other means, without flipping trainset physics, the line should be changed as follows:
                //                 if (car.Flipped)
                if (car.Flipped ^ (car.IsDriveable && car.Train.IsPlayerDriven && ((MSTSLocomotive)car).UsingRearCab))
                {
                    car.TotalForceN = -car.TotalForceN;
                    car.SpeedMpS = -car.SpeedMpS;
                }

So the TotalForceN shows the correct direction, while the sub-components are orientation-dependent. It might be a good idea to flip the component-forces too, because copying these checking conditions would lead to errors, since the number of sub-conditions may increase as time goes by, and everyone will forget to adjust them at all places. :bigboss: (Now this same code appears at two places, and Carlo's proposal is to copy to additional two groups: HUD display and logger.

[roeter]

Csantucci, on 06 February 2015 - 10:45 PM, said:

You just corrected in release 2844 a bug you introduced few releases before: so, before criticizing others, remember that everyone makes errors (not myself in this case) when trying to improve OR .

If you look at my first post, you will see that I do not mention any critics to any developer.
What worries me, is that after an 'absence' from the latest releases for some weeks, I find that the program has not actually improved, but suddenly has some serious errors. And not just for a short while. One error, which basically disabled proper working of brakes for all electric engines after resume, 'survived' for no less than 7 weeks, before being overruled (yes - overruled, not solved) by a stubborn developer who did not believe his engine settings were wrong, as he was told when reporting on the problem.
The other error, which had cars running uphill, survived for 3 weeks and was only picked up by a very attentive user.
What this indicates is a total lack of any quality control mechanism in our process. That has me worrying - and should worry us all.

It means that any such similar errors can (and probably will) be introduced into the program without anyone noticing it for weeks on end. How can we ever issue a stable 1.0 release if we have no means of knowing that the program is correct? Yes, I know, we will never find the 'last' error - but these were not errors which only occured in very specific, limited, situations or circumstances. These were errors which had a severe effect, all the time. Yet they slipped through 'under the radar'.
It is exactly because I know we all make mistakes that this has me worried. Which is why I asked how the error w.r.t. gravity was introduced. So we can learn from it, and somehow perhaps can improve the process such that such errors are properly detected.
If we do not learn from these mistakes and let things go on this way, version 1.0 will indeed prove elusive.

And - yes, there is another serious error somewhere when it comes to the power calculation.
I have a single car DMU which runs a shuttle service. If I select a run from the timetable which starts this unit forward, I need to throttle up to about 60% to get to the allowed 40 mph. But if I select a run which starts this unit in reverse, it suddenly has developed rocket propulsion, and shoots up to 60 mph on 17% throttle. Without sound, as well.
I wonder how long ago this error was introduced into the system - unnoticed.

Regards,
Rob Roeterdink

[gpz]

Partly related: Interestingly in this same method there is an other section a little lower:

            foreach (TrainCar car1 in Cars)
            {
                SpeedMpS += car1.SpeedMpS;
                //TODO: next code line has been modified to flip trainset physics in order to get viewing direction coincident with loco direction when using rear cab.
                // To achieve the same result with other means, without flipping trainset physics, the line should be changed as follows:
                //                 if (car1.Flipped)
                if (car1.Flipped ^ (car1.IsDriveable && car1.Train.IsPlayerDriven && ((MSTSLocomotive)car1).UsingRearCab))
                    car1.SpeedMpS = -car1.SpeedMpS;
            }

I don't really get it: What's the point in swapping SpeedMpS's sign twice in a single method?

[Csantucci]

Peter,
that is something that wondered me too and that caused me to need some considerable time when I tackled the problem of the directions with the rear cab. I only added the second condition of the if in both cases. I believe it is due to various interventions on the program made in different times and maybe by different people.

Rob,
referring to your DMU problem: when you start in reverse, do you use a flipped trainset, or do you switch to rear cab? Do you have the same problem with EMUs?
Maybe also the selection of the type of adhesion could play a role.

[roeter]

gpz, on 07 February 2015 - 05:16 AM, said:

I don't really get it: What's the point in swapping SpeedMpS's sign twice in a single method?

The first sign-swap is used to negate the calculated speed - for flipped cars, that speed has the sign reversed in comparison with non-flipped cars. For various intermediate calculations (like coupler forces), all speed values have to have the same direction.
Also, inbetween those two statements, the speed of the cars is recalculated (method UpdateCarSpeeds) - again, for this calculation all speeds need to be in the same direction.

When all is done, at the end of the method the average car speed is calculated, this is set as the 'train' speed, and obviously this again needs all speeds to be the same direction.
Finally for flipped cars, the new recalculated speed is negated again as that is what is used to move the wheels etc.
And that value is used again as input for the same calculations - so it has to be negated again - and that is where we started.

So - it's not the same value that gets negated twice : the second instance is quite likely to be a different value resulting from the intermediate calculations.

Regards,
Rob Roeterdink

[Lindsayts]

roeter, on 07 February 2015 - 05:14 AM, said:

If you look at my first post, you will see that I do not mention any critics to any developer.
What worries me, is that after an 'absence' from the latest releases for some weeks, I find that the program has not actually improved, but suddenly has some serious errors. And not just for a short while. One error, which basically disabled proper working of brakes for all electric engines after resume, 'survived' for no less than 7 weeks, before being overruled (yes - overruled, not solved) by a stubborn developer who did not believe his engine settings were wrong, as he was told when reporting on the problem.
The other error, which had cars running uphill, survived for 3 weeks and was only picked up by a very attentive user.
What this indicates is a total lack of any quality control mechanism in our process. That has me worrying - and should worry us all.

It means that any such similar errors can (and probably will) be introduced into the program without anyone noticing it for weeks on end. How can we ever issue a stable 1.0 release if we have no means of knowing that the program is correct? Yes, I know, we will never find the 'last' error - but these were not errors which only occured in very specific, limited, situations or circumstances. These were errors which had a severe effect, all the time. Yet they slipped through 'under the radar'.
It is exactly because I know we all make mistakes that this has me worried. Which is why I asked how the error w.r.t. gravity was introduced. So we can learn from it, and somehow perhaps can improve the process such that such errors are properly detected.
If we do not learn from these mistakes and let things go on this way, version 1.0 will indeed prove elusive.

And - yes, there is another serious error somewhere when it comes to the power calculation.
I have a single car DMU which runs a shuttle service. If I select a run from the timetable which starts this unit forward, I need to throttle up to about 60% to get to the allowed 40 mph. But if I select a run which starts this unit in reverse, it suddenly has developed rocket propulsion, and shoots up to 60 mph on 17% throttle. Without sound, as well.
I wonder how long ago this error was introduced into the system - unnoticed.

Regards,
Rob Roeterdink

A couple of points.................

Its almost impossible to forecast every result of a program change, a programmer that does not commit any errors is ____VERY_____ likely not comminting anything else either.

In open source development while the developers are critical, an ______________________EXTREMELY________________________ important source of error reports are the users. Reports from this source (the users) are ignored by the Developers at there peril.

Any open source development project contains many developers all contributing to the cause, all developers contributing what they consider to be an important part of the project. The real fun in such development is contributing new facilities, bug fixing always has been a real grind and therefore is often partly ignored by most people. For this reason almost all open source projects do not have nailed down release schedules.

What ___IS___ usual in OS projects is a "feature freeze", that is a deliberate suspension of all new programming effort in order so that all developers can look at reducing the number of bugs in the program. Debian a Linux " disrtribution" totally developed by open source regularly advertises well in advance such "feature freezes" , Interestingly theres ALWAYS a major avalanche of new features immediately prior to such a freeze.

The Open Rails developers and users ____SHOULD__NOT____ be shy of such freezes, they contribute significantly to the programs development.

Lindsay

[edwardk]

Incorrect errors because sound-files were not properly looked for (only in route directory, not MSTS sound directory).

This stems from me. The initial code I used was based on existing code that has been in place. With this in mind, I will apply the same correction to the levelcrossing process.

Edward K.