MacroQuest64

Plaz, I've been working on the NewUI stuff too, in parallel. I came to the following conclusion, let me know if this is what you've seen.

Either the insanely complicated logic in the top level "click" function will have to be traced and duplicated, OR you'll have to have dozens of different element-specific offsets to do the clicking.

From what I hear, you've been working at the latter method, which I'm starting to think is the only thing that'll work. I can make the top-level click work about 30-40% of the time, but many basic things confound it (like any box with an item in it, and so on).

Below the top-level click it branches into all of the individual elements' click handlers (which is where I get the "you'll need dozens of offsets" from).

There is a global that's passed in ecx to the top level click handler (which is right below the DInput polling loop) that I want to understand. If I could understand that better maybe I could make more headway with the "top down" approach. I see that the current x,y of the pointer is stored in there at least four times (why?), I see that the value of GetTickCount() goes in there (I'm assuming to time double clicks and drags an so on), but there's also a bit flags variable that I'm totally clueless on. Also, it seems to keep track of what UI element the mouse is "over" at any given time.

The top level click function takes that global in ecx, and the x,y coords of the mouse pointer, as parms. Interestingly, if I pass in the global and valid x,y, EQ crashes. Which leads me to believe that some prep/setup work must be done; it appears that a certain amount of UI state is being maintained in the global.

Your thoughts/findings?

I'm probably way off, but since every button is stored in an XML file in the new UI, couldn't you just read that file to find out where to click? Between that and the character ini file for window locations you should be able to locate any button you need and click on it.

not really since i dont believe they tell the mouse to click at x,y and also becaues the xml tells it how it looks, not where it is. you can move windows around and those arent stored in xml.. but they are stored in some files. so /shrug

Mckorr,

It's my understanding that finding the button is not the problem but the clicking *on* that button that is the problem. think of the screen in 3D and that everything on the screen is in layers and that that mouse rest on the bottom most layer but the buttons are on the layer above the mouse. thus the mouse click clicks under the button and not on the button. So the problem.... Again as I understand it... is how to get the mouse from the bottom layer up to the top layer so that that mouse click happens on the button and not under it.

We have the mouse, say its at 400,400

You call the click function and it crashes.........

Is there any way to.. debug?.. EQ and click the mouse and trace every bit of moving code to see what gets called goes where etcetera?

AMM you sound really close. Try this though. Make an item link in your chat box and do a memory search for the name. You come up with the |003462252FishingPole| thing in memory if you find the right copy of it. Try changing the 2 at the end of the item number to a.. 4.. or a 7. or a 3.. EQ instant crashes. Now WTF.. To me that says either your memory editor isnt writing fast enough and causing read denial to EQ or theres some sort of CRC on the data in that field that is broken, but not by the DX keyboard input function which does it just fine..

Possibility that they have something watching memory inside EQ that is stopped at the begining of a keypress or click and crashes if memory changes unusually?

... I have no clue what im talking about though. Just the misguided way I see things.