[Genma Saotome]

I've returned to this topic and have been creating symbolic links using something called Link Shell Extension which makes it easy to create links in Windows Explorer.

It looks like OR is having a problem with certain types of links -- Junctions work but it's looking like Symbolic Links do not, at least at the directory level.

Example:

SourceLibrary\Trainset\Wagonfolder1 has real files.
Miniroute\Trainset\Wagonfolder1 is created using a symbolic link.

A loose consist definition that specifies Wagonfolder1 within the miniroute tree fails to find the .wag file. OR throws a ignoring missing wagon error message. However, using windows explorer I can see the .wag file in the miniroute tree, open it with my editor, make changes, and see the changes over in the SourceLibrary tree. So I know at some level the symbolic link works.

Can someone verify my conclusion -- that symbolic links don't work in OR -- please?

[engmod]

Dave, What OS?

More info:-

https://msdn.microso...v=vs.85%29.aspx

[James Ross]

Genma Saotome, on 16 October 2015 - 12:37 AM, said:

A loose consist definition that specifies Wagonfolder1 within the miniroute tree fails to find the .wag file. OR throws a ignoring missing wagon error message. However, using windows explorer I can see the .wag file in the miniroute tree, open it with my editor, make changes, and see the changes over in the SourceLibrary tree. So I know at some level the symbolic link works.

Can someone verify my conclusion -- that symbolic links don't work in OR -- please?

I don't believe there's any reason symlinks wouldn't work; they're generally invisible to applications the same way junctions are.

Does the OR wagon warning include the path? Is it correct and if you paste it in to a file open dialog (of e.g. Notepad) does it open the file or say it can't be found?

[Genma Saotome]

Several errors given, all .wags mentioned have their folders created as a symbolic link:

Quote

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\GS_SP_92536\GS_SP_92536_Ld.wag:line 10

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_PRR_X29\XM_PRR_569178_LD.wag:line 6

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_GN_USRA_DS\XM_GN_23715_LD.wag:line 7

Warning: Found a suffix ')' which could not be parsed as a Distance unit in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_ATSF_142331\xm_atsf_142331_mt.wag:line 5

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_GN_USRA_DS\XM_GN_23715_MT.wag:line 7

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_PRR_X29\XM_PRR_569178_MT.wag:line 7

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_RDG_5087\XM_RDG_5087_MT.wag:line 7

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_PRR_X29\XM_PRR_571797_MT.wag:line 7

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_GN_USRA_DS\xm_gn_25096_ld.wag:line 7

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\GS_SP_92536\GS_SP_92536_ld.wag:line 10

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_PRR_X29\XM_PRR_569178_ld.wag:line 6

Warning: Ignored missing wagon E:\Bin\Open Rails - US West 1930-1952\trains\trainset\RS_SFRD_Rr_40\RS_SFRD_8225_clsd_mty.wag in activity definition Loose consist.

Warning: Ignored missing wagon E:\Bin\Open Rails - US West 1930-1952\trains\trainset\RS_SFRD_Rr_35\RS_SFRD_7145_clsd_mty.wag in activity definition Loose consist.

Warning: Ignored missing wagon E:\Bin\Open Rails - US West 1930-1952\trains\trainset\RS_SFRD_Rr_40\RS_SFRD_8220_clsd_mty.wag in activity definition Loose consist.

Taking one .wag as an example (bold, in color, above)... it's .wag:

SIMISA@@@@@@@@@@JINX0D0t______

Wagon ( xm_gn_23715_MT

	WagonShape ( GN_USRA_box_23715.s )

	Include ( "..\\Common_Model_stds\\USRA_DS_Boxcar_Tim_Muir_Model\\XM_USRA_DS_Mesh_Dimensions.inc" )
	Include ( "..\\Common_Fleet_stds\\Std_Type_Coupler_Generic_Draft_Gear.inc" )

	Adheasion ( 0.2 0.4 2 0 )

	Include ( "..\\Common_Model_stds\\USRA_DS_Boxcar_Tim_Muir_Model\\XM_USRA_DS_MTY_Weight.inc" )
	Include ( "..\\Common_Fleet_stds\\Single_Pipe_KC_Brakes.inc" )

	Sound ( "genfreightwag2.sms" )
	Name ( "XM 40' GN 23715 MTY" )
)

