Olegkhim"s UZ_Jun Junctions

nicke

Appreciative Trainzer
I have used several of UZ_Jun series of junctions (turnouts - points etc) as a guide for building yards.
I successfully built a yard last week.
Today I wanted to start another yard but found all of UZ_Jun objects I had downloaded now show "faulty".
I reinstalled with 15 errors and 5 warnings showing. Also did a data repair.
They are all the 4.5 version (2017)
<kuid2:354694:20002:3> UZ_Jun_bz_4/ulica_R (and the L version) are the ones I mainly use.
I'm in Trainz+ 22.

Can anyone help with what may have happened?
Appreciate any help.
Thanks
Nick
 
I see that, that asset is used in payware and is packaged. They are used in <kuid2:354694:170027:4> which is Andrushivika to Vinnitsa UZ route. See if reinstalling this fixes them?
 
Happens if obsolete assets from "bugor" and <kuid2:298469:100002:7> S_Junction_Dispatcher have been updated.
 
N3V updated the dispatcher and over a thousand affected junctions last week. The Content Repair Group (CRG) is currently repairing many 100's more that are on the DLS. This may take some time since there are several authors of these assets and not all are known to the CRG.
 
Thank you for your replies.
I hope the CRG is now aware of Olegkhim's junctions. He has quite a few in the UZ_jun series.
Cheers
Nick
 
OK, all known Oleg Khim faulty junctions have been uploaded and should be available in 24 hours or so. Some may already be available.

Some warnings:

These assets and perhaps 1500+ similar switches by other authors are all controlled by a Dispatcher asset and the client script in the switch asset. There is a random bug that causes null errors when "wiring" these junctions with the invisible mesh. The cause of this problem is unknown but I don't believe it resides in the switch asset. Other than a red bug, the blades of the junction sometimes will not show in Surveyor but the junction works correctly.

Generally, this issue resolves itself and the blades do show in game.
 
Again - thank you Paul and the CRG team. I appreciate how monotonous it must be fixing the same thing in so many assets. Well done.
Cheers
Nick
 
Hi guys,

