Progress

[JensAyton]

It seems to me that it could be beneficial for the extra hermit to be added after shipWillExitWitchspace, so that it doesn’t need to happen if OXPs have already added secondary (immobile) stations.

[cim]

It seems to me that it could be beneficial for the extra hermit to be added after shipWillExitWitchspace, so that it doesn’t need to happen if OXPs have already added secondary (immobile) stations.

Possibly, yes. Of course, not every OXP station is suitable for pirates to dock at, not that there's any way for the pirates to tell this at the moment until it starts shooting at them.

[Switeck]

I would just remove unwanted ships (in this case a Rock Hermit and associated nearby asteroids) myself...but I get occasional crashes-to-desktop when .js scripts move (or remove) ships while my ship is cloaked.

But only while cloaked, and not when ships are (re)moved by non-JS means?

There are also graphical glitches associated with moving and/or removing "unwanted" ships on arriving at a new system. Normally, this is unseen...but it can be particularly jarring in the case of Thargoids in interstellar space, as these are both semi-large and often immediately in front of the player's ship when this happens

shipWillExitWitchspace occurs before anything is actually drawn for the new system, though, so any changes made there shouldn't be visible to the player. And then the next several frames are the break pattern.

Best I can tell, the automatic arrival of new traders to a system or the spawning of Thargoids in interstellar space are the main triggers of the CTD while cloaked.

A Rock Hermit only rarely causes a CTD if it adds a defensive ship while I'm cloaked, but I had to hack rockHermitAI.plist script to make that occur. I had to add in a delay between when it was attacked and when it launched a defensive ship to give me time to re-cloak.

The hyperspace arrival rings can sometimes be seen even if the Thargoids are removed.

[cim]

Following this discussion markSystem has been changed slightly from this approach

Its parameters can now either be numbers or objects. If they're numbers, they work exactly as they would in 1.76, so there should be no need to rewrite code from 1.76 just to get it to work in 1.77. However, by passing an object rather than a number you can put the marker in to its own group so that other OXPs can't accidentally overwrite it, and you can also change how the marker looks.

Two markers, of different styles, applied to Leesti.

Cargo and passenger contract markers have been changed away from the old red-X style to distinguish them from mission destinations.

(People following trunk who are running r5117 or later will find that their mission markers all vanish when they upgrade to r5176 or later. It didn't seem worth cluttering up load/save with code to deal with that rare case. 1.76 savegames will get their markers converted to the new system just fine, of course)

[cim]

A new feature for trunk: scriptable flight AI.

This provides an intermediate level between calling "performAttack" or "performFlyToRangeFromDestination" to let the core game code provide generic behaviour, and the other extreme of carefully repositioning and reorienting the ship every frame with a frame callback.

In the AI, you use the command "performScriptedAI" or "performScriptedAttackAI" to put the ship into scriptable flight AI mode. It will then remain in this behaviour mode until you switch it to a different mode in the AI, or an error occurs in the script. While in this mode, the scriptedAI function in the ship script is called each frame to determine the behaviour.

Code: Select all

this.scriptedAI = function(delta) 
{
    // delta = duration of frame. Often irrelevant unless you're doing
    // ultra-high-precision turns, or want a manouevre to last a particular
    // length of time

    // calculations happen here
    return flightParameters;  
}

The function gets a virtual joystick to control the ship with, by returning an object with up to 5 properties. All properties are optional, though returning an object is not. The default is level flight, at zero speed, with the forward weapon selected. Numbers outside the allowed range will be corrected to the nearest allowed value.

• stickRoll: number between -ship.maxRoll and ship.maxRoll
• stickPitch: similarly for pitch
• stickYaw: and for yaw
• desiredSpeed: number at least 0. If this is above ship.maxSpeed, and the ship has usable injectors, it will use them.
• chosenWeapon: "FORWARD", "AFT", "PORT" or "STARBOARD"

The ship will then respond to the virtual joystick. If a large change is requested - say the ship is in level flight, and the virtual joystick is moved to maximum clockwise roll - then it will take some time for the ship to respond and accelerate to that roll rate: quite possibly more than one frame.

If the attack version of the AI is selected, and the ship's current target is in the sights of the selected weapon (and there is a weapon there, and it's ready to fire, etc.), the weapon will be fired.

