Discussion Commanders log manual and data sample

A very big request

It is advisable to add:

- in an entry with a description of the system, its Hipp, HD, Gliese, and, in addition, a localized text with a description, if any;

- when scanning a tourist beacon, it is also desirable to provide more complete information (localized) - the name of the lighthouse, the number of the attraction and the localized text obtained during scanning.

thanks.
 
Anyone know why log may be stopped? I've found today on EDSM that part of journey missed, got there journal and... nothing changed. And I've found that last change of log journal was in about 3 hours before I log outed. Why it may be happend and where may be missed part of log?
 

Attachments

  • Journal.211204092827.01.log
    452.3 KB · Views: 11
Anyone know why log may be stopped? I've found today on EDSM that part of journey missed, got there journal and... nothing changed. And I've found that last change of log journal was in about 3 hours before I log outed. Why it may be happend and where may be missed part of log?
This sounds like the known game bug where it sometimes stops writing to the Journal file. There's nothing any third-party software can do about that. There have been several issues opened with frontier about it, e.g. https://issues.frontierstore.net/issue-detail/35645 , but no-one's been able to track down why or how it happens in order for Frontier to fix it.
 
This sounds like the known game bug where it sometimes stops writing to the Journal file. There's nothing any third-party software can do about that. There have been several issues opened with frontier about it, e.g. https://issues.frontierstore.net/issue-detail/35645 , but no-one's been able to track down why or how it happens in order for Frontier to fix it.
Given a similar situation I saw with the netlog when the HDD my game is on was under heavy load, it makes me wonder if it is caused when a write to the journal file (or flush to disk) takes too long to complete.
 
Last edited:
Well, so currently (in Horizons, at least) it only has ID, name, isCompleted and expiry timestamp, while other events, such as MissionAccepted has basically everything; localised name, faction, rewards, objectives, destination system etc. So basically all of that. We have a bunch of data dump events at this point, and I think this one makes sense, too. I think the event is not all that useful as it stands.
 
Well, so currently (in Horizons, at least) it only has ID, name, isCompleted and expiry timestamp, while other events, such as MissionAccepted has basically everything; localised name, faction, rewards, objectives, destination system etc. So basically all of that. We have a bunch of data dump events at this point, and I think this one makes sense, too. I think the event is not all that useful as it stands.
That would, of course, be good. Don't be surprised if any answer from Frontier is "the game client doesn't have that data at that point, so it can't go in that Journal event".

Obivously there's a boot-strap problem, but the way to handle this is to remember the details from when a Mission is accepted, and track it across all game sessions. Yes, there's at the very least a bug with Odyssey where saying you'll consider the options of an in-person on-foot mission causes an 'Accepted' event straight away, with no indication as to if you did actually accept it in the end (at least I've not heard about them fixing this).
 
Obivously there's a boot-strap problem, but the way to handle this is to remember the details from when a Mission is accepted, and track it across all game sessions. Yes, there's at the very least a bug with Odyssey where saying you'll consider the options of an in-person on-foot mission causes an 'Accepted' event straight away, with no indication as to if you did actually accept it in the end (at least I've not heard about them fixing this).
Remembering details from the Mission accepted event is exactly the approach we take, but if our app wasn't running during the last play session then we might still miss information needed to fill in full details. So yes, I agree that filling out the Missions event at game start (or writing a missions.json file?) would be desirable if the option is available.

Since we're on the topic, here's my current wish-list for journal mission events improvements.
  • Fix the Odyssey bug where negotiating an on-foot mission is recorded as accepting the mission, irrespective of if you actually do accept the mission.
  • Fix a bug where failed Odyssey on-foot missions are not recorded in the player journal, even though it is clearly evident that they have failed in the game UI.
  • Fix a bug where Odyssey mission completion is sometimes not recorded in the player journal.
  • Fix missing DestinationSystem and DestinationStation (and DestinationBody?) properties for on foot missions in the MissionAccepted event.
  • For Odyssey on-foot missions, the mission expiration timer can change (often by +1 day) once the mission objective has been completed. Add missing information about the updated mission timer when the MissionRedirected event is written?
  • Generate a MissionAccepted event when accepting a mission offered via in-ship message, e.g. "event":"ReceiveText", "From":"$npc_name_decorate:#name=ARIEL;", "From_Localised":"ARIEL", "Message":"$Mission_Collect_CivilUnrest_MessengerChat1...
 
Top Bottom