Problems with several VSR Station Platforms between T:ANE & TRS19

I'm not sure if I am the only person that's encountered this but I have stumbled across an odd problem with 6 of the VSR station platforms by Bloodnok. What to me is odd about this, is out of the total number of these stations it's only happened to 6 of them and the stations still work fine in T:ANE.

The issues are with

<kuid2:60850:22017:2> Station Platforms 02 210m Curved VSR
<kuid2:60850:22001:2> Station Platforms 02 130m VSR
<kuid2:60850:22020:2> Station Platforms 02 210m VSR
<kuid2:60850:22004:2> Station Platforms 02 130m Wide VSR
<kuid2:60850:22029:1> Station Platforms 02 260m VSR
<kuid2:60850:22021:2> Station Platforms 02 210m Wide VSR

Somehow TRS19 seems to have stripped away EVERY attachment point these assets have and there seemingly isn't a way to correct the issue. I have deleted the assets completely and tried to redownload them from the DLS but have had the same problem each time, I've tried manually importing them as a .CDP file from T:ANE and again in produces the same error and even tried re-importing them from a .CDP made in TRS19 after confirming they were working but still these errors remain so I am wondering if I am the only person that has experienced this?

Thanks

I wonder if this is related to some of my passenger enabled platforms losing some of their attached track. The track is attached in 6 sections, (strung between 7 attachment points) and on seemingly random occasions I will find one or more sections missing. Don't know how to provoke it deliberately, so hard to reproduce on demand. I'll be working in Surveyor, all tracks accounted for. Then try a Driver test. Sometimes during the Driving, a section will go missing or only after returning to Surveyor. The same platforms work without issues in TANE and previous versions.

I saw this on a route I downloaded, but could never figure out what was causing the problem.

martinvk said:

I wonder if this is related to some of my passenger enabled platforms losing some of their attached track. The track is attached in 6 sections, (strung between 7 attachment points) and on seemingly random occasions I will find one or more sections missing. Don't know how to provoke it deliberately, so hard to reproduce on demand. I'll be working in Surveyor, all tracks accounted for. Then try a Driver test. Sometimes during the Driving, a section will go missing or only after returning to Surveyor. The same platforms work without issues in TANE and previous versions.

Click to expand...

I wish this was one or two sections, but this is literally EVERY attachment point. I've just wiped my data folder in case it's corrupted and I'll attempt to download them again. I'll have to see if there's perhaps a specific download that can reproduce the error or whether it happened on random chance. The annoying thing is I couldn't even get at the IM or attachment mesh to manually fix the problem either.

**UPDATE**

So downloaded them again onto a fresh data folder and the assets are faulty still. Maybe worth a bug report

JCitron said:

I saw this on a route I downloaded, but could never figure out what was causing the problem.

Click to expand...

Nice to see I'm not alone with this. Did you ever have any theories?

Prince271088 said:

I'm not sure if I am the only person that's encountered this but I have stumbled across an odd problem with 6 of the VSR station platforms by Bloodnok. What to me is odd about this, is out of the total number of these stations it's only happened to 6 of them and the stations still work fine in T:ANE.

Click to expand...

This problem does not appear in any tests so far (Build 98592). Can you confirm that this includes the track, passengers, the platform number marker, and the stopping point markers.
The mesh comes from the library <kuid2:60850:90302:4> VSR Station Platforms - Brick Asphalt Mesh Library. Check that only one version of this library is installed. When the mesh from this library is examined in AssetX or Trainz Mesh Viewer are the attachment points listed?
If the library is OK and the attachment points in the mesh in the library are OK then the problem is likely in the script. Or, mesh aliasing might be subject to some sort of timing issue.

SailorDan said:

This problem does not appear in any tests so far (Build 98592). Can you confirm that this includes the track, passengers, the platform number marker, and the stopping point markers.
The mesh comes from the library <kuid2:60850:90302:4> VSR Station Platforms - Brick Asphalt Mesh Library. Check that only one version of this library is installed. When the mesh from this library is examined in AssetX or Trainz Mesh Viewer are the attachment points listed?
If the library is OK and the attachment points in the mesh in the library are OK then the problem is likely in the script. Or, mesh aliasing might be subject to some sort of timing issue.

Click to expand...

