This record describes API changes in 1.8 Beta 5.
Armor
Armor Classes and Armor Limits
See: https://ministry.kronosaur.com/record.hexm?id=84063
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.
Weapons
<OnFireWeaponEvent>
In API 44 you may return a structure to provide additional options. The structure has the following fields:
noShot
: IfTrue
, then we do not create default fire effect, sound effect, or recoil.noFireEffect
: IfTrue
, then we do not create a default fire effect.noSoundEffect
: IfTrue
, then we do not create a default sound effect.noRecoil
: IfTrue
, then we do not create recoil (if any).
Other Changes
- Added
burstTracksTargets="true"
. When set totrue
, 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.
Items
- Added
powerUse
property. - Added
powerOutput
property (for reactors). Previously, thepower
property would return either power use or power output depending on the type of item.
Ships
<ShipStandard>
In API 44, this sub-element of <ShipClass>
is used to control the default calculation of hull price:
<ShipClass ...
<ShipStandard
drivePowerUse="20"
minHullPrice="2000"
pricePerHullPoint="110"
/>
...
</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.
core.desc
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 withcore.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. OrarmorSpeedAdj:{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.
Stations
- Added
(staAbandon ...)
function to cause a station to become abandoned. - Added
wreckType
property for shipwrecks.
Missions
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" ... >
<GetParameters>
(block ()
; Pick a ship class to spawn...
{
class: theClass ; Return the class we picked
}
)
</GetParameters>
</Ship>
</ShipTable>
<???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;"
...
>
...
</ShipClass>
In some extension:
<ShipClassOverride unid=&scMolotok;">
<Armor
armorID= "&itOrthosteel;"
count= "4"
/>
</ShipClassOverride>
The above changes the Molotok to use orthosteel armor and inherits all other parameters from the original type.
<ShipTable>
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.
Trading
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:
MAX BALANCE REPLENISH
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.
Language
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:
<Language>
<Text id="descStartMission">
%titledName@speakerNPC% looks at %his@speakerNPC% light saber and
sighs.
"Looks like I'm going to need a new kyber crystal. Can you fetch one
for me?"
</Text>
</Language>
In the above text, %titledName@speakerNPC%
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 %his@speakerNPC%%
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:
<Language>
<RTF id="myRTFText">
{/rtf This is {/b bolded} text for %itemName%. }
</RTF>
</Language>
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.
TLisp
- 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. UsesysGetRandomLocation
to pick a random, available location. - Added
showAsDestination
property, which returns info if the object is being shown as a player destination.