Page 64 of 138
Re: Progress
Posted: Mon Aug 20, 2012 5:31 pm
by CommonSenseOTB
cim wrote:CommonSenseOTB wrote: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.
CommonSenseOTB wrote: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.
CommonSenseOTB wrote: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!
Re: Progress
Posted: Mon Aug 20, 2012 6:09 pm
by cim
CommonSenseOTB wrote: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.
CommonSenseOTB wrote: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.
Re: Progress
Posted: Mon Aug 20, 2012 8:31 pm
by 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.
Re: Progress
Posted: Mon Aug 20, 2012 9:39 pm
by cim
Tricky wrote: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...)
Re: Progress
Posted: Mon Aug 20, 2012 10:13 pm
by Tricky
cim wrote:Tricky wrote: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.
Re: Progress
Posted: Tue Aug 21, 2012 1:22 pm
by 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.
Re: Progress
Posted: Tue Aug 21, 2012 5:52 pm
by cim
Tricky wrote: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.
Re: Progress
Posted: Tue Aug 21, 2012 7:17 pm
by 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.
Re: Progress
Posted: Wed Aug 22, 2012 2:21 pm
by Svengali
Very cool, cim .-) Will try it asap .-)
Re: Progress
Posted: Wed Aug 22, 2012 3:16 pm
by Smivs
Yes, this sounds very awesome, but I need to get my head around the possibilities
Re: Progress
Posted: Wed Aug 22, 2012 3:19 pm
by Tricky
The new visual effects are messing with the witchspace exit for [wiki]BGS[/wiki] though.
Re: Progress
Posted: Wed Aug 22, 2012 3:32 pm
by cim
Tricky wrote: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.
Re: Progress
Posted: Wed Aug 22, 2012 4:07 pm
by Tricky
Changed the OXP in the test AddOns directory.
Thanks
Re: Progress
Posted: Wed Aug 22, 2012 5:56 pm
by Svengali
Looks really good, cim.
cim wrote: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.
Re: Progress
Posted: Wed Aug 22, 2012 7:45 pm
by cim
Svengali wrote: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.