Comment 2 for bug 1292747

I don't know that I can answer your question as I don't think I have a working installation of MSTS-the-game but I'll look into it.

I did describe the issue as "Possible". For the world file replacement example I provided I've put textures into the routes own \snow directory -- that's where the Scalerail snow textures are as well and that works perfectly well so it may be there is not actually a problem. I've reported it out of the concern I expressed -- that track and roads are not necessarily in \global\shapes (and as I now know from your note below, not all \global\shapes are tracks or roads).

The problem seems to be that KUJU chose not to use the ESD_Alternative_Texture() parameter when they should have done so.

Anyway, it's always been my opinion the route developer should be the one who declares via data values all sorts of things, including what textures to use and so assumptions like you have here get in the way of achieving that. I think it would be better to distribute something akin to a perl script to add ESD_Alternative_Texture( 1 ) to those \global\shapes that lack the line over coding in assumptions that work only 1 way.

Last comment: I had a conversation w/ Steven Masters (Tsection.dat Master emeritus) where I said the right design for the tsection file was to NOT specify a shape file but o provide a descriptive name linked with just the dimensional specifications the actual shape should have. With that RE would guide the user to selecting the dimensional spec (via the descriptive name) and then guide the user to select the shape to use from the routes shape directory. That way you could have many identically sized shapes bearing unique textures (e.g., one 100m tangent specification displaying choice of all combinations of rusty rails vs. well used rails, concrete ties vs wood ties, dark ballast here, light ballast there, etc. etc) and so the Tsection file would not be filled with so many entries bearing identical dimensions. His reply was "Wish we understood that 10 years ago, it would have made life much easier". IOW a standard way of "replacing" a global specification with a non-global displayed shape -- exactly what I'm doing w/o the help of RE.

Dave Nelson

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of James Ross
Sent: Sunday, March 16, 2014 3:15 AM
To: <email address hidden>
Subject: [Bug 1292747] Re: Possib le Erroeneous Assumption

I guess my question is this: does MSTS use snow textures on your
modified-to-not-be-global track/roads? (Even when they don't specify as
such in the SD file.)

The code was added to fix bug 1159557 where a static shape from the
global directory was not getting snow textures, so it appears that even
though the SD file didn't say use-snow, MSTS was using snow textures.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1292747

Title:
  Possib le Erroeneous Assumption

Status in Open Rails Tracker:
  New

Bug description:
  In Shapes.cs, this code:
          /// <summary>
          /// Only one copy of the model is loaded regardless of how many copies are placed in the scene.
          /// </summary>
          void LoadContent()
          {
              Trace.Write("S");
              var sFile = new SFile(FilePath);

              var textureFlags = Helpers.TextureFlags.None;
              if (File.Exists(FilePath + "d"))
              {
                  var sdFile = new SDFile(FilePath + "d");
                  textureFlags = (Helpers.TextureFlags)sdFile.shape.ESD_Alternative_Texture;
                  if (FilePath != null && FilePath.Contains("\\global\\")) textureFlags |= Helpers.TextureFlags.SnowTrack;//roads and tracks are in global, as MSTS will always use snow texture in snow weather
                  HasNightSubObj = sdFile.shape.ESD_SubObj;
              }

  Is making an assumption that track and road shapes will always be
  found in \global\shapes. That is not at all correct. After placing
  any item from Global\shapes via the route editor a subsequent edit can
  be made in the world file to replace that shape with another and the
  later can be located anywhere. For example, this world file entry:

   TrackObj (
    UiD ( 100 )
    SectionIdx ( 25164 )
    Elevation ( -0.00261799 )
    CollideFlags ( 535 )
    FileName ( ../../routes/Goose_Island/shapes/SLW_066a_2LS_100m.s )
    StaticFlags ( 00200100 )
    Position ( 409.975 180.463 389.273 )
    QDirection ( -0.00120662 0.387776 -0.000507626 0.921753 )
    VDbId ( 4294967294 )
    StaticDetailLevel ( 0 )
   )

  As the shape used is in the route's own \shapes directory everything
  about the textures are too.

  Rather than search the path of the shape file it might be better to
  search the world file entry for the string "SectionIdx" as that will
  always mean an entry that KUJU defined as a global shape and will
  guarantee that anything KUJU did with global shapes can be always be
  done that way in OR.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1292747/+subscriptions