Lynx3d

49152 is a generic spell that does exactly what wowhead says:

Apply Aura: Mod Damage Done % (1)

Value: -10

If we'd have to implement each of those ~50k spells seperately, we'd be nowhere near a working server...

Hm you know what, I blame that on autohell, I mean, autotools. They kinda only work flawlessly when they're in the mood to.

I had the same problems when --with-std-malloc, then after messing with a lot of things it suddenly worked and i can't reproduce the problem anymore. Try with a clean build directory.

But Make and me will probably never become best friends, and since Cmake also gives us the "pleasure" to use Make, I'm currently having a little side-project, creating a waf setup for mangos...

Can't help with behaviour on retail...

but you can't seriously be concerned about the overhead of making a function virtual when it calls some of the most expensive core functions

I have my doubts about adding such expensive checks in this way.

For example, IsInWater() is effectively cached for Players from HandleMovementOpcodes().

But here you will repeat identical vmap queries for every unit that tries to attack the same target.

I think we should start this from the other end, improve movement related code first, cache relevant data and then let AI decide if it can reach a unit or not, otherwise vmap queries will just explode.

For example, won't you get the information as by-product when trying to construct a movement path with mmaps anyway?

Oh come one, stop asking for support on custom repos...and not even mention it in the first post.

TBB works fine here on Ubuntu, and 'ldd mangos-realmd' clearly shows it links to the installed lib properly:

libtbb.so.2 => /opt/mangos/lib/libtbb.so.2

libtbbmalloc.so.2 => /opt/mangos/lib/libtbbmalloc.so.2

So unless you can give details about a clean MaNGOS setup that does not work, i consider this not MaNGOS' issue.

NickoNiklas says it, don't really have to add anything

Yes quite useless indeed.

Read the guide on how to post a proper bug report...

base 10 logarithm is written as lg usually, not log...small but important difference

Problem fixed in [10364]

'Fleeing' is a process of a mob calling for assistance from other mobs, it has nothing to do with Aura::HandleAuraModIncreaseSpeed. (or prove me wrong)

Actually, Judgement of Justice also prevents targets from having increased movement speed (sprint, travelforms etc.).

This however is a unique effect of JoJ and does not apply to the Glyph of Rake according to the wowhead comments...

Err sorry, that one was a mistake in a commit i just did, should be fixed now...just a stupid oversight.

Retry with [10348]+ please...

Well that's another one though ^^

At least to me it looks like a totally different place...somewhere ACE related.

in src/shared/Util.cpp:461

@Schmoozered: yea basically this "fix" removes such auras from m_modAuras even though they may (or...if working correctly, will) still be present in a SpellAuraHolder...

If i'm not really mistaken, same harmful spells from different casters stack in most cases...

Should be fixed in [10345], at least i am not able to gain unlimited armor anymore on any shapeshift combination, and it also works in caster form now, as it should.

Well i'm afraid it's not THAT simple

Note that the spell description explitily says that it is also active when not shapeshifted.

Required some larger tweak in Aura::HandleShapeshiftBoosts() to apply/unapply as required, because you cannot generally say it is unapplied on shapeshift or not, need to check which form you apply/unapply.

Hope i got it right in [10345].

Hm...from http://msdn.microsoft.com/en-us/library/1kt27hek%28VS.80%29.aspx

Note

To ensure that there is room for the terminating null, be sure that count is strictly less than the buffer length and initialize the buffer to null prior to calling the function.

So, despite microsoft claiming this is the ANSI compatible version and omits it the argument description of count, does this mean the buffer has to be LARGER than count?

Gotta love those MS dudes...to "fix" this they added _vsnprintf() which duplicates the "count" argument so you can give it the actual buffer size -.-

Try with:

size_t temp_len = vsnprintf(temp_buf, 32*1024-1, str, *ap);

Lunx3d, here target->AddAuraToModList(Aur); it's ok to have same aura added 2 times or more?

Why not?

I really don't it's the task of this function to decide whether auras stack or not.

Basically, this is a very low-level function, and using it directly should be avoided wherever possible. And there's infact only two places outside AddSpellAuraHolder() where it is used, the one just fixed, and Creature::LoadCreaturesAddon() which might need the same fix actually...

