[eric from trainsim]

OK, I'm running into a couple issues.... has anyone else experienced this with TSRE?

1) Random pieces of track are disappearing. Today it was SR_END_W_03Dx2.s and SR_1TSTR_W_090M.s sections, in areas I hadn't touched for weeks.

2) TDB lines which used to be connected are somehow disconnecting...

3) TDB lines dropping without having been Z'd....

Broken TDB lines... I can fix them, save, close, and they'll be broken again after a subsequent save.

https://1.bp.blogspot.com/-kj36sX9MZKw/X-uP_jHKU6I/AAAAAAAAdJg/fO2ajugdSM8LHXjSEvb97U9c9fr7ZO1_QCLcBGAsYHQ/s1920/capture__300042.jpg
https://1.bp.blogspot.com/-lz7dgNmnNSo/X-uP_YHlqPI/AAAAAAAAdJc/GCDt8tEOjIYFBUUPKczohm-diwgwS9QrACLcBGAsYHQ/s894/capture__300043.jpg
https://1.bp.blogspot.com/-5z2rARLSnq4/X-uP_ZmQyqI/AAAAAAAAdJY/B09tzuyd-w4Z6EKXn-Sc4OC2kqdWbhfygCLcBGAsYHQ/s881/capture__300044.jpg
https://1.bp.blogspot.com/-MWL0QhjuY1w/X-uQARbShlI/AAAAAAAAdJw/e_zVbU21AGQ--xS_TUJI_kiAfU64s3owwCLcBGAsYHQ/s516/capture__300050.jpg


Multi-track pieces dropping one vector at random:

https://1.bp.blogspot.com/-t-8reCXK9Sk/X-uQBKm8IZI/AAAAAAAAdKE/_5YB44UGmaEtHDjYVW0ybO2tufz-OG8MACLcBGAsYHQ/s609/capture__300092.jpg
https://1.bp.blogspot.com/-y5p7CRc7FHI/X-uQBfYcqcI/AAAAAAAAdKI/n4QTMJ4ST6cyQhISEyAkPNfGMUGRqyJMwCLcBGAsYHQ/s774/capture__300093.jpg

My guess... there's an issue with the calculations that is causing the vectors to break and skew when being written to the TDB. The track in the W files hasn't been changed (although I didn't check to see if the non-rendered track was still in the W file and simply didn't render...).


A couple of these are on very long vectors (i.e. 5-8 miles without a node) so I'm wondering maybe it's just a different manifestation of "broken coupler syndrome" and the vectors need dummy nodes added to break things up?

[eric from trainsim]

In the last two photos above, I showed multi-track pieces randomly losing the vector connected to the SWT piece. That's not what's happening. The vector is actually being created, but it's 180* in the wrong direction.

I've recreated this multiple times using the SR_1tswt_w_im03dl and SR_1tswt_w_im03dr with both single and multi track sections being connected to the JNode.

It doesn't matter if the axis end of the connected piece shares the XYZQD of the swt or not. I've even gone as far as to rip out all of that track and replace it with new.

And yet the problem persists... Any idea why that might be happening?

[eric from trainsim]

For the issue of pieces "disappearing", it seems to be related to the method of reading in the shapefile from Global\Shapes.

Quote

1) Random pieces of track are disappearing. Today it was SR_END_W_03Dx2.s and SR_1TSTR_W_090M.s sections, in areas I hadn't touched for weeks.

I think I've figured out what's causing this, but no idea how to address it.

Here's what the TSRE log.txt says when I place a SR_1tstr_w_090m.s or SR_1tstr_c_090m.s:

[I] "engItemSelected"
[I] "E:/Dropbox/MSTS/global/shapes/SR_1tStr_w_090m.s"
[I] found :  0
[I] "placeTool"
[I] 1:  -11546   -14423   187.83   190.404   650.047
[I] 2:  -11546   -14423   187.83   190.404   650.047
[I] "trackobj"   "SR_1tStr_w_090m.s" 593
[I] Nowy  651  shape:  "E:/Dropbox/MSTS/global/shapes/SR_1tStr_w_090m.s"
[I] "E:/Dropbox/MSTS/global/shapes/SR_1tStr_w_090m.s|E:/Dropbox/MSTS/routes/cnw-harvard/textures"
[I] #SFile - undefined token "@@\u0000"

