Actually the programming is MUCH WORSE for the one you say is better, with a lot of variables
And since this thread is dead (because I couldn’t see the full d-scan in the now posted pic due to contrast issues in the media)…let’s jump down this rabbit hole.
I’d say the programmers have some options when developing the actual code for the scan, and I wouldn’t know which they’d choose but I can guess which and why.
But the easiest I’d say is they have an algorithm that defines the volume of the scan area, and IF anything shares that coordinates and is NOT cloaked then return a value on the player’s d-scan.
That means defining that volume is the SAME coding either way…and the algorithm choice is going to be preferenced by whoever’s knowledge of defining the volume to be checked for those conditions.
Now, if the programmer went another route, and mimicked actual directional scanning, this has cost implications.
Now, the game has to run calculations on ALL vector paths in the defined area. And as you know, all computers are turing machines and any semblance of parallel processing is simply the overlapped timing of hyperthreading processors. Fancy speak for, everything in code costs time-cycles on the CPU clock. An algorithm is ONE cycle. A directional scan for 2 targets is 2 cycles. For every pixel in the scan area? Could be thousdands of cycles.
BUT this means that the programmer only has TWO variables to define, the distance and radial coordinate, which is a Calc 3 problem. The programmer is MORE likely to know basic trig, than calc. And so already has a built in laziness to push away from the option you chose.
The answer to this is PROBABLY an algorithm defining a volume.
Why?
Because running an emulation of the reality of a distance ping is actually much more taxing from a calculation-overhead consideration as explained above.
I am willing to bet, because the visual supports the evidence, that the programmer went with defining the volume under an arc-of-a-sphere which requires only an algorithm.
I highly doubt they emulated a directional rangefinder, while it’s simpler on the coding if the coder knows his Calc3 and it’s also less prone to hacking (will get to that in a sec), it’s taxing on the system, and so their leads would most certianly push coders into the algorithm.
And here’s the HACKING part…which did they choose?
Because the HACK (Which we can define is identifying something a coder didn’t intend to code) says IF the coder chose an algorithm, did he choose the wrong one? Did he choose the algorithm to define a cone?
Because based on the VISUAL evidence…THAT algorithm would be the WRONG one…and it would create an exploit (albeit practically useless one).
That exploit would be a dead-scan-space between the base of the cone, and the spherical angle of scan.
Meaning YOU could never range find a ship that lives in that dead-scan-space.
Lastly…how to perform this HACK?
Test it…
Put a ship in the supposed dead-scan-space and RUN the scan…did it find it when switching from sphereical to directional?
The dead-scan-space is small, so I guarantee you no one has bumped into this accidentally.
It’s only because of my stupid eyes I even raised the question.
And I do hacking for a living…so once I realized there could BE a gap…my mind raced to discover the gap.
Which is why I snapped at Scoots…cause he is not wrong. But he doesn’t know why he’s right.
Nothing bars a user from using a program as intended, to reverse engineer that program. Which is the foundation of all hacking…If the exploit exists, and CCP knows about it, and CCP listed it as an exploit of game mechanic (and it wasn’t such a trivial one as this), then that’s how you easily slip down from blue to grey to black…and this … in a nutshell, is the tedious world of exploits and fuzzing your code.