Discussion Commanders log manual and data sample
- Thread starter Zac Antonaci
- Start date
Hi Howard, since you're updating the list, could you have a look at my request for a journal entry for 'music mood' so we can select appropriate playlists? Thanks in advance.
Thanks Howard!, Many of the targeting information is accessible via in game, like subsystems targeting, i think this shouldn't affect balance and i hope this improve the game experience
Many of the targeting information is accessible via in game, like subsystems targeting, i think this shouldn't affect balance and i hope this improve the game experience
I think targeting and subsystem targeting is a bit tricky. We selecting targets mostly by next/previous. I can scroll through 10 to 20 targets or subsystems per second with my HOTAS or GlovePie script for XBox Controller support.
Would you generate a log entry each time? I don't think that make much sense.
I think you're misunderstanding my approach. I just want to know the subsystem name in the targeted objective, besides other information of that, this only generates an entry in the log.
If your approach is focused on a misuse, there are many log entries that can be questioned.
Your suggestion lists "Subsystem targeted", what Lemny is saying is that this can change rapidly, particularly when scrolling through the possible subsystems. If an event is emitted for each selected one (if only momentarily during the scrolling) this is rather going to spam the journal. Or, did you mean "list the subsystems on the target when it is targeted" ? i.e. you just want a list of what the target ship has fitted.
Of course it's really only other computer programs that are going to be looking at this, and I don't think the journal files are suddenly going to explode in size due to this, so I don't think it's really an issue.
The entries must be generated on new target selection and in change of subsystem selection.
It's true that at certain times this can generate quite elevated number of entries, but these situations tend to be less continuous, I think, as log would not be collecting an amount of information out of the normal than other logs with I have worked up.
If design team think the amount of information is excessive or affect to balance i will change my point view.
Last edited:
On every larger vessel I want to destroy, I select the power plant as subsystem by "nexting" 7 times (with a simple macro but this doesn't matter) followed +/- 1 sometimes 2, if the target has a different loadout.
The same goes for the ship targeting. While in HAZ RES I rapidly scroll through the targets for unscanned vessels with the wheel on the HOTAS or per special targeting support via the analog triggers i implemented in GlovePie.
While we're on a roll here...
I've noticed that the 'ShieldState' journal event is now broken in 2.3.
I will get a "ShieldsUp":false entry when the shields go down, but not a corresponding "ShieldsUp":true entry when they go back up after re-charge.
I've noticed that the 'ShieldState' journal event is now broken in 2.3.
I will get a "ShieldsUp":false entry when the shields go down, but not a corresponding "ShieldsUp":true entry when they go back up after re-charge.
Last edited:
Cool, I appreciate it thanks.
No, I don't have that bug. If you'd like more info in case it helps to know when the bug doesn't happen let me know.
Cheers
Hey hchalkley,
we found a (serious | funny | interesting | devastating - pick one) bug:
From https://forums.frontier.co.uk/showt...te-Dangerous?p=5410538&viewfull=1#post5410538
we found a (serious | funny | interesting | devastating - pick one) bug:
From https://forums.frontier.co.uk/showt...te-Dangerous?p=5410538&viewfull=1#post5410538
Wow - what a find!
The name coming from the API is Nicollier Hanger and the name coming from the Journal is Nicollier Hangar - this is the perfect data inconsistency bug example.
Only Frontier can fix this...
I understand your point, because is the way everybody are using at the moment, but a lot a of player, including me, wanna precise information about the target, subsystem are a good reason, but another information like name, faction, shield percent at the moment will be a awesome and invaluable info on combat and patrol scan.
The subsystem info would be not possible and I think it's not really necessary.
But the other Information could be logged when the initial scan is finished. Earlier would make no sense because you don't have such information in game yet and with the scan event as a trigger we would have no spam within the log and each ship would only be logged once.
Just thought it was time to put the EDDiscovery team thanks to all at Frontier and @hchalkley in particular for the journal. You have transformed the usefulness of this tool by adding in this interface. And with 2.3, we can now offer a complete insight into your Engineering and Synthesis possibilities.
Many thanks, keep up the good work
Ps. And give us more ;-)
Many thanks, keep up the good work
Ps. And give us more ;-)
And don't forget the absolutely genius EDEngineer! I can't live without anymore.
Speaking of targeting information. A wonderful use case came in mind:
If we also have a log entry of targeting a material (it does not happen while nexting through targets) EDEngineer could bring a popup if the targeted material is on the shopping list or below a given threshold.
In my dreams of a season of QOL features, I see such functions within the game and the onboard computer spit out a warning about a required material nearby in the target list.
And we have smart collector limpets, which could grab this stuff for us without suicide or as ammo of the limpet controller. *sigh* ...only dreams...
Speaking of targeting information. A wonderful use case came in mind:
If we also have a log entry of targeting a material (it does not happen while nexting through targets) EDEngineer could bring a popup if the targeted material is on the shopping list or below a given threshold.
In my dreams of a season of QOL features, I see such functions within the game and the onboard computer spit out a warning about a required material nearby in the target list.
And we have smart collector limpets, which could grab this stuff for us without suicide or as ammo of the limpet controller. *sigh* ...only dreams...
I think that should be decided by the design team.
But is a good point use the initial Scan as a trigger, also combine it with subsystem change to take the name and health of selected subsystem at the moment.
Having the subsystem name each time you change subsystem targeted could result on Voiceattack subsystems targeting precise commands and alerts.
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.