Official v645 Thread

[longiron]

Three observations:

- I get wheel slip with the stock, unmodified Acela Express - on dry rails, in summertime, and it keeps slipping up to more than 120 mph ! Only above 130 or 140 mph the slip finally ends ! Until then you have to accelerate with sanders on all the time ! I bet the real Acela can accelerate at full throttle upwards of say, 20 - 25 mph, without experiencing any wheelslip on dry rails ! I dunno how the slip is calculated in OR, but obviously it's a little different from MSTS.

Currently, Open Rails uses the same parameters as MSTS for calculating wheel slip, but more realistic equations for traction. So there will be differences.

- Loading files is really a worse issue now than with MSTS. On the default NEC, the track and all scenery suddenly ended, and my train continued on into the void ! Only after some three or five seconds, the loading of the new files was finished, and the track and scenery objects showed up again !

Would you mind identifying what activity and where OR "goes off the tracks"? It really would help the team from using trial and error to reproduce the problem.

- camera zoom-out is restricted as in the stock MSTS. Should be extended to the levels of the BinPatch-MSTS, which basically allows you to zoom half a mile away from your train.

If you have a number pad, taking off the NUM LOCK with the #3 and #9 keys allows you to zoom in and out for most cameras.

[buttercup]

Minor problem in the warning message... the captured/displayed text appears to be the Static_Flags(), not the UiD(). As a result there is no telling which entry is failing, making it much more difficult to figure out and fix.

runactivity.exe : Warning : 0 : Error in D:\Program Files (x86)\Microsoft Games\Train Simulator\ROUTES\WP3\WORLD\w-012915+014330.w