That last line is presumably why the shape won't render...

If I decompile and uncompress the shape, it renders....

I've found 53 Scalerail shapes in total that can't be opened in TSRE while in binary compressed form due to undefined token issues (they're not all @@\u0000):

										
SR_1tSwt_w_im03dR_Div.s						@@\u0000
SR_1tBrg_c_0150r10d.s						i
SR_1tBrg_w_0150r10d.s						i
SR_1tCrv_c_00100r03_5d.s						@@\u0000
SR_1tCrv_w_00100r03_5d.s						@@\u0000
SR_1tEnd_c_03dx2.s						@@\u0000
SR_1tEnd_c_05dL.s						@@\u0000
SR_1tEnd_w_03dx2.s						@@\u0000
SR_1tEnd_w_05dL.s						@@\u0000
SR_1tEru_c_06d.s						@@\u0000
SR_1tEru_w_06d.s						@@\u0000
SR_1tStr_c_090m.s						@@\u0000
SR_1tTun_c_05dL.s						@@\u0000
SR_1tTun_c_Crv_02000r10d.s						@@\u0000
SR_1tTun_w_05dL.s						@@\u0000
SR_1tTun_w_Crv_02000r10d.s						@@\u0000
SR_1tWye_c_a10.s						@@\u0000
SR_1tWye_c_m10.s						@@\u0000
SR_1tWye_w_a10.s						@@\u0000
SR_1tWye_w_m10.s						@@\u0000
SR_1tYrd_c_0250r05dG.s						\u0087
SR_1tYrd_w_0250r05dG.s						\u0087
SR_2tBrg_w_1500r05d.s						@@\u0000
SR_2tCrv_c_03000r05d.s						@@\u0000
SR_2tCrv_w_00150r05d.s						@@\u0000
SR_2tCrv_w_03000r05d.s						@@\u0000
SR_2tStr_c_200m.s						\u0096
SR_2tStr_n_500m.s						@@\u0000
SR_4tStr_c_080m.s						@@\u0000
SR_4tStr_c_150m.s						@@\u0000
SR_4tStr_w_080m.s						@@\u0000
SR_4tStr_w_150m.s						@@\u0000
SR_City_4LStr_080m.s						`
SR_Country_2LCrv_0250r20d.s						@@\u0000
SR_Hiway_4LStr_050m.s						@@\u0000
SR_Town_2LCrv_0200r10d.s						å
SR_Town_2LCrv_1000r01d.s						[
SR_Town_2LCrv_1500r10d.s						@@\u0000
SR_Town_2LStr_040m.s						d
SR_Town_Repl03.s						¡
SR_Urban_4LCrv_1500r20d.s						@@\u0000
SR_Urban_4LStr_090m.s						`
SR_XtBrg_n_0500r10dA.s						ã
SR_XtCrv_c_00700r05dA.s						\u0088
SR_XtCrv_w_00700r05dA.s						\u0088
SR_XtEnd_c_05dLA.s						@@\u0000
SR_XtEnd_c_05dLB.s						@@\u0000
SR_XtEnd_c_05dLD.s						@@\u0000
SR_XtEnd_c_05dLE.s						@@\u0000
SR_XtEnd_w_05dLA.s						@@\u0000
SR_XtEnd_w_05dLB.s						@@\u0000
SR_XtEnd_w_05dLD.s						@@\u0000
SR_XtEnd_w_05dLE.s						@@\u0000

If you decompile these with Decomp or FFEDITC_UNICODE, they render just fine...

I can't imagine these are the only shapes that might be compromised, but I only had time to check the 3100 or so Scalerail/Scaleroads shapes.

(this was posted on Trainsim.com back on 01/01, and I've yet to see a response)

[eric from trainsim]

On the issue of random zigs and zags where the TRANSFORM Y was used:

I was able to recreate in a blank route....

1) Lay six sr_3tstr_y_100m pieces in a row
2) Save/exit TSRE
3) Re-open TSRE
4) transform piece C rotate Y by 0.4
5) snap connect piece D
6) transform piece D rotate Y by -0.4
7) snap connect piece E and F
8) Save/exit TSRE
9) Reopen TSRE
10) Lines appear broken at C-D and D-E

