Scripters cove

[Fritz]

This creates an incredible amount of orphaned escorts if I don't remove them as well!

[cim]

system.addShips() can add ships with a certain role. I don't know where I have read it (it isn't documented in the wiki), but the method can also add ships of a certain type if the type name is enclosed in square brackets. But in the latter case, the ships don't seem to have a role, which can be bad for testing. I wonder if there is a possibility to add ships of a certain type in a specific role, like, for example, a Boa trader?

Add the ship with the square brackets role, then immediately update ship.primaryRole to whatever you want (which can include roles that the ship can't normally have, if you want)

[Fritz]

I thought about this, but what I wanted to test is done in shipSpawned(), and it is depending from role, so changing it later would be too late.

[cim]

shipSpawned is called the first time the ship is updated by the core game loop, not immediately when it's added. If you do

Code: Select all

var ships = system.addShips(...);
ships[0].primaryRole = "trader";

then it will be set before the shipSpawned event.

It doesn't have to be on the next line - any time before you return from the function will do.

[Fritz]

That's interesting. I didn't know this, and I'll try it immediately!

Edit: It works perfectly, thank you!

[ocz]

Background (background, setScreenBackground()) and screen overlay (overlay, setScreenOverlay()) are the only two layers of screenbackgrounds one can use to create a background, right? Or is there another possibility? Another possible, undocumented parameter of setScreenOverlay()?
Something like:
[color=#000080][i]setScreenOverlay("bottomLayer.png",0);
setScreenOverlay("middleLayer.png",1);
setScreenOverlay("topLayer.png",5);[/i][/color]
too add more.

EDIT: And while I'm at backgrounds. Shouldn't
bgImage =
{name: "example.png",
height: 768};
setScreenBackground(bgImage);
create a background, that at least has been scaled down to height 480 ("default" screen height)? Or even more preferable isn't scaled down, but fitted to the screen to provided a background with a higher resolution? (example.png would be an image with a resolution of 1366x768 in my example)

[Fritz]

Is there a simple method to detect the death of a NPC entity without having to use a ship script or a timer function? There is a world script "shipSpawned" event for everything, but the world script "shipDied" event seems to be only for the player ship, because it hasn't a "ship" parameter.

[ocz]

Is there a simple method to detect the death of a NPC entity without having to use a ship script or a timer function? There is a world script "shipSpawned" event for everything, but the world script "shipDied" event seems to be only for the player ship, because it hasn't a "ship" parameter.

shipKilledOther I hope that's what you were looking for. You have to test though, if colliding with something or burning up in a sun also triggers it.

[spara]

Is there a simple method to detect the death of a NPC entity without having to use a ship script or a timer function? There is a world script "shipSpawned" event for everything, but the world script "shipDied" event seems to be only for the player ship, because it hasn't a "ship" parameter.

shipKilledOther I hope that's what you were looking for.

To my understanding, this only triggers for the ship that killed the other. So if it's in a workscript, it triggers for player, if it's in a ship script, it triggers forthe ship scoring the kill.

[ocz]

naahh, too bad. The wikis description read like it would be what fritz was looking for.

[Norby]

Is there a simple method to detect the death of a NPC entity without having to use a ship script or a timer function?

You can inject your code in shipSpawned into the shipDied function of the ship's script. For example:

Code: Select all

this.shipSpawned = function(ship) {
    if(ship && ship.dataKey == "yourship") {
        if(!ship.script) ship.script = "oolite-default-ship-script.js";
        ship.script.shipDiedOrig = ship.script.shipDied;
        ship.script.shipDied = function(whom, why) {
            player.consoleMessage(this.ship.name+" shipDied "+whom+" "+why);
            if(this.shipDiedOrig) this.shipDiedOrig(whom, why);
        }
    }
}

[Fritz]

Yes, "shipKilledOther" doesn't have a "ship" parameter either. What I'm looking for really seems to be missing, but probably the situations where you can use it, are rare. In my case, I simply want to detect a rock hermit being destroyed (usually by somebody else). But I also was thinking about tracking the fate of certain NPC ships, for example how often they get destroyed by other NPCs.

Adding a ship script for core ships would be possible by using shipdata-overrides.plist, but this will probably turn into a nightmare if another OXP (in this case, Spicy Hermits) has already added a ship script. I assume, there can't be two ship scripts for a single entity. (I wrote this sentence before reading Norby's suggestion).

You can inject your code in shipSpawned into the shipDied function of the ship's script.

This looks interesting! I'll have to try it but it looks like this actually could work. Being rather new to JavaScript, I'm not used to the concept of creating new functions during runtime...

[spara]

Instead of injecting, co-operation is also possible . If it's just Spicy Hermits, then I'm 100% absolutely, positively sure we can find a way to get the OXPs work together.

Often there might also be some other ways to achieve what one desires. What are you trying to achieve?

[Svengali]

Instead of injecting, co-operation is also possible :) . If it's just Spicy Hermits, then I'm 100% absolutely, positively sure we can find a way to get the OXPs work together.

Often there might also be some other ways to achieve what one desires. What are you trying to achieve?

Yes, please find a general way instead of aiming for a two AddOns coop only. It has shown many times already that earlier or later it gets messy pretty soon.

And as sidenote: Injection (or monkey-patching) is dangerous. In the end every AddOn developer looses the capability to control his own content and runtime behaviours of his/her own scripts. And clashes caused by this kind of thing are nearly impossible to spot. Choose a cleaner approach whenever you can.

[Fritz]

Instead of injecting, co-operation is also possible . If it's just Spicy Hermits, then I'm 100% absolutely, positively sure we can find a way to get the OXPs work together.

I know! But in theory, somebody else could have introduced a ship script too. For Spicy Hermits I could easily find a solution even without your cooperation, because I know your OXP, but there are hundreds of OXPs around, and some of their creators aren't even available anymore. So I would like to find solutions that should, at least in theory, work with OXPs unknown to me. A world script "shipDied" event would have been the easiest way as is the "shipSpawned" event for situations where you don't want to add a ship script.

Often there might also be some other ways to achieve what one desires. What are you trying to achieve?

I simply want to record the death event of a rock hermit, because I have to mark the destroyed hermit in the memory database. You use a ship script, but you need it anyhow.

I had the idea to add the beacon to a "visual effect" at the same position as the hermit, as this would (hopefully!) survive the destruction. Then, on saving or leaving the system, I could check all beacons if the associated hermit is still there. So there are definitely other methods, but I didn't want to do something unnecessarily complicated only because I didn't find a suitable event handler! That's why I asked.

If Norby's suggestion works (I'll probably know this evening), that's exactly what I need. But I'll try the "visual effect" method too, because it has another advantage: The ASC wouldn't lose it's target when the hermit is destroyed while it is set in the compass, and that's the intended behaviour.

For both methods, I wouldn't need to override shipdata.plist and introduce my own ship script. It would even work with OXP rock hermits with different data_keys and models, as long as they stick to the usual roles. And it would work with or without Spicy Hermits, and without you having to change anything!