For information and discussion about Oolite.
https://bb.oolite.space/
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.Storm wrote:Could we have the ability to access the 'special subentities' flashers and exhausts as well please? for example something along the lines ofthis.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.
You mean exposing the total_bounding box dimension when it is a main entity and the normal bounding box for subentities?Commander McLane wrote: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.
Probably. If the bounding box touches the ship's edges in all main directions, then it should give exactly what I'm looking for.Eric Walch wrote:You mean exposing the total_bounding box dimension when it is a main entity and the normal bounding box for subentities?Commander McLane wrote: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.
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.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).Commander McLane wrote:is it possible for thelaunchShipWithRole()method to returnfalseif 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 afalseearlier.
Sounds good.Eric Walch wrote:I started already with 3 most difficult places and it seems okay so far. (ships with escorts and a bunch of police).
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);
...
}A shame.Eric Walch wrote: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.Storm wrote:Could we have the ability to access the 'special subentities' flashers and exhausts as well please? for example something along the lines ofthis.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.
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.Capt. Murphy wrote: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?
Code: Select all
this.runningDeploymentVersion = function(){
return (global.takeSnapShot == undefined);
}
Thargoid wrote:A ship/world script eventthis.equipmentRepaired(equipment), working as a mirror tothis.equipmentDamaged(equipment), triggered when things get fixed (go from "EQUIPMENT_DAMAGED" to "EQUIPMENT_OK" rather than the other way about).
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 wrote:Done (r4873)Thargoid wrote:A ship/world script eventthis.equipmentRepaired(equipment), working as a mirror tothis.equipmentDamaged(equipment), triggered when things get fixed (go from "EQUIPMENT_DAMAGED" to "EQUIPMENT_OK" rather than the other way about).
F3 works (it fires just before playerBoughtEquipment does)Wildeblood wrote: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?)
"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.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.
Or make it read/write in JS?Capt. Murphy wrote:There is a hidden propertycanBeDamaged(visible to JS, not valid as a plist key AFAIK)... Could this be made valid as a plist key...