Beta build 113886 is [on hold]

the engineer side water injector for steam engines is still buggy and has not been fixed, it happens when in DCC mode when pressing the 'W' key, it was not fixed on the last build
>>
DCC mode "W" key is the speed control.
Can you be more specific about this issue so that QA can test. Include in your description what you expect to happen.


Another bug found is that the game freezes on exit as well.
>>
We're unable to reproduce a freeze on exit so it is most likely content specific. Please try and narrow down which assets/routes/sessions where this happens.​


 
I don't mind being left without a system to play with for a while.

There's not a lot more to do in the back ends of Bedfordshire


Are we talking hours or days????

Graham
 
It could be quite some time if we're unable to reproduce the problems. Usually something is identified quite quickly as to what is different between our repro and the beta tester. This time however there are people with major problems we are not seeing at all.

Also, you can simply download 111951 from MyTrainz and install that in a new location to carry on as normal.
 
Sanek17 - This is one of the most common assertion dialogs seen in beta builds - it will affect most of your home-built routes that contain legacy assets.
It can - in most cases - be simply ignored by clicking on the 'Continue' command button to resume the Surveyor or Driver session.

I'm not seeing any of the problems being reported in the thread above with this beta build, even when I intentionally try to reproduce the scenarios outlined, based on the limited information provided for repro. Even for portals with long consists and plenty of reversed locos, etc.
I noted 62 errors from 36,000+ installed assets during the TrainzUtil.exe prebuild process - but they mostly related to the 6 or so 'Out of Date' assets listed in Content Manager that I cannot actually update due to them being classified as "Packaged" (but not for my TRS19-Platinum build).
CM should not show any ineligible asset updates (for Trainz versions that individuals do not own) IMO. I don't want to see asset updates for the mobile version if I'm not running that.

Please send in detailed bug reports to QA here: https://n3vgames.typeform.com/to/xRdryu so they can be tested and addressed by N3V.
We'd all love to see an end of these beta builds and assertion dialogs with a stable end-product that everyone can rely on for their route and session-building pleasures.
 
Yes,Tony, it happens whenever you move forward and in reverse, the weird bug was found in the big steam interior and in other steam cabs, I'll post a screenshot of the culprit after I get home from work.
 
It could be quite some time if we're unable to reproduce the problems. Usually something is identified quite quickly as to what is different between our repro and the beta tester. This time however there are people with major problems we are not seeing at all.

Also, you can simply download 111951 from MyTrainz and install that in a new location to carry on as normal.


After some testing, it seems that Build 113886 is unable to recognize edits on routes that where done in previous versions of Trainz. Especially the spline editing seems to be an issue (Like it was with SP2 to SP3).

This is a example, a route done in 113547, now in 113886 track was removed. The error log says the following:
trainz-error.jpg



All I could figure out till now is that is has something to do with the Straighten Track command.



As for the run around command: it seems that signals and junctions are placed sometimes on a different layer(?) so the AI cant recognize them, even though they are visible its really wired and what makes it difficult is that its completely random! I could complete operations but then the next time I ran it, it was unable to complete the operation.


I do keep backups of the core game files every time they are updated, 113547 is the most stable release for me now so I will keep it until the issues are fixed. Maybe you should try doing something like adding an "old" folder every time a new patch is released, so reversing can be done more easily.
 
Last edited:
Is this kind of a joke?

Guys,

if you would like to keep the users motivated to do the free testing your you, then please do at least some kind of MINIMAL INTERNAL TESTING!
In 2 minutes without looking for any special issues found the following ones:
- Auto-hide the menubar is not working
- after staring a Quickdrive session (without any trains on it), the junction names are not disappearing after switching off the "Junction overlay"

How can it be that such basic things are still not working? I know it is a beta version but don't you have some automated testing or checklist before releasing a version?

Best regards,
Marc
 
I repeat myself, but build 113642 was very solid for me. All my routes from build 111951 ran well with everything working as expected. Some of the 111951 bugs, such as the height adjustment, were fixed and working well.

I have reinstalled this beta build again for further testing.
 
It is doubtful that few, if any, N3V/TRS installs are alike. Legacy code & assets may be similar but it is also a likely source for many issues. Downloaded assets and routes are probably the greatest source of customer issues.

