Announcing Feather River Canyon Enhanced

[buzz456]

There was supposed to be an update to Feather River Canyon Extended that was sent to DTG for review and I have not seen the release of the fix. Tennessee Pass just received it's update. What is the status of the update to FRC Enhanced?

The FRCE patch was provided to DTG some time ago and has been going through QA. We're expecting it to be released in the coming days. The TP patch was prioritized because it addressed a couple key issues related to playability.

No offense intended but FRC Extended has been out since February 15th. One would think that DTG could process a patch faster than 30 days or HIS could release a temporary patch as other developers have in the past.

They did release it just not here. http://milepostsimulations.com/download ... Patch1.zip

[Cardinal51]

That file name has TP in it. Isn't that Tennessee Pass ?

[buzz456]

Oops. My bad. Should read more carefully.

[AmericanSteam]

One of the issues it has are the switch post stanchions are reversed. If you read through some of the older posts you will see more items. The reversed stanchions are prevalent on many other routes. They should be green for straight and red for diverging. If I remember, Donner Pass, The older Feather River Canyon, Soldier Summit-Helper to SL and Provo to SLC and a few more. There is a fix in the library that can be added to any of these routes. https://railworksamerica.com/index.php/download-library/miscellaneous-files?view=document&id=56:donner-pass-switch-target-fix&catid=23:miscellaneous-files
I would suggest to making a file structure pathing to inside the .ap rather than applying to the .ap so it will not be over written.
Note this only works for the red/green stanchions. One of the many issues when things are copy/pasted.

[jalsina]

It also has the HasSpeedsigns flag set to 1 in the RouteProperties.xml, which is wrong, no matter what you say.

Tracks type speed limits seem to be a sort of problems in many of the routes released. For example, Tehachapi Pass at the sortie of the eastern yard for example. And it has not been fixed after years of release.

[jalsina]

I would suggest to making a file structure pathing to inside the .ap rather than applying to the .ap so it will not be over written.

This you suggest is a policy by DTG. It´like trying to delete the career scenarios.

[GreatNortherner]

It also has the HasSpeedsigns flag set to 1 in the RouteProperties.xml, which is wrong, no matter what you say.

Even the original Kuju routes have it set to 1, as do most or perhaps even all of the DTG routes. If you create a new route from a template in the editor, it defaults to 1, too. Unrelated to whether you personally like how the game HUD reacts to speed limits at this setting or if you prefer how it does it when it's set to zero, it seems to me that 1 is the default setting for this parameter.

Cheers,
Michael

[jalsina]

It also has the HasSpeedsigns flag set to 1 in the RouteProperties.xml, which is wrong, no matter what you say.

Even the original Kuju routes have it set to 1, as do most or perhaps even all of the DTG routes. If you create a new route from a template in the editor, it defaults to 1, too. Unrelated to whether you personally like how the game HUD reacts to speed limits at this setting or if you prefer how it does it when it's set to zero, it seems to me that 1 is the default setting for this parameter.

Cheers,
Michael

I will say that "again". I have documented that for a few years years now (here in this RWA forum and in Steam).
When you create a route for the first time, the blueprint sets HasSpeedSigns to zero.
When you clone routes, HasSpeedSigns changes from 0 to 1 or it doesn´t change at all, if it was set to 1. That change in clonings from 0 to 1 is a core error.

I am not too prolific in routes, but I have a few more than 70 routes, most from DTG. I have not been required to fix that flag in so many routes during these years. Actually, I realized about that when I worked in the FRC extension, where I rebuilt all speed signs and signals in the extension.

But this is not the point.
If that flag is set to 1, you will not be able to see most of the speed limit changes in F3 or F4 (no matter what you want to convince me of). You will only be able to see those speed limits designed in the track.
If you don´t know the route, the career scenarios (which I never play with) will make you mad. For example, you will be running at 60 mph and suddenly you will fall into a change to 25 mph, without any warning at all (other than seeing the speed change post aside the track).

Obviously, a route designer, knows exactly where the speed changes are located (those designed by the track and those set by a speed limit post), but not their customers.

[GreatNortherner]

Hi jalsina,

When you create a route for the first time, the blueprint sets HasSpeedSigns to zero.

This is definitely not what happens in my Railworks. And I've just tried it:
1) create a new route from template (in this case, the Kuju Oxford Paddington entry in the list that comes up after clicking the "new route" button
2) select the new route in the routes list in the Build menu and open its folder
3) the route properties.xml shows <HasSpeedsigns d:type="bool">1</HasSpeedsigns>

In other words, this has to be the default setting, i.e. it's not "wrong" nor a bug even if you might not like the implementation of it when playing the game. This might also explain why cloning reverts that to 1 if it had been set to 0 before, as the cloned route receives a new RouteProperties.xml automatically.

