Haylp

Gareth3377 · Post by **Gareth3377** » Wed Mar 28, 2007 6:53 pm

Have generated yet another error - this:

2007-03-28 19:47:59.000 oolite.exe[2644] ***** PlayerEntity DOES NOT RESPOND TO scriptAction: "AddShips: piratestash 1"

can anyone shed any light on this please. Does it refer to a specific OXP?

Thanks in advance

Gareth

JensAyton · Post by **JensAyton** » Wed Mar 28, 2007 7:07 pm

Yep, some OXP has a bad script (it should be addShips:, not AddShips:). Currently there is no useful way of tracking this down. I hope to have a semi-useful way of doing this in the release after next.

JensAyton · Post by **JensAyton** » Wed Mar 28, 2007 7:25 pm

Further elucidation: the semi-useful way will be to print the name of the script in connection with parse errors (but not bad parameter errors). For a plist script in script.plist, the name is the key used in the top-level dictionary of the file; for instance, the first two scripts in Oolite’s standard script.plist are named thargoid_plans and constrictor_hunt. For script segments in shipdata.plist, the name will probably be based on the ship name, and for AIs on the file name.

JavaScript scripts will be able to set their names when they’re loaded; if they don’t, the file name will be used.

Note to OXP developers: only one world script (script.plist script) of a given name may exist. If multiple scripts of a given name are found, the last one found will be used. In other words script names, like file names, must be unique. Given the debug mechanism outlined above, I strongly reccomend using names prefixed with the name of your OXP.

Killer Wolf · Post by **Killer Wolf** » Wed Mar 28, 2007 7:31 pm

If multiple scripts of a given name are found, the last one found will be used. In other words script names, like file names, must be unique. Given the debug mechanism outlined above, I strongly reccomend using names prefixed with the name of your OXP.

that explains it then. i thought "script" was a standard name to execute a script. i had two models in production each w/ a standard script to gen a model when i come out of Witchspace - but only one model showed up. so if i called one "station-script.plist" it'll still execute fine?

JensAyton · Post by **JensAyton** » Wed Mar 28, 2007 7:47 pm

No.

The file name should be script.plist. This should contain a dictionary with at least one entry. The keys of these entries are unique script names (and their values are scripts).

Killer Wolf · Post by **Killer Wolf** » Thu Mar 29, 2007 7:05 am

Thanks Ahruman, i'll have a bit play w/ that next time i need to test something.

wish Oolite was written in COBOL, i'd have more of a clue about it :-)

Gareth3377 · Post by **Gareth3377** » Sat Mar 31, 2007 4:54 pm

I have located the offending OXP - it appears to be the Cargo Wrecks Teaser OXP.

Thanks for all your help...

Cheers

JensAyton · Post by **JensAyton** » Sat Mar 31, 2007 6:21 pm

Ahruman wrote:
Yep, some OXP has a bad script (it should be addShips:, not AddShips:). Currently there is no useful way of tracking this down. I hope to have a semi-useful way of doing this in the release after next.

…and the next version will have a hemisemi-useful way: if you enable a log message class (script.trace.plist.run), Oolite will print the name of each script before it is run, so you’ll get debug messages like:

Code: Select all

[script.trace.plist.run]: Running script "buggy script" 0.1 test
[script.debug.badscript]:   ***** A script did something naughty!

As for setting the message class, my super high-tech cross-platform solution for this is: look for logcontrol.plist files in all the places OXPs can live, and merge them with the default one.

Gareth3377 · Post by **Gareth3377** » Sat Mar 31, 2007 9:03 pm

That would be really usefull - and I suppose then we could (users) change the buggy script ourselves. I made the correction to the script myself (okay, it's changing a letter) and it seems to work now as it should.

Another question - why is it that when I turn off virtual memory (I heard this was recommended) Oolite crashes once you've hyperspaced to a destination. However, with virtual memory enabled Oolite is fairly stable (with the expection of some OXPs that doesn't seem to like my 'puter).

Am confused by this.

Gareth

JensAyton · Post by **JensAyton** » Sat Mar 31, 2007 9:52 pm

Quite probably it’s running out of memory. Oolite is essentially written with the assumption that there will be effective virtual memory. Failing that, ineffective virtual memory will do.
Ideally, it would handle this sort of situation by, at worst, exiting cleanly, but at this point finding all the potential low-memory crashes seems intractable. If anyone can provide precise circumstances which cause a nasty crash, we would of course like to know about it.

docwild · Post by **docwild** » Tue Apr 03, 2007 9:36 am

Ahruman wrote:
Yep, some OXP has a bad script (it should be addShips:, not AddShips:). Currently there is no useful way of tracking this down. I hope to have a semi-useful way of doing this in the release after next.

On linux:

Code: Select all

grep -Hr "AddShips" *.*

run from the Addons directory returns:

Code: Select all

Cargo_wrecks_teaser.oxp/Config/script.plist:                            <string>AddShips: piratestash 1</string>

Can't get much easier than that.

JensAyton · Post by **JensAyton** » Tue Apr 03, 2007 9:42 am

Yes, but the OP is running Windows. :-) (Actually, I got too caught up in this fancy-schmancy Spotlight thing in OS X to consider grep. Spotlight doesn’t want to seach inside “packages”, including OXPs. :-/ )

gabbakeisen · Post by **gabbakeisen** » Mon Apr 09, 2007 3:02 am

Edited the OXP and now I get a treasureoid every time I hyperspace into a system. Anyone else finding this? It would make more sense if it was found near the pirates rather than at a beacon and perhaps needs to be more random rather than every time. Not that I don't enjoy the extra cargo, its just unrealistic.

davcefai · Post by **davcefai** » Tue Apr 10, 2007 4:46 am

The treasureoid IS created at every witchpoint and only yields alloy fragments.

I ended up removing it.