The error complains about line 7. That file is present and it contains this code:

	Comment ( XM_USRA_DS_Mesh_Dimensions.inc )

	Type ( Freight )
      FreightAnim ( USRA_50t_parts.s 1 1 )
	Size ( 3.1m 4.6m 13.275m )
	WheelRadius ( 36in/2 )
	NumWheels ( 8 )
	InertiaTensor ( Box ( 3.1m 4.6m 12.975m ) )

All of the .wags mentioned in the error report were functional before I created symbolic links to replace the actual folders.

Some images of the directory listing (click on image for clarity):

That shows the presence of the "common" include files as peer directories to all of the .wag and .eng folders. These are the target s for many include files specified in .wags



That shows the folders within the "Common_Model" folder.



That shows the folders from the missing in the loose consist errors.



And that shows the folder holding the .wag file I displayed above.


The editor I use, EmEditor Pro, does understand that symbolic links are present. When I have the .wag file that I example above open in my editor I can click on the filename listed in the include statement and if the path is correct it will open that file. That gives me a very handy way to make sure I have not entered a typo of some kind. Were I to make an edit and save I can go over to what I'm calling the source library and verify the edit has migrated from the virtual to the actual file.

An observation: Previously I used junctions to make copies of entire routes. No problems at all. This week I am trying Symbolic links instead of junctions. AFAICT the difference between them is I can delete the virtual side of the symbolic link w/o harming the real files whereas w/ junctions a delete on the virtual side will kill everything on both sides. If that is correct I think symbolic links would be safer for me to use and that's why I decided to try them.

Last, from the command window this string: dir e:\ /a:l /s >"%Userprofile%\Desktop\Junctions.txt" will produce a text file showing all symbolic links and junctions of the specified drive (in this example, E:). Once one goes beyond a certain number there is a need to regularly produce this information and make sure it is on a backup. I certainly would not want to do 200 links by hand a second time.

If you need to see any more examples, let me know and I'll post them ASAP.

Also, let me know if you conclude this needs a bug report and I'll create it.

[Genma Saotome]

engmod, on 16 October 2015 - 12:49 AM, said:

Dave, What OS?

More info:-

https://msdn.microso...v=vs.85%29.aspx

Win7.

This is the page I used as a guide, including downloading the plug in they mention.

[engmod]

>FreightAnim ( USRA_50t_parts.s 1 1 )

OR has been giving these errors for a while, the line should read:-

FreightAnim ( USRA_50t_parts.s 1 1 1 )

Then those OR errors will go away.
Nothing to do with links.

The 3 errors at the bottom are your link errors.

[Genma Saotome]

engmod, on 16 October 2015 - 05:25 PM, said:

>FreightAnim ( USRA_50t_parts.s 1 1 )

OR has been giving these errors for a while, the line should read:-

FreightAnim ( USRA_50t_parts.s 1 1 1 )

Then those OR errors will go away.
Nothing to do with links.

The 3 errors at the bottom are your link errors.

Derek, I don't understand. I just checked the original files, dated 2008, and they have two digits after the file name, not three. Why does three digits fix anything and when did that "fix" occur?

[engmod]

We need to ask the programmers!!

[Genma Saotome]

<sigh> 500 individual files need to be changed and each distributed over some subset of 9 instances of \trainset. At least a few of them are symbolically linked from start to end so in those cases 1 edit on one file fixed everything. I have an editor that will apply changes on filesets and that reduced the one-at-a-time-changes to ~30 files.