If that flag is set to 1, you will not be able to see most of the speed limit changes in F3 or F4

When that is set to 1, you will only see the speed signs that have been linked to the tracks (no matter where the signs' 3D models are on the map -- what matters is where the gizmo got linked to the tracks). All of them will show up on the F3/F4 HUD. If there are any unannounced speed limit decreases then that's a spot where the route builder(s) forgot to place a speed sign or there is an unintentional "stray" speed zone change (either of which then is a route bug which should be reported to the authors).

Again, I'm not trying to argue that any setting of this parameter is "better" than the other. All I'm saying is that 1 is the default value for this and route builders should stick to that because that way it creates the HUD behavioiur that most players have been used to since the Kuju days.

Cheers,
Michael

[jalsina]

II don´t think I will keep discussing this point. After all, I will never have the experience you have in route design.

Only this:
Are you aware that the old Feather River Canyon (00000062-0000-0000-0000-000000002016) has this code in its RouteProperties.xml, inside the .AP?:

Code: Select all

<HasTimeZoneSet d:type="bool">0</HasTimeZoneSet>
<HasSpeedsigns d:type="bool">0</HasSpeedsigns>
<WorkshopId d:type="sUInt64">0</WorkshopId>
<WorkshopBy d:type="sUInt64">0</WorkshopBy>


Other routes (with an .ap compressed file) like Soldier Summit, New York-New Haven or Tehachapi Pass have the flag set to 0. And I am sure that those that have a 1 in that flag, are wrong.
Anyway, thank you for such a wonderful route. I have enjoying it and I´ll keep doing so.

[GreatNortherner]

Are you aware that the old Feather River Canyon (00000062-0000-0000-0000-000000002016) has this code in its RouteProperties.xml, inside the .AP?:

Code: Select all

<HasTimeZoneSet d:type="bool">0</HasTimeZoneSet>
<HasSpeedsigns d:type="bool">0</HasSpeedsigns>
<WorkshopId d:type="sUInt64">0</WorkshopId>
<WorkshopBy d:type="sUInt64">0</WorkshopBy>


Thanks, I wasn't aware of this -- though it explains why there were no buried speed signs at switches, sidings, etc. on the original route. We have placed those in the expanded version, so that 0 setting in the route properties is no longer be needed to see the speed restrictions on the HUD.

In a way, I suppose that confirms what we've both been saying. One thing which I'd like to adjust in my earlier statement is that "wrong" or "right" don't seem to be the appropriate terms, but rather it depends on whether the route has track linked speed signs installed, crucially including the buried ones, or if it doesn't have them (in which case it then absolutely needs that speedsigns=0).

Cheers,
Michael

[jalsina]

Thanks, I wasn't aware of this -- though it explains why there were no buried speed signs at switches, sidings, etc. on the original route. We have placed those in the expanded version, so that 0 setting in the route properties is no longer be needed to see the speed restrictions on the HUD.

Talking here, only of the first FRC route. If I remember well, all speed limits from Oroville to Keddie were set by track. There were no errors, I believe.
But there were some speed posts from Crescent Mills to Keddie with some errors around the tunnels arriving Keddie. I fixed those when I did the major revamp of the extension speed limits and signals. I renamed that route FRCX and I could not released in RWA because the original author of the extension, he just did not want to. So a few friends got my modified route.
For the FRCE new route I did not check if these errors in the Crescent Mills branch were finally fixed.

In a way, I suppose that confirms what we've both been saying. One thing which I'd like to adjust in my earlier statement is that "wrong" or "right" don't seem to be the appropriate terms, but rather it depends on whether the route has track linked speed signs installed, crucially including the buried ones, or if it doesn't have them (in which case it then absolutely needs that speedsigns=0).
Cheers,
Michael

There are actually, a lot of DTG routes (Europe and USA) with the HasSpeedSIgns set to 1 (that were released with the flag value to 1 (as FRCE and Saluda Grade), which I will keep believing it´s wrong (to release them that way), because it makes some speed limits invisible in F3 and F4.
There are also a lot of complaints in forums, specially in Steam, about this issue. Many that complaint don´t know how to fix it (even telling them how to solve it), because they are incapable of editing an .xml file.
Here is a recent example:
https://steamcommunity.com/app/24010/discussions/3/4356746201399899207/?tscn=1715348700
You may find several hundred of this kind of complaint along the years.

[AmericanSteam]

Has been released, however I have not been able to download it as of yet. Has anyone been able to download?

[buzz456]

D/l here.

[AmericanSteam]

D/l here.

Can you check the conductors side wiper on the U30B and see if it works? Still no update here.