This record describes changes to the API in version 1.8 Alpha 1.

Armor

Armor Mass Limits

Starting in 1.8 Alpha 1, player ships can have their maximum speed affected by the total mass of their armor. This added penalty for heavy armor can be balanced by increased hit points or other benefits.

The effect of armor mass on ships depends on the ship class. The following parameters control this behavior:

<ShipClass unid="..."
    maxSpeed=       "20"
    ...
    stdArmor=       "3000"
    maxArmor=       "6000"
    maxArmorSpeed=  "18"
    minArmorSpeed=  "22"
    />
...

The above is a partial definition for the Sapphire class. maxArmor= is the original parameter which controls the maximum mass of a single segment compatible with the ship. stdArmor= is a new parameter which defines the "standard" mass of a single segment. At the standard mass, the ship will travel at its defined maximum speed (set to 20 above).

maxArmorSpeed= defines the ship's speed when the maximum armor mass is installed. For example, if we install 6 ton segments on a Sapphire its speed will be reduced to 18.

minArmorSpeed= defines the ship's speed when installed armor is at minimum armor mass, which we set to half of stdArmor (below that there is no speed improvement).

In both cases, if not all armor segments are the same mass, we use the average mass of all segments.

For more information, see: Ships affected by installed armor mass.

Armor Speed Bonus

Starting in API 36 the armor parameter maxSpeedBonus= has been removed and replaced. This old parameter specified a % increase in max speed from having the armor installed. Instead, we've replaced it with the following:

<ArmorClass
   ...
   maxSpeedInc=    "4"
   maxSpeed=       "25"
   ...
   />

The maxSpeedInc= specifies that the ship's maximum speed should be increased by this value (in 1/100th of light-speed), but not above maxSpeed=. In the example above, a Sapphire's maximum speed would increase from .20c to .24c, but a Wolfen's speed would not increase because it is already at .25c.

Note that you may use negative numbers to indicate a decrease in maximum speed.

The speed change assumes that all of the ship's armor segments have the bonus. If not, we adjust the bonus based on the number of segments installed. For example, if only 1 out of 4 segments has a +4 speed bonus, then we would get a +1 speed bonus.

Drive Device Speeds

In previous versions, a drive device would set a new maximum speed value for a ship. For example, a Titan 440 fusion drive would boost your ship's max speed to .25c regardless of its original speed.

API 36 adds a new parameter for drive devices:

<DriveDevice
   maxSpeedInc= "4"
   maxSpeed=    "25"
   ...
   >
</DriveDevice>

The new parameter, maxSpeedInc=, specifies that the drive increases a ship's maximum speed by the given amount (in 1/100th of light-speed increments). When maxSpeedInc= is specified, maxSpeed= is treated as a limit. Speed will not be increased above it.

In the example above, a freighter with natural speed of .18c would be boosted up to .22c, while a Sapphire would be boosted from .20c to .24c. A Wolfen, however, would not be boosted at all because it is already at the maximum speed of .25c.

If maxSpeedInc= is not specified, we fall back to the original behavior.

If maxSpeedInc= is specified but maxSpeed= is not, then there is no limit on increasing speed.

Power Generation

Starting in API 36, solar devices and solar armor are able to generate power instead of fuel. For solar devices, the syntax is as follows:

<SolarDevice
   powerGen=  "100"
   />

This specifies that the device will generate 10 MWs of power at maximum illumination. Further from a star, power generation will decrease linearly. Power is specified in 1/10ths of a MW.

The power thus generated will be used by devices before tapping the reactor, thus saving on fuel consumption. Note, however, if the solar device generates more power than required by devices, then the excess power is lost.

Armor can also generate solar power:

<Armor
   ...
   photoRecharge= "30"
   />

In previous versions, the photoRecharge= parameter was a boolean. If a number is specified instead, we treat it as generating that much power (in 1/10ths of a MW) when fully illuminated.

This value is per segment. Additional segments will generate additional power.

Healer

API 36 introduces healer, which is a resource counter that can be used to regenerate armor. A ship has a total quantity of healer, which can be added or subtracted programmatically via properties. Some armor classes (specifically, bioship armor) consume healer in order to regenerate.

Connections

Connections are a mechanic for physically connecting two objects. This can be used to implement everything from flexible ships, to grappling hooks, to static discharge effects.

The capabilities of this feature are still embryonic, but the basic design is as follows. The objAddConnection function is used to connect two objects. The function will return a connectionID, which in the future could be used to sever the connection or otherwise manipulate it.

There are different types of connections:

  • hinge: A hinge is the same as a rod of 0 length.
  • rod: The two objects are connected by a solid rod which cannot expand or shrink. The two objects at the end of the rod can rotate freely. The size of the rod is determined by the position of the objects at the time that the connection is created.
  • spine: A spine connection is the same as a rod except there is a force which tries to keep the connection straight.

Missions

Events

In API 36 we added the <OnCanBrief> event, which is triggered just before showing a briefing for a missions (before the mission has been accepted). The event can return Nil to indicate that briefing should continue as normal, or it may return a string, to indicate that briefing should be canceled (the string is displayed to the user).

The event is allowed to destroy the mission (with msnDestroy) if necessary.

Also in API 36, <OnCanDebrief> is only triggered when the mission is completed, as designed. In previous versions it was triggered even when the mission was in progress.

rpgMissionAssignment

In API 36 we no longer show missions that do not match missionCriteria. You can override this by providing a displayCriteria option.

See: https://ministry.kronosaur.com/record.hexm?id=70864

Language

  • Added core.dockingRequestDenied language ID to override standard message. Add to a station/ship object or to a sovereign.

TLisp

  • 'maxArmorMass property for ships returns the maximum armor mass allowed for the ship (in kg).
  • 'maxSpeedAtMaxArmor property for ships returns the maximum speed when the ship has maximum armor mass.
  • 'maxSpeedAtMinArmor property for ships returns the maximum speed when the ship has minimum armor mass.
  • 'stdArmorMass property for ships returns the standard armor mass, at which maximum speed is neither increased nor decreased.
  • 'stealth property returns the current stealth value of a ship or station (including effects such as nebulae).
  • 'external property for devices can be get/set.
  • Added (objGetDetectRange obj targetObj) which returns the maximum distance (in light-seconds) at which the object can detect the target.
0xabcdef 28 Apr 2017:

Forgot to add (objAddConnection obj1 connectType obj2 [options]) -> connectionID

0xabcdef 17 Jul 2017:

This API spec is incomplete. See this ticket.

george moromisato 12 Sep 2017:

Added info on healer and connections. Thanks!

0xabcdef 13 Sep 2017:

Need to mention the useHealerToRegen attribute and healerLeft property