Ring pod warning

Ark · Post by **Ark** » Sat Jan 24, 2009 11:03 am

I am quit supersized that I get this warning for a master and commander oxp


[script.deprecated.scriptActionOnTarget]: ***** WARNING in AI ringpodAI2.plist in state WAITING: 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.
[script.deprecated.scriptActionOnTarget.repeat]: ***** WARNING in AI ringpodAI2.plist in state WAITING: the AI method scriptActionOnTarget: is deprecated and should not be used.
[script.deprecated.scriptActionOnTarget.repeat]: ***** WARNING in AI ringpodAI2.plist in state WAITING: the AI method scriptActionOnTarget: is deprecated and should not be used.
[script.deprecated.scriptActionOnTarget.repeat]: ***** WARNING in AI ringpodAI2.plist in state WAITING: the AI method scriptActionOnTarget: is deprecated and should not be used.
[script.deprecated.scriptActionOnTarget.repeat]: ***** WARNING in AI ringpodAI2.plist in state WAITING: the AI method scriptActionOnTarget: is deprecated and should not be used.

Mentioned it just for the record

Commander McLane · Post by **Commander McLane** » Sat Jan 24, 2009 2:21 pm

Why surprised? It is a quite old OXP, written long before scriptActionOnTarget got deprecated. You can't really blame Aegidian for not exactly anticipating the changes in the scripting model that were made long after his departure.

If there would be a new version, it could of course be brought up to date.

Ark · Post by **Ark** » Sat Jan 24, 2009 3:16 pm

Commander McLane wrote:
You can't really blame Aegidian

Who?? me blame Aegidian?? opps
Please McLane do not tell the cat about this. I do not want to be burnerd alive pleaseeeee!!!!!. Where is that strikethrough key

Wiki pages · Post by **Thargoid** » Sat Jan 24, 2009 4:19 pm

It's not too difficult to update (I've got an adjusted copy in my ooniverse at the moment). The reason for that is one of my WIP's is building on the concept, so could even perhaps act as said new vresion if I ever get it finished...

Post by **Eric Walch** » Sat Jan 24, 2009 4:29 pm

Commander McLane wrote:
Why surprised? It is a quite old OXP, written long before scriptActionOnTarget got deprecated. You can't really blame Aegidian for not exactly anticipating the changes in the scripting model that were made long after his departure.

I even think this oxp is the reason the scriptActionOnTarget was added to Oolite in the first place. It needs the side effects of this command while in most other cases of use, the side effects are not wanted and safeScriptActionOnTarget would be a much better replacement. To rewrite it one needs to do it completely in JS with sendScriptMessage: in the AI. And I understood Thargoid volunteered?

Wiki pages · Post by **Thargoid** » Sat Jan 24, 2009 9:49 pm

My adjusted version is here. I've not thoroughly tested it, but it seems to work.

Doesn't give error messages anyway. It's not a thorough re-write, that kind of thing will be in the OXP I'm working on at the moment, but it'll be a while yet.

Post by **Eric Walch** » Sun Jan 25, 2009 11:11 am

This oxp needs the scriptactions in the AI, but not everywhere.

As reaction on "POSITIVE Z TRAVERSE" is needs the scriptActionOnTarget for an immediate reaction on ring passing but as reaction on "CLOSE CONTACT" both occasions can better can be changed into: safeScriptActionOnTarget for better performance.
This change would make it version 1.71 minimum.

Post by **Eric Walch** » Fri Feb 06, 2009 6:27 pm

Thargoid wrote:
My adjusted version is here. I've not thoroughly tested it, but it seems to work.

??? I do not see what you have changed. All modification dates are old and the same as my old ringpod.oxp. I don't even see what was wrong with the old ringpods as it still works on my computer under 1.72

