Engine not appearing in simulation.

[OmenRotcod]

I've been running into a strange problem lately. I can view an engine in TSRE, but when placed in a consist it does not show up in outside views in the simulation (except for the smoke from the engine and the lights). The cabview from inside is okay but the forward and rearward "head out" views show no engine. The engine pulls.

However, when I load it into Shapeviewer, I get an error: "Error 5: Invalid procedure call or argument."

This is happening to several engines.

I'm running ORTS v1.5.1.

Any help would be appreciated.

[slipperman]

Hi,
There is an error in the shape file - If it's an engine you've downloaded, please give us the file name and from where you downloaded it. If it's a reskinned loco from this site, have you followed all the instructions in the readme? If it's in a commercial (payware) add-on, please tell us the name of the add-on and the engine file name.

Cheers,
Ged

[OmenRotcod]

I'll give you some examples (without wishing to finger-point) that have been downloaded from this site, so you may have copies.

FBL_2023, FBL_2028, TKW_CR_SD40-2_6392, etc.

The .s and .sd files look okay to me - the images specified are present and so on (I'm pretty familar with their structure - I don't claim to be an expert though). I haven't made any changes to the files except for the name which I normalize for my personal inventory system.

I wonder why TSRE handles any problem with the shape file but Shapeviewer and ORTS don't.

The log files don't indicate any problem.

I hope this is enough info to go on, but let me know.

Thanks

David

[Lonewolf2777]

the shape files on them are not compressed they need to be set that way for OR to work for them

[OmenRotcod]

Thank you LoneWolf - I just compressed the .s file on TKW_CR_SD40-2_6392 and it's there! I have never bothered about re-compressing the .s files because I didn't think it would matter, being just a space-saving technique - but seems there's more to it than that as far as ORTS and Shapeviewer are concerned. Live and learn!

Thanks to Ged too for providing such a convenient wrapper ( FFEDIT_Sub v1.2) for the MSTS decompression/compression programs.

[OmenRotcod]

I wasn't clear there, Ged. The "name" I meant was the line that begins "Name ( " and so on. I keep a standard name (e.g., CSX SD40-2) for my inventory so that I can search for engine type and railroad reporting code. That's convenient when using TSRE or my own programs (especially my own because I can get folder and eng filename with one click and suitably formatted for the .act or .con files).

David

[slipperman]

Hi,
Thanks, David. I've deleted my original post as I realised I'd picked up the wrong download! - apologies to you and Lonewolf2777 if I misled you!

FBL_2023 and FBL_2028 both display correctly in MSTS, but not in Open Rails, until the shape files have been compressed.

Cheers,
Ged

[OmenRotcod]

No problem here, Ged. :-)

Still wondering why compression should matter though - something to do with the file format expectations of ORTS and Shapeviewer?

David

[eric]

Compression shouldn't matter. I rarely compress my shapes and they appear just fine......

Sent from my SM-S911U using Tapatalk

[uli2]

The shape file of FBL_2023 (or FBL_2028) is a copy of the shape file from the BNSF SD40-2 that came with MSTS update 1.2 ages ago. That shape has an extra '\' in line 81241. ORTS (other than MSTS) stumbles over that extra '\' and hence does not display the shape. In the ORTS log file the problem IS indicated: "Warning: Expected end of block; got '\' in c:\1msts\trains\trainset\fbl_2023\fbl_2023.s:line 81241."

Also, that shape file can not be compressed with RouteRiter or Shape File Manager. It can however be compressed with"FFEDIT_Sub v1.2". During that compression the extra '\' is somehow removed. I tried compressing and uncompressing the shape file of FBL_2023 with "FFEDIT_Sub v1.2" and the extra '\' was gone. After the '\' is removed, ORTS displays the shape regardless whether it is compressed or uncompressed.

[OmenRotcod]

That's useful to know. Fortunately, I was using FFEDIT_Sub v1.2 to re-compress, so things worked out as they should.

Thank you for the information.