Missing texture filename in forest region. UID=4294967295
at ORTS.ORTraceListener.TraceEventInternal(TraceEvent Cache eventCache, String source, TraceEventType eventType, Int32 id, String format, Object[] args)
at ORTS.ORTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)
at System.Diagnostics.TraceInternal.TraceEvent(TraceE ventType eventType, Int32 id, String format, Object[] args)
at System.Diagnostics.Trace.TraceWarning(String message)
at MSTS.Tr_Worldfile..ctor(SBR block)
at MSTS.WFile..ctor(String filename)
at ORTS.WorldFile..ctor(Viewer3D viewer, Int32 tileX, Int32 tileZ)
at ORTS.SceneryDrawer.LoadAt(Int32 tileX, Int32 tileZ)
at ORTS.SceneryDrawer.Load(RenderProcess renderProcess)
at ORTS.Viewer3D.Load(RenderProcess renderProcess)
at ORTS.RenderProcess.Initialize()
at Microsoft.Xna.Framework.Game.Run()
at ORTS.Viewer3D.Run()
at ORTS.Program.Start(IEnumerable`1 options, String[] args)
at ORTS.Program.Main(String[] args)

This may be caused by yardcam if you have it installed.

[GoGoran]

Would you mind identifying what activity and where OR "goes off the tracks"? It really would help the team from using trial and error to reproduce the problem.

Of course: On the default NEC route, with the Acela Express standard consist in explore mode, starting from Washington in direction of Philadelphia. 17:00h starting time, summer. I basically went full throttle from the start, with sanders on due to the massive and unrealistic wheelslip I was experiencing. Maybe the new OR physics model is more accurate, but almost all existing MSTS rolling stock will have to be retuned to make correct use of these new physics, but that just as an aside now. Anyway, it happened right after the first station en route, after New Carrolton. Files were being reloaded, the landscape thinned out until everything - except for the train, the blue sky and the green ground - disappeared, and it took some five seconds until everything suddenly blopped in again, and the journey continued as normal. I was using camera 4 during all that time, looking in the direction of the train, overlooking two cars plus the leading loco from a slight side angle.

I just checked the eng file of the Acela - NumWheels is set to 1, AntiSlip () has been set, too. So in MSTS you would get no wheelslip at all with this train, even in winter time heading up an icy grade ! But in OR, the slip is uncontrollable, the AntiSlip parameter is ignored !


Another, unrelated and very odd glitch I found on another route (GR Biggetal, German payware): The save game function works now, but after shutting down OR, restarting it later and resuming the saved game, the train first seemed to move uncontrollably fast - maybe due to the initial loading stutter, and then suddenly went on at 15 kmh, slowly accelerating again at full throttle ! When I had saved the game before, I was travelling at 100 kmh !

[GoGoran]

If you have a number pad, taking off the NUM LOCK with the #3 and #9 keys allows you to zoom in and out for most cameras.

Yes, I know, but you cannot zoom out as far as I would like to (and as you can do in MSTS with BinPatch 1.8). I'm sure this will be easy to fix, however.

[OTTODAD]

Try as I might, I still can not run my MAIN MSTS routes in ORTS, getting this error below every time !

O t t o

[mnjrr]

Otto, Thank you for trying to analyze the problem on your own. I can understand that is frustrating for you and others to not be able to get OR 645+ to work at this time. Please give the team more time in resolving the matter. As pointed out, we have been flooded with bug reports and other feedback. We truly greatly appreciate the train simulator community taking the time to send us these reports, which are vital to the continued development of OR. It is going to take a while for the team to process the feedback because of the large influx of messages.

The following is a message to everyone. Please remember OR is a volunteer run project in which members give up their free time to contribute to a FREEWARE product while they have jobs and families. I am sensing a troubling underlining current of urgency from certain members of the community that an issue has to be fixed now. We do not have enough personnel to jump right away to every request that comes our way. In due time, the team will process and respond to all of these requests. Please keep the feedback coming but be mindful it will take a while for the team to address. I do not want to really get into a deep philosophical discussion about my post because I would rather see this thread devoted to constructive feedback about how to improve OR and make it the best train simulator out there.

[OTTODAD]

Otto, Thank you for trying to analyze the problem on your own. I can understand that is frustrating for you and others to not be able to get OR 645+ to work at this time. Please give the team more time in resolving the matter. As pointed out, we have been flooded with bug reports and other feedback. We truly greatly appreciate the train simulator community taking the time to send us these reports, which are vital to the continued development of OR. It is going to take a while for the team to process the feedback because of the large influx of messages.

The following is a message to everyone. Please remember OR is a volunteer run project in which members give up their free time to contribute to a FREEWARE product while they have jobs and families. We do not have enough personnel to jump right away to every request that comes our way. In due time, the team will process and respond to all of these requests. Please keep the feedback coming but be mindful it will take a while for the team to address.

Thanks, Walter and the team !

I am going to keep my eyes peeled watching this thread !

O t t o

[longiron]

I basically went full throttle from the start, with sanders on due to the massive and unrealistic wheelslip I was experiencing.

I wouldn't want to be a passenger drinking a cup of hot tea with you as the engineer BTW, Open Rails has not implemented the AntiSlip() parameter.

[kox]

Currently, Open Rails uses the same parameters as MSTS for calculating wheel slip, but more realistic equations for traction. So there will be differences.

The modern AC traction have serious anti slip control systems, so constant slipping is not likely, especially on dry tracks.

see this You can hear the sounds of the four traction systems (1 system/axle), and how the anti slip throttles back when it slips. In cab you could something like this pulling a heavy freight train uphill.

Will be possible to see anti slip methods like this in or?

[twpol]

Will be possible to see anti slip methods like this in or?

I believe they are being considered with the locomotive traction work going on currently.

[OTTODAD]

I think that the pinned threads relating to the earlier versions can now be un-pinned or deleted, reducing clutter ?

O t t o

[GoGoran]

I just noticed that the power for the eng was set at 9200kW, which is twice the original value. I now set it at 6000kW, which is equal to the power of the HHP8, with which the Acela engines are related. Wheel-slip now terminates somewhere around 90 mph, which ist better, but still way too high speed for slipping.

Generally speaking, the actual wheelslip on trains is a lot less than (non-railway) people think. The OR team should seek the expertise of actual train drivers, both freight and passenger, American as well as European, to reach realistic slip values and physics in general.

Overall, I think the best idea would be to copy the MSTS physics as best as you can, since countless developpers have invested countless hours of time making their engines behave as realistically as possible within MSTS, and a new physics model, no matter how good in and of itself, will render all that fine-tuning that went into these engines (and wagons) null and void, and all the rolling stock will have to be adjusted all over again.

Another idea would be to have two different physics models, one MSTS-copy for existing rolling stock, and another one for OR-rolling stock. An additional line in the eng and wag files could mark the difference, e.g. "ORphysics (1)" for OR models. Or even "Comment ( OR physics (1) )", to keep the files backwards-compatible with the MSTS.

[twpol]

Of course: On the default NEC route, with the Acela Express standard consist in explore mode, starting from Washington in direction of Philadelphia. 17:00h starting time, summer. I basically went full throttle from the start, with sanders on due to the massive and unrealistic wheelslip I was experiencing. Maybe the new OR physics model is more accurate, but almost all existing MSTS rolling stock will have to be retuned to make correct use of these new physics, but that just as an aside now. Anyway, it happened right after the first station en route, after New Carrolton. Files were being reloaded, the landscape thinned out until everything - except for the train, the blue sky and the green ground - disappeared, and it took some five seconds until everything suddenly blopped in again, and the journey continued as normal. I was using camera 4 during all that time, looking in the direction of the train, overlooking two cars plus the leading loco from a slight side angle.

I've been unable to get any Loader Process > 25% whilst trying this so it's not immediately clear why you'd have "late" scenery. Could you repeat it with F5 showing "DEBUG INFORMATION" and see what the various Process values are when you first notice that the scenery is prematurely stopping?

[GoGoran]

I wouldn't want to be a passenger drinking a cup of hot tea with you as the engineer BTW, Open Rails has not implemented the AntiSlip() parameter.

LOL. Yeah, that explains a lot. But It will be implemented soon, I hope.

[mnjrr]

I am not a programmer, but I think it might be a while until the OR team adds the antislip parameter as the team is now focusing on reports by members of the train simulator community who cannot get the latest version of OR to work. Not to sound like a killjoy, but OR will get there in due time with adding additional features such as the antislip parameter in due time.