Discussion Commanders log manual and data sample

I see what you would like to do :) ...with the subsystem spamming you could spam "next target" until a given subsystem is selected.
I use the logs for some QOL features too with a self written c# tool, but I think the price with the spam of subsystems in the log is to high to archive this functionality.

Right men, but is the only option, i think so [blah]
 
I was asked by the designers not to include the details of engineer mods values, as the internal raw values I have access to are not the same as the results that are displayed in the GUI, this extra complexity adds support problems and potential future compatibility problems.

I think I speak for pretty much everyone that we have been dealing with discrepancies for quite some time now and we're ok with it. I do refer to coriolis.edcd.io when playing with load outs and I don't care about the values of the outfitting screen, which are not helpful much.

So, please, tell these designers that they are erring on the wrong side here. This is really an important feature that was REMOVED for no good reason. There are many oddities in the game, I don't think that having somewhat conflicting values in the outfitting screen is so important.
 
Last edited:
Hi Andagor, I am aware of that bug report. At present our priority is fixing critical issues such as any crashes, tha galaxy map gui problem, server performance spikes (which affect its ability to respond promptly, causing some disconnects) and a dozen or so other such issues. I have been able to convince production that any journal syntax bugs that might break 3rd party tools are also critical. (Note, Scanning an asteroid cluster may currently give a "RotationPeriod":inf value, as the double-precision number was bigger than FLT_MAX)
Adding further info to the journal will have to wait for a scheduled update, not an emergency patch.
It's likely to be easier and quicker to fix the engineering info in the companion api, as Webserver fixes don't need a game update, but it may still take a little time.

Sometimes, I'm wondering if you guys are rewriting the entire game each time there is a major update. There are many things that are working and don't seem involved in any new features that break. For example, the GUI bug in the galaxy map. I'm sure there is a good reason for that bug; I just can't understand why this was working fine for almost 2 years and is now broken by an update. Oh, and I've been a developer for over 25 years, so I think I know a thing or two ;). Not critical, I appreciate the huge effort that this game must required, believe me. I'm not sure I would want to be involved in such project as I am sure it must be crazy sometimes. But I'm still worried that things that were working, that didn't seem involved in new features, are suddenly broken...
 
I was asked by the designers not to include the details of engineer mods values, as the internal raw values I have access to are not the same as the results that are displayed in the GUI, this extra complexity adds support problems and potential future compatibility problems.


I think I speak for pretty much everyone that we have been dealing with discrepancies for quite some time now and we're ok with it. I do refer to coriolis.edcd.io when playing with load outs and I don't care about the values of the outfitting screen, which are not helpful much.

So, please, tell these designers that they are erring on the wrong side here. This is really an important feature that was REMOVED for no good reason. There are many oddities in the game, I don't think that having somewhat conflicting values in the outfitting screen is so important.


Hopefully the highlighted text will explain what the reason was.
 
Hopefully the highlighted text will explain what the reason was.

Give me a break, will you? Future compatibility? What are you talking about? Please, explain how an external API generating JSON files can be a compatibility for the game? This is horse just to justify the decision. Once that data is taken out of the API, it is NOT fed back into the game. Hey, you'll need to try a little harder. There is no way in hell it could create a compatibility problem for the game. And judging on how Frontier is treating the 3rd party developers for THEIR game, I doubt the lame compatibility problem you're talking about is for the 3rd party tool. So, give me a break and stop spreading smoke and mirrors.

See, I can play with the tags too!
 
I was asked by the designers not to include the details of engineer mods values, as the internal raw values I have access to are not the same as the results that are displayed in the GUI, this extra complexity adds support problems and potential future compatibility problems.

Please, explain how an external API generating JSON files that are in no way related to the game can be a future compatibility problem. Because there are some trolls here that are starting to use that excuse just to give people a ride for their money.
 
He mentioned that he has access to the raw values, but those are not the ones displayed in the UI.
So, in the future they might decide that those raw values will change, maybe in range, maybe in the exactness of the value. If the API expects a float (4 bytes) but all of a sudden starts receiving a long double (10 bytes), there could be issues.

Being that it is an internal number, it shouldn't even be available. At most, they should supply the same value that goes to the UI, as that has been normalised already.

I know very well the problems of developing 3rd party tools without an open communication with the developer. It's hard. But this is the first time I've seen someone throw a tantrum because it doesn't go their way.

At least FD provides an API, how limited it might be. Some games you have to access the memory and figure out what is what without any support.
 
He mentioned that he has access to the raw values, but those are not the ones displayed in the UI.
So, in the future they might decide that those raw values will change, maybe in range, maybe in the exactness of the value. If the API expects a float (4 bytes) but all of a sudden starts receiving a long double (10 bytes), there could be issues.

Being that it is an internal number, it shouldn't even be available. At most, they should supply the same value that goes to the UI, as that has been normalised already.

I know very well the problems of developing 3rd party tools without an open communication with the developer. It's hard. But this is the first time I've seen someone throw a tantrum because it doesn't go their way.

At least FD provides an API, how limited it might be. Some games you have to access the memory and figure out what is what without any support.

I understand what you are saying. But I've been a developer for over 25 years and there are ways you can program defensively to make sure that you can support those things, specially when we're talking about a simple export of raw data. Of course, if they cut corners, they might have painted themselves in a corner. But, even if they internally change the type of variables that they use and that causes the API to break, so be it. In the meantime, why being proactively shutting oneself in the foot? Let's cross the river when we get to the bridge, please.
 
