Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
CommonSenseOTB
---- E L I T E ----
---- E L I T E ----
Posts: 1397
Joined: Wed May 04, 2011 10:42 am
Location: Saskatchewan, Canada

Re: Progress

Post 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! :D
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.


CommonSense 'Outside-the-Box' Design Studios Ltd.
WIKI+OXPs
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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.
User avatar
Tricky
---- E L I T E ----
---- E L I T E ----
Posts: 821
Joined: Sun May 13, 2012 11:12 pm
Location: Bradford, UK. (Anarchic)

Re: Progress

Post 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. :wink:
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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...)
User avatar
Tricky
---- E L I T E ----
---- E L I T E ----
Posts: 821
Joined: Sun May 13, 2012 11:12 pm
Location: Bradford, UK. (Anarchic)

Re: Progress

Post 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.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Progress

Post 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.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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.
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Re: Progress

Post by Svengali »

Very cool, cim .-) Will try it asap .-)
User avatar
Smivs
Retired Assassin
Retired Assassin
Posts: 8408
Joined: Tue Feb 09, 2010 11:31 am
Location: Lost in space
Contact:

Re: Progress

Post by Smivs »

Yes, this sounds very awesome, but I need to get my head around the possibilities :)
Commander Smivs, the friendliest Gourd this side of Riedquat.
User avatar
Tricky
---- E L I T E ----
---- E L I T E ----
Posts: 821
Joined: Sun May 13, 2012 11:12 pm
Location: Bradford, UK. (Anarchic)

Re: Progress

Post by Tricky »

The new visual effects are messing with the witchspace exit for [wiki]BGS[/wiki] though.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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.
User avatar
Tricky
---- E L I T E ----
---- E L I T E ----
Posts: 821
Joined: Sun May 13, 2012 11:12 pm
Location: Bradford, UK. (Anarchic)

Re: Progress

Post by Tricky »

Changed the OXP in the test AddOns directory.

Thanks
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Re: Progress

Post 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.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Progress

Post 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.
Post Reply