Xenithar

That is how group loot works. One member is chosen to loot the corpse. Any items of green or better (unless you changed it) are rolled on by everybody. The next time a mob dies, somebody else gets to. Think of it like this. You have three players. Player A, B, and C. You kill a mob, player A is allowed to loot. You kill a mob, player B is allowed to loot. You kill a mob, player C is allowed to loot. You kill a mob, player A is allowed to loot. This repeats over and over again. If there is a green, blue, purple, or orange item on the corpse the entire party rolls on it and the winner gets it.

You should try it on a fully optimized Gentoo system. I replaced Debian Wheezy with Gentoo on my work laptop. I set the USE flags and such for my hardware. My GOD it is faster! I am going to be getting to my new Xeon server this month and I intend to put Gentoo on it also.

I forgot I was on Linux for a moment. Linux runs WoW perfectly. Had to grab the client and add my home IP address (hostname), but it worked. I still cannot see my servers in the realm list, but I manually edited the config and added it. Anyway, it appears to work. I will have my fiance and mother test also. That WILL be tonight or maybe even tomorrow.

I am trying to remember if the murloc pet was account or character bound. I seem to recall having it on more than one character, but my memory may be incorrect. The only problem I see here could be the adding of all those codes to the DB. If I add a code and a player uses it, is the code removed from the DB?

I can try it tonight. I am not at the gaming rig right now. I will test though and get back to you.

That is how it worked on official. If a friend and I are grouped and I killed a mob that had an item he wants, I could right-click the corpse and look, then close the loot window and he could then loot the corpse. It seems to be working in R20 on my end.

That is actually kind of cool, Reaper. Would these be account-bound like on Blizzard or character-bound? The CE pets and things are account-bound and every character gets an email thanking them for the CE with the items as attachments when they first login.

The way it worked on official was that each worse case had less health, but I believe the rate of loss was the same. The critical soldiers just had little to begin with so you had less time in that essence, but it was not hard to do. I have redone this repeatedly now for testing and it IS possible to save them, but the problem then is that even after being saved, they take a few steps and die. After being saved the decay should stop. Oh, and to save them you have to start bandaging them as they fade in. If you do not start until they are solid, you cannot save them at this point.

Well since we're on unofficial, maybe we should add flags t the account DB or something that define things like special edition. I bought the collector's edition of everything up to and including Cata, so when I log into the game with each character, I have to give myself those pets (Diablo, Onyxia Whelp, etc) each time. We could add a flag for CE to the account table. If it is 0, no CE. 1 would be CE, and upon first login the character gets the email with the pets and such. We could take it a step farther and do a flag-based entry of integer type. [list] [*]0 - Normal Game [*]1 - Collector's Edition [*]2 - Allowed to get Murky [*]4 - Allowed to get costume [*]8 - Allowed to get mount [/list] You could combine any of those and when the character walks up to the NPCs and chats he will either get the item when selecting it or get a message that he or she wasn't really at Blizzcon, or whatever. You could even extend this list for the extras that may come in future expansions. No code needed!

I just did this with my shaman. Epic fail. It kept wanting to give me those critical patients. I lost fast. I even had some stand up, thank me, run two or three steps, then die. After being healed the drain should stop, they should run outside and despawn.

It isn't game-breaking however, so this should not be a top priority. It should get some love though, maybe in R21.

Still happens. Command: server shutdown 10 [code] Aura 17 now is remove mode 5 [Thread 0xb20f1b70 (LWP 5809) exited] [Thread 0xb6e4db70 (LWP 5805) exited] [Thread 0xb765eb70 (LWP 5804) exited] Halting process... [Thread 0xb664cb70 (LWP 5806) exited] Program received signal SIGPIPE, Broken pipe. 0xb7fe1424 in __kernel_vsyscall () (gdb) backtrace #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb77d42eb in write () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #2 0xb7b7cead in vio_write () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #3 0xb7b6b00e in net_real_write () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #4 0xb7b6b268 in net_flush () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #5 0xb7b6b580 in net_write_command () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #6 0xb7b68598 in cli_advanced_command () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #7 0xb7b65381 in mysql_close () from /usr/lib/i386-linux-gnu/libmysqlclient.so.18 #8 0x08978d3b in MySQLConnection::~MySQLConnection (this=0xafded70, __in_chrg=) at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:80 #9 0x08978d8d in MySQLConnection::~MySQLConnection (this=0xafded70, __in_chrg=) at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:81 #10 0x0897379a in Database::StopServer (this=0x8df92e0) at /home/---/zero/src/server/src/shared/Database/Database.cpp:158 #11 0x08978c4f in DatabaseMysql::~DatabaseMysql (this=0x8df92e0, __in_chrg=) at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:65 #12 0xb769122f in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #13 0xb769129f in exit () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #14 0xb7678e4e in __libc_start_main () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #15 0x085ac9d1 in _start () [/code] Command: server exit [code] mangos>server exit CLI command under processing... Exiting daemon... Command: server exit [Account: 0 from Console] mangos>[Thread 0xb18f0b70 (LWP 24678) exited] Network Thread Exitting Network Thread Exitting [Thread 0xb10efb70 (LWP 24679) exited] [Thread 0xb08eeb70 (LWP 24680) exited] [Thread 0xb20f1b70 (LWP 24677) exited] [Thread 0xb6e4db70 (LWP 24674) exited] [Thread 0xb765eb70 (LWP 24673) exited] Halting process... [Thread 0xb664cb70 (LWP 24675) exited] [Inferior 1 (process 24671) exited normally] [/code] This seems to be normal now. Using exit works, using shutdown fails. I would think that "server shutdown " would wait X seconds and then simply call whatever method exit calls. Apparently this is not the case.

I can do a build shortly. I will report back when complete.

I can reproduce this in the current R20 build. Changing status to confirmed. Happens in 32bit and 64bit builds. Internal ACE will not build mmaps generator. External ACE is fine.

I had no trouble with this on Debian a week or two ago. I will try this right now and get back to this ticket ASAP. *UPDATE* I starting the build process using this configuration. [code] cmake .. -DDEBUG=1 -DUSE_STD_MALLOC=1 -DACE_USE_EXTERNAL=0 -DBUILD_TOOLS=1 -DSCRIPT_LIB_SD2=1 -DSCRIPT_LIB_ELUNA=1 -DCMAKE_INSTALL_PREFIX=/home/---/zero [/code] I will respond when finished. This is Debian Wheezy (7.7).

So AHBot will be a submodule now, like Eluna and SD2?

Seems like the opposite of the current bug in Zero. In Zero, it buys your stuff, but doesn't sell anything. Also, this should be a bug report, not a feature request.

Alright, I have a ticket open about the broken pipe, so we can worry with it there. I will be testing server shutdowns shortly.

This hasn't worked for me for months. I assume it is due to the major overhaul R20 is getting, but it does not work here either. Horde in Horde cities nor Alliance in Alliance cities. I just rebuilt last weekend. I can build again if needed, otherwise I will build again this weekend as scheduled.

I will try this evening. I can tell you that the timed shutdown command causes a broken pipe EVERY TIME for the last two weeks. I will test all shutdown commands tonight on Linux.