-
-
I have uploaded the profiles to the file library (fileid 89703 and 89704). So for now they are available here, on GitHub, and the DBTracks profiles are also on tssf.eu.
There are 114 profiles for DBTracks and 16 for USTracks. Should be for all track variants, but let me know if it isn't and I will probably add more. Also let me know if there is any weird stuff happening with some of them and I will try to fix it.
Requires at minimum Open Rails version T1.5.1-1390, or Open Rails NYMG rev. 160.2. If you are using those versions or newer you should be able to just plop them into the "<route folder>/trackprofiles" folder and then have it work.
Philip has created a fix for the Dynatrax issues, but it hasn't been merged yet as of writing this. Once it is, super-elevation should also work properly with Dynatrax generated track provided you manually add "Dynatrax-*" to the IncludedShapes parameter in one of the profiles. All Dynatrax track will then use that profile by default, and if you want to use a different profile for some of the DynaTrax shape files you can then rename those shapes to include the track variant prefix. All of this is described in the readme.
And of course a profile can still be copy/pasted and named TrProfile.stf to use it for standard dyntrack like in prior versions of Open Rails.
If you decide to use them, have fun! 😀Comment
-
Hi pgoenbaek, I just wanted to thank you for doing this work as it's already helping me in my own route renovation projects and has greatly improved OR's compatibility with the lovely DBtracks and UStracks systems. Are you aware of Phillip's PositionControl feature? This allows control of the appearance of the elements of the track in superelevated curves. I've attached a sample of my personal modifications made to the embankment track sections like the US2he profile. Phillip discussed the use of this feature in the Multiple Track Profiles thread on Elvas Tower:HTML Code:https://www.elvastower.com/forums/index.php?/topic/38114-multiple-track-profiles/page__view__findpost__p__312048
Code:LODItem ( Name ( "mb_trackbed" ) TexName ( "US_Rails2.ace" ) ShaderName ( "BlendATexDiff" ) LightModelName ( "OptSpecular0" ) AlphaTestMode ( 0 ) TexAddrModeName ( "Wrap" ) ESD_Alternative_Texture ( 1 ) MipMapLevelOfDetailBias ( -1 ) Polyline ( Name ( "mb_trackbed_ballast_left_outer" ) DeltaTexCoord ( 0.2 0 ) Vertex ( Position ( -4.2500 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.7300 ) PositionControl ( "Inside" ) ) Vertex ( Position ( -3.0600 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.9180 ) ) ) Polyline ( Name ( "mb_trackbed_ballast_left_inner" ) DeltaTexCoord ( 0.2 0 ) Vertex ( Position ( -3.0600 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.8200 ) ) Vertex ( Position ( -2.6720 -0.1752 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.7300 ) ) ) Polyline ( Name ( "mb_trackbed_ballast_right_inner" ) DeltaTexCoord ( 0.2 0 ) Vertex ( Position ( 2.6720 -0.1752 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.7300 ) ) Vertex ( Position ( 3.0600 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.8200 ) ) ) Polyline ( Name ( "mb_trackbed_ballast_right_outer" ) DeltaTexCoord ( 0.2 0 ) Vertex ( Position ( 3.0600 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.9180 ) ) Vertex ( Position ( 4.2500 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 0.0 0.7300 ) PositionControl ( "Inside" ) ) ) ) LODItem ( Name ( "mt_embgreen" ) TexName ( "US_Emb1.ace" ) ShaderName ( "TexDiff" ) LightModelName ( "OptSpecular0" ) AlphaTestMode ( 0 ) TexAddrModeName ( "Wrap" ) ESD_Alternative_Texture ( 1 ) MipMapLevelOfDetailBias ( -1 ) Polyline ( Name ( "mt_embgreen_left_outer" ) DeltaTexCoord ( 0.1 0 ) Vertex ( Position ( -21.3000 -16.7500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 0.9980 ) PositionControl ( "None" ) ) Vertex ( Position ( -5.3000 -0.7500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.7527 ) PositionControl ( "Inside" ) ) Vertex ( Position ( -4.3000 -0.3700 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.8622 ) PositionControl ( "Inside" ) ) ) Polyline ( Name ( "mt_embgreen_left_inner" ) DeltaTexCoord ( 0.1 0 ) Vertex ( Position ( -4.3000 -0.3700 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.8622 ) PositionControl ( "Inside" ) ) Vertex ( Position ( -3.0500 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.9717 ) ) ) Polyline ( Name ( "mt_embgreen_right_inner" ) DeltaTexCoord ( 0.1 0 ) Vertex ( Position ( 3.0500 -0.3500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.9717 ) ) Vertex ( Position ( 4.3000 -0.3700 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.8622 ) PositionControl ( "Inside" ) ) ) Polyline ( Name ( "mt_embgreen_right_outer" ) DeltaTexCoord ( 0.1 0 ) Vertex ( Position ( 4.3000 -0.3700 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.8622 ) PositionControl ( "Inside" ) ) Vertex ( Position ( 5.3000 -0.7500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 -0.7527 ) PositionControl ( "Inside" ) ) Vertex ( Position ( 21.3000 -16.7500 ) Normal ( 0 1 0 ) TexCoord ( 1.0000 0.9980 ) PositionControl ( "None" ) ) ) ) )Comment
-
Thank you for posting this. I had no idea this existed but I absolutely love it.
I was actually considering to request something like this being added over in the elvastower thread. There are things that were annoying me like the overhead wires in DBTracks not being aligned properly with the masts for super-elevated track. PositionControl is obviously the solution to that.
If you think you have something that's an improvement to the USTracks profiles you are welcome to make a pull request with it on GitHub if you know how to do that. Otherwise I can add it for you (with credit of course).
Now that I know of this there are definitely updates coming up. Thanks again for making me aware of this.
Comment
-
I have uploaded updated versions of all profiles with the PositionControl parameters. They are currently waiting in the approval queue and will become available at some point with the same fileid's. Until then you can grab them from GitHub.
The previous versions can essentially be thrown in the trash. The new ones are much better.
And thanks again sim-al2 for sharing this.
Comment
-
Hello,
I have version DBTracks-stf-profiles_v1.0.6, but seems that issue with Dynatrax is still not fixed.
TrProfile ( Name ( "DB2" ) IncludedShapes ( "DB2_*, Dynatrax-*" ) LODMethod ( 0 ) ChordSpan ( 1 ) PitchControl ( "ChordLength" )
This is the filter i used in profile. For orginal dbtracks and "clean" dynamic track profile works correctly for me.
Can anybody advise if issue with Dynatrax will be fixed? Thank you
Comment
-
Hi StormerDSR,Hello,
I have version DBTracks-stf-profiles_v1.0.6, but seems that issue with Dynatrax is still not fixed.
TrProfile ( Name ( "DB2" ) IncludedShapes ( "DB2_*, Dynatrax-*" ) LODMethod ( 0 ) ChordSpan ( 1 ) PitchControl ( "ChordLength" )
This is the filter i used in profile. For orginal dbtracks and "clean" dynamic track profile works correctly for me.
Can anybody advise if issue with Dynatrax will be fixed? Thank you
It should work how you are doing it now once this pull request is merged into the Open Rails codebase: https://github.com/openrails/openrails/pull/1029
Prior to that pull request Open Rails only looks for curve data in the global tsection.dat while curve data for Dynatrax sections are actually defined in the local tsection.dat. So until then it is necessary to take the curve data from the local tsection.dat and also define it in a route-specific global tsection extension for it to work.
You can use this python script to create a global tsection extension with that curve data for all Dynatrax sections in your route: https://github.com/pgroenbaek/dbtrac...te_tsection.py.
Keep in mind this is a somewhat hacky workaround that may require a bit of technical know-how. But I know that other people than myself have used it successfully for their routes.
The script will not do anything to the normal local/global tsection.dat located at "<route folder>/tsection.dat" and "<global folder>/tsection.dat". It will only cause problems if you already have a file extending the global tsection.dat at "<route folder>/OpenRails/tsection.dat".
Be sure to back up before you do anything just to be safe. Otherwise the solution is to just wait, because that pull request will get merged eventually
Comment
-
Peter,
Can these changes be added to the global tsection?
If so, then would it not be better to do that?
We can then get to a wider audience.Comment
-
Hi Derek,
Do you mean adding it to the standardised global tsection?
If so, not at all. This is going to be unique to every route, because the problem here is Dynatrax generated track that have replaced regular dyntrack using Norbert's dpp profiles. Meaning that even though the track is defined as TrackObj's in the world files the SectionIdx's used are actually still dyntrack with an id of 40000+ defined in the local tsection.
The script I mention above just adds that curve data to the extension file as a hacky workaround. Where the TrackShapes and TrackSections put into the global extension file also have id's over 40000. Solely so that Open Rails has that curve data available because it assumes that is where the data is. The PR I mention above fixes all this so that none of it is necessary.
What you really might be suggesting here is adding every route's local tsection to the standardised global tsection.dat. If we did that we would run out of id's almost immediately.
Comment
-
Hi Peter,
Thanks for that explanation.
Route specific items are not my target.Comment
-
For some context, under the hood OR combines all TSection files into one great big list, but route-specific track sections are entered differently than global ones, and that difference means a tiny bit of extra processing is needed for the system to figure out how the track section is (re-)constructed. Before it would search for data that route-specific sections don't have, and when that data was missing it just gave up.
Microsoft may have been a little crazy when they decided to allow this, because it's evidently a mess.
Contributing to ORTS since 2023
Find me on GitHub @SteelFill
Like what I do? Join my Patreon to help me do more!Comment
-
Hello,
I made some additional testing. Renamed profile to TrProfile_A1t.stf and changed some filters, to include standard shapes from xtrack, which are in global tsection.dat.
TrProfile ( Name ( "A1t" ) IncludedShapes ( "A1t*, A2t*" ) LODMethod ( "CompleteReplacement" ) ChordSpan ( 1 ) PitchControl ( "ChordLength" ) PitchControlScalar ( 10 ) IncludedTextures ( "acleantrack1, acleantrack2")
I noticed that only some shapes are changed to dbtracks (not all intended). In one place shape A1t100mStrt.s was changed correctly, but the same shape placed somewhere else was not changed at all. If my presented "setup" is correct then i think that track profiles needs a lot of improvement from openrails side to works as expected.
Comment
-
Hi StormerDSR,
Do I understand correctly that you are trying to replace all the default tracks in the route?
If so, it will be helpful to understand what Open Rails actually use the profiles for. I can explain it briefly. And don't worry, you can do what you're trying to do, just not by only using the profiles.
So, in order for Open Rails to super-elevate track in curves all of that curved track essentially gets replaced with dynamic track. And all the profiles do is tell Open Rails how to generate this dynamic track so that it looks exactly like Norbert's DBTracks shapes. They are not going to replace the tracks in the entire route.
This is why you're only seeing DBTracks styled track in the curves right now.
In order for your entire route to be DBTracks you'll need to substitute all the track shapes in the world files with Norbert's shapes.
For example:
Here you would change "A2t2000r5d.s" into "DB2f_A2t2000r5d.s". Or some other DBTracks variant. You can get all of Norbert's shapes here.Code:TrackObj ( UiD ( 1 ) SectionIdx ( 59 ) Elevation ( 0 ) CollideFlags ( 39 ) FileName ( A2t2000r5d.s ) StaticFlags ( 00200180 ) Position ( -437.631 11.7179 -780.654 ) QDirection ( 0.00283393 -0.32811 -0.00098434 0.944635 ) )
(Also, please don't do this by hand or for each world file individually. Programs like Notepad++ or VSCode can do it for all files in a folder at once)
Once you do this you also do not need to change anything in the profiles apart from the Dynatrax stuff.
Comment
-
Yes, My route has dbtracks placed the way you described and additionally dynatrax shapes on the curves. I just thought that track profiles takes into consideration all filtered shapes not only on curves and make this test just out of curiosity. As I write in previous post, some straight shapes like A1t100mStrt.s was replaced also by trackprofile but not in every place, so if track profiles should works only on curves then this is a bug For now I'm waiting for dynatrax correction for track profiles in Openrails.
Comment
Comment