This record describes API changes in 1.8 Beta 5.


Armor Classes and Armor Limits


Other Changes

  • Added armorClass property. This returns the mass class for the given armor segment, as defined in an <ArmorMassDesc>.
  • Armor repair level scales appropriately with scalable items.
  • Armor power consumption scales appropriately for scalable items.



In API 44 you may return a structure to provide additional options. The structure has the following fields:

  • noShot: If True, then we do not create default fire effect, sound effect, or recoil.
  • noFireEffect: If True, then we do not create a default fire effect.
  • noSoundEffect: If True, then we do not create a default sound effect.
  • noRecoil: If True, then we do not create recoil (if any).

Other Changes

  • Added burstTracksTargets="true". When set to true, repeating, omnidirectional weapons will recalculate a fire solution for each shot.
  • Added singlePointOrigin property for weapons.

AutoDefense Devices

  • Added checkLineOfFire= parameter to prevent the device from accidentally hitting friendlies.


  • Added powerUse property.
  • Added powerOutput property (for reactors). Previously, the power property would return either power use or power output depending on the type of item.



In API 44, this sub-element of <ShipClass> is used to control the default calculation of hull price:

<ShipClass ...

The parameters have the following meaning:

  • drivePowerUse: This is the standard power use (in 1/10th of a MW) for the default drive. Ships that consume less power than this will have a higher hull price; those that consume more will have a lower hull price.
  • minHullPrice: This is the minimum hull price for the ship, in credits.
  • pricePerHullPoint: The hull price calculation converts various benefits and drawbacks of the ship class into hull points. This parameter defines how much each hull point is worth, in credits.

In practice, a base class defines the <ShipStandard> for all ships. For example, in The Stars of the Pilgrim, the baHumanTechShip class defines <ShipStandard> for all classes.


In previous APIs you could define a description for a ship class in the <PlayerSettings> sub-element. Starting in API 44, you can define it in a core.desc language entry. If core.desc is defined, it takes precedence over any description in <PlayerSettings>.

Other Changes

  • When ship property alwaysLeaveWreck is set, we create the wreck with core.noSalvage, on the assumption that the wreck is mission-critical and that we don't want Salvagers or others to disturb it.
  • Allow <Reactor> element in <ShipClass> to define reactor properties intrinsic to the class. Previously, reactor properties could only be defined in the root <ShipClass> element (or on an item). This allows inheritance.
  • Added armorSpeedAdj property. Returns a list of speed adjustments for every installed armor segment. Or armorSpeedAdj:{mass class} returns the speed adjustment for the given mass class.
  • Added maxArmorClass property.
  • Added stdArmorClass property.
  • Added treasureItemNames property to list the items included as treasure in the class.
  • Added fireWeapon order. Waits for the currently selected weapon to be ready and then fires it.
  • Added useItem order. Pass in an item struct to the order.


  • Added (staAbandon ...) function to cause a station to become abandoned.
  • Added wreckType property for shipwrecks.


Event timers set with msnAddTimerEvent or msnAddRecurringTimerEvent no longer fire when the player is in a different system from when the timer was set. An optional parameter lets the modder request that the timer fires in all system.

Ship Tables

Starting in API 44 you can dynamically choose a ship class to create with the <GetParameters> sub-element. For example:

<ShipTable ...>
   <Ship count="1" ... >
         (block ()
            ; Pick a ship class to spawn...

               class: theClass ; Return the class we picked

<???Override> Types

Starting in 1.8 Beta 5 you may create overrides of any type (not just <ShipClass> as in previous versions). You specify an override by creating a type definition that ends in Override. For example, <ShipClassOverride> or <StationTypeOverride>. An override must refer to an existing UNID of the same type.

Overrides are handled using inheritance. If an extension overrides a given type, it is equivalent to having the override inherit from the original type. For example:

In Core:

<ShipClass unid="&scMolotok;"

In some extension:

<ShipClassOverride unid=&scMolotok;">
      armorID= "&itOrthosteel;"
      count=   "4"

The above changes the Molotok to use orthosteel armor and inherits all other parameters from the original type.


The <ShipTable> type has been enhanced to append elements in <Table> and <LevelTable> when inheriting (or overriding). This allows an extension to add new entries to an existing table.

Currently, only append is supported. You cannot delete or modify table elements without re-defining the entire ship table.


In API 44, you no longer need to specify max= or replenish= to have stations buy items from the player. Instead, stations (and ships) will default to appropriate values based on their level. The default values are:

LEVEL      (credits)    (per 1800 ticks)

  1           10K           500
  2           20K         1,000
  3           30K         1,500
  4           40K         2,000
  5           50K         2,500

  6          100K            5K
  7          200K           10K
  8          400K           20K
  9          800K           40K
 10          1.5M           75K

 11            3M          150K
 12            6M          300K
 13           12M          600K
 14           25M         1.25M
 15           50M          2.5M

 16          100M            5M
 17          200M           10M
 18          400M           20M
 19          800M           40M
 20          1.5B           75M

 21            3B          150M
 22            6B          300M
 23           12B          600M
 24           25B         1.25B
 25           50B          2.5B

If you specify max= or replenish=, it will override the defaults.


Randomized NPCs

Sometimes a station will have a randomized non-player character (NPC) giving out missions. For example, the assistant director of a Korolov station is randomized from station to station. In those cases we want an easy way to vary text depending on the name and gender of the NPC.

In API 44 we've added special syntax to make this process easier. Let's assume that we have a struct containing character info, and that we've stored that character info in a gData variable (for passing to a translate function).

(setq gData {
   speakerNPC: {
      id: 'lukeSkywalker
      fullName: "Luke Skywalker"
      friendlyName: "Luke"
      formalName: "Skywalker"
      titledName: "Master Skywalker"
      gender: 'genderMale

(msnTranslate gSource 'descStartMission gData)

We're specifying that the character speaking (speakerNPC) is Luke Skywalker, and we've defined the name and gender of the character. If we wanted a different character, we would change the fields as appropriate.

Now we can use replaceable parameters in the descStartMission text that refer to the character speaking:

   <Text id="descStartMission">
      %[email protected]% looks at %[email protected]% light saber and

      "Looks like I'm going to need a new kyber crystal. Can you fetch one
      for me?"


In the above text, %[email protected]% looks in gData for the speakerNPC field; then it looks at the titledName field and returns the value. Thus the parameter will be replaced with the text "Master Skywalker".

Similarly, with %[email protected]%% we detect that his is a gendered word and look for the gender field in speakerNPC. Then we use that gender to figure out the correct pronoun.

RTF Entries

Starting in API 44 you can declare that a text entry is RTF text. For example:

   <RTF id="myRTFText">
      {/rtf This is {/b bolded} text for %itemName%. }

The advantage of specifying this is that variable replacement (e.g., %itemName%) are automatically escaped for RTF. That is, if the item name has embedded slashes, they are escaped appropriately.


  • Added hex function to return the hexadecimal representation of an integer.
  • sysFindObject now allows finding "intangible" objects. Intangible objects are objects that are in the system but that are either suspended, virtual, or entering a stargate.
  • Added sysGetLocations to return a list of available locations in a star system. In practice, this is used mostly for debugging. Use sysGetRandomLocation to pick a random, available location.
  • Added showAsDestination property, which returns info if the object is being shown as a player destination.