MMOBugs Release 3 Feb 12 - More Information

htw

Developer
Joined
Aug 27, 2006
Messages
13,194
Reaction score
374
Points
83
Location
Albuquerque, NM
I wanted to discuss some of the bullets from the update I did today, and the changes I made, to perhaps clarify for people what they are for. Hopefully it will answer your questions, but feel free to discuss or question all you like in this thread.

  • Updated to core 20120203 for LP4 scan fix
Xeniaz reported that from looking at LP4, that it is enumerating processes, scanning the modules, and at least has the capability to look for certain modules (dll files, i.e., plugins) and potentially report it back to SOE. Has this been happening? I don't know yet. I will try to get to it soon, to break it down, and analyze any communications. I have to assume that dkaa from macroquest2.com agrees at least with the potential, and perhaps even the current use (I didn't see any solid report of it being used yet). Therefore, we have updated our code to include what he added.

LAUNCHING EQ: What this means for launching EQ, is this: MQ2 injectors add a systemwide hook. MQ2Main 'injects', or loads, into every process that starts from then on, from the time you run the loader (macroquest2's, or ours). Normally, it exits and does nothing, if the process isn't eqgame.exe. For non-EQ processes, windows will generallly unload it at some point after that, as it's no longer used by that process (not going into detail on this, or how/why/if, sorry - google it. heh). Now, MQ2Main sees the process is LP4, then it kills that process, to prevent it doing any snooping. So the sequence you would need to be doing, at least for now, is patch EQ if you need to using LP4. Then launch EQ. Then launch MQ2. You don't have to log all the way into game, you just need eqgame.exe to get launched (which I assume uses the login DLL to get you directly to server select - I haven't tried it yet). MQ2 as soon as it loads, will KILL LP4. Other options are still to use the patchme option of eqgame, so a shortcut using that, or wineq2 or innerspace. The comment about an EQ dev saying it would go away - well, we'll cross that bridge when we come to it.

  • Cleanup code automatic for cookies.txt
As there was concern about macroquest2 or mmobugs cookies being in the mozilla\cookies.txt file, MQ2MMOBugs monitors that now - and removes them.

  • Untargetable filtered by default (option to revert in macroquest.ini)
There has been concern that MQ2's target function, which allows you to target any spawn anywhere in the zone, could be a potential for at least flagging for investigation. By default, I have disabled targetting untargetable spawns. If you want this enabled, I included how to do that in the patch message: Before loading MQ2, edit MacroQuest.ini, and under the [MacroQuest] section, add this entry: AllowUntargetable=1

  • Disabled /icamp aliases & INSTANT_CAMP keypress
There has been at least 1 report of a member saying /icamp got him suspended. The server could (and probably does, IMO) easily detect the difference from a client using this to disconnect from the server, as opposed to normal camping, LD, etc. It's now disabled. If you want it, and are persistent enough, you should be able to find how to enable it by yourself. ;)

  • Move functions enabled, use sparingly, and AT YOUR OWN RISK!!
I can pretty much guarantee you are going to eventually get suspended or banned if you use things that 'warp' you. /warp, /sumcorpse, /usemerch, etc. If it warns you not to use it, don't. If you are wondering whether a certain plugin or function uses any movepackets (warps), then ask first, then decide. Don't make assumptions. Small warps or used sparingly might not get you busted, because they will have set some thresholds for detection, but I wouldn't count on NOT getting caught using these functions, if you value your account/toons.

  • MQ2AutoForage: Fixed sit/stand code finally, added random timer for sit/stand, max forage time (optional)
The random timer is to make it appear more natural. Between the options I have put in for stop on hail, stop on tell, random timers, max forage, etc. then they really don't have a leg to stand on to try to bust anyone for using this. I know there has been some questions regarding it, I'll just tell you, I use it all the damn time, and have had zero issue. However, I do leave the safety options enabled. Also of note: The max timer is how long to autoforage once you start it. For example, you could set it to 360 minutes (6 hours), and go to work. 6 hours later, it would stop. If you leave on the stop on hail and stop on tell, it'll stop if those happen. If you don't care, and don't want it to stop based on max timer, set it to 0.

  • MQ2MoveUtils: Added waypoint usage
This will use the same waypoints.ini that MQ2MMOWarp uses, and in the same format. The function to manipulate waypoints is also included (/way). You will see headings in there if you look, but no worries - it does not use any headings. How X, Y, Z are used by MQ2MoveUtils is entirely up to that plugin and its design.

  • DX9 fix from Xeniaz moved from MQ2EQBugFix to MQ2MMOBugs
If you use our compile, it's automatic. Everybody should be using this. Enough said.

  • Added max distance target options for /target and map click target (use /mqrange to control)
Do they check this yet? Not that I am aware of. EMU servers have used this kind of thing a long time, though. EQ live *could* implement some sort of check, if they wanted to take the time to code it, tune it, etc. - and not catch up false positives. These 'distance options' are basically a reasonable range you could actually target a mob. You can set it lower, or higher, or even disable a distance check altogether, so you can target anywhere as always. Entirely up to you. In game, type: /mqrange. To disable range checking (for map or tar), set the value to 0.

  • Added option to not use MQ2 /target function (MQ2 /target is used by default)
This relates to the bullet above this one. If you want to use the EQ client /target function directly, with no options (such as spawn search, distances, etc.) or modification, you can do that now. As above, that's controlled via /mqrange.

  • Re-enabled right-click wiki for MQ2PluginMan, but uses external browser, EQ's is never touched
They don't look at your system browser or cookies. There is no risk to click a plugin name now, as it will bring up your system browser (IE, Firefox, Chrome, whatever) and take you to that wiki page. The in-game browser will never know, or ever be used any longer, other than by EQ itself (such as the welcome screen)



Hopefully that will answer a few of your basic questions. Don't hesitate to post whatever the hell you want - this is not a flame or argument thread. I'll just simply delete posts from people being assholes (ok, I'll delete any asshole post by myself also, promise!). Also, if you have any knowledge on any issue, whether new, or a correction to anything I've posted here, please feel free to share.

htw
 
Last edited:
Htw,

For WinEQ2, I'm guessing we should turn of LP4 before we load an instance of WinEQ2?

I have been hesitant to patch Everquest for upgrade to LP4, but going from your above statements, I'm assuming we can turn off LP4 then just load up WinEQ2, and that should prevent any type of monitoring of the eq instance once mq2 is loaded yes?

Just trying to be extra careful.
 
Htw,

For WinEQ2, I'm guessing we should turn of LP4 before we load an instance of WinEQ2?

I have been hesitant to patch Everquest for upgrade to LP4, but going from your above statements, I'm assuming we can turn off LP4 then just load up WinEQ2, and that should prevent any type of monitoring of the eq instance once mq2 is loaded yes?

Just trying to be extra careful.
Yes, that's fine. If you don't shut down LP4, MQ2 is just going to kill it, though. So it'd end up being the same.

Just remember WinEQ2 wants to see MQ2 loaded at time it launches itself, so assuming you are checking patch, run LP4, then shut down LP4, then run MQ2, then run WinEQ2. If not checking for patch, just skip the LP4 parts, i.e. Run MQ2, Run WinEQ2.

For Inner Space, the launch order of IS & MQ2 doesn't matter.

htw
 
What I've been doing is:

  1. Patch with Launchpad
  2. Close all Launchpad Products
  3. Launch MMOLoader (patch, if needed)
  4. Launch WinEQ and EQ within WinEQ

Just wanted to make sure that was cool. While I was responding, you answered. I'll just keep what I've been doing then.
 
MQ2AutoForage: Fixed sit/stand code finally, added random timer for sit/stand, max forage time (optional)
Is there a command for the random timer for sit/stand?

And curious in future if its possible to change when forage button is clicked/activate from a random interval between 1.5 min to 4.5 mins (think each forage interval is ~1.5 mins)

I'm wondering if they are tracking a threshold of # of forages done within a certain time period or a threshold of # forages done over a given login or 24 hour period.

Also, I'm guessing its safer to not destroy items?
 
Last edited:
MQ2AutoForage: Fixed sit/stand code finally, added random timer for sit/stand, max forage time (optional)
Is there a command for the random timer for sit/stand?

Not currently. I could add that, so I'll put it on the list. Right now, it generates a random number of seconds I programmed in. Will allow that range to be configured next release.

And curious in future if its possible to change when forage button is clicked/activate from a random interval between 1.5 min to 4.5 mins (think each forage interval is ~1.5 mins)
Right now, it will click it pretty much when it's ready. It won't be EXACTLY as soon as it's ready, but usually within a second or two. I will add a configurable delay option between forage attempts.

I'm wondering if they are tracking a threshold of # of forages done within a certain time period or a threshold of # forages done over a given login or 24 hour period.

Also, I'm guessing its safer to not destroy items?

There is a random delay between keeping or destroying items. It really makes no difference which way you have it set for various items.

htw
 
would it be possibe to get a copy of the compile before this most recent patch? This broke my bots and I cannot figure out what else to fix.
 
Last edited:
/call Cast ${ItemName} item crashes almost every time.
/call Cast ${AAName} alt and /call Cast ${SpellName} are fine.
 
GF got a new laptop and I installed dx9. Ran patcher, loaded to toon select, closed LP, loaded mmobugs. MMO shows as loaded but locks up eq. Not using IS or WinEQ. I can if that will get past it, but anyone else have this issue?
 
GF got a new laptop and I installed dx9. Ran patcher, loaded to toon select, closed LP, loaded mmobugs. MMO shows as loaded but locks up eq. Not using IS or WinEQ. I can if that will get past it, but anyone else have this issue?
What plugins loading?

htw