Entry
| Priority | Request | Rationale |
all | High | Flush the journal file after each new entry (or set the unitbuf flag if using C++ iostream). | Ensure that the journal entries aren't delayed by I/O buffering in the client from being made visible to apps. |
all | High | One JSON object per-entry/line, rather than one per-file. Timestamps shouldn’t be used as keys. | In the current proposal the file contents aren't well formed until the file is closed, and not even then if some timestamps are duplicates (invalid JSON). |
all | High | Use ISO 8601 format for timestamps, in UTC.
E.g.: 2012-04-23T18:25:43.511Z | Plain localtime is a pain to deal with, and needs special handling over midnight.
ISO 8601 is both human readable and unambiguously machine-parsable, doesn't need special handling over midnight, and is understood by JSON parsers. |
new | High | Journal should list user’s current state at startup, on ship swap, on resurrection and on shutdown of:
- current ship type
- current ship loadout (including crafting state of modules)
- cargo
- materials
- credits, debts and assets
- types and locations of other ships | Journal currently (mostly) lists only events/diffs. This makes it difficult for apps to reliably track the current state of the user over an extended period, and impossible to do so in the face of a discontinuity - e.g. the user plays on a different machine, intervention by FDev Support, loss of network connection (?), etc.
Also, for some use-cases just the overall status at the end of play is of interest. |
all | Medium | Unique ship identifier/ID for all ship records (ShipyardBuy, Sell, Swap, LoadGame, etc.) | It is not possible to pair and synchronize ship data with data stored in 3rd party apps automatically without this information. |
2.2 Heading | Medium | Indication of whether the game is beta or production. | Apps may wish to store beta data separately to production, and/or discard data after beta ends. |
3.5 Rank | Medium | Include major faction reputation.
Include Powerplay rank.
Include CQC prestige.
Include CQC sub-rank (numerical). | |
4.1 Docked | Medium | Include additional station parameters like: wealth, population, economies, government, allegiance, controlling faction including its influence/state, services, list of illegal goods, and if it is a controlling/main station of the system | This kind of information is currently entered manually by users on community sites/apps. Which is unreliable, incomplete and tiresome.
(NB: Controlling faction is included in the sample log but not in the manual). |
4.2 FSDJump
4.4 Location | Medium | Include additional star system parameters like: government, allegiance, security, permit and controlling faction. Eventually, also list of all factions in the system and their influences/states. | Similar to station information, this is currently entered manually by users on community sites/apps.
(NB: Controlling faction is included in the sample log but not in the manual). |
4.4 Location | High | Include station name if docked. | No way for the app to know whether and where the user is docked otherwise. |
4.5 Liftoff
4.7 Touchdown | Medium | Include local body coordinates (lat/long) where the ship is touching down at or taking off from | This enables better tracking of ship’s location, rather than only knowing which body |
6.1 Scan | Medium | Include basic info from the local map i.e.:
- Distance from arrival point
- Earth / Solar mass
- Radius / Solar radius
- Gravity (for planets/moons)
- Number of rings
Write this entry even if the user doesn’t have a detailed surface scanner (but in which case omit the Materials property). | This basic info is relevant to the user (or an app on behalf of the user) in deciding whether it's worthwhile (or safe!) to plan to go prospecting on a body. Also, this kind of information is currently entered manually by users on community sites/apps. |
6.1 Scan | Low | Also include all info available from the local map, i.e.:
- Atmosphere gasses and percentages
- Composition and percentages
- Orbital period
- etc | This kind of information is currently entered manually by users on community sites/apps. Which is unreliable, incomplete and tiresome. |
6.1 Scan | High | Discrete values for discrete states | From the description sample it looks like we have to parse the text for specific properties like atmosphere. We highly recommend to use separate discrete properties with numeric values for unique states. |
3.3 LoadGame | High | Include game mode being entered | Useful for e.g. PowerPlay groups, to have estimates of which modes their members are going into. Also it allows apps to filter out data from Training/CQC. |
4.1 Docked | Low | Include starsystem | The app can use “Location” and “FSDJump” entries to keep track of the user’s starsystem, but safer to list the starsystem here too. |
2.2 Heading | Low | Include client version number. | Allows apps in the future to process historical data differently depending on which version of the client wrote the data. Which shouldn’t be necessary, but might be handy to allow for.
(NB: "gameversion" and “build” properties are included in the sample log but not in the manual). |
new
_____________ | Nice to have | Journal should duplicate all functionality of the Companion API. Notably:
- Commodity market listing of prices, demand and stock
- Outfitters listing
- Shipyard listing | Making the Companion API redundant would mean that the user no longer has to supply their Frontier login details to 3rd-party apps. |