Schmoozerd

perhaps then add a assert there, to catch earlier bugs easier?

if you just multiply by 100 you don't fix the bug, but move it out of sight. our main line of calls is: in Unit::DealDamage : pVictim->AddThreat(this, float(damage), (cleanDamage && cleanDamage->hitOutCome == MELEE_HIT_CRIT), damageSchoolMask, spellProto); m_ThreatManager.addThreat(pVictim, threat, crit, schoolMask, threatSpell); float threat = ThreatCalcHelper::calcThreat(pVictim, iOwner, pThreat, crit, schoolMask, pThreatSpell); where Unit::ApplyTotalThreatModifier(float threat, SpellSchoolMask schoolMask) { if (schoolMask == SPELL_SCHOOL_MASK_NONE) return threat; SpellSchools school = GetFirstSchoolInMask(schoolMask); return threat * m_threatModifier[school]; } So, _if_ 1 threat for 1 damage is correct, then our system should be correct at all Exceptions should be carefully examined (ie whitedmg without any special talents) - and as far as I see the only place for problems could be m_threatModifier[school]

I personally prefer to keep the "master" brunch clear, and always work in different branches, in this way, I always can merge master to my dev-branch(es), and see conflicts, and abort if needed

I think there is nothing wrong to start a new thrad, as the code has been changed quite a bit since the aura holder system, and now there are many crashes fixed, and (hopefully no) new crashes

I think the community needs both happy devs and happy admins, so I can agree that in this case (many problems since longer time) crash fixing should be done "soonish", however asking for it, (or even the will to fix it) doesn't alone solve the problem. All we can do is try to reproduce the crashes, provide crashlogs - or try to really understand what is happening, to find out which places in the code are bugged.. perhaps laise has a "test-suite" (or could provide one without too much effort), to log the important aura related events, such that you admins could provide a large-scale stability test, that we might get more insight what's wrong in the code at all..

client patches and updates can be obtained from blizzard, or over some of the mirror sites

teach the tanks to play! I never had any serious problems at all with my test-warrior

do you suggest to remove the chain of DealDamage, remove auras at all? sorry, as I don't know the code well enough, for me it was natural to modify these functions. If you suggest that it should be handled entirely different, I won't be able to give serious help about this issue ;( sorry for that, hope you will have the time and motivation to implement it at all (or likely even slower to explain what needs to be done)

yes, typo ;( thanks for spotting

The other fields have no meaning. This Action can only be used with source=Unit, and target=Gameobject and it does nothing more than (Go)target->Use((Unit)source); afaik it is for internal use only.

sd2 has not yet supported many wotlk instances. If you want this to be changed, go to SD2 forum and try to help out there

so, why didn't you do it already?

hm, I see, didn't take a close enough look.. this suggests that we possible need to filter the targets to only hit feugen & stalagg - but then I am very unsure about the logic how to handle it best at all

if it can be handled in core, it should be handled in core btw - I see no reason to check for the NPC-entries at all. all you need is to check for getVicitim (the spell is only casted from feugen to stalagg) then I think it would be best, if you started a new thread for your patch I have a few things on my todo list, and I think then I will take a look at my solution for Polarity shift, and bring it up here too

I see no problem with a server-side implementation: cast 54517 from feugen to stalagg effect0: target->getVictim->cast(caster, 54485) effect1: caster->getVictim->cast(target, 54485) swap_threat(target->getVictim, caster->getVictim) So I cannot see any reason at all to implement this with sd2-dummy Ofc this would need a few more checks, but that is I think reasonable

What bug does the patch fix? What features does the patch add? * Add additional error.output for reference with loot-condition (currently not allowed) * Insert a missing return, to correctly skip wrong reference-entries For which repository revision was the patch created? 10458 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. no Who has been writing this patch? Please include either forum user names or email addresses. me, thanks to crackm who spotted the missing return The reference with condition check is placed this early, to skip creation of possible unneeded condition-entries Patch manually addeted, as the first part is already in master (or at least similarily) diff --git a/src/game/LootMgr.cpp b/src/game/LootMgr.cpp index 32fc76e..416484e 100644 --- a/src/game/LootMgr.cpp +++ b/src/game/LootMgr.cpp @@ -299,8 +306,11 @@ bool LootStoreItem::IsValid(LootStore const& store, uint32 entry) const else // mincountOrRef < 0 { if (needs_quest) + { sLog.outErrorDb("Table '%s' entry %d item %d: quest chance will be treated as non-quest chance", store.GetName(), entry, itemid); - else if( chance == 0 ) // no chance for the reference + return false; + } + if (chance == 0) // no chance for the reference { sLog.outErrorDb("Table '%s' entry %d item %d: zero chance is specified for a reference, skipped", store.GetName(), entry, itemid); return false; In: [11830]

actually no. The DB-providers like UDB, YTDB, PSDB provide content for the world-database, this has no impact on the character DB

skill it in your talent's tree

it's a bit messy, but http://www.gnu.org/software/make/manual/make.html#Conditional-Syntax could perhaps help for this

Hi, I suggest to add two new Links to wiki and lighthouse in this nice light-blue line where we have 'Forum', 'What's New?' Especially as there is effort to get the wiki as base for documentation there will often be need for posters to link wiki-content, and this would be easier with a big link

I am not sure what the bug really is perhaps it would be correct to not only setincombat with, but to do some checks like if (target->CanInitiateAttack()) target->AI()->StartAtack(this);

hm, so there should be a change of description of the core-mod section? "Discuss code, review existing code, submit patches, or write implementation drafts for new and missing features." and, if we intend to use 3rd party for projects that mainly use mangos databases/ code core-mod for modification with custom goal then I think we need a new place where projects are started, that are targeted for svn (non-custom) and vladimir, I know that the core mod isn't the correct place to start projects, but many of the bigger projects that are now in svn from the last months have been started and developed in there

a big difference is, what kind of bug you want to report: Reporting something like Spell xyz is broken in rev zyx is better handled in a bugtracker, but reporting something like clerarly adresses not only devs but also many users for some input, discussion etc, so this kind of 'problem' is better reported in an environement where it can be discussed So - as long as the Devs accept both systems, I think it is better to have both. Of course it might be a cool thing if the Lighthouse tracker would be more integrated (especially search) into the forum (with same functionality)

Is it intended to move "custom" patches from CoreMods to here - and return CoreMod-section to the development of new features?

I think not, the AI only needs to know, if a enemy is "reachable" The one enemie case is (main points): MoveLoS -> AttackStart -> MoveChase -> Creates the path SelectHostileTarget -> AttackStart For multiple enemies case I suspect the most generic case will be: MoveLos -> AttackStart -> MoveChase -> Create path (to first victim) collect more enemies SelectHostileTarget: check if target is 'reachable' before selecting it, if not, try the next target. if no target is reachable: select targets that might be reachable for a spell (like fireballs) (I think such a spellId should be taken from DB) if no targets available, select most-aggro enemie, start evade mode timer, perhaps chase to the nearest place possible