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

[JensAyton]

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

Actually, no. Calling checkScript in an AI has no effect, except to produce error messages like:

Code: Select all

[ai.takeAction.badSelector]: ***** Asteroid 222 does not respond to checkScript

[tinker]

Got my first Oohaul mission today.

Got this error in stderr, afterwards.

Code: Select all

2008-08-30 15:46:20.372 oolite[13132] [script.deprecated.scriptActionOnTarget]: ***** WARNING in AI oohaulmisgoAI.plist in state GO_TO_STATION: the AI method scriptActionOnTarget: is deprecated and should not be used. It is slow and has unpredictable side effects. The recommended alternative is to use sendScriptMessage: to call a function in a ship's JavaScript ship script instead. scriptActionOnTarget: should not be used at all from scripts. An alternative is safeScriptActionOnTarget:, which is similar to scriptActionOnTarget: but has less side effects.

I have read all the above posts and would like to confirm that it is OK as a temporary solution to change the 2 instances of scriptActionOnTarget: to safescriptActionOnTarget:, or should I stop tinkering and wait for a proper update?

[Commander McLane]

Got my first Oohaul mission today.

Got this error in stderr, afterwards.

Code: Select all

2008-08-30 15:46:20.372 oolite[13132] [script.deprecated.scriptActionOnTarget]: ***** WARNING in AI oohaulmisgoAI.plist in state GO_TO_STATION: the AI method scriptActionOnTarget: is deprecated and should not be used. It is slow and has unpredictable side effects. The recommended alternative is to use sendScriptMessage: to call a function in a ship's JavaScript ship script instead. scriptActionOnTarget: should not be used at all from scripts. An alternative is safeScriptActionOnTarget:, which is similar to scriptActionOnTarget: but has less side effects.

I have read all the above posts and would like to confirm that it is OK as a temporary solution to change the 2 instances of scriptActionOnTarget: to safescriptActionOnTarget:, or should I stop tinkering and wait for a proper update?

Even leaving everything as it is would be an acceptable temporary solution. The scriptActionOnTarget:-method works and does what it is supposed to do. The message in stderr is no ERROR, but a WARNING, only informing you (and the OXP's author in the first place) that there is a better method for his purpose available now. So you can as well ignore it for the time being. (However, if you find it annoying, you may as well write "afeS" between "s" and "criptActionOnTarget:" everywhere you find it in an AI.)

[Eric Walch]

I have read all the above posts and would like to confirm that it is OK as a temporary solution to change the 2 instances of scriptActionOnTarget: to safescriptActionOnTarget:, or should I stop tinkering and wait for a proper update?

In 95% of the cases you can change "scriptActionOnTarget" to "saveScriptActionOnTarget". There are only a few like the rings in ringpod.oxp that need the exect timing of this command.

Problem of this command is that it also executes all installed legacy scripts to be able to react on a very specific line in a very specific script. A waste of time. In OO-Haul you can safely replace the scripts. On the other hand no reel need as it only triggers once after a specific mission. The command is only bad when it is used at a regular base.

I even once wrote a little test oxp to time the legacy scripts. I never managed to do it until I used this command. every 15 seconds it reads out the system clock, does a "scriptActionOnTarget" and reads out the system clock again. It writes out the past time into the log file. On my system it takes from several ms till 100 ms depending on the intalled oxp's:

With this timer you can see the damage in time the command does:ScriptTimer 1.0

[Svengali]

With this timer you can see the damage in time the command does:ScriptTimer 1.0

Very nice one, Eric. I've tested it with a few different oxps and this is a good tool for scripters, because we still have so much legacy scripts and this won't change within the next month. :-)

[Ark]

I am planning to update this oxp for the simple reason that it has the escort missions for the constores. I have also contacted Thargoid so in the future we can have a constore addone in the palnetfall oxp. I cannot see why oohauls need protection only from the controre to the main station but not also to the opposite direction if you can see my point. Thargoid already agreed.

The main problem that i had with this oxp is that it offered you the escort missions only on a Pi-42 constore. I assume that Doc Nil wrote the script in the initial version of your_ad_here oxp (when only the Pi-42 constores existed) but forgot to update it when he created more constore types.
This was easy I have just replace the line:

Code: Select all

conditions = (	"dockedStationName_string equal Pi-42 Con Store" );

with that one:

Code: Select all

conditions = (	"dockedStationName_string oneof Pi-42 Con Store, Tescoo Con Store, Mall-Wart Con Store, Star Con Store, Sainsboory's Con Store" );

In several places in the script.plist and I have already checked that now escort missions are offered from all 5 deferent types of constores. Also the script is totaly functional.
But I want to ask some things:
1.While checking the functionality of the escort missions I have noticed that in the log:

Code: Select all

[general.error.inconsistentState]: ERROR: status is STATUS_DOCKED, but dockedStation is nil; treating as not docked. This is an internal error, please report it.

although that I have completed the mission secesfully and it seems not to affect anything.
This message has nothing to do with the update I have done in oohaul and your_ad_here oxps. It is an old one (I checked it) but I have no idea what it means.

2.I do not feel very conformable with the fact the Ai of the ship is using a deprecated AI command:

Code: Select all

