Schmoozerd

After some research and tests, I came up with the following changes: For core: http://paste2.org/p/1219177 For further testing (and because of compile errros) for SD2: http://paste2.org/p/1219179 Changes in Spell:RangeCheck(): I tested the behaviour with spells of rangeIndexes 8 (10y), 140 (6y), and also one spell with 12 (5y-Interaction) (16612), but _only_ the melee-ranged spells (index 2) behaved with this additional 1.33 offset. Also I could not see any reason for the additional value in the checks, so I think this is something from the good old times There is a known problem with this patch: A mob who has bounding_radius >> combat_reach WILL now be exploitable, as they won't chase to melee-range (so they won't do melee dmg). This bug is not caused by this patch, this patch only makes this bug more obvious. If anyone wants to confirm that this patch _is_ correctly (or want to measure a more precise value for the 1.33f melee-range offset), this is how to check (also there are shown my measured values) http://paste2.org/p/1218554 1) a patch making the test more easy, this is only for debugging purpose 2) use .m as .1 to walk slow enough to get accurate values. 3) the check is the 'color' of the spell's icons, use any spell with a fixed range, and you can go to the place where the range-check changes, and measure the distance to your target by .dist (modifed version's output can be seen in my research datas)

then most likely in ytdb are some values hacked, to get it working. so, if you want to get it working at any cost, too, check differences in related npcs, gos, etc.. and prepare a workaround for udb, too (I am sure many ppl would apreciate it). Or ofc you can use the diffs as basis and try to get a proper patch to get it working correctly

I can agree that for small UPDATEs I too think SET unit_flags = 1 is more beautiful. However, compare UPDATE creature_template SET min_dmg = 356, max_dmg = 654, attack_power = 130, dmg_multiplier = 13 WHERE entry = 448; to UPDATE creature_template SET min_dmg=356, max_dmg=654, attack_power=130, dmg_multiplier=13 WHERE entry = 448; or to UPDATE creature_template SET min_dmg=356, max_dmg=654, attack_power=130, dmg_multiplier=13 WHERE entry=448; From my view, once an Update has more updated fields, it is better readable if the style is "field=value", and for consistency the last one is then easier to read. Though I think that using entry=%u as done in the MaNGOS-sql queries is easy to read Also a small note: the SQL-Query files become smaller, if blanks are skipped, and I think there are reasons to use the same style in core-sqls, DB-sqls, sd2-sqls and so on.

I only took a small look over this patch, and there are quite many (small) changes which seem to be needed, and independend from vehicles in general (ie changes of compo-point holder), so why not post some of them in improved form to review-section?

where did you find the source for these datas? I looked at wowwwiki, and there is only stated 5y ~ 800dmg, 10y~3000 dmg, this rather looks like rather like a quadratic growth. Also I found in DBC the information, that the normal spell 52942 has basepoints=100 and the heroic spell 59837 has basepoints 150.

What bug does the patch fix? What features does the patch add? This patch triggers the AI-calls JustSummoned, SpellHitTarget (and also the other calls for Summoned creatures) for spell summoned mobs to the original caster and not m_caster For which repository revision was the patch created? 11073 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 I didn't see any problems with this change with momentarily scripts, infact this will simplify a few (as no need for special scripts for summon-trigger npcs) Patch, any input welcome http://paste2.org/p/1212878 (V2a, with vladimir's suggestion, for Rev 11073) History http://paste2.org/p/1210352 (V1) http://paste2.org/p/1211001 (V2, with vladimir's suggestion)

What bug does the patch fix? What features does the patch add? Adds an additional check, that SetInCombatWithZone is only called, if the atter is a player or controlled by a player This prevents possible bugs in case aggroing other NPCs For which repository revision was the patch created? 11064 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 Original Idea by NoFantasy. Example where this makes a difference: Ragnaros Kills Majordomo with 19773 which triggers 'aggro' for both, and would with current design set ragnaros into combat with zone (which would be wrong) Remark, not entirely sure if enemy can be NULL but this way it is safe diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index c56fee8..68a9135 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -7716,7 +7716,7 @@ void Unit::SetInCombatState(bool PvP, Unit* enemy) pCreature->AI()->EnterCombat(enemy); // Some bosses are set into combat with zone - if (GetMap()->IsDungeon() && (pCreature->GetCreatureInfo()->flags_extra & CREATURE_FLAG_EXTRA_AGGRO_ZONE)) + if (GetMap()->IsDungeon() && (pCreature->GetCreatureInfo()->flags_extra & CREATURE_FLAG_EXTRA_AGGRO_ZONE) && enemy && enemy->IsControlledByPlayer()) pCreature->SetInCombatWithZone(); if (InstanceData* mapInstance = GetInstanceData())