For example:

Code: Select all

this.scriptedAI = function(delta) 
{
  return { stickPitch: -0.2;
           desiredSpeed: this.ship.maxSpeed;
           chosenWeapon: "PORT"; };
}

will make the ship perform a fairly wide loop, and in attack mode, firing its port laser if the target crosses its sights. Might be a decent evasive attack if the target is the size of a small moon...

This lets you make a ship fly in a way consistent with other ships, without having to mess around with quaternions and masses of validation that you're not suddenly flipping the ship over in a single frame. A good grasp of vectors (and dot products, if you want to line the ship up with anything) is still needed, though.

Since the function is called once per frame, it needs to be quick. This is not the place to mess around searching for entities and new targets, for instance. You do have time for a fair bit of vector maths, though.

There's no direct support for things like missiles, ECM, and other ship equipment, but you can of course call ship.fireMissile() or ship.fireECM() from within the scriptedAI function.

A quick commented example: Orbital Patrol. This OXP adds a number of police ships to planetary orbit in the safer systems, and then uses a scripted AI to make them actually orbit the planet.

[Smivs]

[*]chosenWeapon: "FORWARD", "AFT", "PORT" or "STARBOARD"[/list]
The ship will then respond to the virtual joystick. If a large change is requested - say the ship is in level flight, and the virtual joystick is moved to maximum clockwise roll - then it will take some time for the ship to respond and accelerate to that roll rate: quite possibly more than one frame.

If the attack version of the AI is selected, and the ship's current target is in the sights of the selected weapon (and there is a weapon there, and it's ready to fire, etc.), the weapon will be fired.

For example:

Code: Select all

this.scriptedAI = function(delta) 
{
  return { stickPitch: -0.2;
           desiredSpeed: this.ship.maxSpeed;
           chosenWeapon: "PORT"; };
}

will make the ship perform a fairly wide loop, and in attack mode, firing its port laser if the target crosses its sights.

So NPCs can have and use side lasers?

[cim]

So NPCs can have and use side lasers?

Yes

[Smivs]

Ooooo! Missed that earlier. Brilliant - thanks.

[Cody]

This OXP adds a number of police ships to planetary orbit in the safer systems, and then uses a scripted AI to make them actually orbit the planet.

Excellent... that fits nicely into some Oofic... thanks, cim!

Missed that earlier.

Pay attention at the back there!

[Smivs]

Eh, what?

[Rese249er]

Huh-wha?

[Commander McLane]

A new feature for trunk: scriptable flight AI.

Very intriguing!

• desiredSpeed: number at least 0. If this is above ship.maxSpeed, and the ship has usable injectors, it will use them.

It could perhaps also use an additional desiredSpeedFactor. If above 1.0, injectors would be used. This would allow ships with different max speeds to use the same scriptedAI and fly at their respective speeds.

This can of course be done with desiredSpeed: this.ship.maxSpeed * speedFactor, but since the traditional AI programming allows both setSpeedTo: and setSpeedFactorTo:, it might be more easily accessible to have two different methods in the scriptedAI as well.

[cim]

This can of course be done with desiredSpeed: this.ship.maxSpeed * speedFactor, but since the traditional AI programming allows both setSpeedTo: and setSpeedFactorTo:, it might be more easily accessible to have two different methods in the scriptedAI as well.

The same logic would also suggest stickRollFactor, stickPitchFactor and stickYawFactor.

Added in r5204.

[CommonSenseOTB]

oh boy, oh boy, oh boy!!!





These are amazing cim, thanks for providing an easier way to do some things in some oxp features I have yet to write but are planned and of which some of the groundwork has already been made.

I have some requests:

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

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

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

All of these have uses in many of the 12 or so oxps on my hard drive that are in various states of construction.

Thanks for all the great work cim! I for one greatly appreciate your efforts!

[cim]

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.