An open letter to N3V engineers

[G.M.]

Samplaire i feel your pain
I took an 11 year break when TRS2006 ruined my 500+ contents for the dutch people
after return I *cough* "fixed" my content that was actually just fine.
for months I have helped the dutch creators fix things and will keep doing that as time permits


Great that Mika found the problem, figured it was a thread thing, we need to Sleep(x.x) more.


Hope that N3v once more realizes how much we depend on our content creators,
that it should be a fun hobby, not a dayly repair job or struggle.
Add features and plz. repair features that once worked.(see suggestions boxcar)
Do not destroy old working content. So backwards compatible first then take it further.


if there is anything i can do to help, so we can keep our Polish friends, let me know.
greetings G.M. (kuid:99999)

 

[hans55]

More sleep G.M.?

 

[dundun92]

Seriously, it may take a while, but he may need to update these assets. Some of his assets are old, and making trainz backwards-compatible and efficient with obsolete versions, while still tying to implement the latest features 3d gaming has to offer is hard for N3V. If an asset was made for Trainz 2009, I think they should be played in that version (if you are looking for maximum performance). N3V isn't obligated to make outdated assets to work (efficiently) with the latest versions. Its up to the content creator to update his/her own asssets.

 

[kilanziom]

I hope you reconsider your decision (especially given the strong support shown for your content here).

When you reported the bug our team investigated. This included several hours of QA time and then dev time. The issue with the rolling stock was identified as caused by a script that goes into a total meltdown when attempting to turn the headlights on. I believe you were advised of this problem at the time (if not, then that part of the process has failed).

Given that we didn't write the script and that the only content affected are items that use the script, the obvious solution is to fix the script. While earlier versions did not bring the system to its knees, it is likely that it did harm performance.

Just as we continually optimise systems, 3rd party content creators need to also optimise their systems (such as adding LODs to content, or in this case, updating the script).

I am sure that someone in the community can assist in identifying the problem and fixing it, and the same with repairing assets that are affected.

Dear Mr Hilliam,

Do you see a way in which N3V can help deal with that issue in a more comprehensive way? As was already mentioned in the discussion, the issue touches possibly hundreds of locomotives used widely all around the world. It is not possible for a single author to fix the problem all by himself and a statement such as "we optimised something and now you deal with it" is not very helpful.

Since I am an active content creator, and from what I was informed, the problem also concerns my locomotive models - I am looking forward for your help - possibly with the use of Laurinlaki (Mika)'s solution which hopefully can be adapted with the help of the Content Repair Group.

I tried to recognize my locomotive models (or their reskins) possibly created with the "problematic" scripts - counting only the ones already published on the DLS:

