Scripting requests

[JensAyton]

That means just a copy of this current method without the explosion itself would be sufficient.

Ah, so simple… except that the explosion is the only thing the current method does, with removal from the universe being an emergent side effect. This is the problem with evolved code. :-) (But yes, I agree it would be a good method to have.)

…oh wait, I added a suppressExplosion flag to ShipEntity a while ago for roughly this purpose, and it isn’t being used. OK, remove() is implemented.

[JensAyton]

I’ll look into adding a parameter to the sendAllShipsAway to suppress wormholes. Don’t expect a legacy version.

Not needed; in 1.72, use system.allShips.forEach(function (ship) { ship.remove() }) instead.

[Thargoid]

Would it be possible to add a JS function to add keystrokes (or probably better key actions as defined in keyconfig.plist given the keyboard being redefinable) into the input buffer?

My thinking is to enable a script to simulate a key being pressed by the player. For example to automatically fire off the ECM system if a player-targetted missile is detected, or to "auto-pilot" the ship or probably any number of other applications that clever people can think of.

Some of the recent discussions got me pondering an auto-ECM system, which is trivial to do except for the fact I can't see any way to actually trigger the players ECM where fitted. The above would cure that, plus open the option for many other ideas.

[JensAyton]

That would be an absolutely horrible way to implement the ability to set of the ECM, and would be no use at all for flying the ship (variable frame rates and all that). A fireECM() method and possibly the ability to run the autopilot with a custom AI are possibly potential points of consideration, though. :-)

[Thargoid]

I was trying to make the idea as flexible as possible. The basis was the ECM, but the idea is extendable.

Flying the ship was meaning more small nudges to get it on-course for docking for example, not general scooting about the ooniverse...

[Commander McLane]

Not exactly a scripting request, I know. But I would like a new shipdata-key that allows me to assign a specific type of scavenger to a station.

So exactly analogous to defense_ship and defense_ship_role it could be scavenger_ship and scavenger_ship_role.

Or analogous to escort-ship and escort-role it could be scavenger-ship and scavenger-role.

(Oh boy, these inconsistencies... )

[Commander McLane]

I’ll look into adding a parameter to the sendAllShipsAway to suppress wormholes. Don’t expect a legacy version.

Not needed; in 1.72, use system.allShips.forEach(function (ship) { ship.remove() }) instead.

Just want to give a feedback, that this works (on everything, including the main station).

There is a small but: As this is basically an explosion without explosion, asteroids let out boulders when subjected to this. So the boulders are still in the system, until you use the function for a second time.

[JensAyton]

There is a small but: As this is basically an explosion without explosion, asteroids let out boulders when subjected to this. So the boulders are still in the system, until you use the function for a second time.

Um, actually, they don’t. (Generation of debris is suppressed, and I just checked that it works as expected for asteroids.) Unless you’re using some third-party asteroid which generates boulders in its shipDied()/death_actions.

This does raise the issue of what to do about death actions and remove(), though. The most logical thing would be to call shipDied() with a special context value; currently “energy damage” is used, which doesn’t make much sense.

[Commander McLane]

This does raise the issue of what to do about death actions and remove(), though. The most logical thing would be to call shipDied() with a special context value; currently “energy damage” is used, which doesn’t make much sense.

I already somehow suspected that the asteroids might have been script-created.

And indeed. Death actions are an issue. They should not be executed with remove(). Although I know nothing about how easy that may be to realize.

[Commander McLane]

Following my post here I would like to have a new PlayerShip-property availableEquipment (or something of the like). It would be an array containing the equipment items that can be fitted to the ship. So it would have to contain all items listed in the standard_equipment and optional_equipment sections of the ship's shipyard.plist-entry. (At least for my purpose it would not be necessary to include the available_to_all-items as well.)

The reason is that e.g. the salvaged equipment items in Salvage Gangs all have to be available_to_all, so their availability isn't related to the availability of the original equipment. But it would be nice to have the possibility. Therefore the available equipment in shipyard.plist would have to be accessible for JS.

[Commander McLane]

This does raise the issue of what to do about death actions and remove(), though. The most logical thing would be to call shipDied() with a special context value; currently “energy damage” is used, which doesn’t make much sense.

I already somehow suspected that the asteroids might have been script-created.

And indeed. Death actions are an issue. They should not be executed with remove(). Although I know nothing about how easy that may be to realize.

Just to emphasize on the no-death-actions-with-remove(): Currently all Thargoids produce curses when removed. This leads to the strange result that the player arrives in a completely empty interstellar space, but nevertheless has his screen flooded with Thargoid curses. Not satisfactory.

[Thargoid]

A similar pair of items that would make life a little easier for my current little script project. A pair of JS functions, entity.faceTo(position/entity) and entity.faceFrom(position/entity) to set the entity (ship, player etc) orientation to face either directly towards or away from the argument position or entity (ie 180 degrees from each other). Similar to the AI command performFaceDestination I guess?

I'm currently trying to re-orient the player ship to point directly away from the main planet (ie to have the centre of the planet line up directly with the laser cross-hairs in the aft view) and it's driving me nuts. I can think of a few different ways of doing it, but none seem to work properly

[Eric Walch]

I'm currently trying to re-orient the player ship to point directly away from the main planet (ie to have the centre of the planet line up directly with the laser cross-hairs in the aft view) and it's driving me nuts. I can think of a few different ways of doing it, but none seem to work properly

Look in buoyRepair.js Here the station is put bottom down in systems with economy=0 and slightly tilted with economy=1. I even turn the docking slid in direction of the main station.

Or look in anarchies, the hackeroutpost. When you spawn this station it is auto orientating towards the planet (with the shipSpawned script). Just spawn it at a random location and it will always facing the main-planet.

EDIT:
Code to face the current ship towards object

Code: Select all

this.faceTo = function(object)
{
	// next line sets up a vector ship --> object
	var targetVector = object.position.subtract(this.ship.position).direction()
	// next line calculates the angle between current heading and target heading
	var angle = this.ship.heading.angleTo(targetVector)
	// next line sets up the plane were the rotation should occur in.
	var cross = this.ship.heading.cross(targetVector).direction()
	// next line align the heading to the targetVector by rotating
	this.ship.setOrientation(this.ship.orientation.rotate(cross, -angle))
}

this.faceFrom = function(object)
{
	var targetVector = this.ship.position.subtract(object.position).direction()
	var angle = this.ship.heading.angleTo(targetVector)
	var cross = this.ship.heading.cross(targetVector).direction()
	this.ship.setOrientation(this.ship.orientation.rotate(cross, -angle))
}

For player: replace this.ship by player.ship

EDIT2:
Above code is 1.72+ only as rotate had a bug in 1.71

[Thargoid]

Thanks. I've borrowed the code from Anarchies, and that's doing what I want it to do.

Based on that though, would I be correct to comment that the code above is for v1.72 only?

[Thargoid]

And one more small one (which would possibly help mission writers too, and certainly Frame's Save Anywhere OXP). Could some way be granted to switch/set GUI screens (at least while docked) rather than just read what they are via the (read-only) guiScreen parameter?