In the current design (API 36), a station chooses missions in its dock screen based on a mission criteria. For example, a station might ask for all missions with the korolov attribute.

This works well, but because the mission criteria is specified in the dock screen, we cannot programmatically tell which missions are associated with a station. For example, imagine that we want to programmatically list all the missions given out by Korolov Shipping. This is currently impossible.

This spec describes a simple, backwards-compatible API change to allow such programmatic access.

Core Concepts

Today, a station calls rpgMissionAssignment to bring up the next mission. This function takes the mission criteria as a parameter.

In API 37, we propose that the criteria come by invoking an event instead.

The station would call rpgMissionAssignment as normal, but it would not specify a mission criteria. The function would then invoke the <GetMissionCriteria> event on the station and get back the appropriate criteria. In this case, <GetMissionCriteria> would return the mission criteria as a string.

We also want to support stations with multiple mission sources. For example, a station might give out standard missions at one screen and secret missions at a different screen. For that case, rpgMissionAssignment takes a missionType option, whose value is defined by the station.

The <GetMissionCriteria> event would return a struct, indexed by missionType. E.g.,:

<GetMissionCriteria>
   {
      standard: "n +korolov; +standard;"
      secret: "n +korolov; +secret;"
      }
</GetMissionCriteria>

rpgMissionAssignment would then access the proper criteria based on the missionType option.

Alternatives

An alternative solution is to add an event to mission types to return the stations that might spawn the mission. This has a few advantages, such as dealing with missions that are not assigned at stations.

But the main disadvantage is that it would force the developer to keep the two criteria synchronized (stations and mission). Moreover, it would not handle the case where mission assignment depends on some internal state of the station (such as player rank).