[QUESTION][AND PARTIAL FIX] Which Generic Missions Still Not Closing Out MD Cues?
Moderators: Scripting / Modding Moderators, Moderators for English X Forum
-
- Posts: 1466
- Joined: Wed, 16. Nov 11, 18:37
I have some results for L2M119, Escort Convo.
The issue is under the Cleanup queue. The remove Escort Ships fires and compeletes, BUT, the Wait For Ship Clean up does not! This of course is the que which actually cancels everything.
It will only fire when the CleanupShips, Escort, and COM01Ships groups have all been destroyed. One or more of these are not being destroyed full, I am guessing COM01Ships. Digging in further now!
Edit 1: I turned on SETAX10 walked away for 15 or so minutes and came back and all the escort ship missions had closed out. I think this means that the timeout que is firing and thus causing the cleanup que to fire, BUT, the cleanup que doesn't actually cause a full clean up, so it waits until the ships reach their end point before closing out the que.
This results in dog pile of ques being left open over time. The safer bet might be to just add removal ques for the two above groups, and the parent group as it where L2M119.Ships. That way after cleanup has started and the player is out of sector the ships will be removed no matter what and the que chain will end on time.
The issue is under the Cleanup queue. The remove Escort Ships fires and compeletes, BUT, the Wait For Ship Clean up does not! This of course is the que which actually cancels everything.
It will only fire when the CleanupShips, Escort, and COM01Ships groups have all been destroyed. One or more of these are not being destroyed full, I am guessing COM01Ships. Digging in further now!
Edit 1: I turned on SETAX10 walked away for 15 or so minutes and came back and all the escort ship missions had closed out. I think this means that the timeout que is firing and thus causing the cleanup que to fire, BUT, the cleanup que doesn't actually cause a full clean up, so it waits until the ships reach their end point before closing out the que.
This results in dog pile of ques being left open over time. The safer bet might be to just add removal ques for the two above groups, and the parent group as it where L2M119.Ships. That way after cleanup has started and the player is out of sector the ships will be removed no matter what and the que chain will end on time.
-
- Posts: 1466
- Joined: Wed, 16. Nov 11, 18:37
Here are the changes I have made so far, haven't been able to test them out yet, but this should cause a quicker cleanup of the escort missions.
https://www.diffchecker.com/nlwhzbot
You can download this "fixed" director here, warning have not properly tested this myself yet,
https://s3.amazonaws.com/forums-rover/2 ... Convoy.xml
I am assuming at this point that the really long lived ques are because the cargo ships never reaching their end destination for a number of reasons. When this happens the only way for them to get cleaned up via the "go to director" will never happen and the ques never close.
With the above edit not only are the escorts removed after timeout, but so are the cargo ships. This way the dog pile and the possibility of becoming stranded are not possible.
https://www.diffchecker.com/nlwhzbot
You can download this "fixed" director here, warning have not properly tested this myself yet,
https://s3.amazonaws.com/forums-rover/2 ... Convoy.xml
I am assuming at this point that the really long lived ques are because the cargo ships never reaching their end destination for a number of reasons. When this happens the only way for them to get cleaned up via the "go to director" will never happen and the ques never close.
With the above edit not only are the escorts removed after timeout, but so are the cargo ships. This way the dog pile and the possibility of becoming stranded are not possible.
-
- Posts: 215
- Joined: Sat, 7. Jul 12, 19:16
-
- Posts: 1155
- Joined: Tue, 30. Oct 07, 18:46
-
- Posts: 215
- Joined: Sat, 7. Jul 12, 19:16
-
- Posts: 1466
- Joined: Wed, 16. Nov 11, 18:37
I have been testing the fix for the Escort missions I posted above and it seems to be working. To use MrFiction's vocabulary on the subject, it seems to be ensuring and kicking in sooner the "garbage collection". Which really is a good way to think about this. The "unused/unreferenced objects/cues/ships" are being culled effectively.
Some third party confirmation of this would be much appreciated.
I have already moved on to the scan asteroid missions. Which cause seems far less obvious.
Some third party confirmation of this would be much appreciated.
I have already moved on to the scan asteroid missions. Which cause seems far less obvious.
-
- Posts: 1466
- Joined: Wed, 16. Nov 11, 18:37
Ok I have a theory about the Scan Asteroid Missions.
There are two groups created "this.Unfiltered Roids" and "this.Roids" Under 3/4 cancel ques that happen both of these groups are un-referenced via remove_group before the que is canceled. But when there are less than 5 roids in the sector resulting in the mission offer being aborted the Unfiltered groups is not un-referenced.
See the below diff for the changes I have made so far, and a clearer view of what I am talking about.
https://www.diffchecker.com/igjaa13h
Not sure if this could be a problem, but could cause a bunch of orphaned groups, unless canceling the que already causes them to be un-referenced. Not sure how to test this, because the mission director won't be telling me any info about ques that have already been canceled...
Edit: Actually was reading that wrong, there is one instance where Riods group is not un-referenced but the Unfiltered is, and one where the Unfiltered is not. Please check the updated diff checker below.
https://www.diffchecker.com/omurhrhb
There are two groups created "this.Unfiltered Roids" and "this.Roids" Under 3/4 cancel ques that happen both of these groups are un-referenced via remove_group before the que is canceled. But when there are less than 5 roids in the sector resulting in the mission offer being aborted the Unfiltered groups is not un-referenced.
See the below diff for the changes I have made so far, and a clearer view of what I am talking about.
https://www.diffchecker.com/igjaa13h
Not sure if this could be a problem, but could cause a bunch of orphaned groups, unless canceling the que already causes them to be un-referenced. Not sure how to test this, because the mission director won't be telling me any info about ques that have already been canceled...
Edit: Actually was reading that wrong, there is one instance where Riods group is not un-referenced but the Unfiltered is, and one where the Unfiltered is not. Please check the updated diff checker below.
https://www.diffchecker.com/omurhrhb
-
- Posts: 6
- Joined: Tue, 21. Mar 17, 23:48
-
- Posts: 1
- Joined: Thu, 16. Jun 11, 13:38
-
- Posts: 1466
- Joined: Wed, 16. Nov 11, 18:37