[Goku]

eolesen, on 17 January 2021 - 08:09 PM, said:

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

These grey lines are TDB lines, not Track Section lines.

[Goku]

Genma Saotome, on 17 January 2021 - 03:29 PM, said:

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.

Just use dynamic track at the end?

[eric from trainsim]

Dynamic track is simply an ugly hack Kuju came up with when they realized that snap track didn't work for all solutions. I've successfully avoided using DT for about ten years on my three largest routes. Only one has it, and I was able to use Tim Booth's Dynatrax to create fixed pieces that used the Scalerail profile. Sadly, he's that program isn't available or supported any longer.

It also has its own issues... The run-time profile never matches up with Scalerail and that's visually distracting. I've heard it doesn't work well with UK FineScale either.

It's also not an option if you have multiple track types i.e. concrete, wood, yard or multiple track systems i.e. a mix of USTracks, DBTracks and Scalerail.

Dynamic track only supports one appearance profile.

I'm really not understanding your resistance on this... How does manually modifying the QD in the W file impact TSRE?

If you're reading each track sections XYZQD and simply chaining those into vectors, it shouldn't matter if those were obtained via snap at the time of placement or adjusted thru an offline process.

[Goku]

eolesen, on 18 January 2021 - 05:04 AM, said:

Dynamic track is simply an ugly hack Kuju came up with when they realized that snap track didn't work for all solutions.

LOL. All modern train sims use mostly dynamic tracks. Predefined tracks are just an add-on, mostly for switches. First Trainz versions had no static tracks at all. It is the proper solution, not a "hack". It the time of MSTS, static tracks were better because of memory management. MSTS required only 32 MB of ram installed. Now you have thousands more.

Ugly hack is your solution with rotating tracks around Y axis. It seems to work in most cases, but I'm not going to fix undefined issues related to it:
https://i.imgur.com/fGkoaGQ.png

eolesen, on 18 January 2021 - 05:04 AM, said:

It also has its own issues... The profile never matches up with Scalerail and that's visually distracting. I've heard it doesn't work well with UK FineScale either.

Then just make a good profile for OR?

eolesen, on 18 January 2021 - 05:04 AM, said:

It's also not an option if you have multiple track types i.e. concrete, wood, yard or multiple track systems i.e. a mix of USTracks, DBTracks and Scalerail.
Dynamic track only supports one appearance profile.

It's the fault of OR software. TSRE have support for unlimited track profiles.

[eric from trainsim]

Hmm. I haven't asked you to fix anything related to rotating tracks. I can handle that outside the editor, and TSRE reads it fine. It renders fine.

The only time errors happened with rotating track came when I used the provided Transform feature. If its not supported, put a warning on it like you did with removing TrItems, or disable the Y inputs when its a TrackObj. I've stopped using it and went back and removed the few areas where it was used. Problem solved.

But there are still other issues and nice to haves you need to look at.

Your 180* flip happens on snapped track, not something related to an end user altering QD's. I get that you can't replicate, but that doesn't mean you stop looking for a fix. Put error checking into your vector calculation routine to look for a swapped value on either side of a node member. If you can't force the error in the editor, you might need to create a test case manually.

The inability to render certain track sections isn't related to QDirection.

The only two issues I've asked you to address are those around SDL - editing for signal objects and removing the ancient limit of values 1-10.

If you don't have the time, let me know how to set this up in Visual Studio and I'd be glad to contribute some fixes. You've used some widgets that I've not worked with before.

[eric from trainsim]

The 180* flip is a pain. It's now happening on the dummy switches that I'd used to isolate where it was happening, and flipping the train path 180* instead of simply backtracking and eventually going forward.

