Is there a way to instantly remove an active mission while in space without aborting it, or otherwise triggering OnAbort?
And can this be done without dateposting?

(No, Fxxx does not do this)

Perhaps by completing it somehow?

Are you certain that Axxx causes the OnAbort field to fire? I had thought that all of the "cause action" NCB operators bypassed the OnWhatever fields for that action.

Apart from that, you might be able to do something with SpecialShips, but I can't think of anything low-impact.

Edwards

No, Axxx definitely triggers OnAbort, just as Fxxx triggers OnFail and Sxxx triggers OnAccept as well as showing the accept desc.

Incidentally, why won't Fxxx work? Because you have CanAbort set?

This post has been edited by orcaloverbri9 : 29 August 2006 - 09:23 PM

@orcaloverbri9, on Aug 30 2006, 02:22 AM, said in Remove active missions:

No, Axxx definitely triggers OnAbort, just as Fxxx triggers OnFail and Sxxx triggers OnAccept as well as showing the accept desc.

Incidentally, why won't Fxxx work? Because you have CanAbort set?

Yes, and even if I didn't, it stays in the mission list. And I would still have to abort it to get rid of it. OnAbort still triggers when you abort it, even if the mission is already failed.

Why is there no operator to complete a mission?

Oh, that's right, you found that bug. I'd forgotten about that...Hmm.

Guy: I don't think a completion operator is really practical; however, an operator to simply remove an active mission without triggering anything would be useful.

What if you did this: Duplicate the mission and make two crons that fire on alternating days (or a 1-day cron that uses OnStart and OnEnd - whatever). In one cron, Sxxx the first mission; in the other, Sxxx the duplicate. Set them to have a 1-day deadline. Now, a mission will fail every day, to be replaced by the other mission, giving the impression that it is the same mission. To remove the mission permanently, set some condition so the cron(s) stop(s) firing. Using another cron, you could imitate the deadline field. I also recommend setting DatePostInc to at least one so the mission gets removed immediately upon completion.

Of course, this makes a number of assumptions. You would have to elaborate more on your particular situation for us to be of any great use.

@orcaloverbri9, on Sep 2 2006, 08:25 AM, said in Remove active missions:

What if you did this: Duplicate the mission and make two crons that fire on alternating days (or a 1-day cron that uses OnStart and OnEnd - whatever). In one cron, Sxxx the first mission; in the other, Sxxx the duplicate. Set them to have a 1-day deadline. Now, a mission will fail every day, to be replaced by the other mission, giving the impression that it is the same mission. To remove the mission permanently, set some condition so the cron(s) stop(s) firing. Using another cron, you could imitate the deadline field. I also recommend setting DatePostInc to at least one so the mission gets removed immediately upon completion.

That's actually an interesting idea. Though unsuitable for my purposes, as it is neither intant and requires a day to pass (with or withoutout the datepost)

However, if I recall correctly, a mission that runs out of time simply fails, and gets the bullet. The player can/must still abort the mission, leading back to the original problem.

@desprez, on Sep 3 2006, 08:26 PM, said in Remove active missions:

However, if I recall correctly, a mission that runs out of time simply fails, and gets the bullet. The player can/must still abort the mission, leading back to the original problem.

No, the bullet (and thus FailText) is mutually exclusive with CanAbort (unless you Fxxx it or something, I think).

I'm not clear on why you need this.

If it's because of a mission your player currently has (eg, a current issue, not a design issue), just make another mission which reverses the effects of the OnAbort.

If it's a design issue, there surely must be some other way around the problem. If you need something in the OnAbort field, then whatever calls Axxx could just undo that immediately afterwords.

@lindley, on Sep 3 2006, 04:56 PM, said in Remove active missions:

I'm not clear on why you need this.

If it's because of a mission your player currently has (eg, a current issue, not a design issue), just make another mission which reverses the effects of the OnAbort.

If it's a design issue, there surely must be some other way around the problem. If you need something in the OnAbort field, then whatever calls Axxx could just undo that immediately afterwords.

Because you can't reverse a mission that starts a mission in its OnAbort field.

For example,
128
OnAbort s129

129
OnAbort s128

What function could you use to break out of this loop? Fxxx doesn't work because a mission failed in this manner still allows you to abort it, thus continuing the loop.
The only way to retain the same functionality and still be able to break the loop, is to have a break somwhere in the chain with OnShipDone and a self-destructing dude or something.

128
OnAbort s129

129
OnAbort s130

130
OnShipDone s128

In this case, if you want to end the loop you call a128 a129 a130
This hack is not suitable in all cases because using a self-destructing dude is not instant.

This post has been edited by Desprez : 03 September 2006 - 03:11 PM

Personally, I'd just avoid that entire scenario....I can see how it might be useful if you can get it working, but it must be a real pain to debug.

Luckily, the only immutable missions are those which are currently active, so you can manually break the loop if need be by changing the misn which isn't active.

@lindley, on Sep 3 2006, 09:23 PM, said in Remove active missions:

Luckily, the only immutable missions are those which are currently active, so you can manually break the loop if need be by changing the misn which isn't active.

Huh? How do you change a misn that isn't active?

Anyway, I have the latter working in implementations for certian things where the slight pause during 130 can be justified. One example is an outfit that can change form at the users request (via aborting a mission). It is ncessary to have the chain breakable so when the player sells the item, the missions are removed.
One example of this would be a turret that can be toggled between normal and PD modes. When the player wants to switch it he aborts a particular mission, and it will swap the weapon with the alternate version. The self-destructing dude pause is justified by saying something like "please wait while the turret starts up into auto mode"

The implementation where a pause is unwieldy would be to use the active mission box as a menu of selectable items without taking up a whole bunch of Max Simultaneous Missions.
You could have one mission to cycle through different options, and another to select the current option.

This kind of functionality has all kinds of uses. But it is somewhat impractical because, as it stands, there is a pause to go back to the begining of a cycle. During this pause you need to close the mission box, wait, then reopen it.

@desprez, on Sep 4 2006, 12:16 AM, said in Remove active missions:

Huh? How do you change a misn that isn't active?

Open the plug in an editor, and change it. Note the word "manually".

@lindley, on Sep 4 2006, 01:31 AM, said in Remove active missions:

Open the plug in an editor, and change it. Note the word "manually".

... :blink:

"This outfit works of the honor system. When you sell it, please quit Nova and modify the plug-in as follows..."

How's that for a desc?

Like I said before, I wasn't sure whether this was a current issue or a design issue.

Clearly, it's a design issue, not a "help, how do I get out of this mess I created!" current issue. I suspected that, but it wasn't completely clear before.

Perhaps you could create some way to fail the mission in another way. Like make the goal to protect a ship and then start another mission with a ship hostile towards the first ship which will come along and kill it, thus failing the mission. If it fails in this manner, it should be removed from the active mission list.

Maybe. But it will not fail the mission instantly, which restricts its possible uses and causes some complications.