v360 thread

[GoGoran]

Print Screen works perfectly fine in fullscreen here, but it is not something Open Rails handles, it is handled by the OS, so problems with it would be down to that and/or graphics drivers (I'm using Windows 7 64bit with an NVidia card).

I hope you will implement the screenshot function of MSTS soon - in MSTS you can take lots of pictures without ever stopping the game to save them in a picture editor, it's all done by MSTS automatically.

[longiron]

I hope you will implement the screenshot function of MSTS soon - in MSTS you can take lots of pictures without ever stopping the game to save them in a picture editor, it's all done by MSTS automatically.

Your request has been added to the OR Dev Task list, but there's no promise "if" and "when" it might get done.

[lindsayts]

Probably a bit late to put this in but, just found a minor problem with OR.............

When running an activity that requires a stop at a station if you overshoot the platform even a little bit the sim does not register a stop at the station, Reversing back does not help. I do not know about other areas of the world but here in Australia there were (and still are, Donnybrook and Heathcote Junction in Victoria spring to mind) plenty of stations around with platforms shorter than the train and it is usual to stop the rear of the train in the platform. These does not register as a stop in OR.

Lindsay

[longiron]

Lindsay,
We noticed that when developing the Activity Monitor and thought we had addressed that issue. Bug report back on the TO DO list.

[csantucci]

I can also confirm that that bug exists.

Carlo

[High Iron]

I have been building a route and have been testing it in OR. One of my test trains is made up of the Canadian, using FPA2 and a series of stainless steel passenger cars made by Gaetan Belanger (BLW). When the program tries to run, it comes up with an error message and can not proceed. Since all the errors in the log file are compter code, I'm not sure what it's looking at. Since the log file is larger than is permitted to upload, is there somewhere I can send it for inspection? I suspect the culprits are already known issues, but I would rather be sure.

Cheers,
Thad

[twpol]

Since the log file is larger than is permitted to upload, is there somewhere I can send it for inspection? I suspect the culprits are already known issues, but I would rather be sure.

It is unfortunate that you can't upload it, as the whole load obviously provides us with the most information; however, if you can edit out the "middle", so that the first few lines up to the ====== and the last few dozen lines are included that may get us started.

[longiron]

Since the log file is larger than is permitted to upload, is there somewhere I can send it for inspection?
Cheers,
Thad

Thad,
Can you zip it up? Please send me a PM and we can work out a method of getting the OR team a copy of the log file.

[High Iron]

O.K., I was able to create a zip file with WinRar. It is now down to below limits, and complete as it should be. Thanks for your feedback.

Cheers,
Thad

[GaryG]

I have been helping Gaetan with most of his files so I had to glance at the ORTS log just posted.

All but the final two errors are caused by the "#" comment character which is ignored by MSTS but not yet by ORTS. Gaetan uses that comment method in some of his sets. Hopefully the ORTS team will adjust their parser to allow the "#" as an indicator to skip to the next ")".

The second last error (world_water_layer) is, I think, an already known problem.

The final error is fatal to ORTS and is probably in the FAeng.sms file which I'm including. I think it is an error with a Volume line between the Streams line and the first Stream definition.

I am not certain if this is the exact file in question but it might be the same error causing the ORTS crash.

GaryG

[TBlake]

I have been helping Gaetan with most of his files so I had to glance at the ORTS log just posted.

The final error is fatal to ORTS and is probably in the FAeng.sms file which I'm including. I think it is an error with a Volume line between the Streams line and the first Stream definition.

I am not certain if this is the exact file in question but it might be the same error causing the ORTS crash.

GaryG

Try changing FAeng.sms from:

ScalabiltyGroup( 5
Activation ( ExternalCam () Distance (1500) )
Deactivation ( CabCam () PassengerCam () Distance (1000) )
Streams ( 10
Volume (0.6)
Stream (
Priority ( 6 )

To:

ScalabiltyGroup( 5
Activation ( ExternalCam () Distance (1500) )
Deactivation ( CabCam () PassengerCam () Distance (1000) )
Volume (0.6)
Streams ( 10
Priority ( 6 )

This will move the Volume line outside of the ()'s for the stream section.

TBlake
'Tony'

[longiron]

All but the final two errors are caused by the "#" comment character which is ignored by MSTS but not yet by ORTS. The second last error (world_water_layer) is, I think, an already known problem.

GaryG

Gary,
As an FYI, there's a big difference between a WARNING and ERROR in ORTS. Warnings are recorded when the software encounters data definitions or other things, the software doesn't expect and potentially skips some valuable information. Many of the warnings are of that variety. Especially the #comments inside the ( ) of a parameter definition. As a technical aside, the ORTS team believes it's not best practice to put comments inside of a parameter definition ( ) when using a structured text format. It can lead to lots of problems and mis-interpretations of the author's intent by the software.

Eventually, we'll supress these Warning messages but it's important to record them during the development process to help diagnose issues.

On the other hand, an Error will cause ORTS to fail in many cases.

The ORTS team knows about the water layer issue and will not be addressing it. We are using our dev resources on a next generation water representation.

Thanks

[lindsayts]

Testing the Sudostbahn route

I am currently having a go with the Swiss Sudostbahn route. This is a very heavily scenered route. The render primitives being in the range of 1000 to a max of over 6000. Process percentages range between 160 to way over 200%. Frame rates vary between 40 to 170 fps. OR is handling this very well but crashes XP (BSOD), OR appears to be OK, that is it does not appear to be crashing the OS. There is a lot of out of memory errors in the log file from OR loading textures. Maximum memory specified by the debug screen prior to the crash was 1553 megabytes.

I am reporting this as currently it is the most resource intensive route I have come across by a real good margin and thought the developers may be interested as a worst case example.

The route by the way is amazing.

The system is an 15 750 with 4 gig of ram (XP only reports 3gig) and an NVidia GTX 260 SOC.

Just wondering if the developers would like more info or have some sugestions. The OS is XP pro service pack 2. I am currently optimising it by turning off not required services to see if it improves the situation. It is highly likely currently this route would only work on a 64 bit OS. There are reports it runs OK on MSTS with 4 gig of ram OS was not specfied.

Lindsay

[muskokaandtahoe]

I am reporting this as currently it is the most resource intensive route I have come across by a real good margin and thought the developers may be interested as a worst case example.
Lindsay

Thanks but I don't think it will be needed. The route I test on has several locations where the primitive count exceeds 10,000.

If the camera were out there in the distance and looking back at the viewer it count would be above 11,000.

[kox]

When can we expect the new preview version? I'm very curious about the advancements, and mostly about the source code from what i can see the potential of this sim Currently there aren't much news in rail simulator scene :\