<KUID:547220:5101> PKP SP45-144 MD.Poznan
<KUID2:173943:100120:6> PKP SP45-222 MD.Jelenia Gora
<KUID2:173943:100260:5> PKP SP45-181 MD.Jelenia Gora
<KUID2:173943:100261:5> PKP SP45-149 MD.Jelenia Gora
<KUID2:173943:100125:4> PKP SP45-104 MD.Kutno
<KUID2:173943:100258:4> PKP SP45-035 MD.Wroclaw
<KUID2:173943:100122:4> PKP SP45-014 MD.Gdynia
<KUID2:449411:100049:1> PKP SP45-038 MD.Leszno
<KUID:449411:100032> PKP SP45-150 MD.Kamieniec-Zabkowicki
<KUID:449411:10001061> PKP SP45-152 MD.Torun
<KUID2:348858:100166:1> PKP SP45-122 MT.Chojnice
<KUID:449411:10001062> PKP SP45-006 MD.W-Wa Odolany
<KUID2:547220:5031:1> P-REG SU45-062 ZPR.Poznan
<KUID2:449411:1001017:1> PKP SU45-154 MD.Wroclaw
<KUID2:348858:100149:1> PKP SU45-242 CM.Bialystok
<KUID2:449411:1001016:1> PKP SU45-151 ZT.Lublin
<KUID2:449411:100089:1> P-REG SU45-135 ZPR.Gdynia
<KUID2:493736:1000458:1> PKPC SU45-213 ZT.Lublin
<KUID:449411:10001081> BTK-Karpiel SU45-194
<KUID2:173943:100087:5> PKPC SU46-041 ZT.Gdynia
<KUID:449411:100039> PKP SU46-037 MD.Zagan
<KUID:449411:100037> PKP SU46-031 MD.Zagan
<KUID2:348858:100228:1> PKP SU46-011 CM.Czerwiensk
<KUID2:348858:100230:1> PKP SU46-037 CM.Czerwiensk
<KUID2:449411:100010127:1> DB 233 493-6
<KUID2:173943:100345:6> DB 233 127-0
<KUID2:173943:100004:6> DB 234 551-0
<KUID2:173943:100349:5> DB 234 278-0
<KUID2:173943:100288:3> PCC BR232-446
<KUID:449411:100010156> DB 232 003-4
<KUID2:449411:10001018:1> Raildox 232 103-2
<KUID2:449411:10001010:1> Kolprem BR232-035
<KUID2:173943:100495:3> PTK-Zabrze BR232-010
<KUID2:449411:10038:4> PTK-Zabrze BR232-011
<KUID2:449411:10001076:2> Depol BR232 154-5
<KUID2:449411:10001070:2> Depol BR232-561
<KUID2:449411:10001024:2> Depol BR232-281
<KUID2:449411:10001077:2> EWR 232 401-0
<KUID2:449411:10067:3> EWR 232 579-3
<KUID2:449411:1000109:3> Pozbruk BR232-003
<KUID2:405057:100211:2> Dolata BR232-789
<KUID2:741143:100002:1> EFW 232 088-5
<KUID2:173943:100547:2> CTHS 232 002-8
<KUID2:173943:100546:2> EKO 232 850-8
<KUID2:493736:1000218:4> EWR 232 105-7
<KUID2:493736:1000528:3> DBSRP BR232-275
<KUID2:449411:10001017:2> PTK-Zabrze BR232-008
<KUID2:449411:100010125:1> Skinest BR232 408-5
<KUID2:449411:100103:3> DBSRP 232 567-8
<KUID2:493736:1000544:3> DBSRP 232 122-2
<KUID2:173943:100502:5> DB 232 301-2
<KUID:449411:100010135> DB 232 229-5
<KUID2:405057:1090:4> GySEV 651 004-9
<KUID2:173943:100274:3> PCC BR231-063
<KUID2:449411:100047:1> PHU-Lokomotiv BR231-014
<KUID2:449411:100010126:2> MTMG 648 101-7
<KUID2:405057:100533:2> MTMG 648 102-5

 

[kilanziom]

2nd part:

