It’s trivially easy and only requires some high school geometry.
If you’re d-scanning in a direction with unit vector (u, v, w) and want to decide if you can see a ship at distance vector (x, y, z) then:
distance = sqrt(x^2 + y^2 + z^2)
angle = arccos((ux + vy + wz) / distance)
One must not know the specifics of the DSCAN, one must feel the DSCAN, it’s natural or not.
I hear the screams of several noobs through the DSCAN.
5min. and then you’ll have your proof.
it involves a freighter(or higgs BS) dropping a depot, BM it, warping towards a far destination and pressing ctrl B every seconds to make a new BM, then switch to fast ship, warp to the BM you made that is the closest to 14AU (but within14AU, so ideal is 13.99 AU) and check if you have the depot on dscan.
Computing isn’t related to the equations alone, but to the number of computations.
The problem with distance/angle is you have to do one calculation for every possible point in that described volume.
Where as it is much less taxing on the CPU clock to just define a volume and compare a table of objects and their locations to see if any objects are within that volume.
Have you heard of https://projecteuler.net/
I’m in the top 50th percentile of that site. You should join me. It seems you’re into programming and it’s a great site to improve your coding.
Things I don’t have, is there a test server I could just “creative mode them” into existence?
It’s a nice question, but also immediately answered as soon as you ask it, because the only variables you put into your d-scan are:
It would be incredibly strange if CCP coded the small angled scans with a flat base and the scans at larger angles with a round base.
See for yourself, if you scan without angle you’ll see a sphere. At 180 degrees you get half a sphere, at 90 degrees an eight of a sphere, all the way down to a small 5% cone of that same initial sphere. Why would that last 5% cone be coded differently to be flat at the end?
The volume of a sphere and volume of a half-sphere are much easier known than the volume under some lesser angle of that sphere.
Volumes of platonic solids or spheres are simple trigonometric problems. Volumes of fractions of those solids are a bit more complex, not by much.
Now original to the OP, I thought because of contrast of view, that the cones looked flat at the bottom, but when I was able to see more clearly, they are not. So the question was risen in error.
But, to go down the rabbit hole anyway, one may assume they went with the more easy equation for volume of a cone than for volume under a partial angle of a sphere.
But D-scan isn’t about volumes. It’s about distances and angles. You don’t put in a 9AU^3 volume to find ships, you put in a 15% degree angle and 10 AU distance for example.
That’s my point later in the thread, from a coding perspective it is about volumes, because it’s much fewer calculations to test a volume for true-states of objects in that volume, than to actually scan every possible vector and test each.
The overhead of testing each point of the volume through the distance-vector method is much more vast than testing for the whole volume at once against a database of objects and their coordinates.
To put it another way…if you had to do this by hand would you rather:
A) solve solve for every vector at every distance in the scan area for every pixel (let’s say a 10x10x10 scan volume, so 1000 scans).
Or would you rather:
B) Define the 10x10x10 volume and check against your objects database for all objects whose coordinates are in that volume?
In both A and B you have to check against each object either way, but in B you’ve defined the whole volume already in one algorithm.
in both cases you need to iterate over all the items. So you save nothing by making a first pass.
Let’s make the assumption for now that they use volumes to check whether objects are within D-scan. At what angle do you think CCP stops using volumes based on spheres and starts using flat cones? 5 degrees only, or 15 degrees as well? I’m pretty sure it’s still spherical at 360 to 90.
There’s a distinct diference in both cases. In one case you define ALL possible points in one algorithm. In the other you define each point in each iteration of the algorithm.
Is this picture your example of a flat cone? Because it’s clearly spherical at the end. (Even though the extra light at the edge of the cone may suggest otherwise.)
In error, it looked like the cones were all flat bottomed, so starting at 90.
But, because visually they are not flat bottomed I’d say CCP just checks the entire volume under the defined surface of a sphere at that whatever distance.
I’d be suprised now (after all this chat) if they did the volume of a cone.
I’d also be surprised if they emulated a directional scanner, scanning for each possible point in the volume to be scanned using the vector formula you described.
Anythng’s possible, whether they choose volume or vector is irrelevant to the test, however. The test would be as described above…
Put a mobile depot at a known distance in the area that may be left-out of a scan if the volume were a flat-based cone, and scan 180 spherical, and 90conical and see what the result is.
The picture is me showing the visual was spherical and my original observation through videos was in error.
Everything after that is sort-of-academic fun discussing what they might have coded and why.
what ?
The dscan lists the elements in space that are in the given direction+ distance.
to do this you iterate over all the items in space, and check if they respect the conditions.
Then you return that list.
There is no need to check “for every vector at every distance”. Also pixels do not exist in the engine.
then your B) makes no sense either. The cone is not a 10x10x10 .
You made a 2-possibility choice for wich actually the two choices are bad.
I’ve simplified two generalizations, both are actually valid.
A) you have accurately defined a direction+distance scan, each direction at each distance are iterated. In a 10x10x10 space, that is 1,000 iterations.
B) You have gotten lost on the generalization of 10x10x10 space, that is just a simplification. The point here is that to define a volume you simply use the algorithm a x b x c = d.
Once you have d, you can compare all objects in your coordinate database to that value and you don’t have to do any further iterations.
You save 1,000 calculations.
Now expand this to whatever the “pixels” of the volume are, let’s say CCP makes their spatial resolution be .25 AU, then the volume of a cube that is 20AU across is 20(4) x 20(4) x 20(4), that is 4 pixels resolved per 1AU.
You can quickly see how fast there can be many thousands of iterations in scenario A. Compared to just defining the cube in one iteration of an algorithm.
no. Because it’s a hollow space.
When the teacher ask if chidren are present, he does not ask each point in the class if there is someone here and if this someone belongs to the list : he request everybody in the list if he belongs to the class.
No, it’s a misconception. You don’t need to have 1000 elements to represent a 101010 cube. You just need to have a top left , and a bottom right, point. Same for a cone.
This is not correct for how a program works. A program has to iterate each case and check for the value in each location.
You can either check each value individually (vector) or as a whole (volumetric).
Not sure where you think there’s no difference between the two?