jedidia
shoemaker without legs
I had the problem that IMS caused a ctd when switching to the upper panel of the DGIV or any of the XR series when an IMS vessel is present in the scenario.
I have not managed to identify the exact circumstances, as the ctd is not fully consistent. However, I managed to reproduce it reliably within 10 seconds max by frantic panel switching in the DGIV at 10x time acceleration, which enabled me to track down the source of the trouble.
It turned out to be a timed oapiTriggerPanelRedrawArea execution of one of my panels that caused an access violation. I have other panelelements that redraw on timer, but they never caused any trouble.
My further tests clearly show that the actual redraw is not executed in my vessel, but the triggerredraw is. The ctd isn't caused every time the trigger is executed, though. I suspect it must be some critical timing, with the command executing in the same frame as a certain element triggers a redraw on the other vessel, but I'm not sure. It would explain why panel switching helps reproducing the ctd (I got it only a few times without switching at the moment of the ctd, but it did occur occasionally), and also why it seems much more frequent the faster the machine is (at first I had serious trouble reproducing it on my old laptop after my testers notified me of the bug and said that it happens at practically every switch on their machines).
It happens a bit more often when I run the whole thing as a release build, and the windows error details tell me that the crash occured inside ddraw.dll.
After thinking about it, it seemed to make some sense: oapiTriggerPanelRedrawArea seems to have no possibility to register which vessel the trigger actually came from, and the panel in itself is a global object as far as I can tell. So I fixed the problem by securing my triggers to only occur when the vessel triggering it was the focus vessel. As far as I can tell, the ctd is gone now.
However, if my above assumptions are correct and a vessel can indeed trigger a redraw event for another vessel, I would find it a crucial detail to include in the documentation and the tutorials. There's all sorts of mayhem that can happen if people don't secure their timed triggers, and the fact is not exactly apparent without giving it some thought. And the problem might go unnoticed for a long time even after an add-on is released, just causing occasional random ctds under obscure circumstances.
I have not managed to identify the exact circumstances, as the ctd is not fully consistent. However, I managed to reproduce it reliably within 10 seconds max by frantic panel switching in the DGIV at 10x time acceleration, which enabled me to track down the source of the trouble.
It turned out to be a timed oapiTriggerPanelRedrawArea execution of one of my panels that caused an access violation. I have other panelelements that redraw on timer, but they never caused any trouble.
My further tests clearly show that the actual redraw is not executed in my vessel, but the triggerredraw is. The ctd isn't caused every time the trigger is executed, though. I suspect it must be some critical timing, with the command executing in the same frame as a certain element triggers a redraw on the other vessel, but I'm not sure. It would explain why panel switching helps reproducing the ctd (I got it only a few times without switching at the moment of the ctd, but it did occur occasionally), and also why it seems much more frequent the faster the machine is (at first I had serious trouble reproducing it on my old laptop after my testers notified me of the bug and said that it happens at practically every switch on their machines).
It happens a bit more often when I run the whole thing as a release build, and the windows error details tell me that the crash occured inside ddraw.dll.
After thinking about it, it seemed to make some sense: oapiTriggerPanelRedrawArea seems to have no possibility to register which vessel the trigger actually came from, and the panel in itself is a global object as far as I can tell. So I fixed the problem by securing my triggers to only occur when the vessel triggering it was the focus vessel. As far as I can tell, the ctd is gone now.
However, if my above assumptions are correct and a vessel can indeed trigger a redraw event for another vessel, I would find it a crucial detail to include in the documentation and the tutorials. There's all sorts of mayhem that can happen if people don't secure their timed triggers, and the fact is not exactly apparent without giving it some thought. And the problem might go unnoticed for a long time even after an add-on is released, just causing occasional random ctds under obscure circumstances.
