EQ crashing, would appreciate some help

[Soudeus]

Im writing a large macro to run around to different merchants, buy items, cast spells, and combine them and sell them, after i downloaded yesterdays source something makes EQ crash when im with the merchant, i did change a few things so i cant be sure what it is, it opens the merchant fine, but crashes before it closes the merchant...here are my open and close merchant subs:

Code: Select all

Sub OpenMerchant
/target "@Param0"
/if $target()==FALSE {
/echo "ERROR! Unable to open merchant @Param0"
/endmacro
}

/face fast
/varset Merchant_Name "@Param0"
/call LookUp
/target "@Merchant_Name"
/delay 10
/if "@Param0"~~"Gliblixl" {
/press Page_Down
/press Page_Down
/press Page_Down
/press Page_Down
/press Page_Down
/press Page_Down
/press Page_Down
/press Page_Down
}
/press u
/delay 15
/if $target(name)!~"@Param0" {
/target "@Param0"
}
/if $merchant()==FALSE {
/press u
/delay 10
}
/varset Misc_Timer 50s
:WaitForOpen
/delay 5
/if n @Misc_Timer>0 /if $merchant()==FALSE /goto :WaitForOpen
/delay 10
/if $merchant()==FALSE {
/echo "ERROR! Unable to open merchant @Merchant_Name"
/endmacro
}
/echo there!
/delay 30

/return
|====================================================

Sub CloseMerchant
/echo here!
/delay 50
/click left merchant done
/echo again!
/return
|====================================================

My main sub calls to open merchant, which it does, and the echo at the end of the openmerchant sub works, then at some point it crashes. After the openmerchant i call the closemerchant which nothing executes and i get the windows error that eq has crashed.

[GD]

Change:

Code: Select all

/if $target(name)!~"@Param0" { 

To:

Code: Select all

/if [color=red]"[/color]$target(name)[color=red]"[/color]!~"@Param0" { 

Then try it and see if it works.

[EqMule]

and wtf is up with using u and /press ?

here is an idea for you: /rclicktarget

8)

[theafkxper]

Gliblixl Rocktok 35 - 35 Merchant The Bazaar


that explains page down, lol, its a bazaar macro and hes tryin to avoid lagz0r

/afk

[Joshjje]

The merchant is very short lol and for /press u to work he must be in view...i dont like right clicking just cuz other targets could be in the way, etc...but sometimes that messes up also i dunno, however i figured out that this wasnt my problem, thanks.

[EqMule]

The merchant is very short lol and for /press u to work he must be in view...i dont like right clicking just cuz other targets could be in the way, etc...but sometimes that messes up also i dunno, however i figured out that this wasnt my problem, thanks.

damn... I knew I should have named that command to something else than rclicktarget...

Let me try to explain that:

it does a click in "memory" the mouse isnt actually used... it will "click" whoever you have as the target using a direct call to the function...

I cant explain it better than that, but suffice to say, you can unplug your mouse, you can be in a room with 1000 people NOT looking at anything special, as a matter of fact, you can look up the ceiling or straight at another npc... when you do a /rclicktarget it will simulate a "rightclick" on WHOEVER you have targeted... there is no way you can fail it... you can even move your mouse around as much as you want... it will still make the "rightclick" because it doesnt need the mouse...

[CONTEST!!!]If anyone can come up with a better name for /lclicktarget and /rclicktarget I will send you a special precompiled version of MQ that has a couple goodies in it that are not in the cvs. (and never will be)

[LordGiddion]

EQMule, my suggestions
TriggerTargetR and TriggerTargetL
UseTargetR and UseTargetL
MemClickTarR and MemClickTarL
SendClickTarR and SendClickTarL

I like the last pair for clarity but they might be a bit long

[Joshjje]

Ah thanks, EqMule, as you have obviously noticed the name implies an actual click :) Will be glad to insert that tidbit of code in now.

As for the name, lets see...

My first suggestion would be to add it into the /click class of commands if possible and not allowed to be used with /mouseto if that could be done, then you could issue a /click right target fake or /click right target bypass, copy , simu, etc.

As for an independent name:
/RClickTargetFake
/FakeRClickTarget
/CpyRClickTarget
/RClickTargetCpy

[MacroFiend]

How about ...

/rclickdirect
/lclickdirect

and then ... the coup de gras ... let it take target as an option and as the other click functions are written, they can be added.

[GD]

How about leaving it as it is, and just putting it in the documentation so that others understand it, .

[wassup]

Mulled over a few possibiliies:

sureclick left
sureclick right

exactclick left
exactclick right

preciseclick left
preciseclick right

directclick left
directclick right

Those and the other peoples suggestions should help you pick something.

==Edit==
I actually like MacroFiends better, I'm just used to using commands like

/click left

[EqMule]

how about /openmerchant ?

[KhaosWolf]

how about

/target mouseclick l
/target mouseclick r
/target mouseclick l+r (WOW didnt see this one coming did you! I have no idea if this would even be possible, and if it were when the hell it would be used lol)
/target mouseclick random

!!!

[MacroFiend]

Khaos, your command might work pretty well ... but I wouldn't suggest using /target as the command verb. /target does something totally different already and would probably add a lot of confusion and bug checking errors to macros if it was responsible for both PC/NPC targetting and the direct mouse clicking.

EQMule, /openmerchant would be good ... but would it only be used to open a merchant? What about inspecting PCs? Or opening a chest/trap (thinking of future EQ expansion beyond LDoN)

What if we added more options to the existing /click command?
/click left target direct
/click right target direct

That should be clear enough for most that you are executing a mouseclick on your current target directly (w/o mouse movement)

We've already got a good command verb in /click. We could just make it better :) Granted, this way would add a little more complexity to the /click parameter parsing but I think it could be worked out nicely.

[Mckorr]

Adding complexity to the mouse parser is gonna create other problems. People will start trying to do /click right head direct, and then bitching when it doesn't work. You'll find yourself adding in a hundred memory locations, and eqgame.ini will become unmanageable as it takes days instead of hours to find the new offsets.

First step in deciding how to approach this is figureing out exactly what you want to accomplish. Are you only clicking something that is targetted? If so, make the command /click left|right target, and make the target parameter ALWAYS be direct. If you can invoke the click directly on a target there is no reason to NOT do it directly.

Current parsing via locations.txt was done for two reasons: one, too many offsets to find for all possible locations; two, new locations are added as they modify the UI, and it's easier to add them to locations.txt than it would be to add them to EQLib_Mouse.

I would recommend removing rclicktarget|lclicktarget, adding "target" as a parameter to the existing /click. It maintains uniformity across the commands (i.e. any mouse click is called via /click), and makes conversion of existing macros simple:

Code: Select all

/target foobar
/press u

becomes

Code: Select all

/target foobar
/rclicktarget

becomes

Code: Select all

/target foobar
/click right target

The last is far more readable, and follows the current command parameter conventions for mouse clicks.