Log In
Register Now!
Help
I think many of us have seen the title message appearing in bursts in the OpenRailsLog.txt file.
The problem in analysing this (dennisat worked on this) was that a repeatable test case couldn't be found.
In the last days I had the luck that, on an activity that French trainsimmers provided to me to solve other problems, a repeatable pattern appeared. So I equipped the code with some more log info and obtained the attached logfile.
OpenRailsLog.zip (11.04K)
Number of downloads: 255
As can be seen in the second part of the file, such messages are repeated for the same sound many many times, until at last the related cars are cancelled in the Trains.cs module.
So what are the conditions that trigger this burst of messages? I found these ones, that must be all satisfied at the same moment:
1) an AI train has been arrived at its end of run, and is deleted in the AI train management modules; its cars are flagged with IsPartOfActiveTrain as being false
2) the AI train is in "sight" of the camera (that is within viewing distance) when it arrives at end of run; this means that the sound sources linked to its cars are existing and active
3) the loader process must be working in that moment (e.g. loading new tiles).
It must be said that sound source cancellation is triggered by the loader, in quite a final phase of its periodic execution (surely after tile loading). It must also be said that at beginning of sound source updating, a check is done on the IsPartOfActiveTrain flag of the car linked with such sound source, and if it is false, the updating is not executed and the "Sound Update return False" message string is put out.
Usually what occurs? If an AI train arrives at end of run when it is "out of sight", it has no active sound sources at that moment, and so the problem is not there.
If an AI train arrives at end of run when it is in sight, but the loader is not working, the latter intervenes very fast and commands the sound source cancellation, which is performed before another sound source execution, and so again the problem is not there.
If instead we are unlucky, and the train arrives at end of run when it is in sight, and the loader is busy, the sound source cancellation is delayed until the loader arrives to that task; the sound process however is operating, and when it arrives to sound sources whose linked car is marked with IsPartOfActiveTrain = false, it returns the "Sound Update return False" message. As the loader may be busy for various seconds before considering sound sources to be put in the cancellation list, there may be many "Sound Update return False" messages.
I think that there is unnecessary CPU and disk use here. It has no sense to continue writing such message, and it has no sense keeping those sound sources in a zombie state. In fact the code already has a commented out line that deletes the sound source, just after the "Sound Update return False" message output. I uncommented the line, and in fact this anticipates deletion of the sound source (and indirectly avoids repetition of the message).
So my proposal is to remove the message output (because it does not show an anomalous condition, but only a special condition) and to uncomment the line that deletes the sound source.
The patch file is very simple and is the following one.
SoundProcess_soundupdatereturnfalse.cs.patch.zip (585bytes)
Number of downloads: 259