<KUID:449411:100010140> DR 132 172-7 Bw.Magdeburg
<KUID2:741143:100011:1> DR 132 254-4 Bw.Leipzig-Sud
<KUID2:173943:100286:2> DR 132 093-6 Bw.Saalfeld
<KUID2:741143:100010:1> DR 132 099-3 Bw.Reichenbach
<KUID:449411:100010136> DR 132 122-3 Bw.Falkenberg
<KUID2:173943:100285:2> DR 131 072-1 Bw.Arnstadt
<KUID2:173943:100287:2 DR 142 004-1 Bw.Stralsund
<KUID2:173943:100504:2> DR 130 041-7 Bw.Wustermark
<KUID2:449411:100058:1> DR 130 001-1 Bw.Wustermark
<KUID2:449411:100060:1> DR 130 023-5 Bw.Wustermark
<KUID2:449411:100061:1> DR 130 034-2 Bw.Seddin
<KUID2:547220:5122:1> ZSSK 754 071-9
<KUID2:449411:10095:1> ZSSK 754 073-5
<KUID2:449411:10001032:1 ZSSK 754 055-2
<KUID2:405057:1143:1> ZSSK 754 054-5
<KUID2:173943:100403:3> CD 754 061-0
<KUID:449411:100010115> CD 754 075-0
<KUID:449411:100010113> CD 754 006-5
<KUID:449411:100010111> CD 754 051-1
<KUID2:534300:5420909:1> CD 754 026-3
<KUID:547220:5135> ZSSK 750 183-6 SPD.Nove Zamky
<KUID2:173943:600055:1> ZSSK 750 300-6 RD.Zvolen
<KUID2:534300:8271101:1> CD 750 703-1
<KUID:534300:10042207> CDC 750 338-6
<KUID2:173943:100417:4> CDC 750 163-8
<KUID2:173943:100418:4> CDC 750 326-1
<KUID2:173943:100506:2> ODOS 750 111-7
<KUID2:173943:100330:4> ODOS 750 132-2
<KUID:449411:100010117> CDC 750 013-5
<KUID2:173943:100515:2> TSS 753 783-0
<KUID:449411:100010119> ZSSK 753 147-3 RD.Zvolen
<KUID2:173943:100046:6> ZSSK 753 053-8 RD.Zvolen
<KUID2:173943:100329:3> ZSSK 753 256-7 RD.Zvolen
<KUID2:173943:100318:5> CDC 753 073-7
<KUID2:348858:100067:2> CDC 751 141-3
<KUID:449411:10001072> CDC 751 148-8
<KUID2:173943:100492:2> ZSSKC 751 196-7 RD.Plesivec
<KUID:449411:100076> CD 751 105-8
<KUID2:173943:100468:2> ZSSKC 751 174-4 RD.Prievidza
<KUID:449411:100010107> ZSSKC 751 056-3 SRT.Kosice
<KUID:449411:10001050> ZSSKC 751 034-0 RD.Presov
<KUID2:173943:100507:2> CDC 751 316-1
<KUID2:173943:100343:1> CDC 751 335-1
<KUID:449411:10001069> CD 749 234-1
<KUID2:449411:10086:1> CD 749 248-1
<KUID:449411:10001063> CD 749 260-6
<KUID2:449411:10083:1> CD 749 039-4
<KUID2:173943:100302:5> BDZ 07.087-0
<KUID2:173943:100276:4> Transoda 181 009-2
<KUID2:405057:100079:1> Alza Cargo 181 020-9
<KUID:449411:100010144> CD 181 088-6
<KUID2:173943:100280:4> PCC 181 073-8
<KUID:547220:5195> STK 182 111-5
<KUID:547220:5194> CTL 182 160-2
<KUID:547220:5140> CDC 182 001-8
<KUID:547220:5193> CDC 182 134-7
<KUID:449411:10001088> CD 182 040-6
<KUID:449411:10001089> CD 182 143-8
<KUID:449411:10001087> ZSR 182 037-2
<KUID:449411:10001080> PTK-Rybnik E182 129-3
<KUID2:449411:100107:1> CTL 182 070-3
<KUID:493736:1000678> ID 182 097-6
<KUID:493736:1000677> PTK-Zabrze 182 153-7
<KUID:547220:5144> ZSSKC 183 005-8 RD.Spisska-Nova-Ves
<KUID2:534300:14212259:1> ZSSKC 183 044-7 RD.Spisska-Nova-Ves
<KUID2:493736:1000650:1> ZSSKC 183 029-8 RD.Spisska-Nova-Ves
<KUID:449411:10001078> ZSSKC 183 011-6 RD.Spisska-Nova-Ves
<KUID2:741143:100013:1> PKP SN61-183 MD.Szczecin
<KUID2:493736:1000510:2> CDC 122 049-0
<KUID2:173943:100522:1> CDC 122 015-1
<KUID2:173943:100523:1> CDC 122 019-3
<KUID2:173943:100432:1> CDC 122 051-6
<KUID:449411:10001021> CD 122 022-0 57E
<KUID:449411:10001090> CD 122 011-0 57E
<KUID:449411:10001092> CDC 123 020-0
<KUID2:449411:10001054:1> ZSSKC 756 002-2
<KUID2:534300:3049941:1> DBSRP 181 131-4
<KUID2:173943:100497:5> RZD TE109-026
<KUID2:449411:1000104:2> RZD TE109-017
<KUID2:449411:100097:2> RZD TE125-001
<KUID2:173943:100237:3> CSD M296.1020 PLD.Trutnov
<KUID2:173943:100238:3> CSD M296.2007 LD.Hradec-Kralove

