Custom ui inventory file and macros using inventory items.
Moderator: MacroQuest Developers
Custom ui inventory file and macros using inventory items.
I have a custom UI file for my inventory and ive tried writing macros to find specific items in bags or even the bags themselves and i see my cursor clicking up top where the default ui inventory would of been. Is there an easy way to get the macro to click on my bags or items on my custom ui inventory instead? Any help is appreciated. Thank you.
I think you are going to have to use the default UI for bags and inventory. With the Inventory tho you can use /autoinventory if you are trying to drop something into you inventory, this command does not require the Inventory window being opened.
For the bags I guess you need to tell us which macro you are trying to use since most of the aurthors state to open and close your bags to set and save the bag locations before running the script.
For the bags I guess you need to tell us which macro you are trying to use since most of the aurthors state to open and close your bags to set and save the bag locations before running the script.
Im trying to use the macro that opens a bag, picks up an item, puts it in the correct slot on your character, right clicks it to get the effect, then puts the old item back on and puts the clicky item back into the bag and closes the bag. I however cant do this due to using a custom ui inventory 
Also when i tried to /load default to get my default ui i get an error message saying something about default not being in my favorites list. No idea if thats MQ causing that or somethings screwy with my ui or what.
Btw...how do i set and save bag locations? Im guessing if i can get the macro to click on a bag and open it, i can then use /finditem to get the item im after OUT of the bag. Im also going to run into the same problem when i try to do /click left finger to equip say my coldain ring for example.
Also when i tried to /load default to get my default ui i get an error message saying something about default not being in my favorites list. No idea if thats MQ causing that or somethings screwy with my ui or what.Btw...how do i set and save bag locations? Im guessing if i can get the macro to click on a bag and open it, i can then use /finditem to get the item im after OUT of the bag. Im also going to run into the same problem when i try to do /click left finger to equip say my coldain ring for example.
Post your code that you are using so others can look at it.
As for the defualt UI make sure you are spelling everyting correct in EQ. MQ should not be involved in that area.
As for saving bag locations you manually open and close each bag making sure they do not overlap any other bag. That will save the locations.
As for the defualt UI make sure you are spelling everyting correct in EQ. MQ should not be involved in that area.
As for saving bag locations you manually open and close each bag making sure they do not overlap any other bag. That will save the locations.
#turbo
Sub Main
|finds container and opens it
/finditem "Hand Made Backpack"
/delay 2
/click right
/delay 2
|finds item and equips it
/finditem "velium coldain insignia ring"
/delay 1
/click left finger
/delay 2
/click right
/delay 2
|returns items to their original slots
/click left finger
/delay 2
/click left pack 5 4
/delay 2
|closes everything out
/press esc
/press esc
Sub Main
|finds container and opens it
/finditem "Hand Made Backpack"
/delay 2
/click right
/delay 2
|finds item and equips it
/finditem "velium coldain insignia ring"
/delay 1
/click left finger
/delay 2
/click right
/delay 2
|returns items to their original slots
/click left finger
/delay 2
/click left pack 5 4
/delay 2
|closes everything out
/press esc
/press esc
Bag locations are saved every time you CLOSE the bag. To set locations, open the bag, move it to where you want it, then close it. The location will be updated.Btw...how do i set and save bag locations?
Then open the bag again, find your item, and go. Just don't move the bags around after you open them, or you will click at the old location.
MQ2: Think of it as Evolution in action.
-
MacroFiend
- a grimling bloodguard
- Posts: 662
- Joined: Mon Jul 28, 2003 2:47 am
The reason you are getting the message "default is not in your favorite list" is because there are 3 commands that start with /load. Two are EQ and one is MQ (though the MQ command overrides one of the EQ commands). You need to be a little more specific in your command.
/loadskin default 1
The "1" is important. If you leave it out, all your window positions will be reset to their default locations which is a pain in the tail if you want to load your other UI back and not have to move everything.
/loadskin default 1
The "1" is important. If you leave it out, all your window positions will be reset to their default locations which is a pain in the tail if you want to load your other UI back and not have to move everything.
I think it's just the EQUI_Container.xml file that has to be used.MQSEQ wrote:I think you are going to have to use the default UI for bags and inventory. With the Inventory tho you can use /autoinventory if you are trying to drop something into you inventory, this command does not require the Inventory window being opened.
For the bags I guess you need to tell us which macro you are trying to use since most of the aurthors state to open and close your bags to set and save the bag locations before running the script.
I use a custom UI for stuff, except the container when I use a macro which requires a bag to be used.
You should see how small my inventory window is.
Shouldn't finger be finger1 or finger2?
like this
Zelker
Code: Select all
|returns items to their original slots
/click left finger
/delay 2 Code: Select all
|returns items to their original slots
/click left finger1
/delay 2Zelker
lfinger or rfinger, for left finger or right finger. That's the way it's laid out in locations.txt, the file holding all the possible screen locations for /mouseto and /click.
On that note someone was asking about clicking hotkeys. /click left hotkey_# should work.
If a lot of the locations don't exactly make sense (hotkey_1 instead of hotkey1 for example) it's because for a long time locations.txt has been computer generated instead of manually entered.
On that note someone was asking about clicking hotkeys. /click left hotkey_# should work.
If a lot of the locations don't exactly make sense (hotkey_1 instead of hotkey1 for example) it's because for a long time locations.txt has been computer generated instead of manually entered.
MQ2: Think of it as Evolution in action.
I've never had a problem using custom UIs with tradeskill macros, but I think all my custom UIs just retexture the graphics and such for the container... But I don't have the default inventory screen at all and I never have had issues.
I haven't looked at the source code for MQ for the new ui, i was only in to making personal changes when i first got it, but playing with memory is a bit over my head and it's hard to dig in instead of doing it from scratch. however, i would think it'd be pretty easy to point MQ to your UI xml files and look for the locations themselves once you're inside a container.
in my mind, eq would have their bag. information about the bag is saved in various places. if you get that bag open, where everything is inside STAYS THE SAME according to the UI_Container.xml or whatever. So you can work off the hardcoded values for items inside containers, so to speak (if items are individual features, and container is the window those are in)
Anyone who's been working on the MQ source it'd be nice for a brief explanation of how this is actually done. I'll step through the source code later for my own enjoyment, but from a developign standpoint thats the way I'd do it. Unless EQ kept all it's UI data in memory too then you could grab it from there instead of off the disk.
I haven't looked at the source code for MQ for the new ui, i was only in to making personal changes when i first got it, but playing with memory is a bit over my head and it's hard to dig in instead of doing it from scratch. however, i would think it'd be pretty easy to point MQ to your UI xml files and look for the locations themselves once you're inside a container.
in my mind, eq would have their bag. information about the bag is saved in various places. if you get that bag open, where everything is inside STAYS THE SAME according to the UI_Container.xml or whatever. So you can work off the hardcoded values for items inside containers, so to speak (if items are individual features, and container is the window those are in)
Anyone who's been working on the MQ source it'd be nice for a brief explanation of how this is actually done. I'll step through the source code later for my own enjoyment, but from a developign standpoint thats the way I'd do it. Unless EQ kept all it's UI data in memory too then you could grab it from there instead of off the disk.
Okay, I'll try to explain things. This may get long winded.
Every location in the NewUI is a combination of several factors. First is your UI_Character_Server.ini file. This tells EQ which UI you are using (i.e. the subdirectory name), and the basic locations of all windows in that UI.
Next are the XML files themselves. They lay out the locations of everything in a window, determining the location and size of any button, label, etc.
The INI and XML files are updated every time you CLOSE a window. When you open a window (inventory, pack, whatever) those locations are read into memory, and EQ addresses the memory directly to find those locations. When you close the window, the INI files and XML files are updated with the new information, i.e. whatever has changed since you opened the window (moved it, resized it, whatever.)
Once I had working code to move the mouse and click it (thanks NealThorpayt), I sat down and devised an algorithm for determing the location of anything on the screen. That algorithm became the "parser" you'll see referred to in any post about /mouseto or /click.
First, MQ determines which character is logged on, and which server he is on. That information is used to construct a string for the UI.ini file, UI_Character_Server.ini.
We then read that file to determine which UI you are using, which will give us a subdirectory to look in for XML files.
Next, we check your /mouseto or /click argument against locations.txt. That file is a "roadmap" to screen locations, providing us with a standardized set of names for our screen locations
As you can see above, our standardized "location" for the autoequip area in your inventory window is called "auto".
We search locations.txt for your location, giving you an error message if we can't find it. If we find it, we then have 3 values to work with.
UILabel is the label in your UI_Character_Server.ini file for the base location of the window we need. In this case, for "auto", we need to find the entry in the ini file for InventoryWindow. We then pull the base location of that window from the ini file.
XMLFile is the XML file in your UI directory that corresponds to UILabel in your ini file. It tells us which file in your directory to read to get our actual screen location.
Finally, ScreenID is the label to search for inside the XML file to determine the position and size of our desired screen location within the window. That size and position are relative to the window location derived from UI_Character_Server.ini.
So:
Since we read these locations from the files on your hard drive, not from memory, MQ will go to the wrong location if you open a window and then move it, since the files aren't updated till you close the window.
Now, there are a few locations hardcoded into the parser for the sake of backwards compatibility with the readme file. We could have just changed locations.txt, but since it is computer generated (a program that quickly scans the INI and XML files and builds a list of all locations) it was easier to put the translation directly into the source code, rather than edit locations.txt.
While it would be possible to read the locations directly from memory so that moving windows doesn't cause a problem, it would be very complicated. I was more interested in getting things working at the time I developed the current method, and, well, we didn't really know about that movement problem at the time anyway.
Next you will ask "why does my custom UI not work when yours does?" I'm afraid there's no simple answer. It has to do with the varying size of labels on the top of windows, or whether they exist or not. It has to do with the way the actual XML files of a custom UI are structured, and how close they are to complying with the default UI. Suffice it to say the biggest problem is with custom containers, and you are better off just using the default container file. In general custom inventories don't seem to be affected by this "bug", and I use a custom loot window that is not bothered in the slightest. The more radical your departure from the default UI, the more likely you are to run into problems.
Every location in the NewUI is a combination of several factors. First is your UI_Character_Server.ini file. This tells EQ which UI you are using (i.e. the subdirectory name), and the basic locations of all windows in that UI.
Next are the XML files themselves. They lay out the locations of everything in a window, determining the location and size of any button, label, etc.
The INI and XML files are updated every time you CLOSE a window. When you open a window (inventory, pack, whatever) those locations are read into memory, and EQ addresses the memory directly to find those locations. When you close the window, the INI files and XML files are updated with the new information, i.e. whatever has changed since you opened the window (moved it, resized it, whatever.)
Once I had working code to move the mouse and click it (thanks NealThorpayt), I sat down and devised an algorithm for determing the location of anything on the screen. That algorithm became the "parser" you'll see referred to in any post about /mouseto or /click.
First, MQ determines which character is logged on, and which server he is on. That information is used to construct a string for the UI.ini file, UI_Character_Server.ini.
We then read that file to determine which UI you are using, which will give us a subdirectory to look in for XML files.
Next, we check your /mouseto or /click argument against locations.txt. That file is a "roadmap" to screen locations, providing us with a standardized set of names for our screen locations
Code: Select all
[auto]
UILabel=InventoryWindow
XMLFile=EQUI_Inventory.xml
ScreenID=IW_CharacterViewWe search locations.txt for your location, giving you an error message if we can't find it. If we find it, we then have 3 values to work with.
UILabel is the label in your UI_Character_Server.ini file for the base location of the window we need. In this case, for "auto", we need to find the entry in the ini file for InventoryWindow. We then pull the base location of that window from the ini file.
XMLFile is the XML file in your UI directory that corresponds to UILabel in your ini file. It tells us which file in your directory to read to get our actual screen location.
Finally, ScreenID is the label to search for inside the XML file to determine the position and size of our desired screen location within the window. That size and position are relative to the window location derived from UI_Character_Server.ini.
So:
Code: Select all
Base Window Location from INI + Position Inside Window from XML file + Half the Size of the Location from XML (so we click in the center) = Location on ScreenNow, there are a few locations hardcoded into the parser for the sake of backwards compatibility with the readme file. We could have just changed locations.txt, but since it is computer generated (a program that quickly scans the INI and XML files and builds a list of all locations) it was easier to put the translation directly into the source code, rather than edit locations.txt.
While it would be possible to read the locations directly from memory so that moving windows doesn't cause a problem, it would be very complicated. I was more interested in getting things working at the time I developed the current method, and, well, we didn't really know about that movement problem at the time anyway.
Next you will ask "why does my custom UI not work when yours does?" I'm afraid there's no simple answer. It has to do with the varying size of labels on the top of windows, or whether they exist or not. It has to do with the way the actual XML files of a custom UI are structured, and how close they are to complying with the default UI. Suffice it to say the biggest problem is with custom containers, and you are better off just using the default container file. In general custom inventories don't seem to be affected by this "bug", and I use a custom loot window that is not bothered in the slightest. The more radical your departure from the default UI, the more likely you are to run into problems.
MQ2: Think of it as Evolution in action.