- Joined
- Aug 19, 2020
- RedCents
- 30,704¢
bought your tool, haven't had to use on Next.. but if your burnt/away from the life.. see if you have somebody who will take over?
-
You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋
- Thread starter Denethor
- Start date
- Seller
- #603
First incident report of this. Can you provide me some more info? What's the exact error? Does it occur on first zone in, or after a certain point into the script?
- Seller
- #605
PM'd. Working through problem there, and I'll post a resolution here when we get one.
- Joined
- Oct 18, 2013
- RedCents
- 2,776¢
Same issue. Crashes at the RoF explore. Did the pre-req quests and gets to this step, opens and closes the quest window, and crashes. Tried going back to PoK and restarting, same result.
- Seller
- #607
MQ (Next) or MQ2?
- Joined
- Oct 18, 2013
- RedCents
- 2,776¢
All Next, I assume everyone is going to be running MacroQuest by the game patch next week.
- Joined
- Dec 29, 2017
- RedCents
- 23,976¢
best I can tell the issue occurs in the denecore -nav.inc in the function toggleNavDoors
The function calls for Sub fatalError take a parameter, but the usage of the parameter isn't being wrapped in curly brackets. so it's not outputting where the error is.
The error message and /endmac is triggered because Sub toggleNavDoors is making it to the end and doing a /return unknownError.
Since you're on next, you could do a couple of things.
1. One being change the path of the INI calls to reference the correct location and see if that corrects the issue.
2. replace the final return from unknownError with /return toggleNavDoorsSuccessful
either of those two things in theory should prevent the check from passing directly following the /call toggleNavDoors and thus prevent the fatalError sub from being called which is ending the macro.
The function calls for Sub fatalError take a parameter, but the usage of the parameter isn't being wrapped in curly brackets. so it's not outputting where the error is.
The error message and /endmac is triggered because Sub toggleNavDoors is making it to the end and doing a /return unknownError.
Since you're on next, you could do a couple of things.
1. One being change the path of the INI calls to reference the correct location and see if that corrects the issue.
2. replace the final return from unknownError with /return toggleNavDoorsSuccessful
either of those two things in theory should prevent the check from passing directly following the /call toggleNavDoors and thus prevent the fatalError sub from being called which is ending the macro.
If it isnt running properly with next it should be clearly stated in Overview, FAQ and Instructions.
In Launcher the current version is now called MQ and not Next anymore. So new people come here, not even knowing about the existence of a legacy version, then buy the mac and it might not be running for them.
I'd suggest to eitehr remove it as a payed ressource or make it running with he new MQ.
In Launcher the current version is now called MQ and not Next anymore. So new people come here, not even knowing about the existence of a legacy version, then buy the mac and it might not be running for them.
I'd suggest to eitehr remove it as a payed ressource or make it running with he new MQ.
- Joined
- Sep 13, 2011
- RedCents
- 408¢
or if the author is not playing anymore and having trouble fixing the issues, perhaps it can just be dropped to a free resource and other folks can work on fixing it up to a working state. the content is several expansions old, anyhow.
While I understand that perspective, MQ has been in the launcher for a year and the solution to this problem (which is also a problem in MQ2) has been posted multiple times with multiple recommendations. CWTN’s is just the latest suggestion, but hardcoding paths is always a bad idea. I’ve posted about the fix for that specifically and brainiac has posted about how to not need the path at all.
I totally understand not wanting to work on it, or not having time. But at this point I agree that the resource should be clearly marked until the issues are resolved or a decision is made.
I totally understand not wanting to work on it, or not having time. But at this point I agree that the resource should be clearly marked until the issues are resolved or a decision is made.
knave23
Cookie Champion 2022
- Joined
- Sep 10, 2019
- RedCents
- 6,290¢
Probably not a permanent fix, but if anyone is like me and just now getting around to doing these things, here's what I did to get it to work with MQ(Next):
in \macros\Denecore, edit these two lines in the toggleNavDoors function of denecore-nav.inc, adding
Then place the downloaded explore.mac and Explore folder from the zip file into your macros folder.
I've only done the faydwer one so far but it seems to be working fine. Also, I realize this is what others have been suggesting in this thread, but I wanted to explicitly post what needed changed to hopefully help others,
in \macros\Denecore, edit these two lines in the toggleNavDoors function of denecore-nav.inc, adding
\..\config:
Code:
/declare iniSetting string local ${Ini[..\..\config\MQ2Nav.ini,Settings,OpenDoors]}
...
/varset iniSetting ${Ini[..\..\config\MQ2Nav.ini,Settings,OpenDoors]}I've only done the faydwer one so far but it seems to be working fine. Also, I realize this is what others have been suggesting in this thread, but I wanted to explicitly post what needed changed to hopefully help others,
You can use ${MacroQuest.Path[Config]} to get the path which will be correct even if your config directory or macro directory changes.
Glad to hear!
knave23
Cookie Champion 2022
- Joined
- Sep 10, 2019
- RedCents
- 6,290¢
Not sure if there's anything you can do other than maybe a cleanup on crash function if that's even a thing, but when the macro crashes, my mq2nav settings are jacked up. I've run into it a few times today where after explore.mac crashes, my nav settings to autoclick doors is turned off.
Also, for the record I'm running into the same RoF crash other posters are.
Also, for the record I'm running into the same RoF crash other posters are.
- Seller
- #619
The fix for both of those (they're related) is discussed up-thread.
That issue, and a number of other fixes (some discussed, some that were never needed but discovered during code review over the holidays) are in testing currently. The macro takes 16-18hr to run, so generic (not a specific issue) testing is a long process. (And no, I'm not the only tester.)
That issue, and a number of other fixes (some discussed, some that were never needed but discovered during code review over the holidays) are in testing currently. The macro takes 16-18hr to run, so generic (not a specific issue) testing is a long process. (And no, I'm not the only tester.)
- Seller
- #621
At the time it was written, I had to path close to certain "scripted doors" (zone-activators, like port stones) but didn't want to go activate them. MQ2Nav, if we got too close, would click them anyways. Brainiac added detection for "scripted doors", but certain ones weren't detected properly and it'd still click them and screw me up. So, I would have to toggle the activation of doors in general.
So, what happens is if the macro toggles the doors off, then errors out, there's nothing to re-enable the doors. That toggle is only a couple seconds long, so it's a narrow window it had be break in. But, obviously, it can and is currently happening. The new code both fixes the use of the hardcoded relative path, the func that's causing the break, and several things within the toggle func itself.
Trying to run this again for the first time in awhile. Broken .... /mac explore RoF .... Started it in shards landing it CTD .... downloaded latest version
( Running Next ) Ran /mac explore RoF ... in guild lobby and Pok ..... Just stands there and doesn't Navigate anywhere?
( Running Next ) Ran /mac explore RoF ... in guild lobby and Pok ..... Just stands there and doesn't Navigate anywhere?
Attachments
- Joined
- Oct 18, 2013
- RedCents
- 2,776¢
You'll have to run it with Legacy (MQ2) for now. It works as intended there. I, personally, edited my copy of the macro to remove combat and invis potions as I run through the first 15-ish expansions, as stopping to do combat with super grey-con mobs really seemed to slow exploration progress down!
I'm excited, its been awhile since I ran it, and was unsure you were going 'Next' with it. Very happy.
- Seller
- #627
Denethor updated Explore.Mac - An Explorer / Traveler Achievement Macro with a new update entry:
v1.3.0 - For MQ(Next) Compatibility
Read the rest of this update entry...
v1.3.0 - For MQ(Next) Compatibility
Read the rest of this update entry...
- Seller
- #629
DeneCore was updated as well. You need the v1.1.0 DeneCiore
One thing I have noticed every time I run this macro on a toon is that when running the ROK route it skips over EJ, CoM, Trak, Seb and I have to run these manually on the toon. Also the zone line between West and East Cab puts the toon in a forever loop bouncing between the zones. You have to pause the macro in just the right moment to kill the loop and manually zone the toon through then un-pause when you reach the other side to continue on to FoB.
My understanding is you need to grab the mesh files @Denethor has which work with his macro.
I still get Warning: Undefined Variable CWTN used on line [email protected]
/cleanup
if I comment that out, I get [email protected] /call createDeneCoreINI.
/cleanup
if I comment that out, I get [email protected] /call createDeneCoreINI.
undefined variable CWTN warnings in macros are usually going to be boxhud interfering with something, i.e. trying to use a dannet observer on a toon that doesn't have a CWTN plugin loaded.
you'll want to make sure CWTN stuff is set to only be observed for classes that have the plugins. If its a class which does have a plugin but you unloaded it for whatever reason, that'd make it unhappy too.
if I stop boxhud, and remove CWTN plugin could I bypass this?
- Seller
- #635
/cleanup is a documented command of MQ and should not cause a macro to error out. If boxhud or something else is interfering with the MQ-native command, I'd contend that's indeed a problem with boxhud.I can dig in further when I return home next week. I'm currently travelling with one of my children as then undergo medical treatment.
an undefined variable like CWTN almost certainly means he has something trying to access ${CWTN} in some capacity, like boxhud, or mq2melee holy/down or mq2react, and has no plugin loaded to provide that ${CWTN} portion.
the macro parser just spits out where the macro is where it catches that, it doesn't necessarily mean it is a fault of the macro.
I would bet it has nothing to do with cleanup, and it is exactly as @aquietone said
How would I specify Dead Man Floating for my necro it keeps trying to buy potions even if I edit the ini and put Dead Man Floating as the levi clicky?
- Seller
- #639
Is DMF an AA ability? I thought it was a spell.