I found the threads discussing this... apparently the there is a third digit that is defined but KUJU allowed it to be ignored and OR does not. I didn't bother taking in what the third digit was for, only that if, in some circumstances there is a need for three, the parser isn't smart enough to accept only two the rest of the time.

I'll have to take some time tonight to spread those revised files around the \trainset folders and then will check a number of activities again.

An initial test looks like this third digit is the problem, not symbolic links -- GOOD! I'd much rather waste my time fixing the freightanim() than doing w/o those links.

[James Ross]

Genma Saotome, on 16 October 2015 - 05:00 PM, said:

Several errors given, all .wags mentioned have their folders created as a symbolic link:

Quote

Warning: When expecting a number, we found a ) marker. Using the default 1 in E:\Bin\Open Rails - US West 1930-1952\trains\trainset\XM_GN_USRA_DS\XM_GN_23715_MT.wag:line 7

Hmm, the file you highlighted above only has a warning about parsing FreightAnim - not a problem with being able to load/find it.

Genma Saotome, on 16 October 2015 - 07:08 PM, said:

<sigh> 500 individual files need to be changed and each distributed over some subset of 9 instances of \trainset. At least a few of them are symbolically linked from start to end so in those cases 1 edit on one file fixed everything. I have an editor that will apply changes on filesets and that reduced the one-at-a-time-changes to ~30 files.

I found the threads discussing this... apparently the there is a third digit that is defined but KUJU allowed it to be ignored and OR does not. I didn't bother taking in what the third digit was for, only that if, in some circumstances there is a need for three, the parser isn't smart enough to accept only two the rest of the time.

I'll have to take some time tonight to spread those revised files around the \trainset folders and then will check a number of activities again.

An initial test looks like this third digit is the problem, not symbolic links -- GOOD! I'd much rather waste my time fixing the freightanim() than doing w/o those links.

The warnings should not be preventing anything from working, except perhaps the freight animation. I'm not certain but it sounds like we might want to fix this parsing in OR as well, rather than you fixing the files.

Genma Saotome, on 16 October 2015 - 05:00 PM, said:

Quote

Warning: Ignored missing wagon E:\Bin\Open Rails - US West 1930-1952\trains\trainset\RS_SFRD_Rr_40\RS_SFRD_8225_clsd_mty.wag in activity definition Loose consist.

This is more interesting as it is a file not found. Does the path listed exist or not? Can it be opened in an editor by pasting exactly the path in to the file open dialog?

[Genma Saotome]

James Ross, on 17 October 2015 - 11:22 AM, said:

The warnings should not be preventing anything from working, except perhaps the freight animation. I'm not certain but it sounds like we might want to fix this parsing in OR as well, rather than you fixing the files.


This is more interesting as it is a file not found. Does the path listed exist or not? Can it be opened in an editor by pasting exactly the path in to the file open dialog?

Fixing the parser would please most people I'm sure. I've already dealt w/ the issue by adding a third digit.

As for the loose consist, here is a screenshot (click on image for best clarity)...

...on the left windows explorer where you can see the path at the top, the correct directory on the left and the individual file on the right... and my editor which is showing you the full contents of the .wag file. The folder for the .wag is a symbolic link (designated by the black arrow in the folder icon) and all of the include files displayed within the .wag are in folders that are also symbolic links which I've checked and are present (and may I had how wonderful it is to change a value in one of those COMMON_FLEET_STDS files and have it propagate into n number of .wag files spread across 9 \trainset directories).

I think what I need to do on my side is find some activity that has lots of loose consists containing .wags held in these symbolic links and verify they too are not found. Will advise later today on what I find.

[Genma Saotome]

Solved!

An extra underscore in the path as written in the activity file.

That means symbolic links do work as expected and when properly referenced can be a real blessing.

[James Ross]

Genma Saotome, on 17 October 2015 - 01:14 PM, said:

Fixing the parser would please most people I'm sure. I've already dealt w/ the issue by adding a third digit.

Fixed in X3841.