We all see this while in Surveyor and Driver. We've move along and selecting items in Surveyor, or driving along in Driver, come to junctions, trackmarks, and stations in Driver, only to have a short pause that lasts maybe a second or two. This annoying pause is something that really detracts from the game play. In TS12 SP1 HF4, the problem has gotten worse. This isn't so much the instant load, batch install it seems, of assets on blank baseboards which is annoying enough, but is more related to the game play its self.
The findings on this were simple and it boils down to writing to the database as the action changes, and can be seen. Using view database process console window, I observed Taddaemon in operation. While in Surveyor as we select a menu, the program pauses as it writes to the database and updates a transaction command duration. This pause can take up to 2-3 seconds in Surveyor and makes selecting menus awkward. This can also occur while placing objects, or painting a surface where the latter operation can cause spurious mouse moves as the system stutters intermittently.
Driver showed similar actions. As the AI approaches a station, the write database kicks in with a flutter of drive activity, and the simulation pauses just for a second. This maybe due to the simulator updating the train/AI driver location. During my observations, I have seen this also occur while approaching trackmarks, junctions, and other actions that require AI position updates and script interaction.
The actions as a whole make sense. The program has to know where the AI is located in relation to each other within the route. The information needs to be updated on the menus while performing actions in Surveyor. The problem I find is this is all done through the slowest interfaces on both the computer system and the program its self. The hardware, in this case, is the slowest interface on a computer system being the hard drive whether this is an SSD or old-fashioned platter drive moving at 7200 RPM. This will add to the lag but it was never as bad as it is now. The biggest problem appears to be that the program is utilizing TrainzUtil and TADD to perform the operation. TU is notoriously slow - as Andi06 and other content creators about it, and the information is not cached long enough prior to the write. If the data is cached and dumped too soon, then the operations are as though there is no cache at all, and this appears to be the case. Perhaps the developers could look into this for the upcoming T:ANE, and I along with other PC members will surely be looking at this aspect in detail.
John
The findings on this were simple and it boils down to writing to the database as the action changes, and can be seen. Using view database process console window, I observed Taddaemon in operation. While in Surveyor as we select a menu, the program pauses as it writes to the database and updates a transaction command duration. This pause can take up to 2-3 seconds in Surveyor and makes selecting menus awkward. This can also occur while placing objects, or painting a surface where the latter operation can cause spurious mouse moves as the system stutters intermittently.
Driver showed similar actions. As the AI approaches a station, the write database kicks in with a flutter of drive activity, and the simulation pauses just for a second. This maybe due to the simulator updating the train/AI driver location. During my observations, I have seen this also occur while approaching trackmarks, junctions, and other actions that require AI position updates and script interaction.
The actions as a whole make sense. The program has to know where the AI is located in relation to each other within the route. The information needs to be updated on the menus while performing actions in Surveyor. The problem I find is this is all done through the slowest interfaces on both the computer system and the program its self. The hardware, in this case, is the slowest interface on a computer system being the hard drive whether this is an SSD or old-fashioned platter drive moving at 7200 RPM. This will add to the lag but it was never as bad as it is now. The biggest problem appears to be that the program is utilizing TrainzUtil and TADD to perform the operation. TU is notoriously slow - as Andi06 and other content creators about it, and the information is not cached long enough prior to the write. If the data is cached and dumped too soon, then the operations are as though there is no cache at all, and this appears to be the case. Perhaps the developers could look into this for the upcoming T:ANE, and I along with other PC members will surely be looking at this aspect in detail.
John
