How to do Interrupts?

[Klyith]

So in my WIP script I'm trying to figure out the interrupt system so that I can call a new script on a ship, have it work through the script, and then return to the script it was doing before. Using "$ship -> call script <script>" will interrupt, but it doesn't return to the previous script. From the handbook I've been reading about the interrupt system, and the function "$ship -> interrupt with script <script>" seems like it should do exactly what I want.

BUT, it doesn't seem to work at all. And moreover, I can't find any examples of that function in use, in Ego's scripts or anyone else's. At this point the only think of is that the function is broken (which would explain why nobody uses it) or that it works differently than the handbook says.

Any help would be very appreciated. And if I can't do what I want with interrupt but you know a different way, that would be great too!

[AalaarDB]

You could try start task and then specifiy a task thats greater than say 20. This wouldn't pause the script on task 0, and you wouldn't have a return value immediately. In fact you wouldn't get a return value, you'd have to set a local variable.
I think interrupt with script should work, I suppose I'll check it out.

[moggy2]

have a look at Xai Corporations Navigation Override System (NOS). It's designed to interupt the autopilot's current task and get the ship to safety before handing back control. I assume I used an interupt. Don't quite remember, but it sound's like what you're trying to achive.

[Klyith]

AalaarDB: Thanks. If you're looking at my script package in the other thread, it's kinda crude at this point.


Moggy: Hrmm, you used "interrupt task 0 with script". I just tried that variant in my system, using the same style, and it didn't work at all. But it seems to work fine in your script! One difference I can see is that I'm using the function in a script that's running on the player ship, but targeting a different ship. Maybe the interrupt system only works when you use it on [this]? And anything else would have to be done by signals? If so that would be a pain...

[moggy2]

that would be a pain. Have you made sure the prio is higher than the prio of the script currently running on the target.

a command with a prio of 0 will not interupt a script running at prio 0.

[Klyith]

Yup. I'd think a priority of 1234 would be sufficient to interrupt a ship running "idle".

...
One problem I have is that it takes me forever to write scripts in the editor, so I have a limited amount of time to just experiment with things. And it's totally because of the interface. I know a few programming languages, so picking up the X script language was cake, especially since it's basically a really stripped down C without brackets. Much easier than morrowind scripting was actually.

No, my problem is all in the scrolling up and down through pages of functions looking for the one I want. Every script I've written so far it took me as long to enter in in the editor as it did to design and fully write out in notepad. What X desperately needs is a "compiler" that can assemble scripts to xml from plaintext, outside the game.

[moggy2]

something you might find usefull, http://www.xai-corp.net/msci-handbook/s ... r/commands. It's a complete list of the instructions available in the script editor. It's the same layout as the script editor. I find it slightly easier to use when looking for something.

[Klyith]

OK, it seems to be working now, though I don't know why.

For some reasons that had nothing to do with this interrupt problem I changed my organization method of what scripts do what. The order of which script called the next was changed, and three new scripts were written. The end result was that I don't have to do as much parameter passing.

And once again, I tried switching from "call script" to "interrupt with". Give it one last try before I write it off totally... But it worked!

Why should this work:

Code: Select all

$curentship -> interrupt task 0 with script 'plugin.pdp.sas.follow' and prio 91: arg1=null arg2=null arg3=null arg4=null

And this not:

Code: Select all

$curentship -> interrupt with script 'plugin.pdp.sas.jump' and prio 1234: arg1=$group arg2=null arg3=null arg4=null

??? Makes no sense?!?!

[LV]

I tend to write a handler script inside the calling script but i don't if that's any use to you, i never use the interupt you have used but it's prob my bad coding skills

Code: Select all

031 @  = $tp -> call script 'plugin.handymen.get.energy' :  ship=$tp

prio 1234 = Bad

max pri is 100 and 99% of scripts use pri 0, only sig.attacked and such fires out at 99 pri

[Klyith]

I tend to write a handler script inside the calling script but i don't if that's any use to you, i never use the interupt you have used but it's prob my bad coding skills

The problem with "call script" is that if you are calling it on a different object that what the script is running on, it will end the previous script that object was running. Interrupts instead suspend the old script, and when the new one ends the old resumes where it left off.

prio 1234 = Bad

max pri is 100 and 99% of scripts use pri 0, only sig.attacked and such fires out at 99 pri

Um, I don't think that is right. Handbook gives examples much higher (200 - formation leader change, 300 - captured, 1000 - killed), and this line is from the egosoft script !plugin.acp.fight.attack.tactics:

Code: Select all

[THIS] -> interrupt with script '!plugin.acp.fight.interrupt' and prio 12000

Anyways, I'm pretty sure the first time I tried it I used pri 40-something and it didn't work, so I went for overkill.

I'm thinking it may have something to do with arguements: all the successful uses of interrupt with that I can see are calling scripts that don't take any args. But for now I want to get back to writing my script, I'll experiment with interrupts when I'm done with that.

[Klyith]

OK, I've figured it out. The answer is that I'm an idiot.

Interrupts only work if the ship / object is running a script in the first place. If they are on command "none", interrupts are just non-functional. My problem was that I wasn't controlling my tests well, so I wasn't paying attention to what the ships were doing. Most of the time that I was testing my ships were just sitting around on "none", but when I finally got it working they happened to be "idle". Idle is a script, but none means that no script is running.

But this means I have a new problem: there's no way to get the current orders from a ship except from a script already running on that ship. So there's no way for me to make a decision in my exterior script about using "call script" or "interrupt with" intelligently. Argh. Well, back to the drawing board.

Hrmm... "Standby" is a script, and it is effectively the same thing as "none". Maybe I can write a sub-task script that automatically switches ships in my groups from none to standby. I think that will work...

[Red Spot]

imo ... do not go past prio=98 ..

as signal attacked uses prio=99 and you prob. do not want to 'disable' that ..

if you want to use a prio high enough to make sure signal killed isnt triggered ..
set the script-prio to something from prio=100 to prio=299 ..

as signal captured works on prio=300 ..
and you prob. dont want to 'disable' that ...

setting it at prio=300 or higher means only signal killed can get called ... but no matter how high you set the prio ..
signal killed (prio=1000) will always get triggered .. as signal killed is no 'interrupt' .. but it simply takes 'control' ... at prio=1000 ...



G