We've made excellent progress towards the official release of SP2 this week with a number of stability improvements and lots of edge-case handling. We're often finding that issues are isolated to a single asset or asset group and with hundreds of thousands of assets out there, this is one reason everything takes so much time.
We're still putting the final finishing touches to this new build to fix a couple of remaining critical issues and expect to release it in the next few days. All going well, this RC2 build will be the final build prior to the official release.
We've released a 3 part patch from TANE SP2 RC1 - 87832
Patch 1 of 3 to 87871
Patch 2 of 3 to 87933
Patch 3 of 3 to TANE SP2 RC1 87946
We've release a further update from 87946 to 87967
While a lot of our core users are part of the beta process, those on the outside may not know what is involved in dealing with a single bug report, so we thought we'd give a bit more explanation.
When a bug report comes in, there is a process to verify the bug, identify the aspects involved, isolate extraneous events, then work on a solution to the problem. For example, we received a number of reports of passengers hovering over the tracks in ECML.
The testing process narrowed down to the asset <kuid2:447264:1501:2> Station Basic Flexible Long. This asset can be configured to have passengers on the left or right side of the track. In ECML they were configured left but would jump over to the right. So we established that the script was either failing to configure the animations properly in some cases or the animation was being configured, but failing to apply to the track in some cases.
After much investigation it was determined there were basically two issues;
This isn't surprising as Industries are not supposed to support animated track attachments. So after many hours of testing and analysis a fix was made, and this is just one asset of many, many thousands that from time to time needs updating.
Performance, backwards compatibility, graphical quality, functionality, ease of use - all these elements come together to determine the overall reaction to each version of Trainz we release. If we stray too far in one direction and sacrifices must be made in the others. So there is always a blanace between trying to improve things and the effects those improvements have on legacy content.
We recently fixed a number of bugs and made some optimisations to loading materials in order to improve performance across the board. Sharing materials from a mesh library can make significant improvements to performance, but only if the material is identical.
So after these improvements, a bug surfaced relating to missing textures "<kuidXXX> VE186: Material 'XXX' is shared between multiple meshes in this asset but the material parameters conflict."
We have investigated this case in detail and it appears the main issue is that creators have used two or more materials that share the same material name but use different textures or parameters. This means the materials cannot be shared thereby affecting performance. It is important to note that these libraries, although the intention of the creator was to "share" textures and improve performance, they were actually being loaded individually, and hence slowing things down.
As a content creator, the easiest way to avoid this problem is to place all your meshes in the same 3D scene in your modelling package and assign the correct materials to your meshes then export from that one scene.
As an end user, the good news is that creators are now warned at validation time if their textures cannot be shared, and once these items are updated, performance will improve.
The next SP2 RC build will include the following changes: