I was thinking about posting this in the Orbiter bugs thread, but I can't make enough sense of it to justify that at the moment.
The ctd I'm getting is very weird. Namely, if one of the docks I delete has still another vessel docked to it, or had a vessel docked to it that still exists in the scenario, Orbiter gets a memory exception somewhere in the process (ctd can happen a few frames later, sometimes almost a second).
This is the error message I'm getting from visual studio:
It also happens if I undock all vessels first, and seemingly still significant time after the vessels have been undocked, and even if the scenario has been saved and reloaded, if Orbiter wasn't quit completely in between (closing the launchpad or using re-spawn).
If Orbiter is quit completely, the scenario with the undocked vessel can be loaded and the docking ports deleted safely.
If there are no vessels in the scenario that have been docked to the vessel during this session (either none have ever been docked or they have been deleted before deleting the docking ports), the ports also get deleted safely.
No ctd happens if I delete specific docking ports, even if things are docked to them.
Also, and now it gets even weirder, no ctd if I delete all docking ports. You can see the function I'm using for deletion below. The only dockingport returning true for IsPermanentDockPort is currently dockport 0. If I rig IsPermanentDockPort to always return false (while still doing everything it is doing normally, so it can't be anything in that function either), all docking ports on the vessel get deleted without ctd. If I leave at least one docking port, and the conditions described above are satisfied, I get a ctd.
Does anyone have the faintest idea what could be going on here?
---------- Post added at 05:19 PM ---------- Previous post was at 01:38 PM ----------
Some more info:
Since I don't get a crash when I delete all docking ports, I tried a workaround by deleting all of them, and then re-creating those that have to stay. The result is the same: ctd not quite immediately, but closely following execution. The circumstances under which it occurs seem to be the same as above.
Maybe worth noting, there's a lot of center of gravity shifting going on while the add-on is running. Not during this execution, but since cog-shifts influence docking ports, maybe it's got something to do with it.
Is it possible that there's a memory leak or somesuch in connection with deleting docking ports? as it is not common for Orbiter vessels to frantically spawn and delete docking ports, I could at least imagine something like this having gone unnoticed so far.
---------- Post added 02-12-12 at 03:31 PM ---------- Previous post was 02-11-12 at 05:19 PM ----------
Did some more research and took the issue over to the bug reports. This thread may be closed.
The ctd I'm getting is very weird. Namely, if one of the docks I delete has still another vessel docked to it, or had a vessel docked to it that still exists in the scenario, Orbiter gets a memory exception somewhere in the process (ctd can happen a few frames later, sometimes almost a second).
This is the error message I'm getting from visual studio:
Code:
First-chance exception at 0x00423756 in orbiter.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
Unhandled exception at 0x00423756 in orbiter.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
It also happens if I undock all vessels first, and seemingly still significant time after the vessels have been undocked, and even if the scenario has been saved and reloaded, if Orbiter wasn't quit completely in between (closing the launchpad or using re-spawn).
If Orbiter is quit completely, the scenario with the undocked vessel can be loaded and the docking ports deleted safely.
If there are no vessels in the scenario that have been docked to the vessel during this session (either none have ever been docked or they have been deleted before deleting the docking ports), the ports also get deleted safely.
No ctd happens if I delete specific docking ports, even if things are docked to them.
Also, and now it gets even weirder, no ctd if I delete all docking ports. You can see the function I'm using for deletion below. The only dockingport returning true for IsPermanentDockPort is currently dockport 0. If I rig IsPermanentDockPort to always return false (while still doing everything it is doing normally, so it can't be anything in that function either), all docking ports on the vessel get deleted without ctd. If I leave at least one docking port, and the conditions described above are satisfied, I get a ctd.
Does anyone have the faintest idea what could be going on here?
Code:
void IMS::FinalizeConstruction()
{
Undock(ALLDOCKS); //ctd happens with or without this line
for (UINT i = 0; i < DockCount();)
{
DOCKHANDLE CurDock = GetDockHandle(i);
if (!IsPermanentDockPort(CurDock))
{
if (i < cmParams.NumTotDocks - cmParams.DeleteDocks.size()) cmParams.DeleteDocks.push_back(i);
DelDock(CurDock);
}
else ++i;
}
}
---------- Post added at 05:19 PM ---------- Previous post was at 01:38 PM ----------
Some more info:
Since I don't get a crash when I delete all docking ports, I tried a workaround by deleting all of them, and then re-creating those that have to stay. The result is the same: ctd not quite immediately, but closely following execution. The circumstances under which it occurs seem to be the same as above.
Maybe worth noting, there's a lot of center of gravity shifting going on while the add-on is running. Not during this execution, but since cog-shifts influence docking ports, maybe it's got something to do with it.
Is it possible that there's a memory leak or somesuch in connection with deleting docking ports? as it is not common for Orbiter vessels to frantically spawn and delete docking ports, I could at least imagine something like this having gone unnoticed so far.
---------- Post added 02-12-12 at 03:31 PM ---------- Previous post was 02-11-12 at 05:19 PM ----------
Did some more research and took the issue over to the bug reports. This thread may be closed.