Dekosoft GP30 Pro Union Pacific, Santa Fe and BNSF sets

[kraus]

I do not see how you were able to do that since they are from different authors, and the texture mappings are different.

Whose rule is that?

I copied the shape and it's textures from the source folder and then edited the engine file.

This rule has been adopted by the Open Rails team. If new incompatible features are introduced they will use a different file extension.

[baldwin]

There is also this fact to consider. Open Rails can handle shapes with far higher poly counts than MSTS so it is inevitable that models will be produced that are Open Rails only. It is pure nonsense to say that Open Rails is at fault because of this.

The Dekosoft PDF referring to these models does say that they are for Open Rails, no mention of MSTS.

[kraus]

The shape file gp30_up713.s has 17477 polys while another shape file that does work in MSTS, 3dts_SL2_34105_PH4.s, has 26952 polys. So it is not just a high poly count that is preventing the Dekosoft shape from loading into MSTS. Aside from the broken hierarchy there must be some other problem with the shape file that is being ignored by Shape Viewer and Open Rails.

The Dekosoft shape has 85 matrices while the 3DTS shape has 11 matrices. But what is preventing the shape from opening in MSTS is probably not just a difference in size but some constraint on shape files that is not being implemented.

[dredick]

A bug report will be filed to fix this defect in Open Rails. If a shape file does not work in MSTS it should also not work in Open Rails.

If that "bug" is addressed, then based on your "reasoning" above, ANY content developed SPECIFICALLY for OR will cease to function with OR.

Is that what you really want?

[kraus]

That depends on what is wrong with this shape that is preventing it from loading into Train Simulator. Content that is developed specifically for Open Rails should also work in MSTS but just at lower quality.

I had thought it might be because the shape was using matrix elements with scaling.

matrix 30dbfan ( -1 0 1.50996e-007 0 1 0 -1.50996e-007 0 -1 0.0184622 4.50441 -1.04591 )

The first 9 attributes are use to scale the points and the last three attributes are use to translate. Almost all shape files do not use scaling, their matrix element is of the form

matrix Air_condition ( 1 0 0 0 1 0 0 0 1 -0.0012192 1.581 6.32673 )

But I used scaling on another shape and it displayed correctly in Train Simulator.

scaling x2.jpg

matrix Wheels11 ( 2 0 0 0 1 0 0 0 1 0 -0.0785735 0.015541 )

I had also eliminated the scaling on the Dekosoft shape file and it still failed to load into MSTS.

Using MSTS Shape Fixer got the shape file to load into Train Simulator. Still need to identify what in particular about the shape file caused it to not load.

gp30_up713 after shape fixer.jpg

[eric]

Don't confuse the project charter for ORTS to read in MSTS files and a content provider creating objects which can't be loaded by MSTS. ORTS isn't broken because it reads higher poly objects or non-square textures. It's just not limited by ancient constraints.

[gpz]

I repeat my opinion I posted to bug ticket page opened at launchpad for this issue, to keep the discussion where more people can participate:

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.

[crstagg]

[kraus]

Processing the file through MSTS Shape Fixer split one large sub-object into two smaller sub-objects. This had the side effect of breaking alpha sorting so that portions of the model were not visible. Based on a tip at Elvas Tower, http://www.elvastower.com/forums/ind...66#entry168066, swapping sub-object 0 and 1 resolved this problem.

gp30_up713 after swapping sub_objects.jpg

The web site states that this model should work in Train Simulator but until this shape if fixed it does not. From http://www.dekosoft.com/trains/?page_id=78

How to Install

Download and open the installers for each loco set, and proceed as directed.
Make sure the installation path shown points to the directory where you TRAIN.EXE program is located.
The locomotive files, including consists, will install in place.
Start Microsoft Train Simulator or Open Rails. Choose ‘Explore Route’ on your route of preference. The locomotives should appear in the locomotive choices. You may build your own consists and activities in the activity editor.

[eric]

Jeff, Dekosoft made it clear these sets were designed for ORTS, not MSTS.

You've quoted a general page from their website above, but if you'd read the actual installation & operating instructions for these sets, you will notice there's no mention of starting MSTS. The PDF's are linked from the product pages.

Dekosoft is just one content creator who is only guaranteeing compatibility with ORTS, and there will be others.

My freeware route projects are another example -- I am intentionally ignoring MSTS's constraints regarding node lengths and squared textures.

If/when bug reports come up for things like broken couplers, shapes that fail to load in MSTS, or bounding box errors, I'm not planning to be acting on those.