Tony_Hilliam
Trainz Plus - enjoy Trainz from just 20 cents a da
There have been a number of changes in Service Pack 2 designed to improve the reliability and predictability of how objects interact with digholes. In short, this means that long term, there should be less problems with digholes, but short term, some existing digholes will need to be "repaired".
To explain things a bit more, digholes are a special case asset that “remove” the terrain so that objects such as tunnels and turntables can be placed. The asset is not actually an "object" in the route, but rather digging a hole is a property of various objects affected by placing the asset.
Digholes have also been extensively used in “model railroad” layouts to create the appearance of table top layouts. Note that this “feature” is beyond the original expectations of creating small holes for tunnels and turntables, and using digholes should always be kept to an absolute minimum. For example, don’t simply dig a 400m x 1000m hole to create your “space”. It is far more efficient to lower the ground 40m using the terrain tools, and hide the steep sides with a “curtain” asset.
Digholes are not saved into the map terrain data. The hole in the terrain is generated when the dighole object which creates it is placed/becomes visible in the scene, and is removed when the object is deleted/no longer visible. So every time a route or session is loaded, the dighole is "applied" to the terrain and objects in the vicinity.
The problem with this approach is that there are edge cases where different results will occur based upon what loads first, which LOD level of the terrain is loaded when the dighole is calculated and exactly what happens when the object or the dighole is moved (especially when more than one dighole is placed in close proximity to another).
In short, the results are unreliable. To resolve these ongoing issues we’ve reworked the dighole code to try and resolve all the edge cases and provide a much more reliable format.
As a result of these changes, some items in existing routes will react differently to the presence of a dighole (generally appearing either higher or lower than previously expected, spending on how the hole was created). While the end result should be more robust, it does not match the previous behavior in all scenarios.
In these cases, the solution is to adjust the object and resave the route. Once done, the problems should be gone forever.
We are in the process of doing this for the builtin routes and DLC routes, but the issue will affect other DLS and locally modified routes as well.
We recognise this is an inconvenience but it is a big step forward for the long term reliability of this system. Thanks for your understanding,
To explain things a bit more, digholes are a special case asset that “remove” the terrain so that objects such as tunnels and turntables can be placed. The asset is not actually an "object" in the route, but rather digging a hole is a property of various objects affected by placing the asset.
Digholes have also been extensively used in “model railroad” layouts to create the appearance of table top layouts. Note that this “feature” is beyond the original expectations of creating small holes for tunnels and turntables, and using digholes should always be kept to an absolute minimum. For example, don’t simply dig a 400m x 1000m hole to create your “space”. It is far more efficient to lower the ground 40m using the terrain tools, and hide the steep sides with a “curtain” asset.
Digholes are not saved into the map terrain data. The hole in the terrain is generated when the dighole object which creates it is placed/becomes visible in the scene, and is removed when the object is deleted/no longer visible. So every time a route or session is loaded, the dighole is "applied" to the terrain and objects in the vicinity.
The problem with this approach is that there are edge cases where different results will occur based upon what loads first, which LOD level of the terrain is loaded when the dighole is calculated and exactly what happens when the object or the dighole is moved (especially when more than one dighole is placed in close proximity to another).
In short, the results are unreliable. To resolve these ongoing issues we’ve reworked the dighole code to try and resolve all the edge cases and provide a much more reliable format.
As a result of these changes, some items in existing routes will react differently to the presence of a dighole (generally appearing either higher or lower than previously expected, spending on how the hole was created). While the end result should be more robust, it does not match the previous behavior in all scenarios.
In these cases, the solution is to adjust the object and resave the route. Once done, the problems should be gone forever.
We are in the process of doing this for the builtin routes and DLC routes, but the issue will affect other DLS and locally modified routes as well.
We recognise this is an inconvenience but it is a big step forward for the long term reliability of this system. Thanks for your understanding,