this.shipWasScooped

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Post Reply
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

this.shipWasScooped

Post by Svengali »

Code: Select all

if (scooper == player)
is not working as expected. I have spawned some cargopods with an attached ship-script. The same ship-script. But when I scoop these pods the first spawned pod will do his job, the others not. So I tried

Code: Select all

if (scooper.isPlayer)
and hurray - it's working.

So I put a LogWithClass in the part to get the scooper value.

Code: Select all

[Player "Cobra Mark III" ID: 100 position: (10689.9, -51859.4, 348078) scanClass: CLASS_PLAYER status: STATUS_IN_FLIGHT]
Should it be an array?
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

the first spawned pod will do his job, the others not. So I tried
yep, that's a bug in 1.70, already encountered by LittleBear - and myself - where 'player' would not be accessible from the ship script after the first spawning. 'system' and 'LogWithClass' are also affected. Ahruman's got a fix for that issue, so it shouldn't be a problem from version 1.71 onwards.

Player is actually an object. What you see printed in the log is just a fraction of the player ( & ship) properties. In a pure javascript environment the output in the log would be called its toString() method!
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

It’s the toString() method in Oolite, too. :-)

The square brackets don’t indicate an array. The standard behaviour of toString() for general objects is to return “[Object something]”, where “something” is the class of the object. Oolite’s toString() implementations use a variant of that syntax.

The inability to access global functions and objects, like player, was due to a stupid mistake in setting up JavaScript execution contexts. If more than one script was active at a time, this sort of thing happened. As Kaks says, it has been fixed for 1.71.
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Post by Svengali »

Kaks wrote:
...where 'player' would not be accessible from the ship script...
Strange. If you use a construct like

Code: Select all

this.shipWasScooped = function(scooper)
{
    if (scooper.isPlayer)
    {
         this.your_own_function();
    }
}
you can use the 'normal' way of scripting in the called function. I've tested this yesterday on different ship-scripts and it is working. Or is the called function virtually not in the ship-script?
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Ah, yes, the isPlayer property is attached to any ship object(entities, really). It's a boolean that will be true only for the ship object, and false for all the other objects in the ooniverse.

If you have a reference to an oolite entity, you can always access its properties, and those include isStation, isPlanet, isShip, and many more.

[edit:]The nice thing about properties, is that once they're set -and isPlayer is set when you select a savegame/start a new game - they don't need anything extra.

There's more about entity properties in this section of the wiki, if you haven't seen it already.

The problem with (scooper == player) was that - after the second spawning - the ship script wouldn't have a clue what you meant by typing 'player', so it couldn't compare scooper with it to verify that they were both referring to the same object.

Hope this helps! :D

[More Edit:] Brain like fudge today, just figured out what you said in the previous post: I'd be really surprised if you can use references to player, system, or LogWithClass inside this.your_own_function() after the ship is spawned the second time. You certainly can't inside this.shipWasScooped()
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Post by Svengali »

Kaks wrote:
I'd be really surprised if you can use references to player, system, or LogWithClass inside this.your_own_function() after the ship is spawned the second time.
Take a look in the localhero.oxp. There you can see this way. And it is working. The other working way is to use something like

Code: Select all

scooper.commsMessage("HELLO.");
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Kaks wrote:
[More Edit:] Brain like fudge today, just figured out what you said in the previous post: I'd be really surprised if you can use references to player, system, or LogWithClass inside this.your_own_function() after the ship is spawned the second time. You certainly can't inside this.shipWasScooped()
I had also problems with references for the second ship. But Local_Hero scripts were working so I looked into Svengalies script.

But it was not only the "this.your_own_function()" he added, he also placed the header in comment. The script is now logged as anonymous script. When I add a second ship with with such a script "missionVariables" and "player.xx" get recognised, when the script has an unique name it generated errors on the second ship. It was after this that I finally was satisfied with it in UPS were I copied this method.
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Post by Svengali »

Have you read the remarks? I thought that this could be the reason for the whole trouble.
(f) The problem with undefined Classes/Entities in ship-scripts. Don't use the normal 'header' in the ship-script if you want
to generate more than one of the same type, so Oolite will generate his own internal name for the script and avoid using
Classes like player or system.
When I started to work on the ship-scripts I've read in the WIKI
If no name is set when the script is first run, Oolite will make one up.
and I thought. Wow, this could be handy, if you don't have to communicate to the script.
Post Reply