I was also able to go in, select and un-Z the entire vector, save/close, re-open, re-Z the entire vector, close, reopen, and it would break again.

This is on a route that I've never run WFH on, btw...

The exponential values in the QD appear a bit troubling -- I don't recall ever seeing that in MSTS created W files.

TDB entries

				TrackNode ( 39
			TrEndNode ( 0 )
			UiD ( -11907 13931 6 0 -11907 13931 855.63141 164.81444 -946.8053 0 3.1415896 0 )
			TrPins ( 1 0
				TrPin ( 40 0 )
			)
		)

TrackNode ( 40
			TrVectorNode (
				TrVectorSections ( 6
          2 23619 -11907 13931 12 4 5 00 -11907 13931 856.32965 164.814 -346.80728  0 3.1415901 0 
          2 23619 -11907 13931 11 1 0 00 -11907 13931 856.32965 164.814 -446.80728  0 3.1415901 0 
          2 23619 -11907 13931 10 1 0 00 -11907 13931 856.32965 164.814 -546.80743  0 3.1415901 0
          2 23619 -11907 13931  9 1 0 00 -11907 13931 856.32965 164.814 -646.80743  0 3.1415901 0     <--- UID 9 zigged
          2 23619 -11907 13931  8 1 0 00 -11907 13931 855.63165 164.814 -746.77753  0 3.1485739 0     <--- UID 8 zagged
          2 23619 -11907 13931  6 1 0 00 -11907 13931 855.63141 164.81444 -846.8053 0 3.1415901 0 )
			)
			TrPins ( 1 1
				TrPin ( 41 1 )
				TrPin ( 39 1 )
			)
		)
		TrackNode ( 41
			TrEndNode ( 0 )
			UiD ( -11907 13931 12 4 -11907 13931 856.32965 164.814 -346.80728 0 6.2831826 0 )
			TrPins ( 1 0
				TrPin ( 40 1 )
			)
		)
		

W-file entries

		
	TrackObj (
		UiD ( 6 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 859.594 164.814 -946.805 )
		QDirection ( 0 0 0 1 )
		VDbId ( 4294967295 )
	)
	TrackObj (
		UiD ( 8 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 859.594 164.814 -846.805 )
		QDirection ( 0 0 0 1 )
		VDbId ( 4294967295 )
	)
	TrackObj (
		UiD ( 9 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 859.594 164.814 -746.805 )
		QDirection ( 0 -0.00349065 0 0.999994 )
		VDbId ( 4294967295 )
	)
	TrackObj (
		UiD ( 10 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 860.292 164.814 -646.807 )
		QDirection ( 0 -2.32831e-10 0 1 )
		VDbId ( 4294967295 )
	)
	TrackObj (
		UiD ( 11 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 860.292 164.814 -546.807 )
		QDirection ( 0 -2.32831e-10 0 1 )
		VDbId ( 4294967295 )
	)
	TrackObj (
		UiD ( 12 )
		SectionIdx ( 23619 )
		Elevation ( 0 )
		CollideFlags ( 39 )
		FileName ( SR_3tStr_y_100m.s )
		StaticFlags ( 00200180 )
		Position ( 860.292 164.814 -346.807 )
		QDirection ( 0 -1 0 -4.37114e-08 )
		VDbId ( 4294967295 )
	)
)

(this was also posted on Trainsim.com back on 01/01, and I've yet to see a response)

[Goku]

eolesen, on 17 January 2021 - 11:15 AM, said:

4) transform piece C rotate Y by 0.4
[..]
6) transform piece D rotate Y by -0.4

You should never use "rotate Y" on snapped tracks. It's illegal and not allowed in MSRE. It can cause undefined results.
Anyway, I did try it with A1t100mStrt.s shape and works fine. My Global has no sr_3tstr_y_100m shape.

