Defective shape is rendered by Open Rails

[Jeffrey Kraus]

The shape files included with the Dekosoft GP30 Pro Edition at http://www.dekosoft.com/trains/?p=148 render in Open Rails and Shapeviewer. But when loaded into Microsoft Train Simulator produce an error of

Can't add car gp30_up8005 (uid:200000) to world.

It was confirmed that the shape file caused this error by substituting a different shape into the engine file. This confirms that the engine file, cab view files and sounds are compatible.

[Peter Gulyas (pzgulyas)]

Do you say, the engine with all of its shapes is rendered correctly in OpenRails, but isn't in MSTS?
In this case how it is an OpenRails bug?

[Jeffrey Kraus (krausyaoj)]

The format of the shape file has not been fully documented. The reference implementation is Microsoft Train Simulator. If a shape file fails to load in this program then the file is not formatted correctly.

The hierarchy of objects has indexes into the matrices element. Valid values are either -1 indicating no parent or 0 to the count of elements in the matrices element minus 1. Programs like Shape Viewer and Open Rails ignore the values in the hierarchy element and so render files that are not well-defined shape files.

While the syntax of shape files are understood there are some semantic issues that have not yet been identified.

The shape file that is failing to load while it follows the syntax rules is violating one of the semantic rules. It is violating which values are valid in the hierarcy element and is also violating other semantic rules.

See http://www.trainsim.com/vbts/showthread.php?320543-Dekosoft-GP30-Pro-Union-Pacific-Santa-Fe-and-BNSF-sets

[Peter Gulyas (pzgulyas)]

You are right in that OpenRails' .s file loader is not fully implemented in the same way as MSTS' one. This is reasonable, because OR has no access to MSTS source code, and as such the loader obviously cannot be exactly the same. The target of OpenRails is to load as many .s files as possible.

Loading as few such .s files that MSTS doesn't load could be also a target, but the (benefit / effort) ratio is rather low on that. In fact in my opinion this ratio is nearly zero, because while it would take a lot of testing and researching effort, it wouldn't bring much benefit, if at all.

In fact we do not plan to make many changes on .s file loader, as far as I know. If we try to improve our shape loader, we would concentrate on implementing our custom format loader instead.