This is what I managed to locate on the DLS from my stable. There's about twice more on the 3rd party pages, and another 50% more stil awaiting for the update (based on the original, non-fixed scripts) - and so, it was not yet re-released on the DLS. Important thing: there's a number (at least 5-6) versions of the above mentioned script. There are versions for electric locomotives with 4 animated doors; electric locomotives with 2 animated doors; diesel locomotives; diesel locomotives with steam heating; diesel locomotives with a possibility of gauge changing; diesel motor railcars...etc.

This is a huge issue, at least for my abilities. I am kindly asking for a comprehensive solution... without that I'll be forced to abandon any future updates/creation on locomotives.

 

[pware]

This seems to be a "no win" situation for everyone here.

kilanziom, are you the creator of the script that is causing the problem? If not, then who is?

The issue of N3V altering assets that are not their own has been raised in these forums many times in the past.

I do recall very clearly the firestorm that erupted here a few years ago when it was claimed that N3V were (allegedly) modifying a user created mesh to allow LODs to be added to a DLS asset. Who could possibly object to the addition of LODs which would greatly improve the performance for the game when that asset was used, but plenty of users got very heated over the issue and were highly critical of N3V for daring to alter a creator's work. It turned out that N3V were not altering the original work in any way but were investigating ways of cloning the original mesh so that the LOD meshes could be created - the only thing that would be altered was the config.txt file to add the cloned and modified meshes.

Assuming that permission from the original script creator is given and you give permission for your locos to be repaired, and the already overworked (and underpaid) CRG group (who are all volunteers from the Trainz community by the way) can find the time to do the work, then what about those locos from other creators and the locos on 3rd party web sites? Add to that the well known dangers of altering programming code (the script) created by someone else.

It is never as easy as it always seems to be.

 

[grazlash]

Isn't THIS just nasty arrogant?

No, it's not. Just a realistic use of time outside a development cycle. N3V didn't write the script or produce the assets in question, so why are you expecting them to fix it. If the script wasn't "off" in the first place, then N3V's tighter validation wouldn't have had a problem with the assets. What more do you expect of them.
Graeme

 

[samplaire]

Thank you Gentlemen! Just thank you...

I've hardly slept last night thinking about the situation (before going to bed I've read a couple of answers). My decision was desperate but I couldn't see any other option than splashing a bucket of water on the N3V team to make them sober. I guess they work hard. There is a big BUT however - observing the moves year by year (14 years?) I have the impression they go in a direction nobody asks them for. The features which are promising are abandoned (where are the slidechairs for procedural tracks for instance?) and then they develop a feature you can live without like surveyor/driver in one mouse click (it's cool, but there are more things waiting!). Why the FIND feature is broken (after activating it you have to click the window otherwise you type in the vacum) as I stated in my numerous posts, bug reports? The animated driver window is also a questionable thing... False-faulty assets in CM? Built-in missing dependencies? Free add-on packs which are incomplete? Ok, we can write more but this is not the point. The point is that when a REAL problem occurs nobody from N3V seems to be interested in repairing it or willing to help in repair. Thank god YOU are here, you the community. You are the real value of the game which is for a long time not only a product (AAAA!) but a meeting place for valuable people. Please, remember about it, oh N3V! Yes, your commercial product went its own path and became a lifestyle! Don't ruin that! I'm not a good speechman, I'm just a plain sounddesigner who loves trains (hehe - I always make a mistake typing trainz - isn't it an obsession?) but I spend 4-5h a A DAY developing, tweaking my creations (I'm very poor at Gmax/Blender but I work hard!). There are dozens of people like me all over the world. I can imagine Poland is a minor market for you (the price for the game is fair but still we are in the Europe's tail in terms of earnings) but our models, models from Polish creators are spread all over the world so you can't ignore us.


