Schmoozerd

thanks Spp for your reply, this is at least an extremely interesting DBC - though it didn't yield the answer I hoped for A bit about understanding DF: - Player A has done an instance, then DF needs to be able to check which encounters are done in the instance? - If a player changes the state of an instance, will there be some need to "notify" DF? - What else is needed as "communication" between boss encounters and DF?

perhaps add overwrite to IsFriendlySpell by Id?

this rather looks like trinity, so (if this is so) do ask there

as patman told me recently about his linking observations, I suggested to modify my spawnSpecial system to support linking for aggro, perhaps later on following, cause it has a reasonable overhead to store such linking...

and anub'rekhan is also a bad example, as these crypt guards should be summond whilest the combat

are there _any_ ids anywhere related to "complete" a dungeon (either opcodes or DBCs) (for Van Cleef I would expect an idea somewhere between 1000 and 3000, not related to the npc-entry)

yes, as I said: affin linear transformation from R^2 -> R^2 all you need is to get the 4 entries of the corresponding matrix (for each map) and 2 entries for the affin part (though infact the matrix looks like (0,a,b,0)) that's easiest handled with flying to {0%, 100%}^2 and then do .gps then only you need to solve a system of linear equations. You can simplify this if you retreat to 2 linear functions, px(y) = a*y + s and py(x) = b*x + t (remark these funny blizzard developer somehow managed to go the y-axis from right to left, and the x-axis from south to north

perhaps a proposal, as you already say yourself that you do have heavy bugs in this patch screw it, and start fresh

that's a bunch (one for one map) of linear transformations, so quite simple

likely missing data in your database. both UDB and YTDB have these instances spawned, so check with your DB provider, doesn't seem to be a mangos (core) problem.

http://www.scriptdev2.com/showthread.php?t=4098 is mainly sd2 code style, and mangos codestyle is very similar. the only main difference is the way variables are named - don't really know if mangos doesn't want m_tName var-names or they are just cause of historical reasons (no one willing to rename everything) not introduced.

