strange and unhelpful error message in 1.72.1

Commander McLane · Post by **Commander McLane** » Sat Dec 13, 2008 7:09 am

Oolite 1.72.1 produces the following error message in the log (nothing in the JS-console, obviously it doesn't stem from a JS-script), when I launch from the station in my current system:

Code: Select all

[script.addShips.failed]: SCRIPT ERROR in <anonymous actions> ***** CANNOT addShipsAt: 'police 1 wsu 0.000000 0.000000 0.358377' (should be addShipsAt: role number coordinate_system x y z)
[script.addShips.failed]: SCRIPT ERROR in <anonymous actions> ***** CANNOT addShipsAt: 'police 1 psu 0.000000 0.000000 0.191226' (should be addShipsAt: role number coordinate_system x y z)

It is unhelpful, because it doesn't give a clue which script produced the error. Therefore it's trial and error to uninstall OXPs until the error message vanishes.

Did that, and apparently it is created by Commies.oxp (v 2.07). If I take Commies out, the error message is gone.

The first strange thing is that it is not clear what the error is about. The syntax reported in the message seems to be perfectly correct: 'addShipsAt:', followed by role ('police'), number ('1'), coordinate_system ('wsu' and 'psu' respectively), and x y z. So what's wrong anyway?

The second strange thing is that the methods aren't even present in the script of Commies. The script doesn't add ships with role 'police'.

And the third strange thing is that my current system isn't even a Communist system, so the whole script shouldn't be executed in the first place.

Still, if I take out Commies, the error is gone. If I take out any other OXP, the error persists.

What do you make of it?

JensAyton · Post by **JensAyton** » Sat Dec 13, 2008 10:25 am

That is indeed an unhelpful message. Unfortunately, the underlying method used to implement addShipsAt: and company doesn’t provide very helpful diagnostics.

<anonymous actions> means it’s not from a plist world script. This means it’s either ship actions or, more likely, JavaScript. Unfortunately, the legacy_addShips family in JS don’t generate JS warnings, because they just call through to the legacy script engine. It should be possible to get the script name in there instead of <anonymous actions>, though.
The “should be addShipsAt:” part indicates that it successfully parsed the parameters, and got as far as trying to create the ships, but this failed. Normally this indicates a bad role. Failing to find a police ship seems unlikely, though.
If it had actually failed to parse the parameters, it would have said “(expected <role> <count> <coordinate-system> <x> <y> <z>)” instead.

I know this is bad. The large tangle of methods used to implement the addShips: family needs to be rewritten, both to provide better diagnostics and to have something to build the legendary non-legacy JavaScript addShips() method on. Getting this right is tricky, though, and messing it up would be very bad indeed.

Commander McLane · Post by **Commander McLane** » Sat Dec 13, 2008 10:39 am

Okay, next try. As mentioned earlier, Commies.oxp seems to be the culprit, which doesn't contain any JavaScript, so that seems to be ruled out.

It does, however, contain a shipdata.plist with some problems, and--more important--with a lot of conditions-arrays (practically every entity), demanding systemGovernment_number equal 4 or (sometimes) systemGovernment_number lessthan 4. I mentioned before that my current system is not a Communist one.

Therefore a wild guess: Could

Ahruman wrote:
The “should be addShipsAt:” part indicates that it successfully parsed the parameters, and got as far as trying to create the ships, but this failed. Normally this indicates a bad role.

not be caused by a bad role, but by the fact that the ship chosen has conditions in its shipdata that prevent it from being created in the current system? (And it could be one that has 'police' among its roles, although it may not be the primary role that was called for in this specific instance?)

JensAyton · Post by **JensAyton** » Sat Dec 13, 2008 10:49 am

Commander McLane wrote:
Therefore a wild guess: Could
Ahruman wrote:
The “should be addShipsAt:” part indicates that it successfully parsed the parameters, and got as far as trying to create the ships, but this failed. Normally this indicates a bad role.
not be caused by a bad role, but by the fact that the ship chosen has conditions in its shipdata that prevent it from being created in the current system? (And it could be one that has 'police' among its roles, although it may not be the primary role that was called for in this specific instance?)

No, that would simply result in the ship in question being removed from the set of ships for consideration, and a new selection being made from the ships that have police roles. (This is the “slow path” we were talking about elsewhere).

The primary role is specific to an individual ship, not a ship type. When a ship is created by a method that takes a role, the role passed to the method becomes the ship’s initial primary role.

If you had only one ship definition with the roles “trader police”, that ship could be instantiated by a call to addShipsAt: trader ..., in which case its initial primary role would be “trader”, or it could be instantiated by a addShipsAt: police ..., in which case its initial primary role would be “police”.

Commander McLane · Post by **Commander McLane** » Sat Dec 13, 2008 11:21 am

As I said, it was just a wild guess.

But anyway, if I'm right that the culprit is in Commies.oxp, the bug can't be related to JavaScript, simply because there isn't any. So it must be in the realm of legacy-scripting. And as you said that it is not from a legacy world script (which would be script.plist), it has to be one of the other plists. Which doesn't leave much choice except shipdata.plist, because the other plists in the OXP (commodities.plist, decriptions.plist, and shipyard.plist) don't contain a lot of scripting at all.

EDIT: Now I'm confused. The error message also disappears if I take out total_patrol (which adds police ships to the various routes; and is in JS, as you said). But in what way can total_patrol and Commies interact to produce this error? Has total_patrol chosen a ship from Commies as police, and its creation failed for some reason? Could the problem be another incarnation of that slow-path thing, where in the end the unsolvable slow path produces this error? Which would mean, that this problem wouldn't be fixed yet?

JensAyton · Post by **JensAyton** » Sat Dec 13, 2008 1:01 pm

It could be that commies introduces an unloadable police ship, but that ought to result in more error messages.

Meh. I’m off to do almost-consumermas-related stuff. I’ll look at it later.

Commander McLane · Post by **Commander McLane** » Mon Dec 15, 2008 5:32 am

A_c has posted something over here that for me looks related to my problem:

another_commander wrote:
Something looks funny with the weighted probability sets in my opinion. I mean, even if Commies or whatever OXP adds a buoy with conditions, Oolite should still be able to select a different one when these conditions fail. In the case of Commies, the game already creates the initial probability sets correctly, including the standard buoys, so any failed selection should be able to revert to the typical N-Buoy that comes with the package. I have seen that after the second attempt to select from the probability set, the game returns a nil selection, which is why there is no buoy to be found. However, I am not convinced that this is what should happen. Also, I have noticed plenty of negative weights in the set. Not sure if this should be the case either.

I've highlighted the passage that seems the important one to me.