It might depend on whether you use both apps on the same desktop. I have not tested such a scenario at all. In case you discover any problem with this scenario, you can avoid it by using a different desktop for the alternate UI.
The desktop is a concept within the Windows operating system. Concepts like the focused window and the location of the mouse pointer tied to the desktop. It is possible to have multiple desktops on a single instance of Windows, but in case that requires too much effort to set up, we can also use a completely different instance of Windows. This separation is no problem for our application because the backend and frontend communicate only via HTTP.
The solution is designed from the beginning to support of backend and frontend running on different computers. The backend runs on the machine that also runs the EVE Online client. The frontend runs on the machine where you want to work with the HTML representation.
That seems reasonable. I will have to explore using the representation on another machine, I tried before, but I think I ran into a firewall problem on my back end PC.
Just wanted to write to say that Iâm still very much interested in this project, as at the moment OCR is bad enough that thereâs little i can do in game reliably at the moment. I am glad to see support for 64-bit memory reading, and hope we wonât be too badly impacted by the new bot hunting initiativesâŚ
Good. If I remember correctly, the next priority for you was a way to send mouse clicks to UI elements. I probably have time next week to work on the alternate UI for EVE Online.
Yeah, a way to send mouse clicks through to the client would be good, as would a way to isolate text-based elements from some of the less meaningful background stuff. At the moment the UI tree is still very full of elements but Iâm uncertain how many of them Iâll actually interact with.
I made some progress towards the sending of mouse clicks to the EVE Online client from the alternate UI: I added parsing of the display regions of the UI elements so that we know the location to send a mouse click to. I also updated the alternate UI to use the memory reading implementation for 64-bit game clients. Starting with todayâs version, the EVE Online client needs to be started in 64-bit mode to work with the alternate UI.
I just wanted to check that I hadnât done something wrong⌠I was trying to test this again tonight and kept failing to read from the live process. âBadstatus: 500.â Is this part of the 64-bit transition, or something related to admin rights, orâŚ?
No, the 64-bit transition should not affect this. As long as you continue to use the version for 32-bit clients, it should continue to work with the 32-bit client. You only get the newer software version if you choose it.
In case the âBadstatus: 500â appears in the browser window, it might be that another process already took the address, so the web browser would connect to that other process and not our program.
Does the web browser get you the âBadstatus: 500â also when not starting the program?
NO, I was trying the newest version for 64-bit clients, and getting the âBadStatus,â from that. I only get it when trying to read from a live process, it finds a process ID but then seems to time out after approximately a minute and a half.
I had a look at the newest version for 64-bit clients today.
I did not see a âBadStatusâ error, but I have an idea of what could have caused this.
Based on reports from other users, it seems the memory reading was very slow on some setups. Maybe this affected your setup as well. At least this cause would fit your observation: That it successfully finds the process ID and fails on the first memory reading.
I spend some time optimizing the memory reading for shorter processing time, and it is now much faster. Today I integrated this speedup into the alternate UI.
Just uploaded the fix for that issue in the alternate UI.
In the newest version, not only the contents of the elm-app directory have changed. I also changed one of the two commands to run the UI. The first one changed from
This change results in an HTML frontend with less processing overhead, meaning overall fewer delays in the application.
Another change was to improve the clientâs behavior when getting the first memory reading: Previous versions did request too frequently, resulting in a much longer queue of pending HTTP requests.
Iâm afraid this doesnât work either. I still get the âBadstatus: 500,â message, but I discovered that when I try to read from the client a second time it apparently succeeds, but the OVerview section is empty and unreadable.
THis is very odd. I almost wonder if itâs some kind of browser caching issue.
Good point, I remember there is a cache. Well, something similar, at least, but this is in the file system. The runtime-artifacts directory should be deleted before starting the server. The server creates this on startup.
Maybe the old data in this directory led to that âBadstatus: 500,â message.
Does removing this directory get you the up-to-date overview window?
Nope, the overview is still apparently empty, according to my screen reader. THe client read succeeded the first time around, however, and I did save the memory reading if that would be of any use. Iâll put up a link to it just in case⌠here on Dropbox
Thank you, I will take a look at that memory reading to see what is up with the overview.
The in-game clock in the reading is at 19:49. If I have calculated correctly, that could have been a fresh reading. Not indication so far the memory reading is somehow stale.
Glad to see we got the 64-bit memory reading to work for you.
I am looking at the results from parsing this reading:
It found 19 overview entries, but the reading of the cell contents in the table is not yet adapted to your setup. Probably the relative location of things is out of the range represented in the training samples we had so far.
I will integrate your sample so that this setup is covered too.
I just wanted to confirm that this is indeed working for me now. Thanks, and Iâm very much looking forward to what might come of the recent parsing efforts.