D-scan specifics

Obligatory Note - technique refers to your personal ability to do something, juxtapose your skill levels which makes it easier to have no technique, like an Omega.

There’s a game mechanics question I have, because tutorials don’t seem to get there.

The concept of the scan angles is pretty obvious, but the visual cones are flat at the end? If true then they do not scan between the base of the cone and the full hemispherical arc.

Has anyone tested if the scan is equidistant in the case of the cone’s base or if it’s flat?


Be Alpha

It’s not flat.

1 Like

Thanks. I’m at work so couldn’t check but it’s flat in several video descriptions. Probably just for ease of drawing then I guess.

Fyi this video shows what I’m talking about.

D-Scan at 8:00-8:30 shifting between spherical and conical

The point of this is to be sure that the flat appearance of the cone is just visual and not actual.

… I need you to think about what that would mean if you were trying to DSCAN at a certain distance.

What are you on about Omega? You know the scan cone visual has a flat bottom. Do you know calc 3 or should I teach you the basics of radial volumetrics?

It’s simple. Does the game treat the scan as a radial arc or does it treat the scan as a cone? The maths are different and pertinent.

Actually, yes. Let’s hear you explain this to me, I’m curious. Let’s see if you can walk the walk and not just talk the talk.

I already told you, it’s not flat. If it were, it would defeat the purpose of performing a scan at X distance.

Yeah then you go on to berate the question as if the fact the visual doesnt matter.

What evidence do you HAVE that it’s not flat?

Does CCP explain its use specifically or generally?

Has anyone actually tested this or you just base it off commonsense.


1 Like

So is that a no to citation Scoots? Because you’re not really an authority on this.

The visual is a cone.

Is the scan an actual cone where the distance is the length of the side and not the height?

Yes or no. Citation?

What’s with all those questions? Can’t you just log on and figure it out like a normal person?

You have any idea how big of a time sink thatd be? I’d have to find a spot that is the right AUs with something scannable in order to test.

And wheres the community in that? When usually someone with some great answers also offers above and beyond information on top of just the basic question.

The earth seems flat because the amount we see is minimal compared to the whole picture. When you narrow the angle so much it appears flat.

1 Like

Ummm… you’re right about the earth but wrong about the game visual. Correction - see below.

This is what I was asking for, why can’t you just say “the video you linked it’s hard to see but it’s there.”

Yeesh you’re difficult Scoots


This thread so far :popcorn:

Think of it from a programming perspective:

  • A check on angle and distance (which defines a cone with a rounded end)

is far simpler to implement than

  • A check on angle and distance for large angles (because a 180 degree d-scan is most certainly a hemisphere) and a check on angle and a distance projected on the center line (which would define a cone with a flat end) for small angles.

Programmers are lazy, they prefer the simplest solution and try to avoid solutions with too many side-cases.

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.


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.

I want to caveat, your reasioning is correct…they are lazy

But you under-estimate just how taxing on processors the lazy alternative really is in this case.

I’m almost certain CCP coding staff will catch that, if their own systems are not crushed by the code, a production system will be with people spamming d-scan and lots and lots of people on each server.

Increasing your time-cycle overhead by thousands will probably crush any optimization you had.

Conclusion - I’m willing to bet CCP intends for the d-scan to be a true range finder, and not to be a defined cone.

Therefore they would go for a fast calc-path which would be an algorithim and they would have knowledgeablly chosen to use the algorithm defining the volume defined by r-theta-ro.

And IF they were given pseudo code and said “oh a cone? yeah I’ll code that” and coded the volume of a cone.


AND it can be tested from the user end.

That is legal hacking…technically :slight_smile: 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.