[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.