Official v645 Thread

[longiron]

One thing that I am curious about is that when I run a diesel locomotive, the exhaust appears to be white, where as in the release video, it appears to be darker in color. Is this normal?

Eric,
I thought I noticed a couple of screen shots from over the pond with white smoke coming out of a diesel engine. I believe OR smoke uses your Global\Textures\Dieselsmoke.ace to color the effect.

[longiron]

I had the debug information on all the time. Render process was around 55% with very little waiting time, a few percents. Loading process was 100% during loading and 0% prior to that. Sound was at 20 - 25%

Just ran the default NEC with your activity - here's my findings: Sound Process = very stable 1% with random rises to 2%. You should not be seeing Sound Process levels constantly at the 20% -25% level, unless there's a HW issue.

Question: Do you have onboard or separate sound card?

[ericmp]

Eric,
I thought I noticed a couple of screen shots from over the pond with white smoke coming out of a diesel engine. I believe OR smoke uses your Global\Textures\Dieselsmoke.ace to color the effect.

Yes! I changed the dieselsmoke.ace file to one that was darker in color and now it looks much better. Thanks for the rapid response!

[GoGoran]

Just ran the default NEC with your activity - here's my findings: Sound Process = very stable 1% with random rises to 2%. You should not be seeing Sound Process levels constantly at the 20% -25% level, unless there's a HW issue.

Question: Do you have onboard or separate sound card?

I got a separate sound card. It's either a SoundBlaster Live!- as the driver says - or a SoundBlaster AWE32/64, I don't recall, at any rate a PCI card. Works flawlessly with both MSTS and OR v0.360, and all other games and applications !

And as I said, on other routes, with more sounds or where more sounds are actually loaded by OR, the sound process constantly lingers between 50 - 100% load !

[OTTODAD]

Running comparison tests of the PRR - East Region in MSTS and ORTS I was not aware of it's #5 Passenger views which work the same in ORTS as they do in MSTS.

https://www.otto-wipfel.co.uk/video/...enger-view.wmv

You may have to turn up the sound of your speakers to hear the music and Alt-Enter will switch to full-screen and back !

Frame Rates ?

HD TV frame rates are said to be 30 p.sec. and anything above that is not going to make much difference to the smoothness of what is being displayed !

O t t o

[OTTODAD]

There are known problems with OR and PRR-ER, due to the creative solutions the team used to make it work in MSTS. In some areas it works fine and in others ... you see what happens. We don't test against PRR-ER, nor is the OR team currently spending any time figuring out how to make the PRR-ER work.

Anything that works in MSTS must work in ORTS and BETTER !

We don't want to waste our time finding out what does work in ORTS and what does not !

O.K., it will take some time to achieve that.

O t t o

[conrail1]

Here are few bugs that I’ve come across while taking a look at v645.

So far out of the three routes I’ve looked at in v645 the Feather River Route is the only one that seems to be affected by this issue.

The signals at many of the interlockings are using the heads from the dwarf signal models?





Here’s the same interlocking but in MSTS -






I know in the v645 documentation it says that “very, very basic signaling has been introduced”, but isn’t simple block occupancy “very, very basic”? -





I also came across “flashing” signals where in this case they repeatedly changed from a “Clear” to a “Stop” indication while equipment passed through the interlocking limits -






Then there is the same issue that I’ve seen since I first looked at OpenRails v128, which I’ve been told is a transparent alpha problem -

[longiron]

Here are few bugs that I’ve come across while taking a look at v645.

So far out of the three routes I’ve looked at in v645 the Feather River Route is the only one that seems to be affected by this issue.

The signals at many of the interlockings are using the heads from the dwarf signal models?

I know in the v645 documentation it says that “very, very basic signaling has been introduced”, but isn’t simple block occupancy “very, very basic”? -

It's quite a lot more complicated than just simple block occupancy.

[twpol]

But when I launch my route Quebec - Charlevoix - OR cannot display the route and finally give me this message. I have always this error message regardless the rolling stock I used. The same rolling stock work fine in other route on OR.



I think it's an error on my route but where and what kind of files are wrong. I don't know.

This error happens when a SignalType is missing its SignalLightTex. OR is meant to just print a warning and continue but unfortunately a bug means it crashes instead. I've fixed the code so it will print a warning in the next version. You can avoid the crash by putting SignalLightTex("") in each SignalType without one - the empty value should also avoid the crash and give a warning.

[twpol]

I know in the v645 documentation it says that “very, very basic signaling has been introduced”, but isn’t simple block occupancy “very, very basic”?

The biggest issue I've found with the current WIP dispatcher is that it has a tendancy not to be fully aware - so you'll get two greens going in to a merge and reds in the middle of nowhere and things like that because it's not "understood" the whole rail network. There's plenty of work going on on this area though.

[OTTODAD]

Did some more tests to get to the bottom of this error and can not find a reason why some locos cause it.

Ran the Route Riter's 6 stock FIX options which had no effect as shown below.

No problems with any activities in MSTS.

Then there is this problem of none of my 48 MSTS MAIN routes loading in ORTS I have reported before.

So I renamed the ROUTES folder to ROUTES-COPY, created a new ROUTES folder and copied my GOLD-SPIKE route into it and had no problems running it, except for UNKNOWN locos.

Hope that this helps the team to pin down what causes these errors !

O t t o

[dennisat]

Did some more tests to get to the bottom of this error and can not find a reason why some locos cause it.

Does this apply? https://www.trainsim.com/vbts/showth...40#post1668140

[longiron]

Did some more tests to get to the bottom of this error and can not find a reason why some locos cause it.

So I renamed the ROUTES folder to ROUTES-COPY, created a new ROUTES folder and copied my GOLD-SPIKE route into it and had no problems running it, except for UNKNOWN locos.

Hope that this helps the team to pin down what causes these errors !

O t t o

Thanks for taking the time to help the Open Rails team pinpoint where there are bugs in the menu system. This is a top priority to get fixed.

[conrail1]

It's quite a lot more complicated than just simple block occupancy.

The biggest issue I've found with the current WIP dispatcher is that it has a tendancy not to be fully aware - so you'll get two greens going in to a merge and reds in the middle of nowhere and things like that because it's not "understood" the whole rail network. There's plenty of work going on on this area though.

Actually some (not all) of the automatics (on the FR Route anyway) do correctly show block occupancy when a train is in the block they protect, it’s the control point/interlockings that seem to be the problem that’s why I mentioned it.

Does anyone have any idea of what’s going on with some of the interlocking signal heads on the FR Route showing parts from the dwarf signal models?

[twpol]

Does anyone have any idea of what’s going on with some of the interlocking signal heads on the FR Route showing parts from the dwarf signal models?

I would expect it's a misunderstanding of how MSTS decides which parts of a signal model to show; OR is trying to show only the optional and not-default subobjects that correspond to the defined signal units. Obviously it's not matching MSTS in this case. It'll take time to properly investigate the individual signals.