Oo-Haul - random escort missions (v.1.5)

[Timm74]

Hi.

I did not mess up a mission, thats why the counter is on -140. anything below zero should be fine.

Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...
Seems to be two errors cancelling each other out..

Cheers!
Timm

[Dr. Nil]

Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...

Glad to hear that it worked out. The seven stations sounds strange

[Ark]

Now that I found 7 ! Stations at the same place in Leesti, I finally got a mission again...

Glad to hear that it worked out. The seven stations sounds strange

Not to me

[Dr. Nil]

Hmm. Probably due to running some experimental release instead of the last stable release (1.65).

Errors with the experimental releases should be reported in Testing and Bug reports.

Code: Select all

{ "Pi-Forty-Two Con stores" = (

{ conditions = ("systemGovernment_number greaterthan 0", "systemPopulation_number greaterthan 40", "status_string equal STATUS_EXITING_WITCHSPACE", "planet_number greaterthan -1");
do = ("addShipsAt: constore 1 pwu 0 0 1.05"	); }

       	); }

Script actions that test for Status_Exiting_Witchspace should only happen once each time you exit witchspace - at least that's how it used to work. If this has changed then it will cause problems with a lot of oxps.

[Ark]

It is the ringpod oxp in 1.70 version (remember)

[JensAyton]

Script actions that test for Status_Exiting_Witchspace should only happen once each time you exit witchspace - at least that's how it used to work.

That’s the intended behaviour. Off the top of my head, the most likely cause for it happening more than once is scriptActionOnTarget: being used in STATUS_EXITING_WITCHSPACE. I think the scripting system can be manipulated to avoid this, by judiciously lying to scripts.

[Dr. Nil]

I think the scripting system can be manipulated to avoid this, by judiciously lying to scripts.

...

Huh...

[JensAyton]

A rather important question is which states are expected to be seen only once per event, and which should be substituted? I believe the following is about right, but I’m sure Eric will see something I completely failed to think of. :-)

STATUS_DOCKING -> STATUS_IN_FLIGHT
STATUS_ENTERING_WITCHSPACE -> STATUS_IN_FLIGHT
STATUS_EXITING_WITCHSPACE -> STATUS_IN_FLIGHT
Edit: STATUS_LAUNCHING -> STATUS_IN_FLIGHT

I’ve also made scriptActionOnTarget: print a deprecation warning. It is evil. Do not use.

Incidentally, in testing this stuff I rediscovered a useful tool: the script.trace setting in logcontrol.plist. If it is set to yes, the name of each world script is printed before it is run, which is rather useful for finding out which script is causing a problem. (Under Mac OS X with the Debug OXP, you can set this at run time with the Debug->Log Message Classes->Other… menu command. To do: it should be possible to fiddle with log messages at runtime with the JS console.)

[Eric Walch]

I’ve also made scriptActionOnTarget: print a deprecation warning. It is evil. Do not use.

Maybe alter the command totally. Giles probably introduced it to set missionvariables and to immediately react on it. But I don't know any OXP that needs this behaviour. Remove the checkScript from the command. This way a script will not react on changes in mission variables immediately but only at the next tickle. That means at the most a delay of 10 seconds. I used it is some occasions in UPS but it was never essential that the mission variables were read out immediately. The same is valid for Random Hits. That also needs the values not sooner than on docking.

Remove the checkScript from scriptActionOnTarget: and make it a separate command. Probably there will be a oxp that will suffer from this, but than the checkScript command can be added after the scriptActionOnTarget:.

As Ahruman says: Now, when a ship hyper-spaces it appears in an other system with a message RESTARTED. a scripter can at this point set a system variable with scriptActionOnTarget:. this way forcing to run all scripts twice on EXITTING_WITCHSPACE.

Actually the script itself should catch double additions by counting the ships first before adding. In the case of a station you not only want it to be there when jumping, but also when launching after a just loaded game. And on launching you always need the check if it was already there so why not doing it on witchspace jumping. But I agree: I would not have thought it could run twice but it can. I just think there is not yet a OXP that does it right now?

---

In this case I think it is just oolite 1.70 that is to blame. It has done more strange things. Sometimes when I blow up a ship, there is no debris, but several large asteroids from asteroid storm. An when I put randomHits in, I regularly see parts of the spacebar floating through space. Or today a asteroid crying for help. And a few days ago I shot down such an asteroid and the police started chasing me.
I think adding 7 stations belongs in this category errors not script behaviour.

[JensAyton]

You’ve got a point, but I don’t want to mess about with existing script methods (like I’d ever do that…). I guess I can add a quickScriptActionOnTarget: or some such.

Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.

[Eric Walch]

Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.

This is not a bad bug that will get published. Such a recursion will be so bad that it will crash oolite on first use. I don't think it will get an opportunity to get published. The current situation were this command is hidden in an other command is worse as it now get used without knowing it.

[JensAyton]

Hey, with a proper exit condition it could work. Just very badly.

Anyway, I’ve added safeScriptActionOnTarget: which skips the checkScript, and it’s mentioned in the deprecation warning for scriptActionOnTarget:.

[Commander McLane]

Also, I really don’t want to suggest using checkScript in a script, ever, or someone will bodge together the World’s Most Inefficient Recursive Algorithm as an alternative to learning JavaScript. And then crash in interesting new ways.

This is not a bad bug that will get published. Such a recursion will be so bad that it will crash oolite on first use. I don't think it will get an opportunity to get published. The current situation were this command is hidden in an other command is worse as it now get used without knowing it.

Forgive me my ignorance, but wasn't it you who suggested to me to use checkScript in an AI in order to make STATUS_ENTERING_WITCHSPACE working?

Anyway, it is implemented in Anarchies, in anarchiesCheckscriptAsteroidAI.plist, which has the sole purpose of, errm..., well, I think the name speaks for itself.

So, if the world as we know it comes to an end soon, will I be the one to blame???

[JensAyton]

I think I’m going to have to start randomly renaming methods just to keep Eric away from them. :-) (Seriously, don’t call checkScript. Just don’t.)

[Eric Walch]

Anyway, I’ve added safeScriptActionOnTarget: which skips the checkScript, and it’s mentioned in the deprecation warning for scriptActionOnTarget:.

The scriptActionOnTarget: command without further documentation was a bad idea of Giles. The main purpose of the command was setting variables and immediately running the installed scripts. I think Giles introduced it for the racing rings in ringpod.oxp. In that OXP he uses the command intensively to send points and timings from the rings to the player script.

the command is as killing a rabbit in your garden with a cruise missile. The target will be death, but it does a lot more than you would wish for.