Amtrak Empire Builder East crashes to desktop

[Procopius]

I'm installing activities on MarieaPass5 and have one problem -- Empire Builder East (amtk_eb_east.zip) crashes to the desktop when I try to open it. The player engine is SLI_AMT_EMPIRE_BUILDER\AMT_P42DC_58, and the OpenRails log says: "Information: Renumbering cab control positions from zero due to value > 0xFFFF in C:\msts\trains\trainset\SLI_AMT_EMPIRE_BUILDER\CAB VIEW\P42CAB.cvf:line 246.

CombinedControl (
Type ( CP_HANDLE COMBINED_CONTROL )
Position ( 570 288 21 42 )
Graphic ( dig_blank_lever.ace )
Style ( NONE )
MouseControl ( 1 )
NumFrames ( 18 6 3 )
--> NumPositions ( 10 1056964608 0 0 0 0 0 0 0 0 0 )
NumValues ( 10 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5125 )
Orientation ( 1 )
DirIncrease ( 1 )
)
I think the number 1056964608, in the line with the leading arrow, is supposed to have a decimal point somewhere. It is line 246 in the .cvf file. The Open Rails log says it is unable to resolve a constant value of 0xffff on that line.
--
Roger

[oper190]

Question: Are you trying to run the activity in MSTS or OR? ( You posted in the MSTS section )

I do not see any errors in the OR Log file provided. Also ran a companion SLI engine, ( don't have yours ) with the same cabview, ( same line present ), in Marias 5 and ran A-okay in OR.

[slipperman]

Hi Geary & Roger,
I think the line NumPositions ( 10 1056964608 0 0 0 0 0 0 0 0 0 ) should only contain a set of single numbers, like NumPositions ( 10 0 1 2 3 4 5 6 7 8 9 ).
Open Rails doesn't understand 1056964608 as the first position number!

Cheers,
Ged

[oper190]

Ged - Roger - though I don't have the SLI Empire Builder set, I do have the SLI Southwest Chief set, with the same engine type and the cabview that reads the same and works just fine for me, in both MSTS and OR:
cab.jpg
Note it is the exact same line in the .cvf file, so I suspect they used the same cab for both engines. Cab file is P42CAB.cvf in my set as well.

Edit - After running my explore using my train set in MP5 my OR log has the same "Information" line. That is nothing that should cause OR to drop to desktop. Basically that control just won't move in the cabview. In Roger's Log nor mine NO errors are reported to show why it would have droped out. In MSTS however many things could cause it to drop to desktop, lockup, etc. without any or incorrect explanation.

[oper190]

Did a little further investigation, that "Information" message can be totally ignored.

If you notice in the .cvf file under "CombinedControls" ( and most other control levers as well ) the line: "Graphic" indicates a blank texture which I confirmed by viewing the .ace file. Therefore there is no image to see and move so the position is pointless. You do not see the control stand anyway in the .cvf view to use the controls in cab. This has on effect in either OR or MSTS, so was not causing the issue of dropping to desktop.

Therefore some other issue is at play.

[c44d9w]

On a crash, the log file usually includes an exception, identifying where in the code the crash occurred. The attached log file does not have an exception.
Is there any on-screen indication of a problem? Or does the OpenRails window just close?

[slipperman]

My apologies, Geary and Roger. I didn't check Roger's log file! Open Rails dealt with that entry so isn't the cause of the crash, as has been mentioned by c44d9w.

Cheers,
Ged

[derekmorton]

Which brings us to the point where I don't think the log file and the crash are related.

I think that the log is from a previous run.

A crash to desktop doesn't usually leave a log, certainly not a log with that detail.

[oper190]

This goes back to my question in my first post #2 - Was Roger running MSTS or OR? This is posted in the MSTS Section.

MSTS could crash for any number of reasons, and usually without any sort of message why, or one that doesn't tell you anything useful. My experience with MSTS is if you did get some sort of message they were usually of no real help and often pointed you in the wrong direction when they made scense.

Rogers OR Log is dated 6/18 so was a resent run.

[Procopius]

I'm trying to run it in MSTS, which is where the crash occurred. It runs fine in OR. If I had the problem in OR I would post in the OR forum. Today the activity is running on MSTS, so I apologize to everybody for wasting your time. I should have tried it on MSTS again before posting my query. By the way, I don't think I've had an activity crash on OR since 2019.
--
Roger

[derekmorton]

No point attaching an OR log for MSTS

[oper190]

It seems odd that the OR log shows no errors, so there is no missing or bad rolling stock, objects or sound issues, and yet the same activity crashes in MSTS.

I've run my version of the activity in both MSTS and OR no problems, noting that I've swopped out many of the cars and engines used in the original activity.

Question for Roger - Have you swoped out any cars or engines called for in the activity as downloaded?

[crstagg]

I'm trying to run it in MSTS, which is where the crash occurred. It runs fine in OR. If I had the problem in OR I would post in the OR forum. Today the activity is running on MSTS, so I apologize to everybody for wasting your time. I should have tried it on MSTS again before posting my query. By the way, I don't think I've had an activity crash on OR since 2019.
--
Roger

That is because there is a MAJOR difference in how the programs handle data. MSTS reads into RAM the entire Trainset, all the Engines and Wagons from the folder: ......\Trains\Trainset. OR only reads into RAM the Engines and Wagons called for from the menu selection i. e. the Engines and Wagons identified in the selected Activity or in the Player consist when just exploring.

[oper190]

Another thought, if rolling stock was replaced(?), it could be possible that OR only rolling stock was used and can't run in MSTS.

With MSTS I found must haves:
ConBuilder - to check consists and loss stock and replace missing rolling stock
RouteRiter - to check Routes for missing items and replace
TrainStore - to keep what I run to a minimum, typically 2 or 3 Routes with 2 or 3 Activities in each active so I had some options of what I'd run yet no overload memory.
Bin - to improve performance

With those used I found MSTS to load quicker than out of the box, and ran well with less problems and issues, and very few crashes.

[crstagg]

Another thought, if rolling stock was replaced(?), it could be possible that OR only rolling stock was used and can't run in MSTS.

>>>>>>>>>>>>>.

Or there is OR only stock in the Trainset database and since MSTS loads all of the Trainset it choaked on the OR only item(s).

FYI MSTS cannot read Include files. If an item that is critical to MSTS is in an Include file rather than an ENG file the MSTS will choke.