What bug does the patch fix? What features does the patch add? With current c_t_addon system, every mob with difficulties needs own entries for every difficulty. With this patch the npcs will take the c_t_addon information of normal mode, if they have no own entries For which repository revision was the patch created? 11327+TomRus Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. don't hink so Who has been writing this patch? Please include either forum user names or email addresses. me Only rough tested.. diff --git a/src/game/Creature.cpp b/src/game/Creature.cpp index 6f0012f..e0a3212 100644 --- a/src/game/Creature.cpp +++ b/src/game/Creature.cpp @@ -1894,7 +1894,14 @@ CreatureDataAddon const* Creature::GetCreatureAddon() const return addon; // dependent from difficulty mode entry - return ObjectMgr::GetCreatureTemplateAddon(GetCreatureInfo()->Entry); + if (GetEntry() != GetCreatureInfo()->Entry) + { + if (CreatureDataAddon const* addon = ObjectMgr::GetCreatureTemplateAddon(GetCreatureInfo()->Entry)) + return addon; + } + + // fallback to entry of normal mode + return ObjectMgr::GetCreatureTemplateAddon(GetEntry()); } //creature_addon table

ninja bump from my tests still not working in 11064 (neither with normal tempo nor with heroism buff)

What bug does the patch fix? What features does the patch add? Implements periodic dummy ticks for spells 69008, 68870 For which repository revision was the patch created? 11064 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. don't hink so Who has been writing this patch? Please include either forum user names or email addresses. me Thanks to NoFantasy for advise. Source: Sniff, the triggeredSpells are cast OOC in this order, after some time found spell 69008 as aura in Object create. Spell 68870 is casted, and after you get exactly the right number of casts for the triggered spells (with right time) diff --git a/src/game/SpellAuras.cpp b/src/game/SpellAuras.cpp index b723a02..7fea31d 100644 --- a/src/game/SpellAuras.cpp +++ b/src/game/SpellAuras.cpp @@ -7482,6 +7482,13 @@ void Aura::PeriodicDummyTick() case 2: target->CastSpell(target, 55739, true); break; } return; + case 69008: // Soulstorm (OOC aura) + case 68870: // Soulstorm + { + uint32 triggerSpells[8] = {68898, 68904, 68886, 68905, 68896, 68906, 68897, 68907}; + target->CastSpell(target, triggerSpells[GetAuraTicks() % 8], true); + return; + } // Exist more after, need add later default: break; Various notes, before they got lost: 1) order of the spells should be 68904, 68886, 68905, 68896, 68906, 68897, 68907, 68898 2) GetAuraTicks() starts with 1, not with 0 (so basicly errors 1) and 2) cancel each other out 3) more complicated: these spells should be cast with SMSG_SPELL_START - but also should behave like triggered spells, this seems to be some more generic problem

What bug does the patch fix? What features does the patch add? Fix small issue with reported problems of scripted npcs in high difficulty For which repository revision was the patch created? 11064 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. don't hink so Who has been writing this patch? Please include either forum user names or email addresses. me Currently output is but should have been _1_ in the first part Fix: diff --git a/src/game/ObjectMgr.cpp b/src/game/ObjectMgr.cpp index 07a2187..d7cd6c7 100644 --- a/src/game/ObjectMgr.cpp +++ b/src/game/ObjectMgr.cpp @@ -591,14 +591,14 @@ void ObjectMgr::LoadCreatureTemplates() if (difficultyInfo->AIName && *difficultyInfo->AIName) { sLog.outErrorDb("Difficulty %u mode creature (Entry: %u) has `AIName`, but in any case will used difficulty 0 mode creature (Entry: %u) AIName.", - diff, cInfo->DifficultyEntry[diff], i); + diff + 1, cInfo->DifficultyEntry[diff], i); continue; } if (difficultyInfo->ScriptID) { sLog.outErrorDb("Difficulty %u mode creature (Entry: %u) has `ScriptName`, but in any case will used difficulty 0 mode creature (Entry: %u) ScriptName.", - diff, cInfo->DifficultyEntry[diff], i); + diff + 1, cInfo->DifficultyEntry[diff], i); continue; }

indeed it seems that it must be taken the maximum of GetCombatDistance and ATTACK_DISTANCE and it also looks like that in these small distance cases, the combat range is (again) calculated without bounding_box (I test with 24219, faction changed to 14, values BB=0.748, CR=0.6) Also some of the model infos which have 0 entries for BB and CR are linked (modelid_other_genger) to some modelids which have reasonablevalues for these fields - so this suggests to also try to implement some additional feature to get the better values

yes, this does basicly the same as I did (in the player part). However with this patch the Problem "The melee-range now seems to be too big, don't understand which reasons for decreasing there could be" will be worsened even more, as the IsWithinDistInMap check adds the bounding_box values. I cannot yet tell if the additional check: if < ATTACK_DISTANCE then = ATTACKDISTANCE is important, therefore I haven't explored enough yet