"My routes do not work"" "All my stuff works" is not pejorative. It is a hope that all is not lost. Take the two environments and see why the difference. Do that several dozen times and you might begin to see a pattern. Chances are you will see more than one. The focus today is why are systems failing. Wrong-way-around. Why are systems succeeding? It may be a faster path to success. N3V can then tell customers to avoid certain operations. Gee, some happy customers. Move on to another customer who has problems that may also have a wide exposure. Fix them. Some more happy customers. Benefit - in addition to positive results you start to find more customers seeing their systems working when adopting the fixes. Fixes that may not seem to have any relevance to their problems. Now you get a picture of success BREEDS success. Fix one purple system which also fixes green and pastel system which were not even considered in the testing. It becomes one of those exponential progressions to a point of fewer problems to solve. .

So, when N3V asks for detailed customer testing and their reports, Skip that. Get a copy of successful systems and benchmark against other successes. Look for patterns and commonality. Look for success.
Example - working system's switches are all more than 3 meters apart......
 
For so many years I cannot understand in any way, you are fixing one thing, other problems appear, fix them, those with which you started again appear. Some kind of vicious circle. But nothing really new has appeared ... I want dynamic lighting, weather, finally the clouds are real, not flat!
 
Run around doesn't.
Points are getting stuck
Smoke does some very strange things in AI when running in reverse, OK in DCC and cab mode though.

Getting weird not seen before entries in the log, loads like this, seems to be virtually every asset, small sample below, what the heck is an Invalid Texel factor?

Code:
? <kuid2:446443:21030:1> : MeshResource::LoadResource> <kuid2:446443:21030:1> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 446443 21030 1.tzarc|
  ? <NULL> : Loading mesh gwr_gas_platform_lamp.im
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
    ! <kuid2:446443:21030:1> : Setting an invalid texel factor.
? <kuid:84912:29315> : MeshResource::LoadResource> <kuid:84912:29315> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid 84912 29315.tzarc|
  ? <NULL> : Loading mesh gwrmhdraybarrels.im
    ! <kuid:84912:29315> : VE166: 30 combined chunks (of 30 source) in .im file: gwrmhdraybarrels.im
? <kuid2:46219:50056:1> : MeshResource::LoadResource> <kuid2:46219:50056:1> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 46219 50056 1.tzarc|
  ? <NULL> : Loading mesh shadow.im
    ! <kuid2:46219:50056:1> : Setting an invalid texel factor.
? <kuid2:116296:159494:3> : MeshResource::LoadResource> <kuid2:116296:159494:3> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 116296 159494 3.tzarc|
  ? <NULL> : Loading mesh 22xx tender_bogey.im
    ! <kuid2:116296:159494:3> : Setting an invalid texel factor.
? <kuid2:116296:1024:3> : MeshResource::LoadResource> <kuid2:116296:1024:3> | arc:fld:$(local)/hash-8B||kuid2 116296 1024 3.tzarc|
  ? <NULL> : Loading mesh gw_castle_tender_bogey.im
    ! <kuid2:116296:1024:3> : Setting an invalid texel factor.
? <kuid2:116296:16705:7> : MeshResource::LoadResource> <kuid2:116296:16705:7> | arc:fld:$(original)/hash-8F||kuid2 116296 16705 7.tzarc|
  ? <NULL> : Loading mesh 22xx tender_bogey.im
    ! <kuid2:116296:16705:7> : Setting an invalid texel factor.
? <kuid2:116296:16721:5> : MeshResource::LoadResource> <kuid2:116296:16721:5> | arc:fld:$(original)/hash-9F||kuid2 116296 16721 5.tzarc|
  ? <NULL> : Loading mesh 22xx_drivers.im
    ! <kuid2:116296:16721:5> : Setting an invalid texel factor.
? <kuid2:116296:262491:3> : MeshResource::LoadResource> <kuid2:116296:262491:3> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 116296 262491 3.tzarc|
  ? <NULL> : Loading mesh truro_tender_body/body.im
    ! <kuid2:116296:262491:3> : Setting an invalid texel factor.
    ! <kuid2:116296:262491:3> : Setting an invalid texel factor.
? <kuid2:116296:1930:4> : MeshResource::LoadResource> <kuid2:116296:1930:4> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 116296 1930 4.tzarc|
  ? <NULL> : Loading mesh castle_class_tender_body/castle_class_tender_body.im
    ! <kuid2:116296:1930:4> : VE166: 25 combined chunks (of 25 source) in .im file: castle_class_tender_body/castle_class_tender_body.im
? <kuid2:86627:100434:2> : MeshResource::LoadResource> <kuid2:86627:100434:2> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 86627 100434 2.tzarc|
  ? <NULL> : Loading mesh shadow.im
    ! <kuid2:86627:100434:2> : Setting an invalid texel factor.
