Schmoozerd

Related spells: 22011(channel, triggers next after 30s), 22012 (heal spell) 2584 (waiting for resurrect aura - duration indefinitly) So I really cannot see how the bug arises - but it doesn't look like sd2 problem at all.

no, unit_flags=33554944 is correct. this flag corresponds UNIT_FLAG_PASSIVE | UNIT_FLAG_UNK_29(// used in Feing Death spell) hence likely a core problem.

Mangos Version: 10842 Custom Patches: - nothing related SD2 Version: 1900 (unrelated) Database Name and Version: UDB 394 (no related changes) How it SHOULD work: Entering the toxic tunnel should be toxic How it DOES work: It is rather a small poof (the dmg spell is triggered only once) Related NPC: 16400 Related Spell: 28370 linked via creature_addon (should infact be c_t_a..) SELECT * FROM creature_addon WHERE guid IN (SELECT guid FROM creature WHERE id = 16400); Spell 28370 should trigger 28369 (dmg-aoe) every 2 seconds, but only triggers the dmg-spell one time. I suspected that the mobs enter combat (because of the dmg spell) but evade directly (as they don't get a real target) - however I did observe such behaviour only with a similar spell.

UDB 393 is the last release, you should DL updatepack 394 and install this, see udb-forums for further information SD2 revision only means the last revision, in which SD2 was changed to adapt to mangos changes, so usally it will work with higher versions (except you got a version "destroying" SD2 temporarily, in this case you should file a bug-report at SD2-forums, to wait for a SD2 fix

there is no vehicles patch "approved" by the mangos team. Infact there seems to be rare concern about the many workarounds that are used in all patches around.. However, if you are carefull enough to seriously backup your data, are not afraid of some merge-problems, you should get a "working" vehicle system with this patch. But one should never give up hope, that perhaps someday someone will not only start, but actually finish steps to a working vehicle implementation.

I wouldn't say there is need for cheeting, this rather could use some advanced scripting for such bosses, like prevent Evading (caused by unreachable targets) and to add special ways to move (like flying, teleporting)

thanks, I would be very happy if this would finally be working However I feel I should point to the fact that the first effect of spell 43723 is a script effect with basepoints=43753 which I think makes it more likely that the actual spell-casting should be handled with the second spell (but ofc this won't work)

What bug does the patch fix? What features does the patch add? These timed achievements which are completed on QuestReward are infact simple quest-achievements, and hence need no explicit forced DB-criterias Related Achievements: 1275, 1276, 1277 For which repository revision was the patch created? 10829 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 diff --git a/src/game/AchievementMgr.cpp b/src/game/AchievementMgr.cpp index 570cfae..54b57b5 100644 --- a/src/game/AchievementMgr.cpp +++ b/src/game/AchievementMgr.cpp @@ -2369,9 +2369,9 @@ void AchievementGlobalMgr::LoadAchievementCriteriaRequirements() switch(achievement->ID) { case 31: - case 1275: - case 1276: - case 1277: + //case 1275: // these timed achievements are "started" on Quest Accecpt, and simple ended on quest-complete + //case 1276: + //case 1277: case 1282: case 1789: break;

What bug does the patch fix? What features does the patch add? Implement Script-Effect for spell 26218 For which repository revision was the patch created? 10829 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 Further information: http://www.wowhead.com/npc=15760#comments in short: this spell should trigger one of 26206, 26207, 45036. See also http://www.scriptdev2.com/project.php?issueid=1194 for testing. diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp index 568c2aa..f680ddd 100644 --- a/src/game/SpellEffects.cpp +++ b/src/game/SpellEffects.cpp @@ -5714,6 +5714,16 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx) case 25143: case 25650: case 25652: + case 26218: // Mistletoe + { + if (!unitTarget || unitTarget->GetTypeId() != TYPEID_PLAYER) + return; + + uint32 spells[3] = {26206, 26207, 45036}; + + m_caster->CastSpell(unitTarget, spells[urand(0, 2)], true); + return; + } case 29128: case 29129: case 35376:

likely a unneeded killcredit script in eventAI (acid), check there, and check for conflicting with KillCredit fiedls in DB. Post at sd2 / acid if it is indeed an acid problem

there are tons of scripts doing this work, you can copy the files of the needed updates to a directory, (con)cat them to one file and apply this file, or so many other things to speed up this process Edit - as the system independency is a valid point, this one should work in git-bash too: (it just needs an additional created directory "processed" where it moves files that went through without problems #!/bin/sh USERNAME="<username>" PASSWORD="<userpass>" if [ "$#" -ne "1" ] then echo "call with name of database" exit 1 fi DATABASE="$1" for i in *.sql do echo "Process $i" mysql -u$USERNAME -p$PASSWORD $DATABASE < $i if [ "$?" -ne "0" ] then echo "An error happened" exit 1 fi ## Done i, mv to processed mv $i processed/ done echo "all done"

cd .git/hooks mv pre-commit.sample pre-commit and your whitespace errors are reported before commiting further information: http://www.kernel.org/pub/software/scm/git/docs/githooks.html

I would start with removing all instance-binds therefore: * shutdown your server * DELETE FROM character_instance; * DELETE FROM instance; * DELETE FROM group_instance; * DELETE FROM instance_reset; this way you should have only clean times. Test then again, and if you encounter still a bug, post a detailed bug-report

qsa's patch will need a major extention, as item-loot now is stored in a table darkstalkers patch should be not too hard to adapt to recent version. Personally I still like qsa's idea to write one(or three) classes for loot, but afaik a multi-heritage OOP design throws a few problems (C-casts everywhere) - and I didn't understand why he didn't implement these classes as member variables of the creatures, corpses, or whatever

yes, vladimir already was so very kind to give me a deep feedback -- see below -- * he pointed to programming weaknesses * he strongly suggested to first solve the problems with EventAi combat movement handling * also he provided some other possible ideas to handle MMaster differently so, in the moment I do - think about a new MMGen supporting ranged chasing (movement of hunters, casters) (especially to make your life easier ) - having such possibility it should be possible to make EventAi CombatMovement code easier, which then also makes the changes I thought about easier - explore the idea to provide different stacks (or deques) for different types of MMGens - ie one stack for normal movement, one for combat movement and perhaps another for funny stuff (like transport) bascily main points here are, that we need to very carefully think of every change as this might have quite impact on speed in case anyone is intereted about the RangedChaseMMGen: MMGen providing Min and Max-distance: if the target is > max-distance, then chase till <= max-distance if the target is between min and max distance, then don't move if the target is < min distance, then chase I suspect that this system will need to trigger two events for CreatureAI, EnemyEnterNear and EnemyEnterRange, which then can be used ie for hunters to equip or unequip a weapon and set phases Unfortunately implementation of a MMGen is not too easy -- Status downdate -- It is more than unlikely I will find time for improving the ideas I had here this year, so in case someone want's to do something here, I think it is ok to forward the notes vladimir gave me about my first patch!

I think a good step would be, to start with only grouping players without or with the same id. This way you can implement a solid framework, and won't have to worry about these nasty things of how to mess around with bindings, creature->encounter state, etc And if you have a solid (smaller) patch the chances are way better that this is to be accepted

it is quite easy: achievements have nothing to do with DF and DF has nothing to do with achievements - keep it that simple. spp only used achievements to trigger DF-changes, because both "actions" are _sometimes_ triggered on same event (encounter finished) In my view it is a very bad idea to use something that is not fully working to implement something independend on top of it, but well it partly get's the job working, and as long as I don't need to work with it, I just advise to think of _any_ other way to handle this better

no, my idea should be basicly working as follows: DungeonEncounter lists every "important" encounter of any instance. every encounter (independend from difficulty) has a unique key (map, encounter-position) In SD2 we store (some) encounters in an array, which is saved to a string like "v_1 v_2 .. v_n" where each value of v_i represents the state of the encounter (usally 3=finished) so, if we would change sd2 to represent (and in order) every encounter of DungeonEncounter.dbc then this instance string would be a valid representation of finished encounter. The key (mapId, difficulty, position) identifies any encounter - I don't know if there is anymore information needed then. But well, that is just an idea

I had the idea to use the SD2 part where we write an instance-string to be used for DF (finished encounters) This has the _big_ disadvantage that we would have to change most sd2 instance scripts (though not complicated) - but the advantage that it would be easy to check But I doubt that NoFantasy as chief sd2 dev will be happy with this idea. The best way to implement this would be to add an event-based system (killing a boss throws an event) which would solve other problems as well, but unfortunately it seems impossible to find "real" event-ids for most bosses (infact our way sd2 uses SetData calls is similar in concept- but only used within sd2)

5 days without crash and 10720 (only 50 players) - on debian I think you should just try and take a look how it turns out on your environment

and again (or still?) something messed up at creature_template # (cur | prev) 03:35, 24 November 2010 Iwozukun (Talk | contribs) (27,635 bytes)

perhaps you could get some spells to work if you would mess around in IsPositive spell, but really, that is not the solution^^

Mangos Version: 10760 Custom Patches: -- SD2 Version: -- Database Name and Version:-- How it SHOULD work: Spells of this target-type have quite some different behaviour, what they actually should target How it DOES work: often wrong A few spells and their description (datas from Spell Work, all are (TARGET_CASTER_COORDINATES, TARGET_AREAEFFECT_INSTANT) * 802 SPELL_EFFECT_APPLY_AURA - positive : this spell should target _one_ nearby bug (currently working) * 804 SPELL_EFFECT_APPLY_AURA - negative : this spell should target also one nearby bug, but atm not working (negative aura - targets enemies) * 10252 SPELL_EFFECT_APPLY_AURA - dummy : this spell should target one npc of (at least) one entry * 10860 SPELL_EFFECT_INSTAKILL : should target _all_ npcs of one entry * 12613 SPELL_EFFECT_APPLY_AURA - fear : should target _all_ npcs of one entry * 16807 SPELL_EFFECT_DUMMY : should target _all_ npcs (which are friendly, but might be a well known number of different entries) * 30425 SPELL_EFFECT_SCRIPT_EFFECT - should target a few npcs of different specified entries * 28732 SPELL_EFFECT_APPLY_AURA (SPELL_AURA_MOD_CASTING_SPEED_NOT_STACK) and SPELL_EFFECT_SCRIPT_EFFECT : should target one npc * 30571 SPELL_EFFECT_KNOCK_BACK : should target all enemies * 30572 SPELL_EFFECT_SCRIPT_EFFECT : (likely) all enemies * 30985 SPELL_EFFECT_DUMMY : should target _all_ npcs of one entry I think this list is enough to see, that we need a more generic way to support target-finding based on *npc entry and *type, and also that the generic rules depending on friendly or unfriendly spell are not good enough for such AoE spells. In fact I think the way the targets are to be handled in such a case is similar to the way we handle spells with spell script target. - but as these spells might target _all_ suitable enemies, this will need adjustment - though I think it would enough to act upon some additional provided target information, if there is information provided instead of defineing the need for such information Edit - example for targeted players added (to emphazise that I think it would be wrong to replace current way it is handled)

gee yes never tell anyone that your ip is 127.0.0.1 - if anyone knew he could hack into your pc btw set realmlist 127.0.0.1 make sure to edit with wow-closed, and to start wow not by the launcer, ie use wow.exe

push to 10767