Discussion Commanders log manual and data sample

As others have said, internal names are preferable because we want single unique identifiers. Localisation is more of a client-side thing.
In principle I agree. However, if the Frontier client has the ID and has already localised it for us, why not just give us both. It means clients can do less work, can use the same set of localised values, etc. Win win win.
 
In principle I agree. However, if the Frontier client has the ID and has already localised it for us, why not just give us both. It means clients can do less work, can use the same set of localised values, etc. Win win win.
It would be good if Frontier could provide translation data (the revision is part of the log, so it would be Easy™ to use versioned translations with the highest version ≤ the log revision). Those would just be a chunk of key/value information, e.g., a big stonking JSON-encoded hash.

Having both would make things easier for purely local tools, but it would also add redundant and repeating information to the log.
 

Mu77ley

Volunteer Moderator
It would be good if Frontier could provide translation data (the revision is part of the log, so it would be Easy™ to use versioned translations with the highest version ≤ the log revision). Those would just be a chunk of key/value information, e.g., a big stonking JSON-encoded hash.

Having both would make things easier for purely local tools, but it would also add redundant and repeating information to the log.

That may be difficult to do if all the localisation stuff is handled in the same places (most likely) as there could very easily be spoilers in there.
 
Having both would make things easier for purely local tools, but it would also add redundant and repeating information to the log.
I was, in fact, thinking in terms of a purely local tool. Why raise the bar for such a thing when we the information is there already and easy to obtain. All I see being "repeated" is the internal ID is repeated but localised in a separate property inside the same line of json. So, if the id property (including label) is 20 characters you get roughly 20 more characters.

For a tool which was then uploading the information to a website for other users to see it could easily/simply strip the localised value. The website would then localise for each user individually.
 

hchalkley

Senior Programmer
Frontier
I think we can do auto-generated localised strings like this:
Code:
{ "timestamp":"2016-07-22T14:14:19Z", "event":"Location", "StarSystem":"LFT 926", "StarPos":[51.031,17.688,30.219], 
 "Economy":"$economy_HighTech;", "Economy_French":"Haute Technologie", 
 "Government":"$government_PrisonColony;", "Government_French":"Colonie pénitentiaire",
 "Security":"$SYSTEM_SECURITY_high;", "Security_French":"Haute sécurité",
 "Faction":"Los Chupacabras" }
(word-wrapped for legibility)
 
I think we can do auto-generated localised strings like this:
Code:
{ "timestamp":"2016-07-22T14:14:19Z", "event":"Location", "StarSystem":"LFT 926", "StarPos":[51.031,17.688,30.219], 
 "Economy":"$economy_HighTech;", "Economy_French":"Haute Technologie", 
 "Government":"$government_PrisonColony;", "Government_French":"Colonie pénitentiaire",
 "Security":"$SYSTEM_SECURITY_high;", "Security_French":"Haute sécurité",
 "Faction":"Los Chupacabras" }
(word-wrapped for legibility)

Instead provide a separate static translation file that we could use to map in post-processing. You shouldn't put localized text in the log.
 
Last edited:
Startup will state current credits balance and loan.

Could there be this and perhaps a dump of current player state at the start of each new log file, instead of just at client startup? This way totals from events can be synchronized with server-side values on a regular basis for long game sessions.
 
Last edited:
Instead provide a separate static translation file that we could use to map in post-processing. You shouldn't put localized text in the log.

Discussing with Artie and others on discord, maybe have a static file for the common elements (UI, ship events, etc.), and have specific translation entries in the log for dynamic events, such as star descriptions. This avoids large static files, and prevents spoilers from dynamic content.

The language tag should be ISO 3166 and language code should be ISO 639. So something like this:

EDIT: perhaps get rid of the semi-colon in the IDs?

Wrapped for legibility
Code:
{ "timestamp":"2016-07-22T14:14:19Z", "event":"Location", "StarSystem":"LFT 926", "StarPos":[51.031,17.688,30.219], 
 "Economy":"$economy_HighTech;",
 "Government":"$government_PrisonColony;",
 "Security":"$SYSTEM_SECURITY_high;",
 "Faction":"Los Chupacabras"
}
{ "timestamp":"2016-07-22T14:14:19Z", "event":"locale", "lang":"fr-FR",
 "$economy_HighTech;":"Haute Technologie",
 "$government_PrisonColony;":"Colonie pénitentiaire",
 "$SYSTEM_SECURITY_high;":"Haute sécurité"
}
 
Last edited:
Could you add events for shield down/restored, and ship damage passing certain thresholds? Say, hull damage going below 75%, 50%, 25%, 10%, etc?
 
