I think this is rather simple — there is a hard-coded 10K per search limit; if you search a larger radius, the outer parts of the shell are searched first, until you reach 10K; if you reach 10K before reaching the precious smaller radius, it will not show up in the search.

That's what I thought at first, but I see this behavior from single Lys up to about 75Ly on average where the 10k is typically reached. Get this a lot when I am physically near a planet previous found but not coming up within the 10k limit, sometime it does though.

eg, total stars to scan might be 2700, while I am few 100 AU from a known match, more often than not it won't find that one even though it should scan it? , but it will find results close to the edge of the sphere.

Also much of the time the matches are also off. For example, if I set the temp range 0c to 20c I get a lot of planets that come up that are close but still significantly out from the filter, like 35C and many in the -5 to -20 range, well below the min set level.  Not just temps but atmos pressure and body mass also close-ish... but out some notable amount.

I would imagine the search always starts in the outer layers, otherwise if you've reached the 10K limit, it won't matter whether you select a radius of 20ly or 2000ly it would always find the same results closest to the viewer.

But I hear you on the other parameters not being exact, I think I've seen some of that behaviour. But I also hear Space Engineer has already made significant changes to the search routine. Perhaps all of this is already moot.

Also, I think perhaps depending on the search criteria, the 10K limit may be after weeding out some obvious mismatches, like specifying a particular class of star or multiplicity of the system.

You cannot possibly scan every object in the SE universe. It's not achievable.

There isn't enough hard drive space in the entire world to store all that data

Mr. Abner wrote:

I would imagine the search always starts in the outer layers, otherwise if you've reached the 10K limit, it won't matter whether you select a radius of 20ly or 2000ly it would always find the same results closest to the viewer.

But I hear you on the other parameters not being exact, I think I've seen some of that behaviour. But I also hear Space Engineer has already made significant changes to the search routine. Perhaps all of this is already moot.

Also, I think perhaps depending on the search criteria, the 10K limit may be after weeding out some obvious mismatches, like specifying a particular class of star or multiplicity of the system.

I wouldn't mind a configurable search limit for power users. Something via the console or something to change the value. Even for my mediocre FX cpu 10k is nothing for it. Search starts almost immediately after I click start, will only be faster once I upgrade my PC to a Ryzen 8c/16t and NVMe drive later this year. I still use sata 2 500GB drives from 2008 which are only capable of 60-70mb/s max.

I'm sure having ability to increase this limit won't kill modern PCs at all if the current limit has no impact on such a dated and even slow when it was new type of system.

Mr. Abner wrote:

Source of the post I would imagine the search always starts in the outer layers, otherwise if you've reached the 10K limit, it won't matter whether you select a radius of 20ly or 2000ly it would always find the same results closest to the viewer.

No, searching order is "fractal", according on architecture of the star engine. Search starts from the top octree node, then traverses down and scans all children nodes (8 pieces) which intersects with the sphere. Then each 8 children nodes of that nodes etc. If 10,000 limit reached, search stops. It's hard to say what part of space has been scanned in this case. But typically you will have not fully scanned dwarf stars, because star octree have bright (giant) stars in the top levels (probably 100% scanned), medium-luminosity stars in the intermediate levels, and dim (dwarf) stars in the lower levels (only partially scanned, if 10,000 limit were reached).
20-25 ly bias is perfectly explained by FastFourierTransform, and yes, there are some bugs in search function in 0.980, which had been fixed.

Hmmm... it would seem obvious that a shell of a given depth will have a much greater volume than one of a similar depth but smaller radius, but this whole octree thing is new to me, haven't quite wrapped my old brain around it yet.