Discussion Commanders log manual and data sample
- Thread starter Zac Antonaci
- Start date
Howard, there is a bug with the SetUserShipName event. Details are at https://forums.frontier.co.uk/showt...entry-for-SetUserShipName-incorrect?p=5220805 but in brief the "UserShipId" is only written out when the ship ID (as opposed to the ship name) changes.
Robert Maynard
Volunteer Moderator
.... but it is available on the RH HUD just after entering the system?
A supplementary write could occur after arrival in said system listing Pending and Recovering states....
Last edited:
Hi, would it be possible to add a holo-me import/export feature? Even if it is just a coded string
.... but it is available on the RH HUD just after entering the system?
A supplementary write could occur after arrival in said system listing Pending and Recovering states....
This would incur a server request and database lookup on every jump by every commander - I suspect this is the issue here.
If it was triggered by the player actually opening the RHS panel and selecting the faction, then no extra work would be incurred and we might get some traction here
But does the client do that request any way to pre-fill info for the right hand panel? I've tried to look at that ASAP after completing a jump and never seen a delay in the information being available there. I believe what Howard is saying is that such a request might not have completed at the very moment the FSDJump event is run, probably happening a short (sub-millisecond, plus network latency) time after. What the poster above was requesting is that this event be triggered when that data for right-hand panel is made available, even if only triggered by looking at it.This would incur a server request and database lookup on every jump by every commander - I suspect this is the issue here.
If it was triggered by the player actually opening the RHS panel and selecting the faction, then no extra work would be incurred and we might get some traction here
I get Dave C's argument.
The groups that track this have been doing so through a lot of hard boring work. For years.
It's a tough choice to follow the BGS hamster.
You kinda need a critical mass of competent CMDRs who can consistently devote hours of potential play time to plugging numbers into a database and analysing them.
It's niche.
Opening it up to an API means that the BGS could become a mere popularity contest.
You know Jane Turner has clocked a year in-game?
That's from staring at the GalMap pushing the numbers.
Dave C must be pretty close given how much BGS management he does.
Part of me wants to celebrate how easy it will be to collect / contribute the data.
But the rest hears the rumbling of weight of numbers.
The fact that Jane and Dave have HAD to spend that much game time to keep on top of their stuff is a testament to the dire need for automation. Seriously - no one wants to spend time doing data entry on stuff that should be copy/paste at worst. Trying to use them as examples of why it shouldn't be made easier, is like arguing that we shouldn't get rid of landmines, because it's unfair to the people who already lost a leg.
Any chance of adding a journal event when a new in-game email is received? There's currently no journal event at all for things like missions updating (has this changed in beta?) - and having the full text of the messages (or perhaps a structured journal event would be better) available would allow for having a local program read out pertinent details (even if it's only the type of wrinkle) to you, so you can continue with the business of flying (sometimes these wrinkles happen in the midst of docking when you already got given a very short bonus ETA timer), but still be aware of the new wrinkle consequences.
I'd have to look over my inbox to see if it would be better to add individual journal events for all the possible message types (including things like tip-offs), or if a generic "you've received a new message, here's who it's from, the contents etc" would be the way to go.
I'd have to look over my inbox to see if it would be better to add individual journal events for all the possible message types (including things like tip-offs), or if a generic "you've received a new message, here's who it's from, the contents etc" would be the way to go.
Robert Maynard
Volunteer Moderator
Good morning, again a quick poke about the question of the possibility of exporting/importing commander profiles? I would like to create a backup and database for people to share their holo me's. Think that would be FANTASTIC.
Please do lmk
.... and, if only written to the log when a player saves their Holo-Me, it would not add much output.
Good point. It might work either way. I haven't seen a delay in populating the data either, which might mean it is triggered by an action earlier in the process, or is a fast lookup (it should be as it's for a specific system / presumably indexed on ID), or (as you mention) it might always happen in the background. In any case, assuming a lookup is triggered (in the current/normal way) an event could fire at that time.
2.3 beta notes have Atmospheric Composition added to the Journal on a DSS scan. Do we know if Planet Composition and Axial Tilt are coming, too?
Can you elaborate on this? Will this be a list matching the order of modules in the 'Modules' screen?
We also need an event for when a fighter is destroyed, otherwise the fighter status is just hanging out there.
Lastly, what's a 'Helm's log'...
Is this also the case for the star class as shown in the Galaxy Map? E.g M4 VA, BIII AB?
I know that this probably won't make it in to 2.3 but if you could add a "FireDrone" event to your TODO list for the journal it would be much appreciated.
Reason behind this is that we have BuyDrones and SellDrones events, but because there's no record of when they are used we can't keep accurate track of how many we are carrying. Bonus points for stating if the drone is targeted or not (for collection limpets) and what type of controller is controlling it (fuel/collector/prospector/hatch breaker).
Reason behind this is that we have BuyDrones and SellDrones events, but because there's no record of when they are used we can't keep accurate track of how many we are carrying. Bonus points for stating if the drone is targeted or not (for collection limpets) and what type of controller is controlling it (fuel/collector/prospector/hatch breaker).
And one more for you: the "Loadout" event is missing information on the size of the slot. We can just-about work this out for hardpoints and internals by parsing the slot name, but for military slots and core internals the data just isn't available. So if you could sneak in a "SlotSize" for each module (0 tiny up to 4 huge, or even use the names if you're feeling generous) it would go a long way to making the data a bit more useful.
I've raised this as a bug, along with a few other bits and pieces that are missing when compared to the companion API version of the data.
I've raised this as a bug, along with a few other bits and pieces that are missing when compared to the companion API version of the data.
Last edited:
