Open Rails

Possibly should not assume tracks/roads are in \global

Bug #1292747 reported by Dave Nelson on 2014-03-15

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Open Rails	Triaged	Low	Unassigned

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.

Tags:

Revision history for this message

James Ross (twpol) wrote on 2014-03-16:

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.

Revision history for this message

Dave Nelson (lake-muskoka) wrote on 2014-03-16: RE: [Bug 1292747] Re: Possib le Erroeneous Assumption

Download full text (5.0 KiB)

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 ...

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: bounces@canonical.com [mailto:bounces@canonical.com] On Behalf Of James Ross
Sent: Sunday, March 16, 2014 3:15 AM
To: lake_muskoka@att.net
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

James Ross (twpol) on 2014-03-28

summary:

- Possib le Erroeneous Assumption
+ Possibly should not assume tracks/roads are in \global

James Ross (twpol) on 2014-04-27

Changed in or:
assignee:	nobody → James Ross (twpol)
importance:	Undecided → Low
status:	New → Triaged
tags:	added: content graphics

James Ross (twpol) on 2014-06-17

Changed in or:
assignee:	James Ross (twpol) → nobody

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.