TDB Corruption on Route Save?

[eolesen]

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.







Multi-track pieces dropping one vector at random:




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?

[joe_star]

I can comment on some of them from my experience:

1) Did you run the route thru route riter CLRDB routine? I had route riter try to "clean up" switches laid in TSRE which had multiple JNODEPOSN entries in the w file. The multiple entries get written anytime you reposition a switch in TSRE after laying it.

Also, route riter throws up a ton of TDB errors for my routes edited with TSRE, especially on the TrItem side. Nothing so far that impacted performance so far though.

2) misaligned TDB lines: I experience these usually only after having "Z" ed thru them to realign track, "Z"ing back to capture the new alignment, and saving, but one end follows the old TDB line resulting in the misalignment. The fix is to delete the vectors from both sides, SAVE, then add back the vectors. This seems to save both ends correctly

Multi track vector dropping: the vector isn't dropped, but it's rotation inverted by 180 degrees in the TRVectorNode entry. If you are comfortable with TDB manual editing, the fix is easy, just correcting the vector bearing entry for that particular vector. It's easy to find as that number will stick out like a sore thumb when straight track is involved. Otherwise "Z" the entire section works as well. I notice this happens with multitrack pieces and also the vector connecting to switches when you go back in and edit a track section.

[eolesen]

Thanks for that.

1a) I did not run CLRDB yet. Last time I did, my route appeared somewhat slagged with track completely missing in areas yet TDB lines showing up (and yes, I did copy over the new W files). Fortunately I had a backup to fall back to.

1b) Yes, I've seen the multiple JNODEPOSN entries. That's something I can catch and fix via WFH (I'm working on a new version that's a little more TSRE aware).

2) If I'm reading correctly, if section B has zags, then cycling Z on sections A, B and C should clear this up?

[joe_star]

Thanks for that.

1a) I did not run CLRDB yet. Last time I did, my route appeared somewhat slagged with track completely missing in areas yet TDB lines showing up (and yes, I did copy over the new W files). Fortunately I had a backup to fall back to.

1b) Yes, I've seen the multiple JNODEPOSN entries. That's something I can catch and fix via WFH (I'm working on a new version that's a little more TSRE aware).

2) If I'm reading correctly, if section B has zags, then cycling Z on sections A, B and C should clear this up?

2) I would remove tdb for section A B C using Z, SAVE, then add them back using Z

Just cycling without the save in middle doesn’t seem to lock in the update

Also for the disappearing (ie inverted) vectors, I just noted from your screenshots they are happening on vectors connecting to a switch, exactly as i described. I used to think this only happened on edited track sections (node to node) which had interactives installed, but I have lately seen cases where it happens even on sections without interactives.

[eolesen]

Something else that might not be helping matters -- I'd enabled useOnlyPositiveQuaternions right before this sprint.

I just disabled it.

Latest issue is certain shapes not rendering. Had a SR_1tstr_w_090.s with blue poles and a yellow line but no track. It shows up fine in ORTS, and there's no error in the TSRE log...



capture__300104.jpg

[eolesen]

Tried the un-Z, save, exit, re-open, re-Z, save, exit, re-open, and all the Zigs are back.....

Ah well, that was at least worth a try.


New working theory.... these are areas where I used the Transform function to tweak the Y rotation. Perhaps that isn't doing the QDirection calc quite as cleanly as it should, or is dropping a decimal somewhere? Dunno.

Using Tangent, I went back and calculated the actual QDirections needed to hit two points. After a couple different editing sessions, the zags haven't returned, so maybe that's it. I hope not -- I'd used Transform quite a bit on realigning the 15 miles of track I did over the last two weeks, and am now paying a bit of a price for not having struck the right QD's in the first place.

[joe_star]

Thats interesting. I have never used the transform functions on track pieces, only static objects. I've always used the standard RE approach of snapping one end to the railhead and using the track elevation to adjust grade. When joining 2 sections coming from different directions, I use the elevation & rotate functions to fine tune the final joint.

[GokuMK]

This bug with last traksection wrong rotation is known, but I couldn't reproduce it, so can't fix it.

Other your problems I think is your fault, because you are a "hacker"

[eolesen]

I specifically don't hack track objects in order to avoid TDB updates...

Seriously, there's something odd going on with an array that you keep the track DB in.

If I un-Z a shape and re-Z it, it's retaining rotation and other attributes such as sticking to an adjacent piece of track at the wrong angle.

If I move that same piece without un-Z'ing and then un-Z it after moving it, the track will attach cleanly to the same adjacent piece of track.... it's like the data cleans itself up when it got moved without the TDB removal.

[GokuMK]

If I un-Z a shape and re-Z it, it's retaining rotation and other attributes such as sticking to an adjacent piece of track at the wrong angle.

joe_star already explained you that you have to un-Z adjacent tracks on both ends in case of such error, because track section position and rotation is related to a position of a previous track section in a track vector. So you don't know which one is wrong.
If you un-Z only one track section with somehow broken rotation, this rotation is moved to a new endnode. Then if you use Z again, this broken rotation stored in end node will return to a track section.