tradeskill macros without mouse commands?

Help section from before the user variable changes that broke all macros

Moderator: MacroQuest Developers

DF19
orc pawn
orc pawn
Posts: 17
Joined: Mon Apr 07, 2003 11:48 pm

tradeskill macros without mouse commands?

Post by DF19 » Mon Apr 07, 2003 11:53 pm

i know i am new to this, but it doesnt make sense to me how a tradeskillup macro can work without using the mouse, which apparently doesn't work in the new UI (and there is no way to change back to the old one).
in fact, i tried using tradeskill.mac by DigitalXero ( http://macroquest2.com/phpBB2/viewtopic.php?t=1126 ), which didn't work. it loaded and found the container, but appeared to just endlessly loop searching for the items until i ended it.

is it still possible to make a macro with a similar function to the one above? (tradeskill.mac) Does that one still work for other people here?

Thanks for your help!

eqjoe
a grimling bloodguard
a grimling bloodguard
Posts: 984
Joined: Sat Sep 28, 2002 12:26 pm

Post by eqjoe » Tue Apr 08, 2003 12:41 am

Tradeskill macros do not work. Most of your Cleric Bots, Bard twist and auto melee macros work (without auto loot that is).

Tradeskill macros would be nice, but where abused IMO. It might be worth looking into, but is not a priority as of yet.

DF19
orc pawn
orc pawn
Posts: 17
Joined: Mon Apr 07, 2003 11:48 pm

Post by DF19 » Tue Apr 08, 2003 5:21 pm

ah. that would make sense then :wink:
im not one to make a bot/macro to autoplay my character, but MQ is still very nice for /who npc commands among others.

AlphaBeta
a ghoul
a ghoul
Posts: 126
Joined: Sat Nov 09, 2002 12:35 am

Post by AlphaBeta » Tue Apr 08, 2003 5:48 pm

I would love to see /click working again.. I don't think its much of an issue anymore sence SOE nerfed the prices. I am getting tunnle carple from skilling up :cry:

Non M$ Coder
a lesser mummy
a lesser mummy
Posts: 43
Joined: Sun Apr 13, 2003 8:00 pm

Stupid question

Post by Non M$ Coder » Mon Apr 14, 2003 12:53 pm

This means the fishing macro is also broken? (let me take this opportunity to say DOH! Fishing is the whole reason I started on the journey to build macro quest, damn cobalt cods have been overfished or something, very rare nowadays...)

woodcraft
orc pawn
orc pawn
Posts: 10
Joined: Tue Jan 14, 2003 10:39 pm

Post by woodcraft » Sat Apr 26, 2003 7:57 pm

Fishing does fail as the /click is different. /click <left|right> <mousepos> is the new syntax and the finditem does not seem to work.
I would like to try to get these working, but I don't know where to begin.

Regards

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Sun Apr 27, 2003 12:45 pm

You begin by figuring out how to get X and Y coordinates for buttons/slots/etc. Remember that these things move around and people shift window positions.

So, if you type "/click left auto", there needs to be a function that takes the "auto" part, parses INI and XML files, and returns an X and Y value for the current location of "auto".

Before the NewUI, this was the ParseMouseLoc function in EQLib.cpp.

There are certain conditions that must be met for a new ParseMouseLoc:

1) It must work under both VC6 and VC.NET. This means that using .NET's built in XML functions is not an option. INI and XML files will have to be parsed as text files.

2) It must take into account that the named location moves, which means you can't just store the X Y values but must parse them every time. Also, your EQUI_whatever.xml files do not update everytime you move a window, they update when the character saves. Dunno why SOE wrote it that way, but they did. Lots of potential complications there.

3) When looking for the UI_CharacterName_##.ini file it must take into account that not everyone has EQ installed in the same directory. This might be best handled by adding a line to the MacroQuest.ini file that points to the EQ directory. Use MacroQuest.ini since there is no reason to change that from patch to patch, unlike eqgame.ini.

4) It must be able to determine which skin the character is using, and look in either the uifiles/default or uifiles/myskin directory for the correct XML file.

If you can do all that, I have the algorithm for calculating the X and Y values from the parsed INI and XML files. I've checked the math and it works, as long as you don't move the windows between character saves.

fwiggles
a hill giant
a hill giant
Posts: 161
Joined: Mon Jun 17, 2002 8:29 pm

Post by fwiggles » Sun Apr 27, 2003 1:58 pm

wow Mckorr, good work i must say
[color=red]Latest survey shows that 3 out of 4 people make up 75% of the world's population.[/color]

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Sun Apr 27, 2003 2:22 pm

I've been spending a LOT of time on this. Mostly building on others work, but I'm making progress. But I need the parser, and I haven't started on that yet, mostly 'cause I'm still figuring out the code for reading text files (hey, what can I say, I suck at C.)

