Weird Glitch with CEBX800

[curley]

When I run the CEBX800 from the file library in OR, I get this odd issue going around curves. It seems to only happen on one side and the others turns normally. The car works fine in MSTS. Does anyone else have this issue and is there a fix? Thanks

[jiggywatt]

Have you tried this cebx8007.zip

[curley]

I've installed all the updates and fixes for it but I still have that issue.

[R. Steele]

I've installed all the updates and fixes for it but I still have that issue.

Can't help much, but here's a thread that may apply to your problem:

https://www.trainsim.com/vbts/showthread.php?331643-SLI-based-boxcar-repaint-wheel-error/

It's probably something that MSTS ignored, but OR's penchant for accurate data can produce these aberrant results in simulation.

[curley]

I looked into the shape file and I didn't see anything out of the ordinary at least compared with shape files from other cars. Since the center part of the car is so long, is it possible that OR isn't capable to properly handle it? I ran one of the other Schnabel cars and had the same issue so I'm becoming more convinced that this may be an OR issue. I uploaded the log file just in case I missed something.

[crstagg]

What happens AFTER you fix this error the Log reported?

Warning: Found a suffix 'n/m' which could not be parsed as a Resistance unit in C:\MSTS\trains\trainset\Schnabel CEBX800\CEBX800_A8.wag:line 16

Probably need to change n/m to n/m/s

[R. Steele]

What happens AFTER you fix this error the Log reported?

Warning: Found a suffix 'n/m' which could not be parsed as a Resistance unit in C:\MSTS\trains\trainset\Schnabel CEBX800\CEBX800_A8.wag:line 16

Probably need to change n/m to n/m/s

That's the correct fix Charles, but many wagons have that error and do not exhibit the problem the OP is describing. My best guess ( since he mentioned the Schnabel cars ) that it is a hack that worked for MSTS but will not work in OR. Needs a look by someone with more experience with models and shape files than I have...however, from what I've read these models were constructed this way because MSTS could not handle them if constructed as one shape - multiples had to be used...probably OR would not have that problem.

[curley]

I fixed the error, but results are the same. I have no real knowledge with shape files so I guess this is something I'm just going to have to live with until a solution comes.

[markelecfan]

Ryan,
A similar problem appears to exist with an original MSTS train on the last car of the articulated Series 7000, Japanese Odakyu Railway Luxury Super Express (LSE), the red-&-white streamlined rail-car train.
Looking from underneath it is as if the trailing pivot-pin of the last articulated bogie is not above the trailing edge of the bogie but is on the end of an "invisible arm" that extends about 2 metres (6 feet) behind where it is "attached" to the last car & guides the body of the last car so it swings out more on sharp curves.

Of course none of this happens when running this Series 7000 train under MSTS.

I can only think it is something to do with the shape file that Open Rails interprets differently to MSTS but I have no expertise in these matters, but it may provide a hint for others with more knowledge.

By the way, is your photo shot of the well-car looking from front-to-rear or from rear-to-front ?

Cheers 'n' tears,
Mark.
Series7000LastCarOpenRails.jpg
Series7000LastBogieOpenRails.jpg

[curley]

It's looking front to rear.

[markelecfan]

Ryan,
As your photo shot is front-to-rear then it's just as I suspected : Both your well-car & the last car of the MSTS LSE Series 7000 articulated train appear to be afflicted with the same problem but to a different magnitude because the rear portion of the well-car is much longer than the rear car of the Series 7000.

I can only suspect it has something to do with how the pivot points for multiple bogies have been specified for both these vehicles, but we will have to leave it to others to figure out what's going on & how to fix it.

Cheers, Mark.