Hi guys. Current Code situation: every unit has a model, which has some data stored in creature_model_info These are - modelid - linked with creature_template.modelid_X (usally 1) - bounding_radius a float value, used for distance calculation, assumption this is the 'radius' of the modell - combat_reach a float values, used for spell range check Scematic of these values: http://img96.imageshack.us/i/distancecalculations.png/ Atm in clean core spells are checked with GetCombatDistance float dist = m_caster->GetCombatDistance(target); if(dist > max_range) // max_range is max range of spell (from DBC) return SPELL_FAILED_OUT_OF_RANGE; if(min_range && dist < min_range) // min_range is min range of spell (from DBC) return SPELL_FAILED_TOO_CLOSE; And melee-range is checked with IsWithinDistInMap ~~> GetDistance, that is takes bounding_radius information into account //If we are within range melee the target if (m_creature->IsWithinDistInMap(m_creature->getVictim(), ATTACK_DISTANCE)) Also default MoveChase distance is defined by bounding_radius, as the default distance is 0 (which means, the bounding-boxes are near) My idea is to change this, such that melee-range check is similar to spell range also dependen on combat reach, this gives in my opinion way better results. Suggested check: The icons for spells turn dark-gray if you are out of range, so this is client based, and hence a very good reference. Example mobs: - Murmur, Ragnaros, 16441, Maexxna Base patches: http://paste2.org/p/1205717 (for core) http://paste2.org/p/1205718 (for SD2, might give small conflicts, as I wasn't testing on clean) Problems * A few mobs like supremus, 16441 have most likely wrong MoveChase behaviour, as of extremely large bounding_radius * The melee-range now seems to be too big, don't understand which reasons for decreasing there could be! Any input & feedback is welcome

git status, to see where possible problems might be if you don't have custom code: git reset --hard

a little bump This week I encountered two situations, where I would be very happy to pass a few more arguments to casted spells: 1) DrakTharon keep, novos encounter, there are trigger mobs who must cast a spell through LoS, so I would want to skip the LoS-checking (and I don't want to cast them 'triggered' with current handling) - spell 52106 2) spell 19773 (haven't examined this situation, perhaps this already can be done differntly): this spells instantly kills Majordomo, but sets both majordomo as ragnaros into combat (which I would not want) Edit: Looked at the spell of 1), it has "SPELL_ATTR_EX2_CANT_REFLECTED 0x00000004 // 2 ? used for detect can or not spell reflected // do not need LOS (e.g. 18220 since 3.3.3)" - so _if_ we change this spell attribute to behave to ignore LoS, this spell would be working I guess

you are sure that this spell shouldn't be casted from unit_target -> m_caster (as it is Targets (25, 0) (TARGET_DUELVSPLAYER, NO_TARGET)) btw, spell IDs for heroic: 59803 and 59805

guys, for _new_ whitespace errros, just use git commit hooks then you get error messages when trying to commit (for starters just 'cp.git/hooks/pre-commit.sample .git/hooks/pre-commit' )

about your script: - why declare TYPE and then not use it? - afaik bash is fine with for i in *.$TYPE, no need to ls directly additional ideas: - add a -r switch for recursive - perhaps define a few default types that are cleaned (.cpp .h .txt) - why not add an additional substitution to sed to move all tabs to 4 blanks?

Thank you for the idea, bump with it. Also added the IsFriendlyTo check (in better way as suggested by vladimir) to SetInCombatWithZone to prevent possible bugs (in _very_ rare case that a boss turns friendly by script, should before SetTheCombatInZone, and enters combat with some other NPCs )

this might be something for a new config var <FFA-settings>AllowGroupsInFFA default = true ?

the loot should be handled (with clean core) with some additional conditions check, and if the condition applies to the loot-master, it must work in master loot and group-looting, too

Contained in http://old.wowhead.com/item=44113 Looted item= 43016 If I remember correctly this item was discussed at UDB several times, and it was stated that the container and item both have correct values but better double check

added basic support for following, see also the TODO messages Would be cool if some guys would do carefull rereading, such that I don't make serious logic mistakes -- TODOs TODO: On Death of followed some action is needed - must be discussed what will best way to go TODO: Better check, ie uniqueness of follower (well, currently this is checked, but only by DB-selects, so maybe improve in speed) TODO: Also need better check for ie Despawn on Respawn, (only direct self->self filtered currently) TODO: Re-Following on Evade is needed this means: _where_ do we want to set the following, we could use the evade place, or we could modify motionMaster MoveTargetHome to set into following. The second is a bit more work, though perhaps more convinient

highly dependend onwhat you are going to fix. only good way to learn is to read fixes from other ppl and see what they changed there.