Progress

[CommonSenseOTB]

1)currentWeapon working to query the npc's currently selected or used laser, if that's even possible. The currently chosenWeapon?

NPCs don't quite have a concept of "current weapon" in the same way that the player does, but it's probably close enough.

2)weapon positions exposed to javascript as a read property for at least the player ship.

Sounds reasonable. Might as well be for all ships.

3)thrust as a writeable property for the player ship(already writeable for the npc's)

Hmm. Not sure about this one, since it's previously explicitly been excluded from being writeable for the player ship.

Responding to:
1)When an NPC's weapon fires(at that instant) is what I'm mainly interested in knowing which one fired. If it would work any time that it was queried through JS that would be a bonus.
2)That would be cool, and very useful for many things I'm writing.
3)This is what I suspected. What I'm actually wanting to do is lower the ship's thrust to simulate some cool balanced stuff. Perhaps a cap on the writeability of thrust so that you can't write it over the maxThrust value would work? And then apply that modification to the npc's as well? Then it would work like energy and maxEnergy does now in that energy cannot be set higher than the maxEnergy value. Done in this way would be ideal for what I'm doing and be balanced too.

Whatever you can do, thanks in advance, and all the best!

[cim]

1)When an NPC's weapon fires(at that instant) is what I'm mainly interested in knowing which one fired.

It'll certainly be accurate for your purposes at that point. The update happens (approximately) when aim is checked with the chosen weapon, which then proceeds immediately to firing if it is on target.

3)This is what I suspected. What I'm actually wanting to do is lower the ship's thrust to simulate some cool balanced stuff.

You'd have to lower it a *lot* for it to be noticeable, I think. The player ship already changes speed 5 times faster than its thrust value would imply (35 times faster on injectors, 160 times faster on torus or when slowing down from torus/injection).

Lowered thrust is not always bad, either: setting thrust to near zero while at injector/torus speed would basically keep you at high speed for a very long time without fuel use or mass locks. Conversely, raising it even further would probably only make the controls a bit too sensitive while docking, and make the stop in mass-locking sharper.

[Tricky]

Would it be possible to expose ALL properties and methods used by the AI to ship and/or world scripts?

The way I'm going, the AI will be exclusively written in JS. More flexible in my opinion.

[cim]

Would it be possible to expose ALL properties and methods used by the AI to ship and/or world scripts?

In theory, yes, and a JS-based AI could be considerably simpler than the current state machine language allows for.

In practice there are quite a lot of them - some of which, like checkEnergy or the various scanFor... commands, are unnecessary in JS - so it might be a while before anyone has the free time to audit the list and work out which JS equivalents are really needed, and how to implement them - the various perform... AI commands could be compressed to a single Ship.behaviour property, for instance.

(So if there's any you need right now, a more specific request has a better chance of getting into 1.77...)

[Tricky]

Would it be possible to expose ALL properties and methods used by the AI to ship and/or world scripts?

In theory, yes, and a JS-based AI could be considerably simpler than the current state machine language allows for.

In practice there are quite a lot of them - some of which, like checkEnergy or the various scanFor... commands, are unnecessary in JS - so it might be a while before anyone has the free time to audit the list and work out which JS equivalents are really needed, and how to implement them - the various perform... AI commands could be compressed to a single Ship.behaviour property, for instance.

(So if there's any you need right now, a more specific request has a better chance of getting into 1.77...)

Primary aggressor and found target springs to mind, as in setTargetToPrimaryAggressor and setTargetToFoundTarget.

Also coord based stuff, setCourseTo..., setDesiredRange... and setDestination... methods.

All the other setTarget... methods can be easily recreated in JS.

[Commander McLane]

IIRC porting the complete AI handling to JS—totally replacing the old state machine—was one of the design goals for Oolite 2, which was unfortunately abandoned.

[cim]

Also coord based stuff, setCourseTo..., setDesiredRange... and setDestination... methods.

That entire pile of AI methods, plus a few more, can be replaced by giving the ship 'destination' and 'desiredRange' properties. Added to my list, anyway.

[cim]

A new type of entity for trunk: Visual Effects

A visual effect is a type of entity which only interacts with the universe through being visible - no collisions, no causing damage, lasers pass through it, no mass-locking, etc. Any model which you could use for a ship can be used for a visual effect, with full shader support. Visual effects can also have subentities (which are themselves either visual effects or flashers) in a similar way to a ship, but it's also possible to have a visual effect which has no base model - only subentities.

By default they are invisible on scanners, though they can be given a scanner flag if you want.

They're defined through a new [wiki]effectdata.plist[/wiki] file, and have a JS representation of class VisualEffect. JS manipulation of position and orientation is the only way to get them to do anything, but should be fairly flexible. They can be added with a new System.addVisualEffect(name,position) method.

One other feature: visual effects can be made exceptions to the usual "hide all entities" rule when a station or witchspace break pattern is in effect. Additionally, properties have been added to the Station and System JS classes to allow the usual break patterns to be suppressed. Combine the two and you can make your own break patterns, though their duration is limited to that of the original break pattern.

The JS and plist representation for them is rather sparse at the moment, so there may be things missing that would be useful to have.

[Svengali]

Very cool, cim .-) Will try it asap .-)

[Smivs]

Yes, this sounds very awesome, but I need to get my head around the possibilities

[Tricky]

The new visual effects are messing with the witchspace exit for [wiki]BGS[/wiki] though.

[cim]

The new visual effects are messing with the witchspace exit for [wiki]BGS[/wiki] though.

Ah, yes. Inevitable, unfortunately. To allow the witchspace break pattern to be disabled in shipWillExitWitchspace, that handler must be called just before the break pattern is set up (as opposed to just after, in 1.76). This means that the BGS trick of moving the ship away from the break pattern in shipWillExitWitchspace no longer works, because the position of the break pattern isn't determined until after the end of that method.

Put

Code: Select all

if (system.breakPattern) { system.breakPattern = false; }

in your copy of the BGS shipWillExitWitchspace handler as a temporary fix.

[Tricky]

Changed the OXP in the test AddOns directory.

Thanks

[Svengali]

Looks really good, cim.

The JS and plist representation for them is rather sparse at the moment, so there may be things missing that would be useful to have.

A few scriptable and bindable 'user' properties would be a dream. I'm often using energy, fuel or lightsActive to control shaders or pass infos. This reduces the need to switch them.

[cim]

A few scriptable and bindable 'user' properties would be a dream. I'm often using energy, fuel or lightsActive to control shaders or pass infos. This reduces the need to switch them.

Makes sense. How many do you think would be sensible? I'm thinking two floats, two ints, and two vec4s should be enough in general, plus make hullHeatLevel configurable to simplify use of the default shader.