? <kuid2:86627:100493:2> : MeshResource::LoadResource> <kuid2:86627:100493:2> | arc:arc:fld:$(packages)/||sc484.tzarc||content/kuid2 86627 100493 2.tzarc|


Bug report submitted
 
Last edited:
For so many years I cannot understand in any way, you are fixing one thing, other problems appear, fix them, those with which you started again appear. Some kind of vicious circle. But nothing really new has appeared ... I want dynamic lighting, weather, finally the clouds are real, not flat!

This occurs because parts of one thing are connected to another. If something gets fixed, it can cause another part to break completely, or not work properly all the time. I too would like to see better environmental settings with real clouds such as those found in Bohemia Interactives Arma3, or like the water found in Cities: Skylines, but this stuff takes time and resources and both are limited for a small company. The company ideally should also focus on repairing the bugs before coming out with a product, but that isn't the case because they wouldn't be here. Unlike the olden days, this isn't possible because the need and competition for programs is much higher and the developers can't dwell on perfect code as they did in the past. Today, the whole Software Development Life Cycle (SDLC) has changed to reflect that with time spent mostly developing a product then looking at the bugs reported later by customers after the product goes through a public testing and has been out in the field.

So, my recommendation is to report the bugs as much as you can because without telling the developers about the bugs, they can't fix them.
 
Perhaps "biting off more than you can chew" is also a problem. N3V keeps trying to fix more problems in one go than is reasonable. As you noted, if I may quote, "If something gets fixed, it can cause another part to break completely, or not work properly all the time.

I saw the list for this last go and quickly became apprehensive. I would have cut that into thirds. The risky relationship between the FIX and other code is well known. Good practice says that you set a simple FIX quantity. You only change it if you feel some fixes are too extensive to risk a standard list. DO NOT "assume" that a list can be extended just because a programmer tells you there should be no problems.

Tony has a marketing background (could be wrong) which will sway you toward the dramatic. While a good program manager keeps the lid on the list.

N3V is well into an extended cycle with many completed fixes, plus "fixes of fixes", in processes.
 
So, my recommendation is to report the bugs as much as you can because without telling the developers about the bugs, they can't fix them.[/INDENT]
Yes, this. :)

Fix the bugs!
Don't fix too many bugs!
Test 1,000,000,000,000 permutations before you release externally, but hurry up while you're at it.

Software is complex and anyone who has been involved in software development knows the difficulties involved. When companies worth trillions of dollars get it wrong, can you cut us a little slack.

This build has been through a thorough internal test. From the first set of feedback we were able to reproduce one out of 6 reports. So even when presented with a "known issue" our testing resulted in a different outcome to the tester.

Today we've got more detailed information so we'll hopefully get further along.

Meanwhile, we have been able to reproduce the SnC issues. Let's hope those issues are related to some of the other problems people are seeing.

And once again, thanks to everyone submitting bug reports - not only does it help, it's the only way to get sufficient test coverage!
 
Last edited:
Guys,

if you would like to keep the users motivated to do the free testing your you, then please do at least some kind of MINIMAL INTERNAL TESTING!
In 2 minutes without looking for any special issues found the following ones:
- Auto-hide the menubar is not working
- after staring a Quickdrive session (without any trains on it), the junction names are not disappearing after switching off the "Junction overlay"

How can it be that such basic things are still not working? I know it is a beta version but don't you have some automated testing or checklist before releasing a version?

Best regards,
Marc

Both things are working fine here. Please provide the steps you are using so we can retest.

Our test cases:
1. Settings > Interface settings > Tick the Autohide menu bar option
Mouseover the menu bar > check the menu bar appears
Wait 2-3 seconds > check that the menu bar slides up and disappears
PASS

2. Place a track and create a junction
Quickdrive and save as a new route
Display Menu > Turn off Junction overlays > note the junction arrows and label are hidden
Use Ctrl-H to show the junction arrows and overlay again
PASS
 
Last edited:
Williamg - we've imported various routes from older versions and not had any issues.
DMA runs route validation so it really has nothing to do with "recognising edits from previous versions", it's specifically to fix broken data.
Can you please run the DMA in your old beta build to see if the same errors are fixed there.
It's probably a good idea to submit your route in a bug report (and we'll need any track assets not on the DLS as well).

For anyone having crashing issues, can you please create a fresh local data folder and try the builtin content and let me know if you're still having problems.

At this stage, our assumption is that there are a small number of assets that are causing the problems people are seeing. And given there are over 500,000 assets out there and it may require a combination of things to occur, then we will need your help to track down the problems.

So for clarity, if you did have problems in the beta and didn't submit a bug report yet, then you can expect the same problem to occur in the next update.
 
Back
Top