Please forget my statement from the first post but please consider cooperation both in helping us to solve the problem (logistics mainly) and please listen to us when it comes to features, bugs.

 

[chris-at-la]

Hello Trainz community!

As far as I got it, in builds higher than 105100 (according to samplaire), there is an issue inside on script which might be solved with less work per asset (according to Laurinlaki). At the moment, the real problem seems to be that this script is used very often, but noone realy knows how often.

On build 105175 (Steam version) I tested the <KUID:449411:100010156> DB 232 003-4 which is listed by kilanziom. The locomotive worked well and the game didn't freezed - even by turning on and off the light. Thus, this asset doesn't use the faulty script? Or doesn't it appear because my game version? I don't know.

To give more clearness at this point, it might be helpful if someone would explain in more detail how to detect the faulty script - in example something like "open asset for edit, go to file X, search for line (or lines) Y, if there is written Z than the asset is affected by the issue". In this way, many people here in the community can help very fast to find the assets which need to be fixed. Thus, a better estimate about the total effort to repair all might be able - or to discuss other solutions on base of a better analysis.

Best regards
chris-at-la

BTW: @samplaire I started to build my fist own route on 1st December. Of course, your tracks are included from the begin - they look amazing!

 

[kilanziom]

On build 105175 (Steam version) I tested the <KUID:449411:100010156> DB 232 003-4 which is listed by kilanziom. The locomotive worked well and the game didn't freezed - even by turning on and off the light. Thus, this asset doesn't use the faulty script? Or doesn't it appear because my game version? I don't know.

Now that's very interesting, since the above mentioned <KUID:449411:100010156> DB 232 003-4 diesel locomotive runs exactly on the same version of the script that was also used in <KUID2:173943:100087:5> PKPC SU46-041 model, and that one was reported as faulty in this thread:

https://forums.auran.com/trainz/sho...ves-are-no-longer-running&highlight=kilanziom

 

[G.M.]

Downloaded DB233 127-0 from kilanziom <kuid2:173943:100345:6>, installed it and tested in TRS19 105096 (euro version)
fine working loc, with fun features, no script errors at all.
Studied the script, its well written, uses only things as in CCP and no strange things,
not even a thread that overloads/loops too much. its just fine !
if newer versions of Trainz error this, then i dont need that version.


greetings GM.

 

[JCitron]

Now that's very interesting, since the above mentioned <KUID:449411:100010156> DB 232 003-4 diesel locomotive runs exactly on the same version of the script that was also used in <KUID2:173943:100087:5> PKPC SU46-041 model, and that one was reported as faulty in this thread:

https://forums.auran.com/trainz/sho...ves-are-no-longer-running&highlight=kilanziom

Interesting yes!

Set up a fresh data folder then install your assets that have hiccups and troubles, and test the results. It could very well be something else is causing the locomotive scripts to do weird things because of how everything interacts with everything else.

Create and empty folder.

Go into the Trainz Settings at the Launcher.

Go to Install tab.

Change the path to the empty folder.

Restart.

Go back in again and put in your user information, setup all the stuff how you want it, and test away.

I am interested in finding out the results as well.

 

[Tony_Hilliam]

Samplaire - I've sent you a PM with two updates to the script to resolve the problem.

The actual script issue is as follows:
As soon as you (or the AI) turn the headlights on the traincar script will repeatedly turn them off and on again. This quickly spirals out of control and clogs up the game in a pointless feedback loop of, lights on-turn them off, turn them on, with every change then generating two more requests to toggle it back off and on again.

Best solution is to not do that at all, as it's not good practice to override the players (or AIs) desire to have the headlights on/off. Alternatively, if the script absolutely must alter the state, it should determine the desired state and then set it once.

The reason this is new is that we fixed a bug with other content when a user pressed a button in cab. This change means that the message the script is responding to is new. It did exist in older builds, but it was posted from the old Driver UI script in response to the player pushing a UI button. It's now posted when the lights themselves actually change, hence the feedback loop.

 

