What is that useful for? The game supplies text in the player's chosen language, and the player's programs display that text as-is. Why would they care which language it is?
Discussion Commanders log manual and data sample
- Thread starter Zac Antonaci
- Start date
What is that useful for? The game supplies text in the player's chosen language, and the player's programs display that text as-is. Why would they care which language it is?
Yeah, but JUST for the star descriptions and other "custom" texts (I am writing this just for the case I was misunderstood). For the system securities, governments, etc. translations (simply the "type definitions") I think it is better to has it outside the log completely. But if it will be simpler to create, I am OK with the "Economy_Localised" and the language identifier in the "Headings" solution.
Last edited:
I'm with some of the others here; So long as the keys aren't subject to localisation, even a newb like me should be able to figure it out. I'd much rather have localised output, I don't think it should break too much since most of the items we're working with are variable length anyways. A language tag in the header would be nice for sorting multiple player logs by language, I guess?
Would it be possible to have an option in the launcher/game for symbol output for devs that want multi-lingual support? I don't personally need or want it, but I imagine some might.
Also, is there any standards for how long the logs are kept, and how often they're split? Sorry if that's been answered, I just couldn't find it with a search.
Would it be possible to have an option in the launcher/game for symbol output for devs that want multi-lingual support? I don't personally need or want it, but I imagine some might.
Also, is there any standards for how long the logs are kept, and how often they're split? Sorry if that's been answered, I just couldn't find it with a search.
I agreed on this, that would be very helpful. There are many tools and libraries available that work with standardized codes.
From what I understand, this log isn't so much meant to be viewed by players. It's finally a first step for interopability with third-party tools. So please let's have interoperability first, human readability second.
To me, either way "_Localized" and suffixed with ISO 3166 alpha-2 code "_CODE" seems fine.
But just to be nitpicking: Crowd-sourcing data/translations isn't a "no-problem" problem, but requires tooling, validation, aggregation and more validation.
Last edited:
A couple of questions/comments:
- 5.3: Died. Is there an event if a player dies from something other than another player? I'm thinking of anything from hitting an asteroid to running out of fuel to a station destroying you. Same thing for when in the SRV and out of fuel, or too much hull damage.
- 10.1: Cockpit breached. Is there an equivalent event for when the player enters an atmosphere (i.e. a space station)? I can see an event triggered when the player docks, but the oxygen countdown stops when entering the station and hence before docking takes place.
This log news is fantastic, looking forward to seeing what the tool creators can do with it.
Themroc's post is a pretty complete list but I'd like to add some details to it.
When docked could we please get a few more station details when you dock at a station: Distance from arrival point, Controlling major faction, Economy. This is information that we still have to manually gather as it's not available from the companion app API and it makes fully populating stations on our databases rather fiddly.
Themroc's post is a pretty complete list but I'd like to add some details to it.
When docked could we please get a few more station details when you dock at a station: Distance from arrival point, Controlling major faction, Economy. This is information that we still have to manually gather as it's not available from the companion app API and it makes fully populating stations on our databases rather fiddly.
Thanks for the fantastic news Zac and Howard! Remind me to buy you a beer if we ever meet at LaveCon in the future Howard, or a soft drink if alcohol isn't your thing
So I've started working on a log parser + generator, so we can start working on integration before 2.2, it will eventually(TM) work using genetic algorithms to try and produce a psuedo-realistic log, but for now I'm working on parsing the example log into workable objects.
One small part of feedback I have: why are some of the event records keys lowercase and some uppercase? One example, from 3.1, ClearSavedGame:
"15:08:42": { "event":"ClearSavedGame", "Name":"HRC1" }
I understand I can work around this by just lowercasing everything myself, but for the sake on consistency, can we have all keys lowercase?
Thanks and keep up the good work
So I've started working on a log parser + generator, so we can start working on integration before 2.2, it will eventually(TM) work using genetic algorithms to try and produce a psuedo-realistic log, but for now I'm working on parsing the example log into workable objects.
One small part of feedback I have: why are some of the event records keys lowercase and some uppercase? One example, from 3.1, ClearSavedGame:
"15:08:42": { "event":"ClearSavedGame", "Name":"HRC1" }
I understand I can work around this by just lowercasing everything myself, but for the sake on consistency, can we have all keys lowercase?
Thanks and keep up the good work
Another small inconsistency I just noticed: 3.3 LoadGame uses the key Commander whilst ClearSavedGame and NewCommander use Name :S. I guess I can also work around it by providing an alias key Name which just copies the value from Commander.
EDIT:
This behaviour also appears in some of the examples such a 8.23 ShipyardBuy:
"15:28:14": { "event":"ShipyardBuy", "ShipType":"anaconda", "ShipPrice":114636172, "StoreOldShip":"SideWinder" }
anaconda vs SideWinder
EDIT:
This behaviour also appears in some of the examples such a 8.23 ShipyardBuy:
"15:28:14": { "event":"ShipyardBuy", "ShipType":"anaconda", "ShipPrice":114636172, "StoreOldShip":"SideWinder" }
anaconda vs SideWinder
Last edited:
One more nugget of feedback
Can 5.4 Died be renamed to DiedWing? I intended to use the category names as dictionary keys, and this will cause 5.4 Died to overwrite 5.3 Died
Can 5.4 Died be renamed to DiedWing? I intended to use the category names as dictionary keys, and this will cause 5.4 Died to overwrite 5.3 Died
Sorry for the 4th post in succession, writing things down as I think/remember them.
On the EDCD discord we had a few discussions regarding providing an "anonymisation" option for the journal. Others mentioned that you should only install programs you trust, whilst I err on the side of caution and would rather protect against potential abuse.
My main concerns were first about not providing commander names to avoid possible witchhunting if you were to parse FSDJump locations, but also in regards to ReceiveText and SendText. The anecdote I thought of was someone parsing a commander's chat logs with a regex string for credit card / phone numbers. I know myself to be a bit paranoid, so maybe my concerns are a bit misplaced.
On the EDCD discord we had a few discussions regarding providing an "anonymisation" option for the journal. Others mentioned that you should only install programs you trust, whilst I err on the side of caution and would rather protect against potential abuse.
My main concerns were first about not providing commander names to avoid possible witchhunting if you were to parse FSDJump locations, but also in regards to ReceiveText and SendText. The anecdote I thought of was someone parsing a commander's chat logs with a regex string for credit card / phone numbers. I know myself to be a bit paranoid, so maybe my concerns are a bit misplaced.
One more nugget of feedback
Can 5.4 Died be renamed to DiedWing? I intended to use the category names as dictionary keys, and this will cause 5.4 Died to overwrite 5.3 Died
5.3 should be dropped. It can be replaced with 5.4 having a single entry in each array.
One of the best things about ED , is its full of very smart people , you only have too see the feedback on this thread,& others, plus the work that goes into Web sites Excel Database third party apps, its great.
So I wish the Senior 'LOG' programmer , and those here who know what their talking about, got together
I'm really hoping that ED as a crowdfunded game , starts thinking about players who could really contribute to the code and the game
So I wish the Senior 'LOG' programmer , and those here who know what their talking about, got together
I'm really hoping that ED as a crowdfunded game , starts thinking about players who could really contribute to the code and the game
And a question on synchronisation: if I receive (for example) a "ShipyardBuy" event can I query the companion app API safe in the knowledge that it will give me the data on the new ship, or might there be a delay between seeing the event and the server being updated? I'm very much hoping the former, because otherwise it's going to be a right pain to provide useful event-based triggers.
Another request: List of possible values (within reason?) Things like StationType, Faction names?
For parameter such as commander name, can we get the maximum number of characters that can be in a commander's name?
For parameter such as commander name, can we get the maximum number of characters that can be in a commander's name?
Currently the Companion API lags game events. Typically the lag is less than a second, but sometimes can be much more. I don't see anything in the proposal about changing the Companion API, so don't expect this to change.
Unless FDev implement the suggestion to make the Companion API redundant.
Last edited:
Representing the Rock Rats feedback here.
We absolutely LOVE the changes coming (material distribution) but we do hope all scans done in the past are being retroactively applied since people will not re-scan all bodies of course. It should be easy to do for FD and it would be a tremendous help for the community since EDDB data exposing prospecting results would flourish A LOT more.
We absolutely LOVE the changes coming (material distribution) but we do hope all scans done in the past are being retroactively applied since people will not re-scan all bodies of course. It should be easy to do for FD and it would be a tremendous help for the community since EDDB data exposing prospecting results would flourish A LOT more.
This could actually be useful: if "event" is the only lowercase one (as it isn't a property of an actual event), that's a half-decent way of avoiding any possible collisions - it's not actually a key on the event, it's telling you what it is. Timestamp would potentially also fall into this category.
That's a very good idea; +1 for having the format be consistent between the two, just only populated with one entry if it's not a wing.
Last edited:
Something that was asked on EDCD a day or so ago was about having the area of influence included. Since most planetary outposts (settlements, bases, etc.) have a sphere of influence that stretches 400km, and most people wouldn't want to go that distance in normal flight, it would be nice if the outpost and its controlling party were included in the SupercruiseExit event.
Last edited: