[Hannes44]

Lamplighter, on 22 October 2021 - 11:41 AM, said:

Hi,
You probably mean a car like this.

https://de-academic.com/pictures/dewiki/77/M_120_5_Zg.JPG
Then the parameters are OK.

This is the old 5043 from Austria (or VT 43). I built it for MSTS long ago and you can download it from the-train.de. I shall try the ORTS additions to the eng-files, but I think there should be a decimal point, not a comma with ORTSWheelFlangeLength.

[Laci1959]

Hannes44, on 23 October 2021 - 12:34 AM, said:

This is the old 5043 from Austria (or VT 43). I built it for MSTS long ago and you can download it from the-train.de. I shall try the ORTS additions to the eng-files, but I think there should be a decimal point, not a comma with ORTSWheelFlangeLength.

Thanks for the comment. I was careless.

[steamer_ctn]

Laci1959, on 22 October 2021 - 10:42 PM, said:

Yes, I am aware of that. The question would have been that if you have "ORTSNumAxles (3)", you should have "ORTSNumberAxles (2)" next to it ??
"ORTSNumAxles" is the number of all axes for gliding. But then why should "ORTSNumberAxles" which is the number of running wheels? In addition, this shape file is already separated by animated and non-animated axes. This is what I learned on your website.

I am sorry, but I don't understand the questions.

As you are aware,

Total axles = Driven axles + Non-driven axles.

So if you still have a question, try wording it differently so that I understand your request.

[Laci1959]

Total axles = Driven axles + Non-driven axles

Total axles = ORTSNumAxles
Driven axles = ORTSNumberDriveAxles
Non-driven axles = ORTSNumberAxles

ORTSNumAxles = ORTSNumberDriveAxles + ORTSNumberAxles

Is that how it should be interpreted? Can't add the code to the code?

[steamer_ctn]

Laci1959, on 24 October 2021 - 12:02 AM, said:

Total axles = Driven axles + Non-driven axles

Total axles = ORTSNumAxles
Driven axles = ORTSNumberDriveAxles
Non-driven axles = ORTSNumberAxles

ORTSNumAxles = ORTSNumberDriveAxles + ORTSNumberAxles

Is that how it should be interpreted? Can't add the code to the code?

Total Axles is an internal value calculated by OR, it doesn't need to be specified by the user.

Thus,

Total Axles(internal value only) = ORTSNumberDriveAxles + ORTSNumberAxles

[Laci1959]

Thanks. Now I finally understand. So the value of "ORTSNumAxles" does not need to be specified. This is calculated data, (internal value only).
So far no one has explained this. Or Google's built-in translator is poorly translated and therefore confusing. My entry # 106 was for that too, just badly m, I explained. That is why I apologize.

Thank you very much for your kind patience so far.

[Traindude]

OK, I'm not sure whether to post this here or the "Maybe It's a Bug" section, but I am noticing an odd side effect when I run equipment that has advanced coupler physics.

I recently created a test consist using a steam engine, 20 of the new CTN N&W boxcars and a caboose, and I noticed something odd, as shown below.



As you can see, the speed indication as shown in the Track Monitor is significantly lower than the speed as indicated in either the HUD or cab gauges. It's not specific to this consist, either. It only happens any time I run equipment with advanced coupler physics. Equipment that doesn't have the advanced coupler physics appears to operate normally without any problems occurring.

Other side effects include the boxcars "jittering" backwards and forwards when the consist decelerates, and the locomotive drive wheels apparently "spinning in place" (according to the speed shown on the HUD) even though the consist is stationary (as indicated on the track monitor).

Is anyone else experiencing this problem? Or is my CPU just...having a hard time keeping up? I am using U2021.10.25-0406.

[pschlik]

I've been experiencing similar issues with advanced couplers for ages. It makes long consists entirely undrivable as the glitching and jittering has a habit of entirely nullifying any attempt to apply tractive effort. I have disabled my advanced coupler setup on everything but the shortest of trains, in which case the laws of physics still seem to apply.

[steamer_ctn]

Traindude, on 27 October 2021 - 02:16 PM, said:

As you can see, the speed indication as shown in the Track Monitor is significantly lower than the speed as indicated in either the HUD or cab gauges. It's not specific to this consist, either. It only happens any time I run equipment with advanced coupler physics. Equipment that doesn't have the advanced coupler physics appears to operate normally without any problems occurring.

There are actually multiple speeds in OR.

The speed of an individual car, and the train speed. The train speed is calculated by adding the speeds of each of the individual cars, and then dividing it by the number of cars, ie an average speed. Where a train is exhibiting some form of slack, especially when starting a long train, it is possible for the locomotive to moving at a speed, and the rear of the train is stationary. Thus it is possible for the locomotive speed not to match the train speed. Once the train has accelerated, the two speeds should be similar.

OR uses these two speeds at different places in the HuD, so there maybe times when they do not match each other.

Traindude, on 27 October 2021 - 02:16 PM, said:

Other side effects include the boxcars "jittering" backwards and forwards when the consist decelerates, and the locomotive drive wheels apparently "spinning in place" (according to the speed shown on the HUD) even though the consist is stationary (as indicated on the track monitor).

Is anyone else experiencing this problem? Or is my CPU just...having a hard time keeping up? I am using U2021.10.25-0406.

Unless the coupler is rigid, it would be expected that the coupler will "bounce backwards and forwards" a little bit, as the coupler has a certain amount of "spring" in them. Part of the challenge will be whether the locomotive has sufficient power to overcome the load. If it doesn't then the train may extended, and then "spring" back if the last car cannot move. This is due to the fact that the last car is used as the reference point for the train. I cannot comment on why it was used in preference to the leading car.
I have started a 23000 ton train with two locomotives without any dramas on level track. The tonnage rating will influence how well cars are started.

I haven't experienced the last issue raised, but obviously OR thinks that the wheels are still rotating. Looking at the Advanced Adhesion model may give some clues to this.

As always I am happy to work with anybody in developing a realistic test scenario (initially with CTN stock) to confirm whether OR's performance is realistic or not.

[darwins]

Quote

Unless the coupler is rigid, it would be expected that the coupler will "bounce backwards and forwards" a little bit, as the coupler has a certain amount of "spring" in them. Part of the challenge will be whether the locomotive has sufficient power to overcome the load. If it doesn't then the train may extended, and then "spring" back if the last car cannot move. This is due to the fact that the last car is used as the reference point for the train. I cannot comment on why it was used in preference to the leading car.

Possibly another member of the development team can comment on why the last vehicle is the reference point, rather than the leading vehicle.

This is a major limitation for loose coupled 'unbraked' trains with three link couplings. The amount of slack in these trains is very much greater than with knuckle couplers. In real life the loco would start these gently, not using full power, picking up each wagon one at a time. Using the advanced coupler model in OR the only way to get such trains moving is to go full throttle and charge off. If you attempt to start gently, then to begin with one wagon moves, but rather than picking up the wagon behind, the static rear of the train is trying to pull the wagon back, after a few wagons this pull back force becomes sufficient to pull the moving wagons and locomotive backwards, creating the oscillating effect described on a grand scale.

Having seen the effect it is hard to imagine that advanced coupler physics could ever be of much value unless the front of the train becomes the reference point. Changing something like this would impact on all areas of operation such as timetables, activities and paths.