we already know that though with how long it takes to resolve, a nice clean intuitive symbol on the system map means we can do it more efficiently and do something else while it resolves without wondering what planet it was we actually just scanned, my 2 cents anyways, ill get back under my rock.
About the new proposal on how the FSS should show more efficiently info about planet POI's
- Thread starter VR SenseiMatty
- Start date
we already know that though with how long it takes to resolve, a nice clean intuitive symbol on the system map means we can do it more efficiently and do something else while it resolves without wondering what planet it was we actually just scanned, my 2 cents anyways, ill get back under my rock.
Part of exploration is finding nothing, but it would be nice to know when you have found nothing.
Well to be fair you will find that out when you've mapped the planet.
It's a tricky one this because on the face of it the proposal is worse but it does elevate probe mapping which is at the moment mostly about locating sites. If you don't know for sure until you probe map if there are any sites though, now the probes discover something.
I guess we'll see how it works out, so I'll reserve judgement until it's a real thing. I'll see how it feels with the whole context.
Not true actually. Biological POI’s suffer the same FSS scan delay as geological sites.
Except it appears that the delay isn't actually due to the geo sites themselves its due to the extra time required to generate bodies with volcanism compared to those without.
Geo sites only occur on bodies with volcanism, which is why the two things get conflated.
All a long scan times means is that you are scanning a landable body with volcanism.
It doesn't guarantee there will be geo POIs though it's very likely there will. Maybe around 0.1% won't have Geo sites.
It says absolutely nothing about Bio POIs and it says absolutely nothing about all the other POI types.
My personal favourite option (already mentioned in this thread) is that the FSS shows what type(s) of POI are on a body (but certainty, not likelihood), and then you need to Surface Map in order to discover the number and location.
The bigger thing though is that FDev obviously have a big disconnect with what the cause of the issue is in the first place. Geo's are SLOW (even for me and I run 120fps), whereas Bio's are instant (and it seems they are for everybody regardless of framerate). So the primary issue is the different generation algorithms being used. The Geo one is locked to the framerate, the Bio one isn't. Seems that the proper fix is to do a refactoring pass so that both Geo and Bio use the newer generation code from Bio's.
The bigger thing though is that FDev obviously have a big disconnect with what the cause of the issue is in the first place. Geo's are SLOW (even for me and I run 120fps), whereas Bio's are instant (and it seems they are for everybody regardless of framerate). So the primary issue is the different generation algorithms being used. The Geo one is locked to the framerate, the Bio one isn't. Seems that the proper fix is to do a refactoring pass so that both Geo and Bio use the newer generation code from Bio's.
It depends on how the prediction works I guess. The planet generation for landables with volcanism creates a processing bottleneck, and every body of that kind will also add to that bottleneck causing a backlog, which can then effect other things. If that bottleneck/backlog would also effect the calculation of likelihoods then there's going to be problems. Maybe there's sufficient control over how things get processed to avoid that, but couldn't say for sure personally.
Pretty much this. There's no database (it's all procgen), but apart from that spot on. ALL we want is a Yes/No from the FSS. We're then happy to pootle to the planet and DSS it for the details.
Umm... no they don't.
If a planet has Geo sites, it's slow (whether or not it also has Bio sites). Results only show up once the Geo sites scan is finished.
But if a planet only has Bio sites, the results show up instantly. This indicates that the fault is not with the Bio sites and whatever algorithm they've used here is actually performant and not dependent on framerate.
Thise here exactly ^
That wouldn't do anything to resolve the issue. There wouldn't be any material difference in the time needed for the FSS to show the types of POIs with certainty and the numbers of those POIs.
No, the issue is that planet generation for landables with volcanism takes considerably longer than for landables without volcanism.
It appears that Geos are slow, because Geos don't appear on bodies without volcanism.
Bios are not instant. Bios are just as dependent on the planet generation as Geos are.
When you're seeing Bios return instantly, they're not returning instantly, you're just seeing the relatively quick time taken for generating a landable without volcanism. On a low performing GPU it takes 3-5 seconds.
Bios on a landable with volcanism take just as long as Geos do.
For reference, here's the relative times things take:
- returning the detailed body info (what used to be obtained by the DSS pre-3.3) - Instant (because that's info that's generated as part of the system procedural generation in hyperspace).
- returning the POI info for non-landables - Instant (because surface POIs aren't being checked for, so there's no dependency on the planet generation system, and all that's returned is the orbital POIs)
- returning the POI info for landables without volcanism - Quick, but not instant (because the planet generation system has to generate the body to determine whether there will be anywhere where the POIs the body is eligible for will actually occur).
- returning the POI info for landables without volcanism - Slow (because the planet generation system has to generate the body to determine whether there will be anywhere where the POIs the body is eligible for will actually occur, and generation of a body with volcanism is more complex than generation of one without).
Edit - the appearance that geos are somehow locked to framerate and bios aren't is just an illusion. The frame rate thing is simply a factor which effects how long the planet generation takes, as is GPU performance.
Last edited:
I don't see how the proposal would help at all. Players end up using more time for exploration than before. What good is it actually for?
ok so i haven't found a planet with volcanism, no geos, but bios.
So let's focus FDevs effort on why volcanism takes sooooooo much longer then. A little bit sure, but it's several orders of magnitude. Seems some room for algorithm optimisation.
This is the path I'd like to see FDev take. Optimize the geo scanning routine, don't abandon it for a new exploration Russian Roulette.
You can definitely find planets with biology but no geology, saw a couple today in fact.
An earth based telescope can determine the composition of atmosphere.
Volcanism create gas pockets around them, detectable by the sensors. Our own real world satellite Cassini could spot the water vapor in low orbit from the geysers on Enceladus.
so gaseous signatures on barren moons are a dead giveaway.
There is lots with the FSS that needs to be tweaked, from the mineral content being crammed in 3 page flipping window.
The radio signals spamming out the areas.
Finding things you’ve previously discovered. (Where was that water planet again, I can tune to the blue ball on the spectrum, but now I have no pointers anymore).
Seeing the catalogue of planets detected, as you would in the contacts list.
If the contacts panel and orbit lines exist all-ready in the helm, one wonders why the same information is pushed into the FSS and not excluded in one UI but present in another. (Uniformity and consistency chaps).
I think we have monkey gripped enough with the old discovery scanner concept, and we need a rethink how this all works again.
I’ve always thought the FSS should be a little more scientific as well as being more of a tool to search and discover.
Having an overall mass of the system, and subtracting the discovered bodies.
Unless a planetary body is in its own discrete orbit, then they are masked by the gravity well & EMS blur. We know something is there, but what it is and how much needs to be investigated.
the exact number of Moons of a gas giant can remain hidden.
Binary bodies orbiting their on Barry center, count as one, until discovered.
Hotspots should have a neutral hot glow of the combined emf spectrums, as we tune the EMF we polarized our filter to that colour (so we tune to gas giant (orange) allowing us to see that orange colour bleed through into the neutral hotspot.
Planets are blank in the system map, until fss’d
And so on.
Volcanism create gas pockets around them, detectable by the sensors. Our own real world satellite Cassini could spot the water vapor in low orbit from the geysers on Enceladus.
so gaseous signatures on barren moons are a dead giveaway.
There is lots with the FSS that needs to be tweaked, from the mineral content being crammed in 3 page flipping window.
The radio signals spamming out the areas.
Finding things you’ve previously discovered. (Where was that water planet again, I can tune to the blue ball on the spectrum, but now I have no pointers anymore).
Seeing the catalogue of planets detected, as you would in the contacts list.
If the contacts panel and orbit lines exist all-ready in the helm, one wonders why the same information is pushed into the FSS and not excluded in one UI but present in another. (Uniformity and consistency chaps).
I think we have monkey gripped enough with the old discovery scanner concept, and we need a rethink how this all works again.
I’ve always thought the FSS should be a little more scientific as well as being more of a tool to search and discover.
Having an overall mass of the system, and subtracting the discovered bodies.
Unless a planetary body is in its own discrete orbit, then they are masked by the gravity well & EMS blur. We know something is there, but what it is and how much needs to be investigated.
the exact number of Moons of a gas giant can remain hidden.
Binary bodies orbiting their on Barry center, count as one, until discovered.
Hotspots should have a neutral hot glow of the combined emf spectrums, as we tune the EMF we polarized our filter to that colour (so we tune to gas giant (orange) allowing us to see that orange colour bleed through into the neutral hotspot.
Planets are blank in the system map, until fss’d
And so on.
Uhuh.
When I say "database" I just mean whatever "pool" of information the game has that allows it to populate a planet.
I assume, perhaps, the game is unpacking some kind of "seed" and looking at the results to tell you there's a Geo/Bio POI present.
Point is, the fact that it takes time to scan a planet suggests the game's doing something in a linear manner and there's really no need to carry on with that process once it's confirmed the presence of a POI and reported it.
I suppose the only possible hiccup might be that you could have, say, a planet with a hundred Geo POIs on it and a previously undiscovered Thargoid hive-ship and you'd do your FSS scan, it'd report Geo' POIs and you might not bother going to investigate further.
Again, though, I guess this should only be intended as a preliminary scan and, having scanned an entire system, a diligent explorer/surveyor should probably consult the sysmap to see if anything else has turned up as the scan data has been "processed".
Honestly, I don't really see why people get so uppity about getting the scan results in real-time, from the , at all though.
It's not like you could actually, for example, locate a planet with Bio POIs, head toward that, keep on scanning and then divert elsewhere if you discover something more interesting.
It'd probably work a lot smoother if the FSS was actually just a navigational aid, allowing you to locate planets
You enter the "Navigational Scanner" (previously the FSS) and operate it exactly as you currently do.
Whenever you find a planet you get a message saying something like "Planet logged. Scan Commencing."
You then carry on doing that as much as you want, ideally until you've logged every planet in the system.
In the background, the game is doing it's thing, sniffing through the data and producing the results for each planet.
As each scan completes, whether you're actually IN the "Navi Scanner" or not, you get a message saying "Planetary scan complete" and, if there's anything interesting on the surface you get an additional message saying something like "Additional data downloaded to System Map".
With that done, you would be able to pick a planet that's got something interesting on it and head toward it and then, if a newly-completed scan revealed something even more interesting, you could alter course and head to that planet instead.
Basically, use the FSS to initiate the scans by locating planets and then output the data to the Sysmap so you can review it while you're moving rather than having to sit around waiting for the FSS to finish what it's doing.
Wait; you confused me. Geo POIs are Volcanism. What's the point of confusing the matter by splitting the two apart?
Not all volcanic planets have Geo POIs, but all Geo POIs are volcanism and are on volcanic planets.
I never said otherwise.
I said I've never seen Bios on a planet with Volcanism without ALSO having Geos.
If you have a planet with Bios, but no Geos, then, in my experience, it's also not a volcanic planet.
While we can quibble about the details, overall I like it.
People can either stay watching spinning circles in the FSS until all the data has been processed, or they can go on to scan other planets (as per present, but WITHOUT the current slowdown) and then view the results in the SysMap.
One big thing I DON'T want to see though is even more popup message spam. Maybe an icon lights up if something interesting has been found, and briefly flashes if something new has been found, but NO MORE POPUP MESSAGES!!! Those must all die!
As for the SysMap, it should mark a planet if it has any POIs, and then once you've Surface-Mapped it, it should show the various locations with icons similar to the Surface Bases. I made a mockup a couple of years ago. Wouldn't have thought it'd take much effort to implement given existing features and functionality.