Scripting requests

[Commander McLane]

If possible, I'd like the model sizes (width, height, length) exposed to JS as read-only properties of Entity. Ideally the sizes should include subentity-sizes in order to give a true picture of an entity's dimensions.

[Eric Walch]

Could we have the ability to access the 'special subentities' flashers and exhausts as well please? for example something along the lines of this.ship.flashersCount, this.ship.flashers[x], this.ship.exhaustsCount, this.ship.exhausts[x] and ability to change their positions, size, color etc. accordingly. The ability to turn specific flashers (and maybe exhaust trails) on and off as well would be nice too.

This will probably be difficult (read a lot of work). Internally there is one big array that contains all 3 types of subs. Than there are three filter methods to split them in three arrays. So there is already an array with flashers. But, when exposing them in the same way as the subentities, it exposes an array with null for each entry. I assume this is because there is no explicit exposure written of a flasher class. So it will not be a simple copying of the subentity exposure as I did in a quick test. And than stops my knowledge of the internal JS implementation.

[Eric Walch]

If possible, I'd like the model sizes (width, height, length) exposed to JS as read-only properties of Entity. Ideally the sizes should include subentity-sizes in order to give a true picture of an entity's dimensions.

You mean exposing the total_bounding box dimension when it is a main entity and the normal bounding box for subentities?

[Commander McLane]

If possible, I'd like the model sizes (width, height, length) exposed to JS as read-only properties of Entity. Ideally the sizes should include subentity-sizes in order to give a true picture of an entity's dimensions.

You mean exposing the total_bounding box dimension when it is a main entity and the normal bounding box for subentities?

Probably. If the bounding box touches the ship's edges in all main directions, then it should give exactly what I'm looking for.

Additionally: is it possible for the launchShipWithRole() method to return false if the ship is too big to get launched? Currently, it always returns the ship that is to be launched. Perhaps the size check is performed only later in the code, when the launch attempt is actually done. This would of course make it difficult to return a false earlier. But the current status makes it difficult to check inside a script whether the launch attempt will be successful or not. When typing for instance this.T=PS.target.launchShipWithRole("generationship"), this.T remains valid until the launch gets cancelled. The canceling is written to the log, but the script never learns about it. So alternatively, perhaps a new event handler for stations would be handy for the event of canceling a launch. It should contain the entity whose launch failed. Then the script could at least check whether this was the same entity that was returned from the previous launch command. Something like stationLaunchedShipFailed(whom), where whom is the launched ship, shortly before it gets invalid. However, I'd prefer the solution with launchShipWithRole() returning false right away.

This is needed mainly in all cases where one of the generic ship roles is launched, and therefore the launching script expects a ship to appear after a while. Currently there is no way to handle the fact that sometimes by chance a ship too big may get selected, and the actual launch will never take place. But it's of course also useful, because not all docking bays have the same size. Therefore, depending on the station the ship may sometimes get launched, and sometimes not. Currently, a script can't deal with that at all.

[Eric Walch]

is it possible for the launchShipWithRole() method to return false if the ship is too big to get launched? Currently, it always returns the ship that is to be launched. Perhaps the size check is performed only later in the code, when the launch attempt is actually done. This would of course make it difficult to return a false earlier.

You are right that the current way was the lazy way. There are about 10 places were ships are put into the launching queue. So, only testing on launch was the easiest way. But you are right that scripting wise, it would be easier when they were not added to the queue in the first place. I'll try to change it. I started already with 3 most difficult places and it seems okay so far. (ships with escorts and a bunch of police).

[Capt. Murphy]

Hi,

In preparation for future stable releases being in deployment build format, but with developer releases in test-release format could we add a property to the Oolite object - something along the lines of buildType - a string which is either "deployment", "test" or "snapshot". This would allow scripters to continue to utilise non deployment scripting features in OXPs like TAF and scripted screenshots, but automatically disable them if the OXP is running in a deployment context.

Edit to add - alternatively is the status of scriptable TAF/screenshots and availability in deployment builds an item open for discussion?

[Commander McLane]

I started already with 3 most difficult places and it seems okay so far. (ships with escorts and a bunch of police).

