ApoC
-
Posts
87 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by ApoC
-
-
Did you check if client crash on some quest? Nofantasy complains that this is reason why poiID is in DB....
-
Shouldn't be there some chance? May be better to implement it in *_loot_template way?
-
Why not implement it into Unit::SpellDamageBonus ?
-
Applied in [9505]
Thank You
-
Applied in [9504], proc flags looks to be already in
Thank You.
-
Applied in [9503]
Thank You.
-
Do we neeed to store in structure PoiId? It is alwayes counted from 0 to X by one. So i think index in vector == PoiId.
-
In
void Aura::HandleAuraDummy(bool apply, bool Real) you are not checking caster pointer to NULL what can cause possible crashes.
-
I'll recheck windows build tonight. I used official release 5.7.5 (not SVN checkout).
-
Please check if you don't have one object (guid) present in more than one pool.
-
ace/config.h is generated from config.h.in by configure script. And config.h.in is generated by autotools, so you should try to do autoreconf --install --force again.
-
I created new patch file. Tested on FreeBSD 8.0-STABLE AMD64 and compilation + linking went well.
-
Patch not working:
1. Missing some files from ACE distribution
2. Messed up Makefile.am
3. Why are everywhere removed version ids from all ace files?
4. Not compile on FreeBSD because of missing hack added by Derex
I am now trying to fix it up
-
Why not loop in Spell::CheckCast aura effects like:
Unit* target = m_targets.GetUnitTarget(); for (int i = 0; target && i < 3; ++i) { if (!m_spellInfo->EffectApplyAuraName[i]) continue; // else const AuraList& aurasByName = target->GetAurasByType(m_spellInfo->EffectApplyAuraName[i]); AuraList::const_iterator it = aurasByName.begin(); for ( ; it != aurasByName.end(); ++it) { // Do your checks here // on first hit return SPELL_FAILED_AURA_BOUNCED } }
And may be better to do this as method for avoid code duplication on more places.
-
But coeff is passed by reference into method and modified. With your change it is not.
-
+ case SPELLFAMILY_DEATHKNIGHT: + { + // Improved Unholy Presence (rune cd spells) + if (m_spellInfo->Id == 2825) + { + AddTriggeredSpell(63622); + AddTriggeredSpell(65095); + } + break; + }
Spell ID 2825 looks weird to me for deadknight Shouldn't be this spell icon check?
-
Applied in [8724]
Than You.
-
Applied in [8713]
Thank You
-
Applied in [8709]
Thank You.
-
Patch applied in [8708].
I changed calculation of 25% health to not use floating point arithmetic and switched from icon check to spell family flag check what is more accurate.
Thank You.
-
Applied in [8693]
Thank You.
-
Patch applied with little changes in [8692]
Thank you.
-
Patch applied with little modifications and cleanup in [8671]
Thank You.
-
Maybe this is solution
diff --git a/src/game/PoolHandler.cpp b/src/game/PoolHandler.cpp index d1f2305..e038add 100644 --- a/src/game/PoolHandler.cpp +++ b/src/game/PoolHandler.cpp @@ -185,11 +185,15 @@ void PoolGroup<T>::SpawnObject(uint32 limit, bool cache) if (limit == 1) // This is the only case where explicit chance is used { uint32 roll = RollOne(); - if (cache && m_LastDespawnedNode != roll) - Despawn1Object(m_LastDespawnedNode); - + if (!cache || (cache && m_LastDespawnedNode != roll)) + { + if (cache) + Despawn1Object(m_LastDespawnedNode); + Spawn1Object(roll); + } + else + ReSpawn1Object(roll); m_LastDespawnedNode = 0; - Spawn1Object(roll); } else if (limit < EqualChanced.size() && m_SpawnedPoolAmount < limit) {
?
Original post by seirge at http://getmangos.ru/forum/showthread.php?p=289270
Yes, i think this solves problem what I also find in pools and what leads to same assert.
[Map/Grid] New Map/Terrain Management System
in ... under reviewOld
Posted
I looked on to the patch (very quick look) and there are some problems i think. For example
If we want to have this working under multithreaded environment it will need real locking (mutex or other primitive) because this and similar operations are not atomic what can cause problems in real multithreaded environment. Even simple ++ -- operations are not atomic! It is good to keep this in mind. It can be solved by some fast mutex or using atomic operations (special CPU instructions for this purposes).