[Lindsayts]

I have come across a small problem in OR V0.7. Some consists take very little power to maintain high speed. If one brings Up the "shift F5" forces HUD there are three forces concerned with the problem, these are

Coupler force
Axle out force
Axle drive force.

On a loco that works correctly these forces change as one would expect. On a loco that exhibts the problem when one starts out and opens the throttle all three of the forces increase. As one speeds up the Axle out and Axle drive forces decrease but the Coupler force does not. The throttle position is some how tied up with "Axle out force" but the Coupler force appears to control accelartion hill climbing etc. So one in effect gets a loco that will travel at high speed as the Coupler force is high but at a very low throttle setting as the Axle drive force is low.

I have established that it is the loco that is causing the problem but have as yet to establish which (if any) of the eng parameters is causing the problem and I wonder if the OR developers have any clue here.

Any help will be greatly appreciated

An N class loco (VLine N class DE) works OK

CVW 3rd series X class exhibts the problem, unfortunately this is no longer availble for download.
The is one other I think is bring up the problem, SE 180107 Grand Central, a DEMU (I think).

Lindsay

[Lindsayts]

Are the OR developers interested in bug reports such as these as there has been no acknowledgement....................... no point in talking if no one is listening...................







Any way I figured out what is causing this, If a motive force unit such as a loco or a DMU is flipped the tractive effort produced by the flipped unit only depends on the throttle position and does NOT vary with speed at all. So for say a push pull set with a loco on the front and a flipped loco on the rear the tractive effort of the rear unit does NOT vary with speed by only with the throttle position the tractive effort staying at the starting level. So if a flipped unit has a starting tractive effort of 150,000 newtons this is what its tractive effort will stay at at notch 8 inspite of any change in speed. For a multiple DMU all units will behave properly except for the rear unit which is flipped. If in a DMU consist in which no unit is flipped behaves properly.

Lindsay

[thegrindre]

Absolutely, Lindsay. All input is noted and placed on 'the list' to be taken care of in turn.
We still have a ways to go yet so please continue to add all your findings. We appreciate it.

;)

;)

[Lindsayts]

thegrindre, on 30 January 2012 - 01:24 AM, said:

Absolutely, Lindsay. All input is noted and placed on 'the list' to be taken care of in turn.
We still have a ways to go yet so please continue to add all your findings. We appreciate it.

:sign_thanks:

:oldstry:

Thank you, I discussed this a bit on this thread on Trainsim.com on my experience of developing with Linux, my main platform.

Back to the thread, It is definitely the flipped loco/locos causing the problem on one of the faulty consists I straightened out the rear loco and the consist then behaved correctly.

Lindsay

[Matej Pacha]

Lindsayts, on 30 January 2012 - 02:22 PM, said:

Thank you, I discussed this a bit on this thread on Trainsim.com on my experience of developing with Linux, my main platform.

Back to the thread, It is definitely the flipped loco/locos causing the problem on one of the faulty consists I straightened out the rear loco and the consist then behaved correctly.

Lindsay

Hi,
This issue is definitelly a bug. But anyway, it has been located and fixed. The main problem was caused by changes in power computation. I've changed the power to be computed from the wheelspeed rather than the train speed. Unsufficient testing caused this bug beeing "implemented" in the release.
And finally, the delay of this response came with my bussiness deadlines.
Matej

[Lindsayts]

Many many thanks for the response it is most apreciated. Also no real need to make any kind of excuse, at least to "this little black duck", the problems of open source development being well understood, having been using and developing in the OS world for nearly twenty years.

absolutely itching to get hold of the next version I may say.

Lindsay

[Lindsayts]

Matej Pacha, on 12 February 2012 - 01:35 AM, said:

Hi,
This issue is definitelly a bug. But anyway, it has been located and fixed. The main problem was caused by changes in power computation. I've changed the power to be computed from the wheelspeed rather than the train speed. Unsufficient testing caused this bug beeing "implemented" in the release.
And finally, the delay of this response came with my bussiness deadlines.
Matej

Just another point, It is usually impossible when developing anything particularly something as complex as a train simulator to test every function adequately, One of the major reasons in open source for periodic releases when developing is to allow users to discover bugs in said software. Do NOT under estimate the input from the public when developing such software. Hope you do not take this in any way as a negative comment as the peroiodic releases is the THE PRIME advantage of open source development and one for the the major reasons why such software performs so well (Note 1).

Note 1: The major reason is that the people writing the software REALLY wish to use it and want it to work correctly, hence the drive to produce good software .

Note 2: I believe it was Richard Stallman a long time very vocal advocate for open source said something like "that when 100's of people were looking at and testing the source there was no such thing as a complex or hiden bug"

haveing enjoyably worked in opensource projects including the Linux kernel frame buffer driver and parralel port driver for over 15 years,
Lindsay

[captain_bazza]

I asked last year that we establish a team of trusted beta testers, whose job would be to test each issue and report as required by the team. I thought a team of at least twelve reliable and trusted experienced MSTS users would be suitable. I still believe this is what we need to do.

Cheers Bazza

[Lindsayts]

captain_bazza, on 12 February 2012 - 07:21 PM, said:

I asked last year that we establish a team of trusted beta testers, whose job would be to test each issue and report as required by the team. I thought a team of at least twelve reliable and trusted experienced MSTS users would be suitable. I still believe this is what we need to do.

Cheers Bazza

THE primary and in reality the only rule in open source development is everyone has to be comfortable in what they are doing, in the volunteer world no one can force anyone to do anything.

Long live the revolution.............. :pleasantry: :unknw: :book2:

Lindsay

[Matej Pacha]

Lindsay,
I really do appreciate any bug reports you post here. Sometimes it seems like nobody is answering but the open source project is not the first priority in our lifes. Please keep testing and reporting, because these bugs will be fixed as soon as possible.
Matej