@Viir So, I’m in the process of trying to update my AHK code to use information from Sanderling, but I’ve noticed something odd. The coordinates seem to be off. See the screenshot below. My code gets the corners by finding and setting the corners as illustrated in red. (I can assure you that my numbers are correct.) Is there some window padding rules that I need to account for when converting Sanderling values to mine? (I know I’m using relative an Sanderling uses client coordinates. But you’d think that they’d be off by the same amounts.)
My code saves CPU cycles by calculating the relative positions of things inside windows by using the window corner coordinates instead of image searching. I have mathematically deduced and accounted for how windows and all their internal components behave down to the pixel. With the overview. It even calculates where each overview cell’s 4 coords are by using window corners, static offsets, and then finding the differently colored pixels that indicate where each column ends/begins… This way I can click on lines (or even individual cells) by calculating where they are. I guess my point is, I have to make sure that the conversion system I use is exact…
I know that Sanderling can get most of this stuff, but it would just be unnecessary work (to figure out where to get it all from Sanderling) since I already have accounted for where lines are mathematically. Eventually I’ll do it, but right now it only makes sense to work on the big things…
First advice, remove the screenshot and cover your nickname into Active Windows Info, on line "EVE - "…
Second thing, you are getting the relative coordinates, usually this is wrong, you have to take the Client Coordinates then difference from what get the Active Windows and Sanderling will be around 2px (I think)
Anyway I still not understand why you are doing all this, if it’s for do anomaly, A-Bot do all this stuff byself, so why make all this getting an conversion of coordinates?
I saw your edit, but you forgot to cover your Charname at the top section under “Window Title, Class and Process:” you have to pay attention in this little stuff, when you post in Botting Forums
@Master Thanks for spotting that, twice. I’m usually more careful! It won’t happen again.
The coordinates are not wrong, but from a different starting point. The difference should be static.
I’ve used your A-Bot for testing. It is good. However (and no offense meant here) my class code base, utilities, inter-bot-communication/coordination, and combat prioritization logic is a fair amount more advanced than what is available in A-Bot. I’m trying to ease into Sanderling instead of having to recode and debug over ten thousand lines of class based logic.
To ease into Sanderling, I need to understand the differences in coordinates.
+1 on understanding the coordinates difference, notably why the X and Y disparities b/t client and relative differ. At first I thought the Y disparity was from the top of the EVE Window, but that doesn’t account for why the Min1 and Max1 are different offsets from what the imagesearch shows.
As far as using A-Bot, I also have to agree with Innominate. Our bot runs autonomously for weeks without interruption, logs itself in and out, reloads and rearms, makes intelligent combat decisions, can remember what its targeting to focus DPS, and can mimic player coordination and communication to avoid choosing the same sites, detect hostiles nearby, etc. Re-doing all of that in C# would be an incredible labor for no real benefit. AHK is well-suited to interacting with windows What Sanderling offers that’s really game-changing for us is saving us from needing to use imagesearch, copying text and parsing it, etc. to detect what’s on the screen. So, being able to fit Sanderling’s measurement into our bot makes far more sense than starting over from scratch.
So, TL;DR: we’d be grateful for your help in understand the coordinate differences
No offese from me, I collaborated to realize the logic of A-Bot, but the architetture of it it’s made by @Viir, however I agree about the prioritization logic, for this I have in plan to work on it.
But Im not working on A-Bot, precisally Im rewriting some A-Bot functions for make it working with capitals and mothership, my coding it’s actually in a private repository where I update the various status here: A-Bot for Capitals and Motherships
What I can do to “help you” is to share the code for the priority targhet, when I finish the project
My plan is to make all damage to frigates, then cruisers and then bs, the project it’s to recalculate the primary when the actually primary is dead, this will give to A-Bot a dinamic primary calculation, plus another function to check “webs and point” if someone point or web the ship then will switch primary.
This is what I can do for help you, but before do it I have to finish the squadrons integration, atm Im able to launch and retreat all squadrons, tonight/tomorrow I will work for make them shoot on the primary, then I will work on the code for the dinamic primary calculation
About the coordinations, I don’t think it’s the just approach, Idk why bur from your approach it’s like a double work, sincerally what I would try to do at your point, would be integrate sanderling’s structure to your poject and then retrieve the path directly from sanderling and not from the pointer position inside the client. This avoid to go to recalculate the corners time by time.
The rules as applied at the moment and where they come from:
I found an offset when using the coordinates from memory reading for clicking with the mouse.
To compensate this, I applied a global offset on the effect side (coordinates to move mouse to) of Sanderling.
This was done with the following change:
In light of your discovery (comparison with screenshot), it might be better to move the offset to the sensor side.
Furthermore, also a safety margin is subtracted from a region to click in when choosing a point in the region:
I understand your point-of-view, A-Bot is born like a “open bot” modficable from who want partecipate on it.
But in the same time the “why” because the coordinates are different can be various, I do an example, stupid example, but can be “logical”.
Imagine to be for a second the CCP client code, and you go to write in a RAM statment the coordinates of the windows ect, it’s more logical you go to write the coordinates relative to workspace without keep in consideration che window’s corners.
Now Imagine to be a software like AHK, where try to do a coordination pointer on Window Space position (screen size) and then into Workground in Window position, it’s more logical AHK not exclude the height and width of corner size because the coorners are a part of the Window.
This can make a difference between the coordinations write from the client and after retrieved from sanderling then the coordinates retrieved used AHK
So if I would be in your situation, I would try to do a little manual calculation where I try to get the cooner size in all 4 window part, then exclude them from what AHK give and then compare them with sanderling coordinates.
So is the offset generated by Vektor2DInt(2, 2) dynamic or static? Is there a way for us to determine what it will be so we can apply it in our own code until you can make the fix to the sensor, either in C# when we take the measurements or in AHK when we use the values.
First idea which comes to mind on how to determine the offset to apply:
As I understand the post from Innominate at Window Coordinates Descrepancy, he has already found an offset:
Since I don’t remember any other than the static/global offset shown above, I suggest to use the offset found by innominate.
Because so far, there seems to be no problem with using the global static offset.
I see a screenshot from innominate, but it is blurry and I have no idea what to make of it. No idea if there is any information in there which indicates a problem with the approach described above.
I can’t believe I forgot to ask the most basic question! Are the Sanderling coordinates 0 or 1 based? (After a bit of analysis, Sanderling seems to be 0 based. AHK is 1 based.)
To make sure that I’m using the right Sanderling data, is the correct place to get the pixel coordinates for the Drone Window “Sanderling.Interface.MemoryStruct.WindowDroneView.Region”?
To expand on what Abbadon said. Did you find that different windows need different offsets?
Yes, the screenshot is blurry, so let me describe it. And actually my math in there is wrong… But here were our findings.
Sanderling X/Y,X/Y Coords: 407/324, 670/500 (Add 1 to each coord for proper comparison, due to 0 based.)
Window X/Y Dimensions: 263 (=670-407) , 176 (=500-324)
My X/Y,X/Y Coords: 416/351, 676/524
Window X/Y Dimensions: 260 (=676-416) , 173 (=524-351) {Regardless of 0 or 1 based, dimensions should be the same.}
In the middle-bottom I show the drone window. Above I’ve cut the window and made it bigger so I could show (in red) the pixels I’m using for the X/Y values. (I also get the bottom Y, but it isn’t necessary for the example.)
On the right, the “Active Window Information” shows the coordinates of my mouse that is positioned at the top-right of the drone window. (Your code seems to use something close to the Client window coordinates, while mine uses Relative.) The difference between the Relative and Client X/Y was +8/-26.
On the left is what is gotten with our code. It seems that the coordinates they get are in disagreement. If we count the first corner pixel as 1 and add 1 to your findings (to account for it being 0 based), the difference in coordinates is +8/+26**, +5/+23. Your code says the window’s pixel width is 263 (=670-407), when the width is actually 260 (=676-416). And the heights yours got was 176 (=500-324) versus 173 (=524-351) actual. Regardless of whether we’re using 0 or 1 based coordinates, the widths/heights should be the same.
OKAY, I just did another test and found what I suspected. The coordinates say that the two windows overlap.
@Viir
Now this is just a guess, but I have a theory as to why you got weird values for window coordinates… I suspect it is because all windows have a 2-3 pixel buffer space between the outer edge and where the actual window content areas begin… (Most are 3, but a few are 2.) So my guess is that Eve defines window coords based on the main internal content areas and then adds the outside buffer after that… (Buffer would be corners and edge area.) Does that make sense?
OKAY, so upon further inspection, I found that the window LeftX and TopY values seem to be good, but something is applying extra (+3) offsets to the RightX and BottomY values.
I don’t know. I don’t have an idea what difference this could make.
I also don’t know how to measure that.
Yes, this is where I would expect them too.
No. This question makes me suspicious, as it seems your expecting a possibility of different windows. I do not see how there could be different windows anyway.
I have no idea if that makes sense.
In that paragraph there are a lot of concepts I do not remember seeing in Sanderling. For example “pixel buffer space” and “outer edge” and “window content area” and “outside buffer”.
If you want to know if such things exist in eve online: I have no idea as I have not looked into this.
