Lynx3d

so you don't use core dumps anyway...and i have no idea why you are running mangos in gdb twice in the loop, or why you set the date before running it...

Need more information...which method are you using in the first place? You can't force GDB to do anything if it has no input...if you're using core dumps, make sure they are actually created, and have expected names. check ulimit and /proc/sys/kernel/core_pattern first...

Also, GNU sed can process in place (with optional backup), no need to move around files But for some reason, trailing white spaces keep coming back anyway, i start to believe that getting rid of them is a futile untertaking

Windows actually still divides virtual address space 2GB/2GB by default from what i can find out, and changing it to 3/1 requires tweaking of Boot.ini (XP) or with BCDEdit (Vista/7), and the binary you run needs the "large address aware" bit set (special linker option) so the process will really get 3GB useable address space...hence, somewhere between 1.5 and 2GB used memory most applications will crap out without tweaking. You can find many discussions on the web of people having trouble with large data sets in Photoshop, CAD programs etc. since many software providers were slow on migrating to 64bit.

Startup errors should be gone with [11036], at least if you didn't have any custom data in there...

This is pretty much nonsense on any modern OS (since VAXes) thanks to virtual memory. God knows what really goes on in windows universe I never saw allocator throwing anything on normal usage. But, then again, I never run anything that takes over 1Giga memory on windows either. Well sorry exchange "RAM" by "Memory", but it's not nonsense. Virtual memory doesn't help with the fact that you eventually run out of contiguous 32bit addresses to allocate a memory chunk, virtual or not.

Well operator new[] followed by an exception means most likely out of memory Out of available contiguous addresses, more precisely, which on 32bit windows (without tweaks) can happen when the process uses about 1.5GB RAM already...

Sorry for taking so long, but i had to investigate why the existing bonus threat from spells like warrior shouts didn't work at all, and while writing a fix i noticed there's even more wrong in threatAssist, basicllay due to a false assumption, self-healing/-buffing didn't actually have any effect because it tried to make the player hate the target instead of vice versa Anyway, after all this was sorted, i could finally decide where to best put things, and basically went back to the original suggestion instead of ThreatCalcHelper::calcThreat(), because there's at least one ability (Lacerate) that has a flat threat bonus and a custom multiplier. With some tweaks here and there, accepted in [11023]

I know, just now shows the data has been crap for a long time Currently am trying to fix a remaining problem in a more elegant way... If anyone wants to prepare some more correct spell_threat data meanwhile, you're welcome

Basically, you can't. Because two connections sharing the same IP don't necessarily end at the same person...people sharing the same apartment or even just living in the same complex might use a common internet connection via local router, so you would disallow them to play at the same time. And it still could be tricked by a proxy having a different IP. So IP is at best an indication of multi boxing, but neither a positive nor negative proof for it.

Hm i figured it was because my test char had Improved Frost Presence skilled, but there might be a bug. The aura is applied in SpellAuraHolder::HandleSpellSpecificBoosts()

This in fact already works, it's handled by spell aura 61261. I already tested it after Vladimir pointed me to that...

Oh laise again This one also has been added in [10582] a while ago, among some others...

This one had been added in [10582] a while ago, among some others...why does everyone choose to fix just one random item btw? ^^

This one had been added in [10582] a while ago, among some others...hadn't seen this patch either...

This one had been added in [10582] a while ago, among some others...hadn't seen this patch.

Hm pretty much had to redo the whole thing... I don't think there is a need to override proc flags for any of them. Hunter is not really correct, successfull ranged auto attack has own proc flag, so it should not actually proc on a secific spell. Also the 4P bonus had the wrong wyvern sting spell, it should proc on the triggered DoT, not the sleep part. Divine Plea has some weird family flags, the only unique one is the one in SpellFamilyFlags2, so i took that one. Added in [10951], tested all and hope they work as intended.

I've been working on this a bit lately, but i did a few things differently. - I'm not adding another map, but follow the rest of the code, that is, one table => one map => one (re)load function. - I added support for auto-filling higher spell ranks as in spell_proc_event, i'm just not very happy with the amount of duplicated code yet. Suggestions welcome. - I moved threat multiplication to ThreatCalcHelper::calcThreat(), seemed more logical to me unless we really need different cases for damage and healing. And i think we need a third column for attack power bonus, because non-damaging spells like sunder armor scale with AP. https://gist.github.com/762020

Hope it's fixed in [10944]. Basically re-implemented patch posted by przemratajczak, after some testing the code comments aren't really correct, that packet locks action bars, not clear them. Unfortunately przemratajczak didn't tell original patch author, but whoever it was, thanks for pointing in the right direction. What was happening is that client automatically requests removal of action buttons that have spells you just unlearned.

Some "MaNGOS XC3 EmuTech" that is "supporting" client 13329? Whatever it is, it has nothing to do with this community's supported projects, so i'll have to close thise one. Complain at whomever created this fork (or whatever it really is).

Hm this old and redundant execute code really has been removed lately with proper implementation of aura 262 in [10762]. I start love this stamp... *blam* rejected

*scratches head* I think this one is really outdated now...I ended up with a slightly more extensive "fix" *grabs big "rejected" stamp again*

Oh another proc spell...was added in [10582] *rolls dice again* Because you were too lazy to review your own patches, and i put in a small ICD, you get a rejected as outdated too (just trying to cleanup 'under review' area, in fact...)

Oh really old one... Don't think it needs a custom chance, but spell proc system and possibly dbc have changed since. Fix for internal cooldown is (among others) in [10835]. *rolls dice* Rejecting this as outdated, but thanks anyway for contributing.

Part of [10906], thank you. Just once more forgot to search forum again to give credits to really original author...