Clawed
a ghoul
a ghoul
Posts: 105
Joined: Mon Jan 20, 2003 6:17 am

Post by Clawed » Sun Apr 27, 2003 2:46 pm

Aren't your window locations saved in the UI_Character_xx.ini file? So those are only saved when your character is saved? That's very annoying... because I move my windows around quite a bit during normal play. I guess if you intend to use a clicking macro, you'd just have to know not to move anything. Very interesting. Also I have to admit that creating our own XML parser isn't my idea of a good time... :?
Clawed

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Sun Apr 27, 2003 3:25 pm

The xml files can be parsed as straight text.

You find values as follows:

UI_Character_##.ini contains the base window locations. The XY coordinates of the upper left corner of the window.

EQUI_Whatever.xml contains the button/slot location and it's size.

So:

WindowX (from UI.ini) + ButtonX (from UI.xml) + Half the ButtonSizeX (from UI.xml) = X coordinate of Button.

Same for Y coordinates.

You use half the button size to make sure you are clicking inside the button and don't miss it by just hitting the corner.

The XML files can be parsed as straight text (lol, I see I'm repeating myself). I mean, you can read them in Notepad so why not treat them as text?

If you parse the locations this way, set up your windows, wait for "Mckorr has been saved", THEN run your tradeskill macro, locations should be current and click in the right places.

Since we know what XML file contains what button, and those names are always the same, it's just a matter of parsing the skin directory, testing for the existence of the file, and using that file, or using the one from the default skin if no custom file exists. So if I have a custom EQUI_InventoryWnd.xml I use the one from my skin directory. If that file doesn't exist I use the one from the default directory.

Ideally you could have an array set up for every button and slot. The array contains the common button name ("Destroy"), the XML file we need ("EQUI_Inventory.xml"), and the xml button name ("IW_Destroy"). Then when we "click left destroy" we reference the array to find the xml file we need and the corresponding location in that file. I might even go so far as to set up a new INI file, "locations.ini" or somesuch, so that new buttons could be added easily as SOE adds or subracts from the interface.

And, of course, we don't need every single button or slot.

As I've said, I got the theory down, I just need the code and haven't had time to work on that part.

Finally, I'll repeat myself again. You must parse new X and Y coordinates every time. You can't store them for later use.

Now, gimme a function that will accept one argument (the button name) and return two arguments (X and Y), and I think I can finish the whole thing up and get /click working again.

Clawed
a ghoul
a ghoul
Posts: 105
Joined: Mon Jan 20, 2003 6:17 am

Post by Clawed » Sun Apr 27, 2003 3:50 pm

Except for I believe we still have issues dealing with clicking on the right layer in the UI. Otherwise, finding the coords seems quite simple. I like the idea of a locations.ini (or maybe UI.ini) file to generalize the code a bit.

Oh, and I know XML is straight text. I just find writing text parsers to be kind of annoying. 8)
Clawed

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Sun Apr 27, 2003 8:05 pm

Clawed, you parse the location, let me worry about the rest :twisted:

Clawed
a ghoul
a ghoul
Posts: 105
Joined: Mon Jan 20, 2003 6:17 am

Post by Clawed » Mon Apr 28, 2003 2:48 am

LOL. :lol:

Kk.
Clawed

Geeknik
decaying skeleton
decaying skeleton
Posts: 2
Joined: Wed Apr 30, 2003 10:41 pm
Location: Home.. wait, this isn't my home?

Post by Geeknik » Wed Apr 30, 2003 11:09 pm

I'm new to the forums and MacroQuest in general, so bare with me plz =(

just a couple thoughts...
"You begin by figuring out how to get X and Y coordinates for buttons/slots/etc. Remember that these things move around and people shift window positions. " --Mckorr
I realize you don't want to further limit the users' options but why not require the default skin, at least for now? After all everyone had to use the old UI no? You can find the upper left hand corner of a window in one of the ini files (found it somewhere before), and then move x,y from that spot to get to bag1's slot 1, close, combine etc..

From what I've read it seems like MacroQuest used to be able to find lots of crazy stuff, so I realize the XML parsing approach may be disappointing to some and make scripts less universal between users, but this is what you're currently talking about no?
"Except for I believe we still have issues dealing with clicking on the right layer in the UI" --Clawd
What if it just becomes good script coding practice to close windows that might open over other windows (bags, etc)
"Aren't your window locations saved in the UI_Character_xx.ini file? [... ]because I move my windows around quite a bit during normal play. I guess if you intend to use a clicking macro, you'd just have to know not to move anything. " --Clawed
I think you can lock windows so they can't be moved around (or am I high?) with a key sequence in the game (sendkey?)