You are thinking of an 1980s arcade game on a rectangular grid. That is not Eve.
Considering the size of a solar system this is a spectacularly inefficient method. If you consider a “point” to be a cubic km (you can d-scan to 1km accurately, so that’s its resolution) there will be trillions and trillions points (specifically 150000000^3 = 2475000000000000000000) in just 1 AU distance.
Most of space is empty though, so iterating over all objects in space is far more efficient. If you check the database dumps you’ll notice that all static objects have X, Y and Z coordinates, it seems self evident to me that space ships and other mobile objects do as well.
Yes it does have to, you have to enumerate the state of each object with regards to the action performed.
For instance you D-scan an area, is that object contained in that area, true or false? That process requires checks against each objects’ coordinate placement.
Unless you’re suggesting there’s another set of data the object has that the d-scan trigger checks against?
You’re telling me that you do action: d-scan and you will know the state of all the objects therefore returning a value to the user, without checking their location?
Because the scan only returns results based on where you set the scan, the volume the scan checks.
No, I tell you exactly what I wrote in the post I wrote. Nothing more.
You don’t need to “check for value in each location”.
BTW you sentence makes no sense at all. That’s why no, I don’t mean “no sense at all”.
Not based on the volume.
You don’t need to define an area.
You are making it unnecessarily complicated.
So lets be clear : the user is not making the DSCAN. The server is.
When a user makes a dscan in a direction and with a given angle and distance, the server must ONLY return the list of items that are in the given direction ± the angle, and in the distance required.
The server already knows ALL the items in space. So all it NEEDS to do is to iterate over them and check if their position meet the conditions specified by the user. Anything more is a waste of time.
more formally, once you have the point for the user, a point to make the direction, you can iterate over each entity in space and
check if the distance² from user to the entity poistion is <= distance² specified by user
find the distance da from the entity to the directional vector using eg Point-Line Distance--3-Dimensional -- from Wolfram MathWorld , and from this you can check if the ratio da²<=sin²(angle)*d² (that is if the entity is within the cone of direction+angle)
no, the “volume” you are talking about is not necessary.
I updated the previous post with a part of the formula to check if an entity is withing dscan range. There is no need to have any notion of volume.
Your notion of volume/area is a waste of time. Forget it. There is no volume. no area. Just the user position, a vector of direction (that is a second point), an angle, a max distance.
With this you can tell if an entity is within range or not.
the server already has the list of entities in the system. Enumeration is not an issue. Filter is.
more intensive than WHAT ?
What is a non-volume filter ?
again : YOUR VOLUME MAKES NO SENSE.
even in real life, a volume is described by its limit.
The only case where it’s worth it to represent a system as an aggregate of points is when there are very complex relations between those points, for example nuclear/thermal/fluid modeling.
In most cases you don’t need to have a discrete modeling of space and instead can use continuous effects, that is the “volume” is modeled as forces applying to the interesting elements of the system. So your whole system is only represented as a very little number of items to manage (that’s why it’s hollow)
What in the actual hell is this thread? How is it still going?
You point the camera, which points the d-scan.
You set an arc, whether it’s 360 or 180 or 5 degrees.
You set a distance from yourself, whether it’s 14 au or 1 au.
Then you hit scan.
If there is something within the arc, within that distance, then it shows. It’s going to be rounded at the edge, b/c that’s how radius works. Straight line from the origin out to the spherical edge of chosen distance. This is clearly obvious with a 360 scan b/c you get to see the entire sphere. When you reduce the arc, you’re seeing portions of the sphere, but it’s still rounded out there at the edge.
If it didn’t, then the flat face of the cone would either be further than designated at the edges, or the center would be closer than designated.
You claimed the calculation needs to be done for every point in space, which would be inefficient, I claim the calculation needs to be for every ship in space.
So something like this:
def dscan(myship, direction):
for ship in system.all_ships:
d = dist(myship, ship)
a = angle(direction, ship)
if (d < maxd and a < maxa): dscan_report.add(ship)
Where the dist and angle functions are as I defined above. This implicitly defines a rounded cone in space. Ships within this cone will be shown on dscan.
Obviously I’m guessing how CCP has coded this. Possibly depending on how the system data is structured, you could use some heuristics to reduce the amount of objects you have to check.
I cant prove its a cone, but it is. I use it to find targets at scannable locations without combat probes. You just have to remember to aline the cone with the ship. I’m very rusty at the tactic, but it looks like I’m going to have to brush up on it now.
The end of the cone can not be flat as it would curve at the upmost range scan is possible at.
Thats about as basic as it gets but in reality what your gonna end up doing is pressing v a lot and just reducing the angle; looking at the cone probably isnt as efficient but each to their own.