Sounds good. The escort cases can be handled in the script already. I just added this to the Sentinel Station script (it's with this station that I noticed the problem):

Code: Select all

this.stationLaunchedShip = function(ship)
{
    // escorts of ships whose launch was cancelled are removed
    if(ship.primaryRole === "escort" && !ship.owner) ship.remove(true);
    ...
}

[Storm]

Could we have the ability to access the 'special subentities' flashers and exhausts as well please? for example something along the lines of this.ship.flashersCount, this.ship.flashers[x], this.ship.exhaustsCount, this.ship.exhausts[x] and ability to change their positions, size, color etc. accordingly. The ability to turn specific flashers (and maybe exhaust trails) on and off as well would be nice too.

This will probably be difficult (read a lot of work). Internally there is one big array that contains all 3 types of subs. Than there are three filter methods to split them in three arrays. So there is already an array with flashers. But, when exposing them in the same way as the subentities, it exposes an array with null for each entry. I assume this is because there is no explicit exposure written of a flasher class. So it will not be a simple copying of the subentity exposure as I did in a quick test. And than stops my knowledge of the internal JS implementation.

A shame.

Being able to move the exhausts would have been nice for ships like the imperial courier/trader, where you could script their engines so they could retract/extend on their booms.

Ah well, thanks for looking into it Eric.

[Kaks]

Hi,

In preparation for future stable releases being in deployment build format, but with developer releases in test-release format could we add a property to the Oolite object - something along the lines of buildType - a string which is either "deployment", "test" or "snapshot". This would allow scripters to continue to utilise non deployment scripting features in OXPs like TAF and scripted screenshots, but automatically disable them if the OXP is running in a deployment context.

Edit to add - alternatively is the status of scriptable TAF/screenshots and availability in deployment builds an item open for discussion?

Hmm... test & snapshot(nightly) builds are indistinguishable from each other in terms of actual scripting features, and you can already check if you're in a deployment build in a number of ways by directly checking the features themselves.

Here's a fairly simple snippet that (I think) does what you're asking for:

Code: Select all

this.runningDeploymentVersion = function(){
   return (global.takeSnapShot == undefined);
}

A more complex alternative would be to look at the current TAF, if it's <> 1 you know you're in test/nightly build, if it's == 1 try and halve it, if still 1 you're in deployment, if not restore it to 1 & you know you're running a test/nightly build.
In any case, there's more than one way to skin this particular cat...

[cim]

A ship/world script event this.equipmentRepaired(equipment), working as a mirror to this.equipmentDamaged(equipment), triggered when things get fixed (go from "EQUIPMENT_DAMAGED" to "EQUIPMENT_OK" rather than the other way about).

Done (r4873)

[Wildeblood]

A ship/world script event this.equipmentRepaired(equipment), working as a mirror to this.equipmentDamaged(equipment), triggered when things get fixed (go from "EQUIPMENT_DAMAGED" to "EQUIPMENT_OK" rather than the other way about).

Done (r4873)

Does it work on the F3 screen, or only when equipment is repaired by another script? Does it work if awardEquipment() is used to repair the equipment, rather than setEquipmentStatus()? (And if so, should it?)

[cim]

Does it work on the F3 screen, or only when equipment is repaired by another script? Does it work if awardEquipment() is used to repair the equipment, rather than setEquipmentStatus()? (And if so, should it?)

F3 works (it fires just before playerBoughtEquipment does)

awardEquipment() doesn't and probably should. I'd forgotten that one could be used to repair equipment (since you can't use it to damage equipment), and people do use it for that purpose in OXPs.

Edit: r4874 now fires on awardEquipment too.

[Capt. Murphy]

Whilst your messing with equipment related code could some consideration be given to the code that selects equipment for damage in combat.

A number of OXP's use hidden equipment (e.g. plist key "visible" = no for various funky purposes. Some (CSOTB Numeric HUD for example) use dozens & dozens. I would have thought that 99.99% of the time it is undesirable for these to be damaged and the author will generally repair damaged items via script as soon as they are. It would also seem to me that logically the presence of so many EQ's that the game engine thinks are up for grabs as being damageable, acts to reduce the frequency of damage to actual visible equipment that has some impact on the player, so these OXP's inadvertently balance the odds in favour of the player in an unintended way.

There is a hidden property canBeDamaged (visible to JS, not valid as a plist key AFAIK), currently used for Trumbles, External Stores and the like. Could this be made valid as a plist key and if not explicitly defined default to true for visible items, and false for non-visible items? If an author needs to make a visible item non-damageable / non visible damageable he can add the key, and in general we can all stop worrying about having to capture equipmentDamaged events and fix them when they are not wanted.

[Smivs]

Seconded.
I am currently re-writing the WIP Battle Damage OXP as the first iteration used EQ_HULL_DAMAGE which was awarded when the ship was taking damage.
During testing I (ahem) docked rather badly and damaged my Hull Damage
Not a big problem as there are other ways I could do this for my OXP, but having non-damageable equipment available for things like this would be useful.

[Wildeblood]

There is a hidden property canBeDamaged (visible to JS, not valid as a plist key AFAIK)... Could this be made valid as a plist key...

Or make it read/write in JS?