When you say "manually execute the client" do you mean:

1. Double click your character specific EQ shortcut - Becken.lnk, etc - and let MQ2AutoLogin continue.

2. Double click your EQGame.exe shorcut and manually type in username/password and manually select server/character...

3. Something else.

Something to try...

Open your EQ folder, open dbgstr_us.txt and search for 5362. Post any lines associated with that number. Do the same with spells_us.txt. And eqstr_us.txt. Look in dbg.txt (in EQ/Logs) and look for 5362 there as well.

On second thought... if the string is missing, it probably won't be in one of those files.

Alrighty... found the issue and it was all me. The target directory was correct, but the "Start in" was not. It was pointing to the UF directory, not the ROF2. /facepalm

Autologin is working just fine. Thanks for fixing this and all the help along the way.

Glad you got it working.

From RoF2 eqstr_us.txt:



Haxors being detected and shut down!

That sounds like a custom UI issue based on the error info. Are you running custom files for dbstr_us.txt and/or a custom UI on RoF2? I haven't seen any fully supported custom UIs for RoF2 yet (though I haven't looked too deep into it yet). You may want to try using the default UI for now. It is actually quite a bit more functional and customizable than previous UI versions for EQ.

Also, thanks a ton to Maudigan for working on getting this plugin fixed. It is one of the last major hang-ups that was keeping players from moving to the RoF2 client. There is still more work to be done to finalize the client, but it is quite good at this point.

You're welcome, I should have had it two weeks ago when I fiddled with it; both issues were me missing something simple. Anytime an offset is referenced in ROF forward you need to run it through the FixOffset() function. I didn't add it to the ROF builds because it uses a memory pattern to find the offsets it needs. What I forgot about was it doesn't search the entire client memory, you give it a starting address and a scan length. I didn't do FixOffset() on the starting address so it was scanning a random part of the client. I also missed a memory offset that was hardcoded way down in the code (I was expecting anything like that to be up top as a constant).

That sounds like a custom UI issue based on the error info.

In a way, this is correct. The RoF2 executable was being pointed to the UF folder - including UF default UI.

I have found an inconsistency on the Classic compile with the RoF2 client.

If an item is in the first bag slot in pack1 of your inventory:
${FindItem[itemnamehere].InvSlot} returns slot number 338 whereas slot 262 should be the first slot in bag 1.

${InvSlot[262].Item.Name} will return the correct itemname above.

The Classis compile with the UF client does not have this problem. I.E., both slots resolve to 262.

Is there a fix for this that I'm not aware of? Has this been reported earlier?

This should have been fixed in the March 8 2015 patch but I just tested and I can't get it to work either.

OK. Couple of things....

The inventory system in RoF2 is not the same as UF's inventory system. The 338 number is correct for RoF2. /itemnotify 338 leftmouseup will pick up the item in the first pack, first slot.

Also, InvSlot is deprecated in RoF2 (anything past House of Thule client). Sometimes it's correct but sometimes it's not. It's usually incorrect for anything in bags. ItemSlot and ItemSlot2 are the replacements.

/echo ${FindItem[Diamond].ItemSlot}
/echo ${FindItem[Diamond].ItemSlot2}

ItemSlot refers to the slot id. Legs will return 18. Necklaces will return 5. If an item is in a bag, the position of the bag is returned. An item in the first bag will return 23. The slot numbers are the same as in UF.

If an item is inside a bag, ItemSlot2 will return the position inside that bag. The top left slot starts at 0 and continues normally.

ItemSlot and ItemSlot2 were fixed in the March 8, 2015 patch. Read the associated bug report for more information. However, the fix doesn't seem to work for the Classic build. It does work for the Gold build.

Thanks Grumble. Are there plans for correcting the Classic build for this to work properly? Does the Gold build give extra functionality over the Classic? Maybe I should do some homework and see if I need to get the Gold.

The Classic build should handle ItemSlot and ItemSlot2 commands just as well as the Gold build. The Gold build does provide extra functionality but the extra functionality comes from plugins. Basic MQ2 (EQMain.dll) should be identical between the two builds.

Feel free to download the Gold build and run that to test things out. Gold specific features won't work right out of the box but regular MQ2 features will.

Ok, I now see how that works to find the bag and slot number of an item.

What are the equivalent "itemnotify" statements to "pick up" to the cursor, or "drop" an item off the cursor into a bag slot number? For example, to pick up an item from bag 23 slot 0 and drop it into bag 25 slot 4?

Thanks again for your guidance.

ItemNotify wiki entry.

To pick up an item: /itemnotify ### leftmouseup

If you have an item on your cursor and wish to drop it in ###: /itemnotify ### leftmouseup

The relevant ### may be found by the InvSlot command. If not, a bit of trial and error is required.

edit:
For bag25 slot4, try /itemnotify in pack3 3 leftmouseup. Or maybe /itemnotify in pack3 4 leftmouseup

Thanks Grumble, but still problems.

/itemnotify in pack1 0 leftmouseup ... picks up the whole bag, not just the item in slot 0. Seems like the information after the pack assignment is ignored, and the bag is targeted.

In general, I'm just trying to find a technique on RoF2 build that will let me examine what is in a certain bag location (its name and its ID). The InvSlot[xxx].Item.ID function worked on the UF build with UF client, but it crashes on the Classic RoF2 build and RoF2 client since it is no longer supported. Need a replacement technique.

Also, Is there an update to the manual that shows the "ItemSlot" and "ItemSlot2" uses?

The manual at "http://www.macroquest2.com/includes/wassup/manual.php" seems outdated for these new abilities.