Journal file entry FSSBodySignals missing for autoscanned bodies?

athulin

A
I'm considering making an issue out of this, but I'd like to check that I am not making some silly mistake, and it isn't already a well-known and ignored issue, or that there are questions I haven't realized yet.

I'm looking for brain trees. I use a) the in-game planet map to check FSSed systems for signals of biolife (and other interesting things), and b) I use EDMC with Canonn and BioScan plugins as a fast way to see what is present. However, in a number of recent cases, I got different results: in-game data tells me there is biolife on planet X, while EDMS plugins do not report anything of the sort.

After some digging in journals, this seems to be because planet X is autoscanned on system entry, and this seems to remove it from the list of bodies that FSS presents for manual attention once the FSS display is shown.

Now, while FSS scanning does produce FSSBodySignals for bodies that have them, autoscan doesn't, and if a body has been autoscanned it is no longer available for a manual FSS so that FSSBodySignals can be added.

So ... correct info in-game, but info missing from journal file.

That's what I think happens, at least. (By FSS scan I mean FSS only, not preceded by a Discovery Scanner honk, in case there's an actual difference. Tricky to test these things when FSS scan state is so sticky.)

If that is what is going on, it seems the way to fix it would be to add FssBodySignals to autoscan, or drop autoscanned planets from the list FSS thinks already have been fully scanned. (Added: or by letting FSS treat autoscanned bodies as unscanned ones, and allow the user to scan them.)

Any comments?
 
Last edited:

Lhorndra

Lhorndra
I think the same thing happens with Elite Observatory and its BioInsights plugin by @MattG. I haven't looked into this in detail, though. As you said, no information about biosignals on autoscanned bodies, but correct biosignal info on FSSed bodies. From what I can see in my journals and the docs (slightly out of date?), autoscan doesn't write a lot of detail into the journals, while the FSS and a nav beacon scan does.

So I think you're right: third party tools can't discern any biosignals on an autoscanned body from the journals alone. Adding more info to an autoscan event in the journal would solve that problem.

Another thing that I noticed: at least BioInsights handles Horizons biosignals (brain trees, sinuous tubers etc.) differently than Odyssey biosignals. But this is probably the plugin's doing, not the journal's.
 

athulin

A
Thanks for the pointer to documentation. Must examine ...