bump for rev 10637 - I fixed the long time mentioned bugs and also some bug in the for loop, please take extra care there: -- the for-loop part as in version for rev 10637 for (AchievementCriteriaFailTime::iterator iter = m_criteriaFailTimes.begin(); iter != m_criteriaFailTimes.end() { if (iter->second > now) { ++iter; continue; } ... // Send Fail for failed criterias if (!IsCompletedCriteria(criteria, achievement)) { ... < no break/continue here } iter = m_criteriaFailTimes.erase(iter);

So, yes, it is an AoE spell, but should be applied to friends (not tested what happens)

possible test scenario: use a small river, pet on one side attacking a non-swimming mob, you do dmg from the other side tests: both start on mobs side, you cross to other side pet start on mob side, you not some wild crossing from you

I am not sure, but we not really say that we would want to generate the paths in SelectHostile, we only would want to _know_ if a path can be created - and this is an information that the AI "needs to know" think of a complex situation: let threat list be: normal mob(reachable), taunter1(unreachable), taunter2(reachable) SelectHostile selects taunter1, sets target as taunter1, calls MoveChase(taunter1) MoveChase(taunter1) fails, movement generator either does nothing, or Chases normal mob next tick (though target is taunter1) SelectHostile skips taunter1 and selects taunter2, calls MoveChase(taunter2) MoveChase(taunter2) works, and we have taunter to as target, and as chased mob if you extend such an example further, you see that it might take many ticks till you get correct working mechanics the logic must be: AI: I have my targets AI: which of them can I chase AI: which of the chaseable do I want to chase AI: start chasing MoveChase: Do Chase. as this is very ineffective, we start the first optimation, which is also still very logical: AI: order targets along preference AI: check if reachable till found a reachable target AI: no reachable target found: do something cool (evade, return special value in some cases) AI: start chasing reachable target MoveChase: Do Chase So, that is a wonderful modular logic, and this only has the disadvantage that the check if a target is reachable is (likely) the same work as creating a path to this target So, if we implement the check clever, and use a even cleverer storage system for the created path(s) - we get rid of double work.

there is a "big" class of mobs that doesn't do MoveChase, and these are mobs which have no combatmovement. (ie Caster) This information _could_ be checked in SelectHostileTarget, as I already proposed to move combat movement (same in EventAi and SD2, and usefull for summoned mobs) to CreatureAI

What bug does the patch fix? What features does the patch add? Store the tapped-dynflags in case of Update Entry For which repository revision was the patch created? 10607 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. http://www.scriptdev2.com/project.php?issueid=1120 none else seen around Who has been writing this patch? Please include either forum user names or email addresses. me This patch is very fresh and not very thoughtfull, but I have the feeling that it is the right thing to store tapped information in such a case Might be possible, that UNIT_DYNFLAG_TRACK_UNIT (Hunters-mark and similar) or UNIT_DYNFLAG_REFER_A_FRIEND (unused?, at least unknown for me) should also be stored Bug Description: If a tapped npc UpdatesEntry, the Dynflags are resetted to new entry's dynflags, and so the tapped dynflag is overwritten, and the Updated npc cannot be lootet anymore. Example: NPC 10812 which Updates whilest the fight (need sd2 installed) Patch: diff --git a/src/game/Creature.cpp b/src/game/Creature.cpp index 183b765..be23f1d 100644 --- a/src/game/Creature.cpp +++ b/src/game/Creature.cpp @@ -325,7 +325,17 @@ bool Creature::UpdateEntry(uint32 Entry, uint32 team, const CreatureData *data, SetUInt32Value(UNIT_FIELD_FLAGS, unitFlags); + // Tapping related dynflags should be stored + uint32 origDynamicFlags = GetUInt32Value(UNIT_DYNAMIC_FLAGS); + // Update Dynamic Flags SetUInt32Value(UNIT_DYNAMIC_FLAGS,GetCreatureInfo()->dynamicflags); + // Restore tapping if npc was tapped + if (origDynamicFlags & UNIT_DYNFLAG_TAPPED) + SetFlag(UNIT_DYNAMIC_FLAGS, UNIT_DYNFLAG_TAPPED); + if (origDynamicFlags & UNIT_DYNFLAG_TAPPED_BY_PLAYER) + SetFlag(UNIT_DYNAMIC_FLAGS, UNIT_DYNFLAG_TAPPED_BY_PLAYER); + if (origDynamicFlags & UNIT_DYNFLAG_TAPPED_BY_ALL_THREAT_LIST) + SetFlag(UNIT_DYNAMIC_FLAGS, UNIT_DYNFLAG_TAPPED_BY_ALL_THREAT_LIST); SetModifierValue(UNIT_MOD_ARMOR, BASE_VALUE, float(GetCreatureInfo()->armor)); SetModifierValue(UNIT_MOD_RESISTANCE_HOLY, BASE_VALUE, float(GetCreatureInfo()->resistance1)); Edit: Alternative Version, _should_ do the same, in my view worse to read, but smaller code: diff --git a/src/game/Creature.cpp b/src/game/Creature.cpp index 183b765..b5f713d 100644 --- a/src/game/Creature.cpp +++ b/src/game/Creature.cpp @@ -325,7 +325,9 @@ bool Creature::UpdateEntry(uint32 Entry, uint32 team, const CreatureData *data, SetUInt32Value(UNIT_FIELD_FLAGS, unitFlags); - SetUInt32Value(UNIT_DYNAMIC_FLAGS,GetCreatureInfo()->dynamicflags); + // Tapping related dynflags should be stored (default | (original & (tapped1 | tapped2 | tapped3))) + SetUInt32Value(UNIT_DYNAMIC_FLAGS, GetCreatureInfo()->dynamicflags | (GetUInt32Value(UNIT_DYNAMIC_FLAGS) & + (UNIT_DYNFLAG_TAPPED | UNIT_DYNFLAG_TAPPED_BY_PLAYER | UNIT_DYNFLAG_TAPPED_BY_ALL_THREAT_LIST))); SetModifierValue(UNIT_MOD_ARMOR, BASE_VALUE, float(GetCreatureInfo()->armor)); SetModifierValue(UNIT_MOD_RESISTANCE_HOLY, BASE_VALUE, float(GetCreatureInfo()->resistance1));

* there is also a "thank you" button under own posts - seems to have no effect, but is a bit strange. * would be nice if it would be possible to "thank" for any post in any thread (I cannot 'say thank you' in accepted)

udb wiki also moved: http://udbwiki.no-ip.org/index.php/Main_Page

hmm, I can see what you are referring too - though this is mainly a question of saving/ accessing, the actual work that is to be done is always the same. And the logic is in my view clear, that the selecting of the target should be handled in SelectHostileTarget But I don't know anything about movement generators, so I just wanted to give some input (I come from the AI direction) (A small note: there is no principle problem to check if we do have combatMovement for a mob in SelectHostileTarget, I already prepared a patch to move this to generic CreatureAI)

thanks to tom but some might say, that TC saying "won' support" rather means "might support after mangos has done the work"

thanks, looks interesting One thing I don't understand: Shouldn't a mob(player too perhaps?) be on Idle-movement _while_ he is jumping - so is this handled anywhere else already, or are all of these jump-spells so fast (short time) that there wouldn't be any visual impact?

scripts are to be handled at scriptdev2.com Trinity scripts are overall just bad, I cannot recommend to waste your time with them. If you want to implement something, and fall onto a problem, you can take a look what trinity did, but I wouldn't expect any solutions from there.

this guide is more focused on the tanking side, but it is very detailed, and also has no indication for the 0.02 - but the 0.04. http://elitistjerks.com/f81/t18771-protection_guide/

weird, as this spell has 1.5 as cast-time in dbc