Over time and creation of macros, I have tried to make things as lag resistant and portable as I could. Looking at the progression from my early macros to my current potion macro, I feel I have accomplished this finally. So anyhow, I have attached my vendor interaction procedures for people to use.
Look in the comment section before each procedure to see how to use them. The vendordelay procedure is just a loop to have your macro wait for the vendor to open. It will wait up to two minutes before assuming the vendor is open. There is one purchase procedure for items that can be bought in stacks, and another for items that have to be bought one at a time.
You must also use INCUI and then call setui in your macros since I make use of the universal mouse positions, which is necessary for navigating the vendor menus. I did not put that in this include to avoid conflict with your macro if you already do this.
Full Version: Vendor open and purchase include...
| QUOTE |
Make sure to include the incui macro by adding this line to yours: Include incUI.mac And make sure the chat bar is maximized with this: Call SetUI If $uiChatMaxed <> 1 // Maximize the chat window MousePos $uiPosX, $uiPosY Delay 333 LeftClick Delay 333 Call SetUI End Chat bar should be maximized since some vendor menus are out of sight when chat is minimized |
Stay tuned for the _VendorID variable.
I was using it in a test version of ACTool before the January patch, and it was working reliably in vendor interaction to indicate when the client has a vendor open.
(It's a direct memloc read that returns the GUID of the vendor your client currently has open, so it's client side only and relatively lag-proof).
I have to recode & retest it with Decal 2.6.1.0, since it was 1 of the renamed memlocs. Will try to sneak it in with the other memloc-related fixes that are required for 2.6.1.0
I was using it in a test version of ACTool before the January patch, and it was working reliably in vendor interaction to indicate when the client has a vendor open.
(It's a direct memloc read that returns the GUID of the vendor your client currently has open, so it's client side only and relatively lag-proof).
I have to recode & retest it with Decal 2.6.1.0, since it was 1 of the renamed memlocs. Will try to sneak it in with the other memloc-related fixes that are required for 2.6.1.0
figures you would make me have to redo this!!!!
Oh, and 1 other "robustifier"
| CODE |
| Call SetUI If $uiChatMaxed <> 1 // Maximize the chat window MousePos $uiPosX, $uiPosY Delay 333 LeftClick Delay 333 Call SetUI End |
In that code, what happens if the 1st detection screws up and sets $uiChatMaxed to 1, when the window is minimized ? Your click-to-maximize doesn't happen.
What happens if the 2nd SetUI fails auto-detect, sets the state to minimized and calculates for minimized, when it's actually maxed.
The only sure way to do this is have the macro always left-click on the maximize box location (which has no effect if already maxed) and force over-ride in incUI.
Kinda like this
| QUOTE |
| figures you would make me have to redo this!!!! |
LOL
Hey, if I have to spend my weekend coding, might as well share the joy
I will have to take your word on it. Never ran into that kind of problem. Of course I sure now that I said that, it will happen very soon!!!
Was renamed to ShopVendorID in Decal and is there no other way but direct usage of the memloc to do this?
As I thought -> ACHooks->Get_VendorID(); So no real need to mess with memlocs on this one, or is there?
As I thought -> ACHooks->Get_VendorID(); So no real need to mess with memlocs on this one, or is there?
I use the ACHook for it.
Didn't mean to imply I was reading memory directly, was trying to convey that the ACHook grabs the 4 bytes directly from client, and does not rely on filters or anything sniffed out of server msgs that may get out of sync with client.
Didn't mean to imply I was reading memory directly, was trying to convey that the ACHook grabs the 4 bytes directly from client, and does not rely on filters or anything sniffed out of server msgs that may get out of sync with client.
Ahh, okies I was trying to figure out if memlocs are even needed anymore now that we have the hooks.
| QUOTE |
| I was trying to figure out if memlocs are even needed anymore now that we have the hooks |
They are needed if you want to do something to the client, but aren't running a plugin COM DLL.
2 examples: ACTool.exe and SkunkWorks console.
Oh, now I understand the impact of screwing with the memlocs it only affects none plugins.
Thanks Ipa.
Thanks Ipa.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.