Ok so I am running Build 98952, I have tried this on my current data file and also on a fresh data file and managed to get the same issue both times.
The attachment points affected are every attachment point on the associated asset this includes the markers, passengers and track
I went and checked the mesh library and that seemingly was the problem. I think where an older version of the platforms had been installed it added <kuid2:60850:90302:1> and that's what has thrown everything off. I removed the mark 1 version and the other assets in question have corrected themselves.

Thank you very much for that

Prince271088 said:

I went and checked the mesh library and that seemingly was the problem. I think where an older version of the platforms had been installed it added <kuid2:60850:90302:1> and that's what has thrown everything off. I removed the mark 1 version and the other assets in question have corrected themselves.

Click to expand...

This is a known issue with the obsoleting process. It seems that sometime about the time of T:ane release a change was made to the obsoleting rule when a mesh is referenced in a library. If more than one library version exists and either one generates a fault, then the asset is recorded as faulty. So if, for instance, a library update is released that includes new meshes, any assets that use those new meshes won't work if the original version of the library is already installed, because one version of the library doesn't include those meshes. You have to ensure only the latest version of the library is installed. N3V has been asked to fix this, but nothing has happened. They don't even document this 'feature'.

Yeah that's understandable. I mean I had the latest version installed because they were built-in to TRS19 so not quite sure where I managed to pick up the older version from. That being said I have so many .CDP files that it could have honestly come from any number of places. For now I am just happy it's fixed and in future if I notice other assets with similar issues I am going to now know the first place to look.

Bit of a bump, I know, but I'm having a similar problem.