This seems to be the tell-tale:

	TrackObj (
		UiD ( 567 )
		SectionIdx ( 24628 )
		Elevation ( 0 )
		JNodePosn ( -11557 14421 -39.6314 229.598 914.237 )
		JNodePosn ( -11557 14421 -39.6314 229.598 914.237 )
		JNodePosn ( -11557 14421 -39.6314 229.598 914.237 )
		CollideFlags ( 39 )
		FileName ( SR_1tDmy_w_020m.s )
		StaticFlags ( 00200180 )
		Position ( -39.6314 229.598 914.237 )
		QDirection ( 0 -0.749293 0 -0.662239 )
		VDbId ( 4294967295 )
	)


	TrackObj (
		UiD ( 568 )
		SectionIdx ( 24628 )
		Elevation ( 0 )
		JNodePosn ( -11557 14421 -40.1181 229.598 918.169 )
		JNodePosn ( -11557 14421 -40.1181 229.598 918.169 )
		CollideFlags ( 39 )
		FileName ( SR_1tDmy_w_020m.s )
		StaticFlags ( 00200180 )
		Position ( -40.1181 229.598 918.169 )
		QDirection ( 0 -0.749293 0 -0.662239 )
		VDbId ( 4294967295 )
	)

No idea why there would be three JDonePosn's for the first definition, and two for the second, and the first one is where this is happening:

 capture__300162.jpg (25.87K)
Number of downloads: 0

Meanwhile, the second one is fine...

 capture__300163.jpg (18.55K)
Number of downloads: 0

[Goku]

It has nothing to do with JNodePosn, dummy switches, quaternions, vector lengths, shapes, etc.

It is caused by a vector direction change bug, when you join two vectors into one. If two vectors have different direction, TSRE must flip one of them before joining them. There must be a bug, where one rotation inherited from a junction node is wrongly rotated.
Sadly, every time I try, it never occurs. So, can't fix it.
I have also build a big route myself with not even one occurrence of this bug.

Solution is simple, just stop endlessly splitting and editing your existing vectors and if you do it, check for this bug at the end and fix it. It's not a random error, that can occur on itself in other parts of the route.



Multiple JNodePosn is a minor TSRE bug indicating that you are snapping the same track a lot around. Why?

[roeter]

Strangely, I have no problem at all in reproducing this bug.
It does indeed happen if you replace track sections within a vector. Take a vector which runs from switch A to switch B, and was created by starting at A, always adding tracks in the same direction ending at B. If you remove some track and replace them, and again place these tracks going from A to B, there is no problem. But if you fill the gap going from B to A, the vector switches direction and the first section, connected to A, has flipped - but only if A is a trailing switch, that is if two tracks join together as one, seen in the direction towards B. If A is a facing switch, the problem does not occur.

As for multiple tracks connecting to the same point - this is indeed a bug in TSRE, and can happen when there are two JNodePosn close together. A good example are the slip points in UK fine scale - the switch within single and double slips in UKFS tracks are placed 1m. within the slip shape itself. When placing these slips, it often happens that new track connected to the slip shape is not connected to the end of the slip as it should be, but to the switch position within the slip. This even happens if the switch has been placed, so when there is no 'empty' position at the node where slip and switch connect (no blue pole). This problem has cost me many a wasted hour as I had to rebuild complex layouts if the error went unnoticed and the track ended up connected to the wrong node.

Regards,
Rob Roeterdink

[Goku]

roeter, on 19 January 2021 - 01:20 AM, said:

Strangely, I have no problem at all in reproducing this bug.

Can you then make a step by step guide with images?

roeter, on 19 January 2021 - 01:20 AM, said:

When placing these slips, it often happens that new track connected to the slip shape is not connected to the end of the slip as it should be, but to the switch position within the slip. This even happens if the switch has been placed, so when there is no 'empty' position at the node where slip and switch connect (no blue pole).

Nope, the new track is not connected to the full junction note. Just placed at it's position. You can easily see it by end node hidden inside junction node (blue node number hidden under red number). Don't know how it can be unnoticed, these numbers are big.


JNodePosn value is used for switch animations? And TSRE just don't remove old values when you are snapping track shape around. There is a button to fix it.

[eric from trainsim]

Interesting, Rob... What's the track center spacing for UK FineScale?

I'm not seeing this problem manifest with Scalerail where track spacing is 5m. But it's happening with Scalerail yard spacing which has track centers at 4m apart.


If the problem is editing within a vector, that makes some sense. It's easy enough to remove a vector with the Hack function, so I'll take that approach to see how well it behaves.

Would be nice if there was some ability to recreate a vector some way other than clicking each piece. It's easy enough on large track sections, but it's pretty easy to miss the 0_2m's or 0_3m's that are used for gap filling. It's also messy when you have very tight spacing on crossovers, slip switches, etc...

That's perhaps getting back to needing a TDB rebuild function that some think isn't necessary.