He mentioned that he has access to the raw values, but those are not the ones displayed in the UI.
I suspect that whatever designer(s) asked him not to expose those raw values were ignorant of the fact that they were already exposed in the Companion API. I know jgm (coriolis.edcd.io) and others had been spending time working out how the raw values related to in-game values.

Basically whatever concerns that designer might have had were already addressed in the live Coriolios, ED Shipyard, and possibly other tools. Sure, the third party devs involved had to put in some extra work to get it working, and would have needed more such work if there was any change to the raw represenation, but they had already done that and would have proven willing to continue.

Of course ideally FDev would expose the game UI values in the player journal so as to negate any need for this hackery, but that's the situation third party devs have been in. Putting in that work and having the data was much more preferable than the 2.3 situation of now not having the data at all.
 
Hey hchalkley may I offer a suggestion for the player journal, which would enable Frontier to support all kinds of log output without fear of breaking anything for normal players?

6kbSRUA.png


This is a screenshot from X-Plane 11. It allows users to customize the output. X-Plane not only supports writing to a file, but also to a network device via UDP - but the key takeaway here is that you can check and uncheck things you want or don't want!

Why am I suggesting this? Because Elite Dangerous is one of those cockpit-heavy games that would benefit from more detailed damage events, and I'd really love to have players be able to switch on file output for individual weapon hits and other damage events, beyond the current "one event every x % of damage". The more detailed the output, the more sophisticated external lights and effects can be set up.

Simpit builders would love you for this. It'd make damn great youtube and promo material for the game too *hint hint* :)

Anyway, I'm not saying that I'm super angry if you guys don't have the time for stuff like this, I just think it'd be a cool opportunity to make ED grow beyond the confines of a computer screen a little bit. And hey, maybe the X-Plane UI screenshot here is a useful source for ideas for you guys!
 
Last edited:
UDP, now there's something we need on XBox One!

Afaik you are not allowed to just open a port to another IP or send udp packets to LAN on XBox, outside their multiplayer API. If your software does that, you don't get approved.
Xbox would need more direct support, for example usb dmx interfaces.
 
Last edited:
Last edited:
Not sure if this is the correct place to report this.
Last night was interdicted by a CMDR, attempted to evade but was too close to a planet/moon. As a result was forced out of supercruise. No entry was made in the journal for either the attempted interdiction nor the evasion of the interdiction. Only entry was for dropping out of Supercruise(4.12 SupercruiseExit). Is this as expected?
 
Not sure if this is the correct place to report this.
Last night was interdicted by a CMDR, attempted to evade but was too close to a planet/moon. As a result was forced out of supercruise. No entry was made in the journal for either the attempted interdiction nor the evasion of the interdiction. Only entry was for dropping out of Supercruise(4.12 SupercruiseExit). Is this as expected?

This should be reported as a bug, here:
https://forums.frontier.co.uk/forumdisplay.php/124-Elite-Dangerous-Bug-Reporting
 
Is there anywhere a list of the various mission type names for the journal event "MissionAccepted", so I am able to identify the type and the related icon displayed in the game?
Sadly the different types are not covered by the journal manual.
Thanks in advance.
 
Last edited:
Is there anywhere a list of the various mission type names for the journal event "MissionAccepted", so I am able to identify the type and the related icon displayed in the game?

I don't know of any such list. But there seems to be a lot of different names. I just greped these from my Journal files and I don't play that much missions:
Code:
[
    "Chain_HelpFinishTheOrder",
    "MISSION_Salvage_Refinery",
    "MISSION_Scan",
    "Mission_Altruism",
    "Mission_AltruismCredits",
    "Mission_AltruismCredits_Bust",
    "Mission_AltruismCredits_CivilUnrest",
    "Mission_Collect",
    "Mission_Collect_Industrial",
    "Mission_Courier",
    "Mission_Courier_Boom",
    "Mission_Courier_Elections",
    "Mission_Courier_Engineer",
    "Mission_Courier_Expansion",
    "Mission_Courier_Lockdown",
    "Mission_Courier_Service",
    "Mission_Courier_War",
    "Mission_Delivery",
    "Mission_Delivery_Boom",
    "Mission_Delivery_CivilUnrest",
    "Mission_Delivery_Cooperative",
    "Mission_Delivery_Democracy",
    "Mission_Mining_Boom",
    "Mission_PassengerBulk",
    "Mission_PassengerBulk_BUSINESS_ARRIVING",
    "Mission_PassengerBulk_REBEL_ARRIVING",
    "Mission_PassengerVIP",
    "Mission_PassengerVIP_CEO_BOOM",
    "Mission_PassengerVIP_Criminal_BOOM",
    "Mission_PassengerVIP_General_WAR",
    "Mission_PassengerVIP_Scientist_WAR",
    "Mission_Rescue_Planet",
    "Mission_Sightseeing",
    "Mission_Sightseeing_CEO_BOOM",
    "Mission_Sightseeing_Criminal_BOOM",
    "Mission_Sightseeing_Doctor_CIVILWAR",
    "Mission_Sightseeing_Doctor_OUTBREAK",
    "Mission_Sightseeing_Doctor_WAR",
    "Mission_Sightseeing_General_WAR",
    "Mission_Sightseeing_Tourist_BOOM"
]
They look grouped. So I guess you could get away with a group name for the icons.
 
Top Bottom