However, looking at it I could not resist to turn it into JS. (to be downloaded from the box here. I always found it stupid that it displayed the time of passing a single ring from front to end, instead of the time between two rings. So I changed that. You now get split times and a total time.
I added a few warnings when the player passes the wrong ring, or the right ring in the wrong direction.

There is just one very big bug, but that is oolite to blame for: Most of the time it shows rubbish numbers as time. That is something that happens to me since 1.72 for al kind of display features. It works very well on 1.71 with me and as I understood this bug with me can't be reproduced on many other computers. It would be interesting who else suffers from it. It happens with me without any other oxp installed so it is not a conflict between oxp.

Wiki pages · Post by **Thargoid** » Fri Feb 06, 2009 7:34 pm

The old ringpod was giving warnings in the JS console for me, so I tweaked it a little. I must admit it I don't remember exactly what was done, but it wasn't much.

Anyway I'm currently finishing off something else though which will in a way supercede it I hope.

Post by **Kaks** » Fri Feb 06, 2009 9:21 pm

Eric Walch wrote:

There is just one very big bug, but that is oolite to blame for: Most of the time it shows rubbish numbers as time. That is something that happens to me since 1.72 for al kind of display features. It works very well on 1.71 with me and as I understood this bug with me can't be reproduced on many other computers. It would be interesting who else suffers from it. It happens with me without any other oxp installed so it is not a conflict between oxp.

Hmmm, sounds a bit like deja vu... IIRC Gorans was having a similarly puzzling problem and it turned out to be a little endian/big endian snafu. Which model mac have you got?

Post by **Eric Walch** » Fri Feb 06, 2009 9:39 pm

Kaks wrote:
Hmmm, sounds a bit like deja vu... IIRC Gorans was having a similarly puzzling problem and it turned out to be a little endian/big endian snafu. Which model mac have you got?

Hello Kaks,

Great to hear from you. Hope you don't mind I adapted some of your code for the 1.72 release as that release broke a few things.

To the mac. Yes, I expect it to be something in the mac internal code. I use a 7 years old mac 700 mHz G4 (The first i-mac with a tft screen)
And yes, I also suspected that it had to do something with the storage format. All calculations with it are correct, but when it has to be displayed (turned into a string) things are mixed up. Sometimes it is only cosmetic sometimes it hangs oolite and sometimes it crashes oolite. I now use the Math.round() quite often as that seems to prevent the bug from crashing my mac.
It could be a change to the code, but it could also be caused by a change in the compiler since 1.72.

The reason I uploaded it here is i hope others can reproduce the bug to get a clue on what computer types it occurs.

EDIT:
It seems to be related with non integer numbers. When I ask for integer numbers to be displayed all goes well, but as soon as it are decimal numbers the result is wrong or oolite crashes.

Code: Select all

> player.ship.fuel
7
> player.ship.fuel/10
1.9035983712402182e+185
> player.ship.fuel/10
1.9035983712402182e+185
> player.ship.fuel*100
700
> player.ship.fuel/100
:.811503501238332e-161
player.ship.fuel*1.5
******* No result but a oolite crash****

I can reproducibly crash oolite by just printing 7*1.5 = 10.5

Hmm, it is even easier. Just typing 10.5 in the console already crashes Oolite. (now 4 times in a row, so it's not random).

Post by **Eric Walch** » Fri Feb 06, 2009 10:26 pm

It is not only the console. When I use:

Code: Select all

player.commsMessage("Passed the first ring, time starts running..."+10.5)

In a script, Oolite already crashes at startup on compiling this line. This time with an error in the crashlog:

Code: Select all

Thread 0 Crashed:
0   org.aegidian.oolite            	0x001319d8 JS_dtostr + 4356 (crt.c:355)
1   org.aegidian.oolite            	0x001317d0 JS_dtostr + 3836 (crt.c:355)
2   org.aegidian.oolite            	0x0015d4dc js_NumberToString + 276 (crt.c:355)

JensAyton · Post by **JensAyton** » Fri Feb 06, 2009 10:48 pm

Kaks has pounded the nail squarely on the noggin.

0.7 in hex is 0x3FE6666666666666. Flip the bytes around (0x666666666666E63F) and you get 1.90359856626517460223285e+185.

And, in fact, the problem occurs if I run Oolite under Rosetta. Strange how quickly you forget a problem like endianism… and I’m surprised to see it happening in the JS library.

Anyway, now I know what to do about it tomorrow.

Post by **Kaks** » Sat Feb 07, 2009 1:39 pm

Eric Walch wrote:
Hello Kaks,

Great to hear from you. Hope you don't mind I adapted some of your code for the 1.72 release as that release broke a few things.

Great to be semi-back! Won't be able to actually do anything for a while (dev computer hd is 'in flux' atm & RL is still somewhat demanding) but I'll try to get up to speed with all the fantastic stuff you guys have been doing while I wasn't looking!

@Ahruman: Glad to be of help, Sir!

JensAyton · Post by **JensAyton** » Sat Feb 07, 2009 2:54 pm

Turns out to be a very simple fix: I had somehow polluted my build environment with an x86-specific version of jsautocfg.h. (It isn’t in the svn repo, so no fix needs to be checked in.)