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

[Goku]

This rotation bug is easy to fix in editor, just double Z. No need for removing vectors or track db rebuilds.

[eric from trainsim]

I started out doing double Z. That didn't work consistently.

So far Rob's approach is working i.e. rebuilding the vector from A to B.

Hardly conclusive, but after three hours of editing, nothing that has been flipping has re-flipped.

[Genma Saotome]

Would it help if the world object marker had two colors -- one color facing the track associated to the marker and the opposite side having a different color? That would make it very easy to see where the origin point was.

[eric from trainsim]

I was thinking the same thing. There's really not a clear indicator of where the axis is on non-junction pieces. Perhaps show the t-section lines for sections before they're in the TDB.

The view menu option makes them show up as yellow once they've been written to the TDB, but there's nothing whatsoever when you Z them out of the TDB.

[Goku]

Ok, I found why you have a problem with your rotation hack:

eolesen said:

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

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

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

When you use your hack it seems to work at first:

https://i.imgur.com/nT5awpO.png
But when you return to editing this vector, splitting and joining, TSRE must flip it. And when it does it, this rotation hack will cause the flip to fail, because TSRE does not allow not matching rotations in a track vector, so the new one is broken:

https://i.imgur.com/bbVsqDA.png
If you want to use this rotation hack, avoid situations where you have to split it later. And if you have to, you must remove whole vector from TDB and add each track one by one from first to last, so that TSRE does not have to flip any vector.

[eric from trainsim]

Thanks for the explanation... I think I'll continue avoiding it for now.

[eric from trainsim]

Ok, vectors seem to be behaving better.

Looking in the TrItems in the TDB I see a half dozen EmptyItems that I'm assuming were speedposts or signals that got clobbered when a vector got changed.

If the applicable world file items referencing them are deleted, will TSRE clean these up and renumber things or should I do a CLRDB in TSutils?

[Goku]

TrItems won't renumber. Emptyitems are reused if you place new items.

[roeter]

Here are the details for the problems with UKFS slips.

1. The slip is placed, in this case a single slip. The basic shape is the cross-over only, the switches are placed within this shape.
The blue poles at the end are the connections to the tracks, the blue poles within the crossover shape are the connections for the switch shapes.
 SingleSlipA.jpg (197.46K)
Number of downloads: 7

2. The switches are placed. Note that the blue poles within the crossover have gone, those near the end have been replaced with the red switch poles.
 SingleSlipB.jpg (203.68K)
Number of downloads: 5

3. The track has been placed and has been connected to the slip - but at the wrong position. The track next to it has the same geometry but clearly, the track connected to the slip is 1m. short of its position.
 SingleSlipC.jpg (194.43K)
Number of downloads: 4

4. This shows more clearly what happened - the track has connected to the switch, and not to the 'outer' connection of the slip. Where in fig. 2 there was a red pole for the switch, there is now a blue and red pole. The track has connected to the switch and has 'undone' the connection between the switch and the slip. The blue pole at the end of the slip remains unused.
This should not be possible. There was no 'open' connection at this point (no blue pole in fig. 2 at this location).
 SingleSlipD.jpg (211.97K)
Number of downloads: 4


As for the visibility of those blue poles - yes, they are very clearly visible, if you look sideways. But if you look straight from above these are not so clear at all. Sometimes, depending on the angle, they are not visible at all. When laying track in complex areas, and that's where slips are used, I always work from straight above. It provides a better overview and it is more easy to move around and zoom in if required.

Regards,
Rob Roeterdink

[eric from trainsim]

New bug.

Laid a piece of dynamic track, 3000r -0.2 for the angle.

Selected after adding to TDB, and changed angle to -3 permile.

Poof goes the editor...

Tried again, using just the default 10m straight.

Selected after the yellow line appeared, changed angle. Poof!...

It's doing it regardless if it's attached to another TDB vector or standalone.

Pretty much makes dynamic track useless if you need to make adjustments as you go...