[script.deprecated.scriptActionOnTarget]: ***** WARNING in AI oohaulmisgoAI.plist in state GO_TO_STATION: the AI method scriptActionOnTarget: is deprecated and should not be used. It is slow and has unpredictable side effects. The recommended alternative is to use sendScriptMessage: to call a function in a ship's JavaScript ship script instead. scriptActionOnTarget: should not be used at all from scripts. An alternative is safeScriptActionOnTarget:, which is similar to scriptActionOnTarget: but has less side effects.

If I simple replace the "scriptActionOnTarget" to "saveScriptActionOnTarget" will do the job or I have to do something more.Does those 2 above commands use the same syntax and do the same thing

3.The AI of the Pi-42 clerk (I have to rename that to constore clerk - also a nice alternative png without the Pi-42 logo would be nice) seems not to function anymore and I do not know why

4.Finally does anybody knows why zzoohaul.oxp. Is there any particular reason why Dc Nil wanted this oxp to be loaded after all the others because if there is any reason I cannot see it.

[JensAyton]

This was easy I have just replace the line:

Code: Select all

conditions = (	"dockedStationName_string equal Pi-42 Con Store" );

with that one:

Code: Select all

conditions = (	"dockedStationName_string oneof Pi-42 Con Store, Tescoo Con Store, Mall-Wart Con Store, Star Con Store, Sainsboory's Con Store" );

I was going to suggest a role set-based check would be more robust here, but it turns out there’s no way to do that in a legacy script. Oh well. :-)

Code: Select all

[general.error.inconsistentState]: ERROR: status is STATUS_DOCKED, but dockedStation is nil; treating as not docked. This is an internal error, please report it.

although that I have completed the mission secesfully and it seems not to affect anything.
This message has nothing to do with the update I have done in oohaul and your_ad_here oxps. It is an old one (I checked it) but I have no idea what it means.

This probably happens in connection with docking or undocking. It would be very helpful if you could identify the circumstances where it happens.

Code: Select all

[script.deprecated.scriptActionOnTarget]: ***** WARNING in AI oohaulmisgoAI.plist in state GO_TO_STATION: the AI method scriptActionOnTarget: is deprecated and should not be used. It is slow and has unpredictable side effects. The recommended alternative is to use sendScriptMessage: to call a function in a ship's JavaScript ship script instead. scriptActionOnTarget: should not be used at all from scripts. An alternative is safeScriptActionOnTarget:, which is similar to scriptActionOnTarget: but has less side effects.

If I simple replace the "scriptActionOnTarget" to "saveScriptActionOnTarget" will do the job or I have to do something more.Does those 2 above commands use the same syntax and do the same thing

In general, replacing scriptActionOnTarget: with safeScriptActionOnTarget: should just work, but you’ll need to test it. If it doesn’t work, you’ll have to either stick with scriptActionOnTarget: or use JavaScript.

[Ark]

This probably happens in connection with docking or undocking. It would be very helpful if you could identify the circumstances where it happens.

When i dock a constore every time that it has an escort mission to offer me. It does that even with the old your ad here and oohaul oxps so it is not something that it has to do with the changes i have done to the above 2 oxps
I am not sure if i also have to accept the mission but i can check it

[Ark]

I am not sure if i also have to accept the mission but i can check it

Yep you have to accept the mission after you dock.

[JensAyton]

I’ve been able to recreate the issue. Then I modified the code to track down the problematic state change causing it to occur; as a side effect, the bug seems to have gone away. Clearly I’m a genius.

[Ark]

I’ve been able to recreate the issue. Then I modified the code to track down the problematic state change causing it to occur; as a side effect, the bug seems to have gone away. Clearly I’m a genius.

Would you care to share the modifications you have made

Also just for the record

Code: Select all

[ai.takeAction.badSelector]: ***** ERROR in AI oohaulmisgoAI.plist in state GO_TO_STATION: Oo-Haul 369 does not respond to saveScriptActionOnTarget:

Bad luck

[Kaks]

I know this! It's misspelled: should be safeScriptActionOnTarget!

[Ark]

I know this! It's misspelled: should be safeScriptActionOnTarget!

Doh!!!!!!!!

[Commander McLane]

3.The AI of the Pi-42 clerk (I have to rename that to constore clerk - also a nice alternative png without the Pi-42 logo would be nice) seems not to function anymore and I do not know why

Which AI do you mean? The OXP, as downloaded via the wiki OXP page, contains only 'oohaulAI', 'oohaulmisgoAI', and 'Pi-42SandwichBoardAI'.

4.Finally does anybody knows why zzoohaul.oxp. Is there any particular reason why Dc Nil wanted this oxp to be loaded after all the others because if there is any reason I cannot see it.

I would guess because it may be overwriting something from YAH.oxp. I can't say, though, whether it's a necessity to have it loaded after YAH.

By the way, in the OXP I just downloaded there is a strange 'juggernaut.dat' in the Textures-folder. Very odd.

[Ark]

Which AI do you mean? The OXP, as downloaded via the wiki OXP page, contains only 'oohaulAI', 'oohaulmisgoAI', and 'Pi-42SandwichBoardAI'.

It is the 'Pi-42SandwichBoardAI' although i think that the reason is inside the shipdata plist

I would guess because it may be overwriting something from YAH.oxp. I can't say, though, whether it's a necessity to have it loaded after YAH.

Well it does not.
The script of oohaul search for a ship with the role constore, constores added in the game by the script of youradhere. I assume that Dc Nill wanted to be sure that the script of youradhere will run before the script of oohaul. This is the only logical explanation, for why he did this, that i can see.