Using the "VR Unballasted Track 10m" <kuid2:103475:28019:1>, the track doesn't appear at all, in Surveyor or in the content preview window. No attached track, no nodes for either the track or the roadbed, though the roadbed spline does appear and can be connected to despite the lack of nodes. When part of a previously existing route when it worked, the track appears, but the ends are folded up as sometimes happens when bugs occur, but it doesn't appear to be connected correctly (but this may be related to the 'folding', I'm not sure).
I've tried re-downloading, changing build versions of the asset, TRS 2019 is fully up to date, I had a poke around in the config and mesh attachment points, all seems to be in order, tried removing the script, no change, tried comparing it to the built in 130m version, same build version, but builtin, which seems to change everything. Tried copying the script from the builtin one, no luck as there seems to be some kind of DRM on the built-in scripts.
I've checked for all the dependencies, they all look good, no updates, none faulty.
Has anyone got any ideas? Or should I contact the content author (s301), see if they know anything? (The build version is 2.9, which is an unsupported build version, so I don't know if I should put in a bug report for TRS.)

Thanks in advance.
Edit:


Also having the exact same problem with: "VR Unballasted Track 50m" <kuid2:103475:28020:1>

rexhunt said:

Bit of a bump, I know, but I'm having a similar problem.

Using the "VR Unballasted Track 10m" <kuid2:103475:28019:1>, the track doesn't appear at all, in Surveyor or in the content preview window. No attached track, no nodes for either the track or the roadbed, though the roadbed spline does appear and can be connected to despite the lack of nodes. When part of a previously existing route when it worked, the track appears, but the ends are folded up as sometimes happens when bugs occur, but it doesn't appear to be connected correctly (but this may be related to the 'folding', I'm not sure).
I've tried re-downloading, changing build versions of the asset, TRS 2019 is fully up to date, I had a poke around in the config and mesh attachment points, all seems to be in order, tried removing the script, no change, tried comparing it to the built in 130m version, same build version, but builtin, which seems to change everything. Tried copying the script from the builtin one, no luck as there seems to be some kind of DRM on the built-in scripts.
I've checked for all the dependencies, they all look good, no updates, none faulty.
Has anyone got any ideas? Or should I contact the content author (s301), see if they know anything? (The build version is 2.9, which is an unsupported build version, so I don't know if I should put in a bug report for TRS.)

Thanks in advance.
Edit:
pic removed from comment

Also having the exact same problem with: "VR Unballasted Track 50m" <kuid2:103475:28020:1>

Click to expand...

This is an issue with the procedural track and not related to the fixed-track stations which is another animal altogether. Your problem is related to uneven track. On junctions ensure they are flat and there is plenty of stretch between the spline points. Sometimes it helps to add in an extra spline point where the ties don't render properly. For you track stretches without ties, try a similar thing with an extra spline point and ensuring the track is flat.

I guess I explained myself poorly.
That pic was from where the industry had been placed on hte route in a previous version of Trainz (possibly TANE? it was a while ago), and the track on the industry (without ballast) had disconnected from the track around it; a train can't roll across that track without derailing.

I hope this pic explains it better:


When placing the industry, there is no track attached, and no spline points, even for the roadbed which is a spline that can be attached to, but still with no dotted outlines (nodes/spline points). This seems to be at least somewhat related to the problems experienced upthread.

Edit: for those unfamilar with the specific asset, it's a section of unballasted track that will unload ballast hoppers as they move over it, and the ballast level will rise accordingly. The track is meant to be between the 2 blue arrows, and the buried brown is the road bed spline. In the background is a 130m version that is working, but is built-in, and too long for my use.
I just checked, and adding ballast using the 'properties' tool in surveyor, the animation appears to be not working either.

Okay. That makes a bit more sense. The asset may have a script error or some other kind of issue which causes it not to load properly such as the mesh-library mentioned above that's also breaking the station platforms as well. My recommendation, at this point, is to find something else that will work in its place, at least for now. There are many, many invisible industry tracks that are suitable. Check out the new BI3 industries by MSGSAPPER. The names begin with SAP, or have SAP in the name, and are on the DLS.

rexhunt said:

When placing the industry, there is no track attached, and no spline points, even for the roadbed which is a spline that can be attached to, but still with no dotted outlines (nodes/spline points). This seems to be at least somewhat related to the problems experienced upthread.

Click to expand...

If it's the same problem the fix will be the same - make sure that there is only one version of the mesh library that these assets use If they do not use a mesh library, or if there is only one installed version of the library they do use, then the problem is different.

Recent versions of Trainz have tightened the rules about the path defined by the vertices in the attached track container. At the same time, some assumptions were made about how legacy path definitions were meant to function: in particular, it was assumed that if there were two attachment points with exactly the same coordinates then they were meant to be connected. This was suitable where the content creator was placing the attachment points visually, as it was extremely unlikely that two points that weren't meant to connect would be placed with exactly the same values. But those content creators who carefully positioned their attachments using the actual coordinate values found their content behaving in very strange ways. The symptoms are what you describe: the ends of attached track appear to connect back on themselves, and the connection circles are not displayed (because the attachment point is now considered an internal connection point).

The fix is to adjust the attachment point coordinates so that they differ - I haven't tested how much difference is required, but I suspect it is very small. Check the attachment points for the mesh for the asset you are trying to use. If they are exactly the same then this is the problem.

Note that I have assumed this behaviour is deliberate - it has not been documented anywhere that I can find, so it might be a bug.

SailorDan said:

The fix is to adjust the attachment point coordinates so that they differ - I haven't tested how much difference is required, but I suspect it is very small. Check the attachment points for the mesh for the asset you are trying to use. If they are exactly the same then this is the problem.

Note that I have assumed this behaviour is deliberate - it has not been documented anywhere that I can find, so it might be a bug.

Click to expand...

You're absolutely right!
I used the PEVsoft Attachment Maker to change a cloned version, both the roadbed and track attachment points were 5m out from the origin on either end, so I moved the roadbed attachment points out by 1m, and it works!


(the cloned one is at the bottom, originals above)

Thanks so much for your help! I'm off to modify the originals, happy Trainzing!

Sounds like this is all tied in with the return of the infamous spline detaching from fixed object then freezing bug, which has already come up.

Can N3V not maintain a stable version of this software which doesn't break either past bugfixes or content which is tried, trusted and in use by a large number of route authors? And before anyone says anything, it should not be up to asset creators to spot changes N3V make to their code that render stuff broken. We were lectured at great extent a while back by N3V about the need to keep backward compatibility, rather than pushing forward with an all new version yet here we are just down the road with changes that break said content (seemingly) anyway.

Vern said:

Sounds like this is all tied in with the return of the infamous spline detaching from fixed object then freezing bug, which has already come up.

Can N3V not maintain a stable version of this software which doesn't break either past bugfixes or content which is tried, trusted and in use by a large number of route authors? And before anyone says anything, it should not be up to asset creators to spot changes N3V make to their code that render stuff broken. We were lectured at great extent a while back by N3V about the need to keep backward compatibility, rather than pushing forward with an all new version yet here we are just down the road with changes that break said content (seemingly) anyway.

Click to expand...

It sounds like N3V "fixed" something else and broke these. At least we haven't gone back to the hairball spline issue we had in TS2010.

Yeah, I remember trying to edit double track, I forget which version, and having all sorts of trouble, splines going everywhere, nodes dissappearing. Glad that one's sorted now.