Scripters cove

[jh145]

Okay, slight modification needed, then: ...

I looked it up and decided to go with:

Code: Select all

this._myCallbackFunction = function() {
  // ...
  this._score += 1;
}.bind(this)    // within the function, "this" is the worldscript

[jh145]

I'm spawning random ships, but would like to get them alone, without escorts. More generally, I'd like to pick a random ship type, edit the attributes I don't like (e.g. ensure escorts=0), then spawn. Is this possible? I definitely want to make these customisations at runtime, not hard-coded into a shipdata file.

Thanks.

[cim]

More generally, I'd like to pick a random ship type, edit the attributes I don't like (e.g. ensure escorts=0), then spawn. Is this possible?

No. What you can often do is spawn the ship, and then edit the attributes on the next line before anything is done with it (more so in the current nightly builds where a lot more of the ship attributes are writable, than in 1.80), but you can't - in effect - define shipdata.plist entries at run-time.

To remove escorts, look at ship.escortGroup, and ship.remove() all the members of that which aren't the original ship.

[jh145]

you can't - in effect - define shipdata.plist entries at run-time.

I can probably hack round it as you suggest but, still, I'm curious: does the code need to forbid runtime customisation before spawning, or is that just the way it happens to work today?

[cim]

I can probably hack round it as you suggest but, still, I'm curious: does the code need to forbid runtime customisation before spawning, or is that just the way it happens to work today?

It would require a fair bit of reorganisation to make it possible, and both of the obvious ways it could be done would probably cause problems for other OXPs. Which properties are you wanting to edit?

[jh145]

It would require a fair bit of reorganisation to make it possible, and both of the obvious ways it could be done would probably cause problems for other OXPs. Which properties are you wanting to edit?

I've no burning desire to change any one particular thing; I just felt uncomfortable that the current design is open to race conditions whereby escorts spawn, or an AI activates, or whatever, before I've had a chance to get in there and "correct" my newly-spawned ship. Before being pointed at the docs, I suppose I'd assumed I'd be able to do something like

Code: Select all

myship = new Ship("[asp]");
myship.setScript("myai.js");
myship.setScript("myscript.js");
myship.someparam = 4.669201609;
System.addShips(myship,1);

But, like I said, this is just mild newbie discomfort. I'll get used to it

[Smivs]

Is there a way to stop a rotating sub-entity from rotating via script?

[cim]

Is there a way to stop a rotating sub-entity from rotating via script?

Not a nice one - using a frame callback to reset its orientation is probably about all that you can do, and that's not perfect. I'll add it to the list for 1.82.

[Smivs]

Ah, OK. No worries. Good to know it's on the to-do list - thanks.

[spara]

I want to limit docking and to achieve that have

Code: Select all

requires_docking_clearance = yes;

in shipdata.plist and a ship script attached to a station with this:

Code: Select all

this.stationReceivedDockingRequest = function(whom) {
	if (whom === player.ship) {
		this.ship.subEntities[2].allowsDocking = false;
		this.ship.subEntities[2].disallowedDockingCollides = true;
	}
}

All is working docking wise ok, but the station sends a standard message saying for example "Due to an emergency your docking clearance has been revoked. Please clear the station approach immediately". Is there some simple way to suppress that message in this particular case to communicate with something more suitable.

[cim]

Probably the better approach in this case is a script on the dock subentity (or subentities) using acceptDockingRequestFrom.

Code: Select all

this.acceptDockingRequestFrom = function(ship)
{
     return !ship.isPlayer;
}

That way the player being disallowed to dock won't kick everyone else out of the queue too. It should also give a better message.

[spara]

Probably the better approach in this case is a script on the dock subentity (or subentities) using acceptDockingRequestFrom.

Code: Select all

this.acceptDockingRequestFrom = function(ship)
{
     return !ship.isPlayer;
}

That way the player being disallowed to dock won't kick everyone else out of the queue too. It should also give a better message.

Thanks. Better messages indeed. However, if I request docking while there is a queue, I get a note that I'm in a queue and after the queue resolves nothing seems to happen. I added logging to the acceptDockingRequestFrom of the dock and it appears that the game is in a loop and keeps on hammering the function 20 times in a second. After canceling the request and requesting again the game correctly denies docking.

[cim]

You'll probably run across a few bugs like that as you start using those functions, but that one will be fixed in tonight's build. It wasn't handling the case where no docks are eligible for docking properly.

[Diziet Sma]

Trying to implement this:

It might be useful to consider whether the game could benefit from some sort of "incoming message" sound effect, to alert players to the fact.

I've run into a wee snag.. looking through the Oolite Javascript Reference (for both Player and Ship) I don't see any easy way to detect when commsMessage or consoleMessage is called by the game or an OXP script.

Can anyone suggest a method for doing so, or am I going to have to make a feature request?

[cim]

I've run into a wee snag.. looking through the Oolite Javascript Reference (for both Player and Ship) I don't see any easy way to detect when commsMessage or consoleMessage is called by the game or an OXP script.

Can anyone suggest a method for doing so, or am I going to have to make a feature request?

For now, you want the commsMessageReceived ship script event (which is as usual also a world script event for messages received by the player ship)

If this turns out to be a good idea (and it sounds like it is) it should probably get a customsounds.plist entry and a default sound in the core game.