Port Zyd session issues in Trainz Plus.... (Proper to post here?)

1611mac

- - . -
Should a SESSION that works OK in TRS19 100240 release (latest "official" release) work OK in "stable" Trainz PLUS (103368)?

I'm only now trying some routes/sessions in Plus and finding some issues. One issue has already been posted concerning Port Zyd game (session) saves. I've also found a possible AI train issue in the Port Zyd session under the stable PLUS build. Portals are not generating AI trains in Plus as they are in stable release 100240.

Should these session issues (running under PLUS) be posted here? Or are Plus sessions not expected to be "fulling" working yet??

Thanks!
 
This is a CPC rule/Portal Problem (not AI trains problem) - I did a complete re-install of Trainz Plus. Portal problem remained. For the Session, Central Portal Control rule in PLUS install shows "ERROR" for Portal Name. I reselected the portal and reset the rule parameters and the portal then worked properly. So for some reason the portal name was "Error" in the Plus install session. Submitting a bug report.
 
This is a CPC rule/Portal Problem (not AI trains problem) - I did a complete re-install of Trainz Plus. Portal problem remained. For the Session, Central Portal Control rule in PLUS install shows "ERROR" for Portal Name. I reselected the portal and reset the rule parameters and the portal then worked properly. So for some reason the portal name was "Error" in the Plus install session. Submitting a bug report.

Question. Is the Quick Portal Manager Standard Edition enabled in the session?

If so then this maybe where the problem lies. CPC and Quick Portal Manager rely on this script to operate, and if this isn't working properly this will cause issues. PGuy (Pierre) needs to address this if this is the case since he wrote this script.
 
Hello... Point is... The exact same session runs fine in "official release" TRS19 100240 and N3V says above that if a session works in 100240 it should run with no problem in Trainz Plus 103369 which it doesn't.
 
Hello... Point is... The exact same session runs fine in "official release" TRS19 100240 and N3V says above that if a session works in 100240 it should run with no problem in Trainz Plus 103369 which it doesn't.

Yup. I agree it should work. What's interesting is something changed somewhere that broke the code and needs to look at what's broke. The thing is software is it's like a bowl of spaghetti, or a badly knotted ball of string. You pull one thing, and something else gets knotted up. In this case someone "fixed" *note the quotes* something in one place, but because of how things are intertwined, knotted, and looped together, this little tweak here or there caused something else to break.

Beta testing is not an easy task. It may seem easy, but in some ways to do it properly, it requires a set of parameters and things to follow, which we were not given. Then again this is a dual edged sword. Give testers a set of things to check, and they only check for those things. If you don't give them anything and let them have a go at the program, stuff may or may not be found, retested, or not. In this regard, perhaps N3V should consider providing a punch list to test some things they've confirmed fixed on their end, and then provide time and space to test for new stuff. (Tony does do this from time to time, but as often perhaps as he should). From experience, this sort of works, but not always.

Another issue that has come up with TRS19 is the new interface and newer ways of doing some normally used to things like search-filter/pick-lists, bulk asset replace, as two things that came across my head at the moment. (I promised I ducked though as they whizzed by!) With a new interface and new ways of doing things, the user is more inclined to miss some of the mundane things that are taking place underneath because they're focusing on new things. TRS19 has gotten better in this regard since the earlier days, I noticed that in the previous Plus patches/tests as people have gotten used to where things are, but this will always remain an issue with new things going on. Perhaps N3V should consider beta-testing interface changes only in one release, then other bugs in another. It may slow down production, but it will make things a lot cleaner too.

In this case, it maybe that no one else tested this session, or the action of those portals anywhere so that got missed, or as sometimes happens more often than not they did test them and things worked fine. Persnickitty, intermittent problems are the worst ones to find. Testers can test over, and over, and over, and over, but never find anything wrong. Then the program is released and something shows up. In other cases a problem may occur once as if the sun shone on a shiny quartz crystal at a particular angle and caused that problem on that particular day only. Rebooting, reinstalling, spinning in a chair, or going for a walk will appear to fix the problem because it never occurs again. Then the program is released and it shows up again. This is the issue that N3V faced with smokenadoes floating all over the place in T:ANE. That was a combination of things that caused that just they're facing that now with the crash at 100 km/h (65 mph or around that).

Given the very dynamic nature of computer hardware and software combinations with what's installed, OS updates (any version/company), data corruption, anti-malware program running at the time, or glitches in the hardware due to age, power, heat, dust, aliens, and anything else, it's a wonder that anything works as well as it does. This is why there needs to be as many eyes and hands on the testing process. Having a handful of programmers test their program, isn't the way to do it. It's no different than a cook tasting his or her meal, or a company such as Boeing self-test and check their airplanes... (won't go into this...!). A second set of eyes finds stuff that the creator and originator does now.

The good news is this occurs in a test release and not what would be considered a full release. With that said, if you find something report it, and get it on the list even if it appears to be a tiny thing.
 
On 10/7/19 I received a response to my Portal ticket which says:
..Thank you for contacting QA. We've opened a task for this under [FONT=arial, sans-serif]TSR 406976691
[/FONT]

Now if someone could me what a TSR is.... Is this something that can be monitored?
 
An added consideration in Beta testing:

"JCitron": One added Beta Test element is learning from the discovery of errors. Why was it coded that way? Why was it missed, etc. Need After Action Report to reduce repeating the same error again. But - more time spent and more money allocated. At some point the process must be appended or the lenders bring baseball bats to their next meeting on Late Payments.:n:

In the dark ages you coded and prayed. The process was to code, submit the written code for transcription to punched cards or mag tape. Over night processing. Then a trip to that same window to get a printout of the results. Too many trips to that window, on a project, and you go to another window to pickup your last check.
 
Thanks John for the defence - you missed the bit about "there are literally hundreds of thousands of objects that could be affected by a change. Testing them all each time is not feasible."
;)

Btw, there was a fix today for this issue (internal build).
 
RE: Internal fix... awesome!

btw.. No complaints here on testing or releases. As complex and the environment is (N3V, 3rd party, payware, freeware, etc, etc,) I think N3V does a good job considering everything.
 
Hopefully that fix will also include a repair to all of the broken multiple-industry loading and unloading scripts.
Most of my sessions involve large numbers of industries supplying and receiving goods to and from AI drivers which were all working correctly in Build 100240 and now don't in 103369.

Some are intermittently faulty (like <kuid:-25:1224> Multiple_Industry_New), but the majority, like almost ALL of the 3rd party scripted commodity loading assets (SAP, JR, TrainzPro, etc.) are comprehensively broken. i.e. they don't produce or consume the commodities they have been programmed to create or consume. This destroys interdependent industry production/ consumption chains and, ultimately, the whole point of these complex goods and services delivery sessions.
 
Back
Top