(Added: As far as I understand BioInsight does not 'do' Horizon's bio at all.)
 
Last edited:

Eahlstan

E
athulin said:
Now, while FSS scanning does produce FSSBodySignals for bodies that have them, autoscan doesn't, and if a body has been autoscanned it is no longer available for a manual FSS so that FSSBodySignals can be added.
Click to expand...
That's not true. While you can't rescan those bodies, zooming to them does produce the desired event.

Proof:

JSON: 
{ "timestamp":"2023-09-19T19:11:27Z", "event":"Scan", "ScanType":"AutoScan", "BodyName":"Aries Dark Region UE-P b6-1 AB 2 a", "BodyID":7, "Parents":[ {"Planet":6}, {"Null":1}, {"Null":0} ], "StarSystem":"Aries Dark Region UE-P b6-1", "SystemAddress":2869440488785, "DistanceFromArrivalLS":31.845888, "TidalLock":true, "TerraformState":"", "PlanetClass":"Rocky body", "Atmosphere":"", "AtmosphereType":"None", "Volcanism":"major silicate vapour geysers volcanism", "MassEM":0.001571, "Radius":806804.875000, "SurfaceGravity":0.961870, "SurfaceTemperature":486.024261, "SurfacePressure":0.000000, "Landable":true, "Materials":[ { "Name":"iron", "Percent":19.797129 }, { "Name":"sulphur", "Percent":17.591349 }, { "Name":"nickel", "Percent":14.973720 }, { "Name":"carbon", "Percent":14.792501 }, { "Name":"phosphorus", "Percent":9.470414 }, { "Name":"chromium", "Percent":8.903426 }, { "Name":"manganese", "Percent":8.176012 }, { "Name":"zirconium", "Percent":2.298855 }, { "Name":"niobium", "Percent":1.353028 }, { "Name":"tellurium", "Percent":1.350834 }, { "Name":"molybdenum", "Percent":1.292741 } ], "Composition":{ "Ice":0.000000, "Rock":0.859974, "Metal":0.140026 }, "SemiMajorAxis":9132044.911385, "Eccentricity":0.000000, "Orbitalclination":-84.428132, "Periapsis":276.322819, "OrbitalPeriod":34699.093699, "AscendingNode":42.854922, "MeanAnomaly":220.999145, "RotationPeriod":35142.484890, "AxialTilt":-0.522399, "WasDiscovered":true, "WasMapped":true }

{ "timestamp":"2023-09-19T19:13:24Z", "event":"FSSBodySignals", "BodyName":"Aries Dark Region UE-P b6-1 AB 2 a", "BodyID":7, "SystemAddress":2869440488785, "Signals":[ { "Type":"$SAA_SignalType_Geological;", "Type_Localised":"Geological", "Count":3 } ] }
 

athulin

A
Eahlstan said:
That's not true. While you can't rescan those bodies, zooming to them does produce the desired event.
Click to expand...

Interesting and weird -- I don't expect I will be able to test that until I find a new system having an autoscanned planet with Horizon bios, though, which probably will take a few days. I'll note it for now. Thanks! (I hope I haven't missed some cache of 'Things you never thought you'd know about FSS scanning' in some out-of-the way corner of the web?)

It doesn't seem to lead to any full solution though. In my case, I could probably add 'follow up any signal discrepancies between in-game info and BioScan by FSS zooming the relevant bodies' after 'cross-check all signal data in-game against journal reading software'. But that means it is still subject to user error.

It also suggest that autoscan does collect FssBodySignals info, it just doesn't emit it into the journal file until a zoom is performed. It seems that that is the thing that should be addressed.

(Just thinking aloud now: I wonder how often this happens, and how many systems in net databases have autoscanned planets that actually have signals that have gone undetected. The exploration programmes that I know about have a 'check in-game info for signal data' step so they are only affected as far as that user-dependent error source goes. But anything that relied on journal files only would be affected, unless it recorded the scanning method that generated the data.)
 
Last edited:

athulin

A
@Eahlstan (Ignore -- incorrect test. Interesting for pathological reasons only.)

Hm ... decided to check zoom-functionality as described by Eahlstan above on something more important than brain trees, and selected Pencil Sector YJ-A c33 as it is close, it contains a Guardian Structure on body 1, which is not close enough to be autoscanned on entry, but close enough to allow me to sneak up on it, and so do an autoscan as well as check on auto scan distance.

First, immediately on entry, and so even without autoscan and FSS, System Map & Navigation view showed an Unexplored body with a Guardian Structure. This suggests that this test might be flawed, as the target is discovered earlier than expected.

Autoscan forced by sneaking up on body 1: kicked in around 32ls distance. Standard autoscan journal entry produced. Nothing out of the ordinary.

Went back to entry star for FSS, just in case. 2 bodies logged by FSS as known (entry star and body 1), remaining bodies FSSed. Nothing unexpected.

Still no journal entry about the guardian structure on body 1.

In FSS, zoomed in on body 1: UI OK, clearly showed 'Guardian' info in yellow. Zoomed out, and exited, and closed Elite Dangerous. (Exit was not clean -- it hangs for some reason. It usually does on Thursdays close to server restart, but as journal contains the 'Shutdown' entry I expect all journal lines to be available.)

Journal file does not have any line that mentions 'Guardian', or any Scan entry for Pencil Sector YJ-A c33 1 that suggests the presence of any signals. Only such entries concern body 9 and a single bio signal.

So ... case not clearly proven. Is there anything else involved?

* The Guardian structure might upset things, as it was clearly known before any normal scan.

* Original proof was for geo signals. Need to test case involving those.

* I also need to test this on my actual focus, which is brain trees.

I expect both geo and bio within a week.
 
Last edited:

Eahlstan

E
FSSBodySignals only contains things that are listed under "Features", so geological and biological signals. Things listed under "Locations" aren't part of that event, you need to probe a body to produce the SAASignalsFound event to get those into the journal.
 
Last edited:

athulin

A
Next test, this time with both bio and geo signals on autoscanned planet -- confirmatory.

Pencil Sector AV-Y c25 with planet a2 at a distance of 27.2 ls. It was autoscanned while I was FSSing the system, and a2 turned out to have 1 bio and 2 geo signal when I checked system map details. Only Autoscan entry in journal. Repeat visit in FSS and zoom on a2 emitted a corresponding FSSBodySignals entry.

So zoom works for at least bios and geos. That means there's a workaround (zooming) to get signals recorded/reported into the journal file (and presumably also to EDDN by listeners) from bodies that were autoscanned and so did not appear among to to-do bodies/signals in the FSS viewer.

Of pathological interest: the FSSBodySIgnals entry appeared after the FSSAllBodiesFound, which presumably is emitted when FSS is exited with a 100% score (100% then means 100% of the bodies that had not been scanned when FSS was started, not 100% of bodiesin system). The documentation of FSSBodySignals is thus misleading (probably) as this entry is also emitted at other times, when the result from an AutoScan is injected into the FSS result by zooming or other magic.

I'll get an issue report done this weekend; I'll add info in a new post when I post it in the hope that readers may add their voices/votes for or against it.

Thanks for the help, everybody!
 

CMDR Zashyn

CMDR Zashyn
Sorry for the necro.
I actually learned of this issue relatively recently. I intend to update BioScan to detect auto scanned bodies that meet criteria for a bio and add an indicator that it needs to be scanned in the FSS.
 
You must log in or register to reply here.
Back
Top Bottom