As Nick say : a big thanks for the tremendous work of repairing bazillons of assets :eek: !!!
If repairing some old usefull assets can be is some way rewarding, this last task must have been a real pain in the what you know :( ...

Cheers,

Philippe
 
Those updated assets from "bugor" (all "Packaged") show as "Faulty" in CM:

<kuid2:502415:101058:5>,<kuid2:502415:101065:5>,<kuid2:502415:101072:5>,<kuid2:502415:101077:5>,<kuid2:502415:101079:5>,<kuid2:502415:101089:5>,<kuid2:502415:101094:5>,<kuid2:502415:101103:5>,<kuid2:502415:102141:5>,<kuid2:502415:102148:5>,<kuid2:502415:102152:5>,<kuid2:502415:103405:4>,<kuid2:502415:103409:4>,<kuid2:502415:103414:4>,<kuid2:502415:103416:4>,<kuid2:502415:103418:4>,<kuid2:502415:103419:4>
 
Those updated assets from "bugor" (all "Packaged") show as "Faulty" in CM:
...

You don't say which version of Trainz is showing them as faulty which is important in this case.

I checked again and those assets are error free, but not warning free, in TS19 and TS22. They will be faulty in TS12 and TANE because of base script changes after Trainz Build 4.5.

If the assets were boosted to TB4.6 then validation errors, such as Level of Detail, would make them all faulty for TS19 and TS22 and they would be very unlikely to be repaired by the CRG.

The versions I see in TS19 and TS22 are not marked packaged.

Edit: Some of the dependencies have also been updated so make sure you have the latest versions.
 
Last edited:
TRS22+ Build 119450

They are all "Packaged" from "Rodnye Prostory - SND" DLC route:

z6q9ux.jpg



Once updated, all new versions are "Faulty" (CM doesn't show any obsolete related dependencies):

avwcr5.jpg
 
TRS22+ Build 119450

They are all "Packaged" from "Rodnye Prostory - SND" DLC route:

....


Once updated, all new versions are "Faulty" (CM doesn't show any obsolete related dependencies):
....

OK, thanks. There are at least 3 updated libraries including <kuid2:502415:100532:5> BGR Switch Main Library. That library is showing as available for download.

Most of the libraries had material conflict errors.

I'll post a list of affected libraries later today.
 
For anyone using Bugor switches/turnouts. The following libraries were updated as part of these repairs.

These libraries are on the DLS:
<kuid2:502415:100532:5> BGR Switch Main Library
<kuid2:502415:100158:1> BGR Switch Library Build 270712


These libraries should be available on the DLS in 24 hours or so.
<kuid2:502415:107083:3> BGR LsC9-SK8
<kuid2:502415:107019:3> BGR LsC9-SK1
 
For anyone using Bugor switches/turnouts. The following libraries were updated as part of these repairs.

These libraries are on the DLS:
<kuid2:502415:100532:5> BGR Switch Main Library
<kuid2:502415:100158:1> BGR Switch Library Build 270712

<kuid2:502415:100532:5> is already installed but doesn't prevent updated bugor's assets from being "Faulty" (as shown in screenshot above).
As of <kuid2:502415:100158:1>, I don't have <kuid:502415:100158> installed.
 
Last edited:
<kuid2:502415:100532:5> is already installed but doesn't prevent updated bugor's assets from being "Faulty" (as shown in screenshot above).
As of <kuid2:502415:100158:1>, I don't have <kuid:502415:100158> installed.

They are definitely not faulty here with the same TS22 build.

Perhaps it is just TS22 showing them as faulty when they are not. Try viewing them individually using Ctrl Shift R. That often clears the faulty label.
 
I uninstalled all bugor's assets and their dependencies then reinstalled them, now CM doesn't show "Faulties" anymore!
 
Hi Paul,

I've updated 200 items to the last occurence, and I've nearly 200 faulty assets .
Good news is there is only one fault in the same gs file :
- "VE197: Syntax error in script 'rdsjunc.gs'"
- "VE220: rdsjunc.gs(199) : parse error, line 199" or "VE220: rdsjunc.gs(217) : parse error, line 217"

The line (199 or 217) depends of the asset .
Example for the line 199 : <kuid2:502415:103202:6>
Example for the line 217 : <kuid2:354694:1250021:6>

Working with TS2019 Platinium, b.111951 .

I've opened the offending rdsjunc.gs file, in order to find what was wrong in the 199th or 217th line (comma, space, bracket, reference) but didn't found anything (I'm not expert in scripting language, sorry : I used only some logical searches and comparisons) .

Hope this helps,

Philippe
 
...
Good news is there is only one fault in the same gs file :
- "VE197: Syntax error in script 'rdsjunc.gs'"
- "VE220: rdsjunc.gs(199) : parse error, line 199" or "VE220: rdsjunc.gs(217) : parse error, line 217"

The line (199 or 217) depends of the asset .
Example for the line 199 : <kuid2:502415:103202:6>
Example for the line 217 : <kuid2:354694:1250021:6>

Working with TS2019 Platinium, b.111951 .

I've opened the offending rdsjunc.gs file, in order to find what was wrong in the 199th or 217th line (comma, space, bracket, reference) but didn't found anything (I'm not expert in scripting language, sorry : I used only some logical searches and comparisons) .

Hope this helps,

Philippe

Both those assets are error free in my installation of TS19 (build 117009). Don't know if the build numbers vary between French and English/UK/Australian versions. I thought they were the same these days unlike earlier versions of Trainz.

The first asset is one of around 1000 assets repaired by N3V and all the rest were repaired by the CRG. The script is essentially the same although the CRG version has a test for the library validity. Probably not important here. The two script lines you quote contain a script function call to a "legacy_compatibility" function intended to allow session data to update from the older data format to the newer one. I'm not sure but I think your version of TS19 doesn't recognise that function. If possible, you should try and update to a later version of TS19.
 
Back
Top