New Findings.

/itemnotify in pack1 0 leftmouseup ... picks up the whole bag
/itemnotify in pack1 1 leftmouseup ... picks up the item in the first slot of the bag.

I'm still looking for a way to examine bags for what's in the slot, without having to pick it up and examining the cursor. InvSlot[xxx] used to do it in the old version, but no longer works (crashes sometimes).

Any help?

That manual hasn't been updated since 2007. The wiki is the closest thing to a manual you will find outside of reading the source code.

I don't know of a better way that works for RoF2. What are you doing with the data? Have you tried "/output inventory"?

It seems hard to believe that the ability to see the ID number of an item in pack 1-8 can not be done anymore on RoF2. For example, if you wanted to see the first vacant slot in your bags ... no way to do it anymore that I can see.

The InvSlot function was really really useful in the UF client and build.

/echo ${Me.Inventory[pack1].Item[1].Name}

Mea Culpa. I played around with ${Me.Inventory} before but couldn't get it to work. In RoF2, items can have items.

Grumble ... You're the one!! Works great. I knew there had to be a way.

Thanks again.

Grumble. Trevious mentioned earlier that what's missing in the build for RoF2 is the guild/bank/bazaar interfaces.

I tried the FindItemBank[xxx] function and it crashes the client. Am I correct in assuming that ability to count items in the bank is no longer possible on this build? Or has it been replaced with a more viable function?

Thanks again for your support.

Correction. The crashing function is really "FindItemBankCount" and not "FindItemBank".

Under RoF2, Bank items work similarly to Inventory items. Simply change Inventory to Bank.

See Inventory.mac for an example.

I don't see a simple shared bank entry.

Raelin, I added two gold months to your account, you should be able to download the ROF2 gold build now, which should work until I get a chance to figure out what's up with it. Sorry, I've been distracted with school woes.

I have been having issues with the ROF2 classic build as well. Finditembankcount and /updateitems crash the client. I have disabled all plugins and the problem persists. Are there any workarounds I should try?

At the moment, I don't think either command works on RoF2. Any workaround depends on how you use those commands.

Do you need to know the exact count of an item in the bank or do you need to know if at least one is present?

The /updateitems command was disabled because it's purpose was no longer needed. If you want a list of items on that character, try the built in EQ command: /output inventory (and look in your EQ folder for the resulting file).

Thanks for the reply grumble. I was just trying to get a HUD working that tracked the number of certain items on person and bank. I just removed that section of the HUD for now.

I tried /updateitems because I thought it and Finditembankcount both used ItemDB.txt and I was just trying to track down the problem.

May I suggest printing a message saying that those functions have been deprecated or WIP on ROF2 instead of just going down a bad code path and crashing the client when they are called? It took a while to figure out what in the HUD was causing the crash.

Also have you guys thought about putting the source on like GitHub, my favorite, or the like? Working from a public repo would make packaged source releases unnecessary and ensure you were always in GPL compliance without effort. There would also be the obvious benefits of branches, pull requests, issue tracking, etc. Which might encourage getting more contributions outside of your core team. I for instance would try adding my suggestion from my previous post and submitting a PR for you to review.

Thanks for all your hard work.

It's been considered, and it most certainly would increase participation in the development process, but were less focused on Devs and more focused on getting pre compiles into the hands of average (read, non-Devs) players hands. Because of that goal, I'm skeptic that it would increase activity too terribly much though, and In all honesty, if I put a repo up I'd probably be really rotten about keeping up with it. Right now it's just me and Grumble. He really has a great idea of all the ins and outs of the bigger MQ picture and how people use it, and I have no earthly clue what people do with and I haven't played for about five years, I just really enjoy writing the code. (I have to ask him questions in the private chat forum about game-play all the time. Just the other day he set me straight on Berserkers not being hybrid casters). So, at the end of the day it's mostly just me coding. There is a developer forum, and sometimes people post code or ask for help (which I'm happy to give) but its pretty rare to have C++ developers around. I assume most of them maintain their own code-base. That makes it sound like I'm lamenting that fact, but I'm pretty pleased that so many non-devs are getting to enjoy MQ. I'm rambling. I'll add you to the dev forum; if you do have submissions I'll merge them in. I'm relatively quick with plugin updates, but a little sluggish with MQ2Main fixes.

Leviticai,

Can you email me your /MQ/Assembly log.txt and your /EQ/logs/debug.dmp

Debug.dmp should contain your most recent crash, so this'll only point us to one of your crashes; we'd need a seperate dump file for the other one.It's also important that you're running one of our builds. If it's your own build the debug dumps offsets won't match our symbol files.The assembly log will help me be sure that I'm using the right symbol files.

Please keep in mind that the debug.dmp may contain information about your workstation--nothing world shattering though. So, if there are privacy concerns, don't send it. I won't share it with anyone though and I'll delete it when I'm through.


Mqemulator at gmail


EDIT: until recently I wasn't aware that EQ did it's own minidump, so I didn't know troubleshooting like this would be easy. I was actually writing a plugin, MQ2Debug, which was going to capture crashes and do a minidump. I staged a crash and gave it a shot, but the stack trace didn't look right. I decompiled eqgame.exe and went to the location the stack trace pointed too and I found a bunch of code in eqgame.exe that did it's own minidump. That pointed me to the debug.dmp in the eq directory. I guess their minidump beat my minidump to the punch, so my dumps stack trace wasn't of the error, it was of eqgame's own error handler.