If you don't care about them then of course you aren't fussed, just as I don't care about conflict zones, but I wouldn't push for a change that meant you had to fly within a few dozen ls of every signal source to find out if it actually was a combat zone and not just a "possible" combat zone. The idea is to have the game be the best possible game for all of us, not just for you.
Geo/bio POI scanning changes in the next update
- Thread starter marx
- Start date
If you don't care about them then of course you aren't fussed, just as I don't care about conflict zones, but I wouldn't push for a change that meant you had to fly within a few dozen ls of every signal source to find out if it actually was a combat zone and not just a "possible" combat zone. The idea is to have the game be the best possible game for all of us, not just for you.
My point exactly - there is no need for that to be consigned to the graphics card - instead let's have a sensible bit of coding by someone not contaminated by "bitcoin mining thinking".
I understand it is tempting for coders to tap into the processing power of a graphics card but in this case it has produced an unwelcome effect in my opinion.
I don't see why I should have my GPU all toasty and warming my feet all the time just to carry out basic FSS operations when necessary.
Personally, I think what's being proposed would have been great if it had been what had been done in the first place.
As we're now moving from a point of definites I'm a bit more reticent.
Have asked some about how it will actually work, and will need to see how it plays in the beta.
Here's how it all looks to me:
- removing the long scan times is a good thing
- presence of geo POIs can be determined with >99.9% accuracy just from the body info, so not getting definite geo POI results makes no difference whatsoever for me personally (not sure how it'll work for anyone who doesn't know to check for volcanism to see if a body will have Geo sites though.)
- probabilities rather than definites for bio POIs is something I'm not sure about. Might be absolutely fine. Most criteria are in the Codex anyway so it's not actually that huge a deal not getting definites, and there's lots of bodies with bios that I just don't go to anyway as I already know what they're going to be. Can't really predict how it'll all be for other people though. Worth considering that we don't get actual types of Bio POI reported anyway, so it's not like we currently get notified if there's a new Bio POI type on a body.
- All other POI types are currently delayed on bodies with volcanism while waiting for the Geo/Bio ones, and aren't moving to showing the likelihood, so getting them without the delays will be a massive improvement.
Overall, it should be a considerable improvement.
I still think however that it might be better to go with a yes/no model rather than the likelihoods, but that does necessitate everyone accepting that there will definitely be some false results.
The only thing we've got clear estimates of in terms of false results is the % that would result from a yes/no for geo sites based on whether a body has volcanism, so there's nothing on which to judge how a yes/no model would fare against the likelihoods model on that front.
I guess FD also have to make a call on whether false results from a yes/no model would cause more of a fuss than the likelihoods and the potential issues with them.
As we're now moving from a point of definites I'm a bit more reticent.
Have asked some about how it will actually work, and will need to see how it plays in the beta.
Here's how it all looks to me:
- removing the long scan times is a good thing
- presence of geo POIs can be determined with >99.9% accuracy just from the body info, so not getting definite geo POI results makes no difference whatsoever for me personally (not sure how it'll work for anyone who doesn't know to check for volcanism to see if a body will have Geo sites though.)
- probabilities rather than definites for bio POIs is something I'm not sure about. Might be absolutely fine. Most criteria are in the Codex anyway so it's not actually that huge a deal not getting definites, and there's lots of bodies with bios that I just don't go to anyway as I already know what they're going to be. Can't really predict how it'll all be for other people though. Worth considering that we don't get actual types of Bio POI reported anyway, so it's not like we currently get notified if there's a new Bio POI type on a body.
- All other POI types are currently delayed on bodies with volcanism while waiting for the Geo/Bio ones, and aren't moving to showing the likelihood, so getting them without the delays will be a massive improvement.
Overall, it should be a considerable improvement.
I still think however that it might be better to go with a yes/no model rather than the likelihoods, but that does necessitate everyone accepting that there will definitely be some false results.
The only thing we've got clear estimates of in terms of false results is the % that would result from a yes/no for geo sites based on whether a body has volcanism, so there's nothing on which to judge how a yes/no model would fare against the likelihoods model on that front.
I guess FD also have to make a call on whether false results from a yes/no model would cause more of a fuss than the likelihoods and the potential issues with them.
Play as you like, but I’m normally trying to cover as many systems as I can do so efficiently. Exploration doesn’t make the credits of trading or mining, but neither am I out in the black without the goal of gaining credits. You do you but that’s me...
So yes I try to maximize the number of systems per hour. I filter routes which focus on F and G Stars, (stellar mass code D). I only fully FSS systems where the initial pulse indicate the presence of water worlds or earth likes. I then check the system map for other terraformable planets to DSS. If the system is small and compact I might do a full DSS of everything in a system if it’s worth the time. I pass on DSS-ing water worlds and even earth likes more than 150,000ls from primary since in the time it takes for me to SC out and DSS I can be in another system containing water worlds at 1000ls to 2000ls out.
Bio and Geo resolution gets to be more important when I’ve been out for a while, and need some mats or I want a diversion. But it’s been my observation that very few Biological POIs exist on planets without Geological POIs, and I can’t waste my time waiting in the FSS. For Geological sites I will just pull that from planet info from the system map post-FSS, but they don’t report biological presence in the planet info (another problem.) Sometimes it would be nice to fill out my Codex without going to places where other people have seen things, but with discovering things on my own. It’s what I do with planets and stars, and it would be nice to do the same with geo bio, but it ain’t my priority, so...yeah.
So you be patient. Lay as you’d like. I have no disagreement with that. But I’d prefer a simple “yes” or “no” when it comes to bio and geo POIs in the FSS, and I’d be very appreciative for some bio info in the system map post FSS resolution. But hey we’ve had this in the issue tracker for over a year now, so I kinda figured we were patient.
Deleted member 38366
D
Might sound counter-intuitive for some, but that might be indeed the best basic approach.
I've made a similar suggestion elsewhere on the Topic - essentially keep the current process but tweak and optimize it
How (short form) :
Instead of starting to process the Data on Geologicals "on demand" (in Target System and FSS'ing onto a Body with Geologicals to trigger it)
- start this process already when starting a Hyperjump into a new System (earliest possible time), but no later than the Hyperjump countdown starts
- use the time gained until arrival in new System to have the process rolling already (possibly finished by the time of arrival under optimal conditions)
- by the time of being in a new System, setup the Ship (i.e. Fuel Scooping), operating the FSS and getting to the 1st body with Geologicals, most of the Info is already there
- still missing Data (high number of Bodies with Geologicals)? Might still encounter a delay in the FSS - but at least the whole process is already running.
- to prevent clogging the Client performance, a limit of parallel processes to attain the Data would be sensible (otherwise the effect of tagging a dozen Geo bodies at once could leade to severe FSS stuttering)
Make best possible use of the time spent waiting for the Jump to complete, plus the Hyperjump animation isn't too GPU intensive anyway.
Umm, no need to tie the generation of the 3D surface of the planets to the video card? So you have a faster graphics processor in your computer? You'll have to let me know what it is so I can get one installed in mine, obviously my RTX 2060 is old hat now.
That's a possible, but according to FDEV the location of the geo POI's is tied to body generation, previously I suspect that would happen as we approach each individual body close enough to scan with the DSS, which is why the DSS had limited range. The problem is we have only a limited time in hyperspace to assist with this process and the vid card, I suspect, is already using all the time it has available to generate the currently needed assets, such as the star and any nearby bodies for instance. I have noticed if you come into a system with really close orbiting bodies with vulcanism they appear in the FSS almost the moment you focus on them, so to an extent it already does this probably for everything within a certain number of LS of entry point.
I can see this working fine with small systems, but large systems may create a loading on the vid card that delays the entry to the system or creates unplayable lag for minutes after entering the system. Given those two possibilities I would rather have it left as is.
According to FDEV's statement it appears that even they don't know for sure whether a body has bio or geo until it's generated fully and locations established, that's how I would expect the procedural generation system to work, otherwise why bother to try and guess if a body has geo or bio according to the system data, if they actually know it does why not just display that. The delay during the old DSS days and the fact that the system map couldn't display geo at the time until you had scanned it all point in this direction, FDEV doesn't actually know until a body is scanned, and the geo sites can't be located until it is scanned, so there's going to be a scanning delay whichever way we do it.
FDEV's suggested method, of guessing based on available data and then only providing locations once we get close enough and probe the body sounds ok as long as it actually gives us the correct answer every time, but they stated it can't necessarily do that, also what if apart from false positives, we also get false negatives. I mean if they can't be 100% certain there is bio/geo there when they say there is, they also can't be 100% certain the the other way, their system may say no bio/geo when there actually is.
Which pushes me straight back to the old days, if I can't trust the scanning system I am going to have to fly out and check and probe every possibility just in case. So better to go back to the old DSS system that will tell me whether the bodies have bio/geo when I get close enough, then I can make the decision to use probes to locate them rather than wasting time probing just to find out for certain if a body has bio/geo.
All in all out of the current crop of suggestions I would rather just stick with the current system, at least we have 100% certainty on the scan, we don't have to fly to and probe every likely body. Basically the suggested system seems ideal for casual explorers, but leaves serious explorers out on a limb, we lose time, maybe a lot, and certainty which I consider the deal breaker. I can see where the push is coming from for casual explorers who just want to get out and gather some data, maybe for a CG or mission, the delay during FSS is probably irritating, however it doesn't bother me at all because anything that is going to provide certainty is going to take a finite amount of time, that can never be reduced to zero and just moving that time around will cause issues for other players who will then complain, basically a never ending problem.
But moving some of the body generation to hyperspace and slowing jump rate down would be a howler of a bad idea, sounds good, but even an extra 3 seconds added on to jump times would generate a lot if bad vibes.
Of course there's another possibility that's workable for an explorer with a set course, use some of the spare processing time in the previous system while a CMDR may be in SC traveling to a body or taking ship selfies to generate data for the next system on their set route, won't help if you deviate from the set route of course, but could alleviate 90% of the issue.
Last edited:
My point is that they don't have to actually produce the complete model of the planet / moon - all they need to do is run the "has it got POI, what types and how many" calculation - no need to go through the rendering process. In effect the two-up game they are proposing is a method of guessing that calculation without doing it.
Obviously I am not a programmer / coder (although I do have some experience) so I don't know if their algorithms can be uncoupled from the rendering process but it seems feasible to me.
Agreed with what @varonica said. It’s a good idea in principle, but in practice I don’t think there’s going to be any spare processing power in the hyperspace jump as it’s already going to be busy doing procgen.
Also, for me personally, returning scan results for a landable with volcansim takes 25-50 seconds. Wouldn’t really want hyperspace jumps extending at all to do extra processing with that type of time involved per landable with volcanism.
The issue is that there isn’t an independent ‘has it got a POI calculation’.
Easiest to use Geo sites as an example, as only landable bodies with volcanism will have them.
When you scan a landable with volcansim, the surface has to procedurally generate, and then if suitable sites have been generated, then there will be POIs. If no suitable sites are generated then there won’t be POIs.
Same principle applies for Bio sites, except they don’t have the same clear universal indicator as to whether a body might have them like Geo sites do.
Err, got to ask... what’s this about the old DSS saying whether there were bio/geos on a planet?
It never had that functionality for me.
Hence why I said " ... if their algorithms can be uncoupled from the rendering process but it seems feasible to me "
That Is why I have always couched my remarks on this as asking for "alternative coding" of the process.
Fair enough!
For what it’s worth, although I’d had a fair idea what was going on with the geo sites for a while, I’d hoped that for the bio sites it would be a bit more like you said, but from what Stephen said, apparently it’s not.
Not sure if I rate as a “casual explorer” but I think even with explorers using a cherry-picking, jump-scan-jump approach (which I would put myself in that group 90% of my time in the black), you make a valid argument about it might be better as it is, especially if FDEV can’t provide the information with certainty.
The old DSS always indicated whether or not a planet had vulcanism, it just didn't tell you where the sites were or how many there were, once you ran the DSS over the body the vulcanism type came up in the system info tab, of course bio didn't, and still doesn't show in the system info panel even with the FSS until you actually probe the body. Also to note, sometimes a body will show vulcanism in the FSS but then report no actual sites, I have seen this quite often. With the new system this will probably still happen, only you won't know there are zero sites until you probe.
Ah, ok. I did wonder if you just meant the Volcanism info but it seemed like you were saying there was some functionality beyond that which stated whether there were bio or geo POIs.
With regard to the time taken for the old DSS to get results, AFAIK that was just a gameplay thing, and all that info was already pre-determined on system entry, with the DSS just revealing it. The FSS certainly returns that info almost instantaneously, and much quicker than the time it takes to render the image of the body in the zoomed view.
I’m not sure if I misunderstood before but you seemed to be saying that rather than the probabilities you’d rather go back to the old DSS to avoid wasting time. I’m slightly thrown by that - what would be the time benefit of flying out to the body to get the DSS info vs and getting that same info, plus some extra supplemental info on the POI likelihood via zooming in on a body in the FSS? Maybe I’ve just completely misunderstood what you meant!
Anyway, for reference, I’ve asked whether the 3 likelihoods that were stated are all there will be or whether there will be a ‘definitely not’, and essentially pointed out that it’s going to be a bit odd having anything other than ‘definitely not’ as the likelihood for geo sites on landables without volcanism. Will see if there’s any response.
What I mean is, you can never be 100% certain with the new system, so you risk missing likely candidate bio sites on bodies unless you probe them. Even now some bodies that return geo positive don't actually have any sites, how many that return geo negative do actually have sites? So even if the FSS says no, you can't be certain until you fly up to probing distance and probe the body. Which is time consuming because you have to get so close, probe the body, then fly out of the gravity well if you want to check a second body. I don't know how other people feel but how much exactly do you trust FDEV to get the new system right given their track record of things not always working as expected?
So if they have the FSS using the new system, which is not 100% certain either way, then give us some functionality like the DSS where if you want to check a body anyway just to find out if they are right you don't have to probe to find out if it has bio/geo, just get a few ls away like the old DSS so it can confirm the original FS scan without having to probe and that will save a lot of time. The other question is, how do we bug test the system efficiently unless in the beta we fly out to check bodies, how accurate is FDEV's data, what sort of systems did they check on? Does it work on any system, even the unusual ones? As it stands we are just going to have to take FDEV's word that it works, there's no way for players to verify the accuracy of the system.
I can't help feeling that this playing around with a system that may be a little slow but works 100% for a system that's maybe a little faster but doesn't work 100% is not a good idea. My FSS scans usually take on the order of well under 10 seconds so if I FSS a body in a binary arrangement by the time I zoom in and out again to get the second body the scan of the first is only a few seconds from finishing. I can fairly quickly jump from one to the other and back and only waste a few seconds at most. I get very little delay but that's all down to hardware so changing the system over for me is not much of an advantage, how about a choice, I keep the old FSS functionality and players with slower systems use the new one?
We're right back to that old argument, "keep the old ADS functionality", how long has that been running now and it refuses to die?
You'd very likely be waiting even longer if they chose to go that route. Even with the current limitation of performing discrete chunks of work each frame, the calculation throughput of your GPU is likely significantly higher than the throughput of your CPU, at least for the kinds of simple-but-repetitive calculations that seem to be involved here.
I can confirm, this is exactly what would happen. You see, it is possible to trigger stellar forge to pre-generate the POI data for all bodies in a system, provided the system has previously been fully scanned. Under the current system, if you mouse over a body in the system map, the game will start generating the planet's details in the background. When entering a system that is fully discovered, all bodies will be populated in the system map already, so it is quick to mouse over all of them. On my (decidedly mid-range) machine, this results in reduced framerate and significant lag for a minute or two in a large system - but once that is over, all scans resolve immediately in the FSS.
Personally, I think most people would consider it a downgrade for game performance to be significantly degraded for a period of time after every jump.
There is a reason it refuses to die. But the people who are happy with FSS are often entrenched in their "I like it, therefore it must be good" religion and refuse to acknowledge any argument that casts a shadow on it.
Anyway, on the topic.
I am indifferent about the change. Not interested in bio sites, so it doesnt affect me. If i was, probably the change would frustrate me. FSS is a huge time sink already and adding more to that is not welcome.
What i see as a very positive sign is that under the leadership of the new Lead Designer, this time they ask the community before implementing a controversial change. Even a minor one like this. They didnt ask and didnt listen back then when implemented the FSS. The fact that the former Lead Designer was fired shortly after this was implemented tells a lot.