Or maybe not so dirty hack. But as i think, the fix is in the place where is the real reason of problem.

In GridNotifiersImpl.h in function void MaNGOS::DynamicObjectUpdater::VisitHelper(Unit* target)

For the freeze with Desecration + Shapeshift, this is definitely the place where it goes wrong yes.

It has nothing to do with AuraHolder functions going wrong, problem is that multiple DynamicObjects from different effects of same spell have to share SpellAuraHolder in current code design, so this manual fiddling is necessary for now.

You cannot just delete the whole holder, because if spell have more than one effect, second effect will erase first effect etc...

Fix for this specific problem added in [10335]

maybe this is done by some "worldwide constant", which is affecting every way reputation could be gained: commandation badges, daily quests, ... and the reputation is not changed on every single item/quest. Maybe adding something like ReputationMultiplier could help solve this issue. Use of some kind of this constant could explain, why description of effect and description on item is different.

We (well mostly NoFantary) pretty much came to the same conclusion and implemented it, finally

Apparently Bl... has some big tweaking know to scale reputation globally, now implemented in reputation_reward_rate table.

What the dummy effect does is unknown, but i doubt it has anything to do with global reputation rates, because Argent Dawn Valor Token does not have a dummy effect yet it gives double the rep. in its base points now, as does every kill and quest.

Rates for spells implemented in [10327].

Fixed now in [10327] in more generic way with new reputation_reward_rate DB table.

Also Argent Dawn Valor Tokens were affected by missing "hidden" rates.

Any particular reason why you want an i7 930 over and i7 860?

The 860 has higher turbo frequencies and has much lower idle power usage for otherwise comparable performance, the only reasons to get a 9xx CPU would be overclocking and SLI (or Crossfire or whatever AMD calls it again)...

Otherwise, according to AnadTech reviews the i7 930 and Phenom II x6 1090T have similar enough cost, performance and power usage to make it pretty much a matter of preference if you go AMD or Intel...

it should be percent from caster's spell damage, not percent of damage done.

No, definitely not.

If i may just quote wowhead:

"cause the target to burn for an additional 40% of your spell's damage over 4 sec."

"spell's damage", not "spell damage".

About the basepoints being wrong...

Why would DoT damage be handled per tick?

EDIT: Take a look at Deep Wounds proc handling in core. The basepoints are not handled per tick.

What i see is:

case 12867: basepoints[0] = int32(weaponDamage * 48 / 100); break;
(....)
// 1 tick/sec * 6 sec = 6 ticks
basepoints[0] /= 6;

That looks damn much like damage per tick to me...

Hm...my mage does pretty much damage from ignite proccs

I'd say current code is correct, because ignite is a DoT, and basepoints is the damage per tick.

MaNGOS does not provide any "world" related database content and hence is not responsible for this kind of problem.

File a bug at the project site of whichever database you are using.

*cough*

Did you try removing Aura::IsDeleted() and recompile? Notice something? ^^

Shouldn't be a list of pointers be sorted, and hence as a better searching (like O(log n))?

It's only a garbage collection list, so it's not meant to be searched. If you sort it, inserting goes from O(1) to O(log n).

Hm a few more exentsive comments:

-Use a vector for bag slots, instead of a simple array ("more" C++)

Debatable if it's really worth it in this case, just adds additional indirections for marginal potential memory savings...and you still use MAX_BAG_SIZE in any case instead of actual bag size, so no win here.

-Use of uint8 instead of uint32

Another myth from god knows what times of early computer history is that "samller int types are faster", with current CPUs you can at worst even hurt performance when not using native word size (32 or even 64bit these days) because memory subsystem is optimized for memory alignment in multiple of its native word size. Also, for examble GetBagSize() returns uint32 anyway, so your uint8 is widened anyway to compare it to the return value.

-Add comments for each function

If i'm not mistaken Vladimir said trivial documentation such as

"@param slot The slot where the item is"

"@param limitedCategory The limitedCategory to look for"

is not desireable, function and argument names shall make such documentation needless, that's what is called self-documenting code.

So only add additional documentation to things that actually need it.