[eric from trainsim]

It's definitely causing unexpected results...

Adjusting the QD value in the W file worked fine in MSTS, as long as it wasn't connected to another piece of track. You could change the QD in the W file, open up the MSRE, selecting the track, and it would modify that TDB vector to what's in the W file.

I can live without the Y adjust, but that 180* vector flip at a JNode is a big issue.

[Goku]

MSRE did not render yellow tsection lines like TSRE so you didn't know that it is a problem.

Why do you need such an ugly hack like rot Y on a snapped track?

180d flip is a big issue but I cant reproduce this error for testing.

[Genma Saotome]

Goku, on 17 January 2021 - 03:00 PM, said:

MSRE did not render yellow tsection lines like TSRE so you didn't know that it is a problem.

Why do you need such an ugly hack like rot Y on a snapped track?

There are the rare situations where it is necessary to "create" a skew in the track. I've done so on a couple of occasions, road and track. The easiest one to explain was a 50km tangent coming off a curve. No amount of fiddling with the curve shapes would result in the far end of the tangent landing anywhere near where it was supposed to land. The closest I got was something on the order of 25m off. But setting down 3 short tangent shapes at the start of that long run and skewing each on 1/3 of the angle necessary to achieve the correct result did work and the individual skews were so minor you really don't notice them when running over those segments of track.

I would never have been able to do that w/o the aid of the Object Rotator spreadsheet which provided me with the correct QDirection between points A and B that I then used for the long tangent as well as the QDirections necessary for the individual skews. If you havn't worked with the Object Rotator spreadsheet Goku you should check it out.

[eric from trainsim]

Goku, on 17 January 2021 - 03:00 PM, said:

MSRE did not render yellow tsection lines like TSRE so you didn't know that it is a problem.

You're wrong about that....

In the MSTS-RE, go to the View menu and select the "Track DB Lines" option and you'll have grey track DB lines above track and road sections. And yes, they did show zigged track if the vector was messed up in the TDB. That's how I knew what I was seeing when it first showed up in TSRE...

Goku, on 17 January 2021 - 03:00 PM, said:

Why do you need such an ugly hack like rot Y on a snapped track?

Sure, snap track works great for most situations, but not all. Dave's already explained it pretty well.

You might consider calculating the QDirection an "ugly hack" but when you're placing track over a long distance, but it's the way that route developers have been doing it since at least 2003 when the object rotator spreadsheet came out. I took that formula and wrapped a GUI around it to create Tangent, and the results have been foolproof regardless which utility was being used.

With photo terrain, being off by a couple meters is quite noticeable. When you need something other than a 1d or 0_5d (assuming the snap shapes provide that degree of resolution), you're out of luck. Even dynamic track has limits on what you can get for curvature.

Goku, on 17 January 2021 - 03:00 PM, said:

180d flip is a big issue but I cant reproduce this error for testing.

That's definitely a problem... Is there a way to do more logging around the TDB build routine?

What's odd is that other track sections in the vector seem to be fine. I'd think that it should be pretty easy to identify where adjacent TrVectorSection chunks have a single reversed/swapped value when compared to the other chunks in that particular TrVectorSection.

I know you've said that the geographical length of the vector doesn't matter, but I'm wondering if the length of the vector declaration in the TDB is perhaps part of the problem . I noticed tonight that one section where I've seen the 180* flip happen frequently has a pin/node where the TrVectorNode length was >16000 characters and broken up into multiple lines.

On that area, I've now added dummy nodes on either side so that the TrVectorNode is under 2000 characters and will be watching to see if those flips come back.

[Genma Saotome]

A tangental comment related to route developers getting it right: I have always wanted a route editor that let me work only in 2d to position the track path just like it was on a map (ideally actually on some sort of map). Then switch to 3d and loft a face vertically from that path. This obviously forms an intersection to the terrain. Last step: mark at several locations all changes in grade and the actual gradient. Put that line on the lofted face. This lets you see where cuts and fills are. Edit as needed. When satisfied transform the lofted face into procedural track.

Dunno if it is possible but it does handle the major problems of covering great distances in 3d with reference to any track chart.