[Swordfish]

...

The reason this is new is that we fixed a bug with other content when a user pressed a button in cab. This change means that the message the script is responding to is new. It did exist in older builds, but it was posted from the old Driver UI script in response to the player pushing a UI button. It's now posted when the lights themselves actually change, hence the feedback loop.

In which builds did you fix that bug and at what time?
I could imagine, that some users still have an older build without the fix and therefore no problems with Polish locomotives.
Thank you very much for your answer in advance.

Regards
Swordfish

 

[chris-at-la]

Now that's very interesting, since the above mentioned <KUID:449411:100010156> DB 232 003-4 diesel locomotive runs exactly on the same version of the script that was also used in <KUID2:173943:100087:5> PKPC SU46-041 model, and that one was reported as faulty in this thread:

https://forums.auran.com/trainz/sho...ves-are-no-longer-running&highlight=kilanziom

Until now, I assumed that build 105175 is newer than the original mentioned 105100 because of the higher number. That's the reason why I posted my test result. However, now I have taken a closer look to the build numbers, according to http://online.ts2009.com/mediaWiki/index.php/Build_Numbers these numbers (and a few other) are all the current version (but for different providers). Thus, maybe 105100 and 105175 might be almost similar (at least in the game core). I want to apologise if that caused some confusion.

In this thread, the game version which has this issue is only named as 'Beta' but without point out a specific build number. Thus, it might be possible that the issue occurs in a build after 105175 - I'm looking forward, that Swordfish's request might bring light in this topic.

 

[wreeder]

The build number of a version is assigned by the compiler when the source code is compiled. If the source code hasn't changed between compiler runs then it is the same game. It is possible for SP4 of Tane to have a higher build number than a version of TRS19 since it is just when each version was compiled. The Steam version 105175 has to be changed a small bit to work in the Steam environment. Hence a separate compiler run is needed.

William

 

[Laurinlaki]

The issue is occuring in TRS19 SP2 (currently Beta) builds, that roughly means TRS19 Builds >=109641. It can be obtained via the Platinum Edition Beta stream iirc. The current Steam version of TRS19 does not have this issue.

The error, to my knowledge, affects locomotives that somewhere in their script have functions titled "SetLamps" and "LampySpawdz". From these function, the marked lines must either be removed or commented out with a double slash

Greets, Mika

 

[clam1952]

Ouch! just tried one of the affected locos not only is it stuttering very badly, when changing view it's completely locked up TRS19 and nothing is working, just a test board so no damage done, however don't need things like that happening on an actual route requiring a hard reset as in killing TRS19 with task manager. TRS19 109641.

I've raised to option of the CRG getting involved for the DLS items, just waiting for feedback from the other two active members! yes there are only 3 of us active, so could do with some recruits!

 

[Laurinlaki]

I've raised to option of the CRG getting involved for the DLS items, just waiting for feedback from the other two active members! yes there are only 3 of us active, so could do with some recruits!

Since it involves potentially quite many pieces of content and the fact I have already done all the testing and research for finding the issue initially, I'd try to help whereever I can. I guess I'll have some more time over the christmas days...



Greets, Mika

 

[G.M.]

Before people start changing scripts, please think
-Now its 200? loco's but who knows about all content, realize there is more content outside the DLS then on
-The script itself is just fine, SetHeadlightState(true/false) is a valid way to turn headlight off/on
the script writer wanted to turn ALL lights off in "case S_NONE" there is nothing wrong with that.
-In the Trainz code there should be a way to break the(a) loop if it shows up(it did so in the past)


-Trainz should not change lights when at an industry(station), its unrealistic
not just the lights go out but also the nightmode turns off, Who wants that?
-On leaving a station lights flash?, also unrealistic and then they(and nightmode) get turned on again?
-The story misses info, how many things actually get fixed when N3v changes this
i mean why fix 1 loco/cab and break 200+ locos?


please dont correct/error stuff that is basicly ok
greetings GM