If you want to keep things local to the events, how about something like this:
Code:
{
  "timestamp":"2016-07-22T14:14:19Z",
  "event":"Location",
  "StarSystem":"LFT 926",
  "StarPos":[51.031,17.688,30.219],

  "Economy":"$economy_HighTech;",
  "Government":"$government_PrisonColony;",
  "Security":"$SYSTEM_SECURITY_high;",
  "Faction":"Los Chupacabras",

  "txn":{
    "fr":{
      "Economy":"Haute Technologie",
      "Security":"Haute sécurité",
      "Government":"Colonie pénitentiaire"
    }
  }
}

That would make it easier to map translations to fields (no substring matches, just direct lookups).
 
If you want to keep things local to the events, how about something like this:
Code:
{
  "timestamp":"2016-07-22T14:14:19Z",
  "event":"Location",
  "StarSystem":"LFT 926",
  "StarPos":[51.031,17.688,30.219],

  "Economy":"$economy_HighTech;",
  "Government":"$government_PrisonColony;",
  "Security":"$SYSTEM_SECURITY_high;",
  "Faction":"Los Chupacabras",

  "txn":{
    "fr":{
      "Economy":"Haute Technologie",
      "Security":"Haute sécurité",
      "Government":"Colonie pénitentiaire"
    }
  }
}

That would make it easier to map translations to fields (no substring matches, just direct lookups).

That's not bad either. It keeps things nicely together. +1

EDIT: although I would use the actual IDs as keys for the translation. EDIT2: Hmm, or maybe not, thats good too
 
Last edited:
If you want to keep things local to the events, how about something like this:
Code:
{
  "timestamp":"2016-07-22T14:14:19Z",
  "event":"Location",
  "StarSystem":"LFT 926",
  "StarPos":[51.031,17.688,30.219],

  "Economy":"$economy_HighTech;",
  "Government":"$government_PrisonColony;",
  "Security":"$SYSTEM_SECURITY_high;",
  "Faction":"Los Chupacabras",

  "txn":{
    "fr":{
      "Economy":"Haute Technologie",
      "Security":"Haute sécurité",
      "Government":"Colonie pénitentiaire"
    }
  }
}

That would make it easier to map translations to fields (no substring matches, just direct lookups).

+1 I like it.
 
Last edited:
With the bounty object .. does that only get written for NPC's or will it also include PvP. Be nice if it included the CMDR name - of the target destroyed.
 
Really, the version hchalkley proposed is the simplest way to do it, both for the game writing the logs, and anyone wanting to read them. The only thing I'd see as an improvement there is changing e.g. "Economy_French" to "Economy_Localised", and then anything reading it wouldn't need to look for these values, or even know which language the player is using.
As these localised values would only be relevant for local display (the $whatever; things should be parsed/stored/uploaded instead), just showing any _Localised directly to the player should be fine. Websites wanting to display the localised text should have no problems gathering the translations with the help of users.
 
Last edited:
Really, the version hchalkley proposed is the simplest way to do it, both for the game writing the logs, and anyone wanting to read them. The only thing I'd see as an improvement there is changing e.g. "Economy_French" to "Economy_Localised", and then anything reading it wouldn't need to look for these values, or even know which language the player is using.
As these localised values would only be relevant for local display (the $whatever; things should be parsed/stored/uploaded instead), just showing any _Localised directly to the player should be fine. Websites wanting to display the localised text should have no problems gathering the translations with the help of users.

This - then the programmer has constant keys to deal with - and put a 'locale': 'fr', key/value pair (ISO 631 codes) into the Heading (you do want to rename it to Header, don't you?) so we know what is in use for this game session.
 
Really, the version hchalkley proposed is the simplest way to do it, both for the game writing the logs, and anyone wanting to read them. The only thing I'd see as an improvement there is changing e.g. "Economy_French" to "Economy_Localised", and then anything reading it wouldn't need to look for these values, or even know which language the player is using.
As these localised values would only be relevant for local display (the $whatever; things should be parsed/stored/uploaded instead), just showing any _Localised directly to the player should be fine. Websites wanting to display the localised text should have no problems gathering the translations with the help of users.

+1 for simplicity, I like this too
 
Really, the version hchalkley proposed is the simplest way to do it, both for the game writing the logs, and anyone wanting to read them. The only thing I'd see as an improvement there is changing e.g. "Economy_French" to "Economy_Localised", and then anything reading it wouldn't need to look for these values, or even know which language the player is using.
As these localised values would only be relevant for local display (the $whatever; things should be parsed/stored/uploaded instead), just showing any _Localised directly to the player should be fine. Websites wanting to display the localised text should have no problems gathering the translations with the help of users.

Exactly this.
 
Back
Top Bottom