Schmoozerd

Hi guys, a bit advertisment here, too! I thought to start a project related to ICC implementation (mainly SD2) - with main focus on learning. But ofc I am only willing to make myself such extra work, if there are some ppl actually interested! So that no one can tell he didn't know about it, here is the link containing the information of what I have in mind: http://www.scriptdev2.com/showthread.php?t=5802

no, sart is just blabbering. Fixing itself will not be difficult. The problem is to know how to fix it proper. If you can provide reasonable sources when fear is removed due damage on retails, implementing such a change is easy. (reasonable source would be for example wowwiki or elite-jerks)

then we would need a proper aura for this case From research it seems that Zul'Jins overpower is only used in bear form, so the natural aura is 42594, but there is nothing related to triggering

Let's be clear: Git is especially designed to fork stuff and do own work on the own forks. So I think that it is a good thing that there are dynamic forks out there. However I can see the problems stfx noticed - using and especially developing for a custom fork goes to expense of the original project (in our case mangos/master) I think we all could benefit if we try to figure ways to get more of the development "back" to mangos. I know that there is no chance that the big boulders like "vehicles" are to be implemented on mangos/master only because there is a pull request. However I do see very high chances for the many small patches (like a spell fix, or the commit stfx mentioned) that are implemented to custom forks - chances for fast review and fast commiting to mangos. But there is one big problem (I noticed already with sd2 with which I am much more familiar): Someone who doesn't know the fork cannot (directly) see which commits are a commit fitting for master, or rather a commit related to custom patches, or what they are done for actually! And this is exactly where "pull commits" come in: So my suggestion would be: * Recreate your (actually this holds reasonable for many custom forks) repo on github that it is forked from mangos/mangos.git (Maybe this even can work with some admin changes) * Add pull requests for the small patches that you guys think are reasonable for master * Note in the pull-request basicly the same information you would post here on forums in a bug report or a patch submission I think such a flow should help all of us quite well with a little amount of additional work for anyone.

it is not forgotten, especially not the part of the npc-flag, this is infact very likely that we must add, only very unclear how. I currently favour the idea to reset the flags on respawn

In [11800]. Thank you Note: Related to way these GOs (type 10) currently work, a mob can be summoned every 3 seconds now.

hmm, I see no reason to not use a lua addon. Infact this might even work as basic guide for a report. However somebody (not me) would have to write this addon. This would have the advantage that this whole discussion topic would boil down to * An Addon which gives a well formatted string * A tool that parses a table and will be able to work (ie forward to some trackers) with this formatted string * Maybe some tiny additions to the characters.bugreport table to support some additonal noting of states

A bit different in the mechanics - this now depends only on the aura that might be removed, not only on all auras (and all casters) of this aura's type. I think this is more logical. UNTESTED diff --git a/src/game/UnitAuraProcHandler.cpp b/src/game/UnitAuraProcHandler.cpp index 0080e5a..3b6ad70 100644 --- a/src/game/UnitAuraProcHandler.cpp +++ b/src/game/UnitAuraProcHandler.cpp @@ -4073,6 +4073,16 @@ SpellAuraProcResult Unit::HandleRemoveByDamageChanceProc(Unit* pVictim, uint32 d { // The chance to dispel an aura depends on the damage taken with respect to the casters level. uint32 max_dmg = getLevel() > 8 ? 25 * getLevel() - 150 : 50; + + // Also the chance depends on modifiers on the caster + if (Unit* caster = triggeredByAura->GetCaster()) + { + AuraList const& mOverrideClassScript = caster->GetAurasByType(SPELL_AURA_OVERRIDE_CLASS_SCRIPTS); + for (AuraList::const_iterator itr = mOverrideClassScript.begin(); itr != mOverrideClassScript.end(); ++itr) + if ((*itr)->GetModifier()->m_miscvalue == 7801 && (*itr)->isAffectedOnSpell(triggeredByAura->GetSpellProto())) + max_dmg += (*itr)->GetModifier()->m_amount * max_dmg / 100; + } + float chance = float(damage) / max_dmg * 100.0f; if (roll_chance_f(chance)) {

@shlainn Implementing such a dialogue reporting system would be much more work - starting with the need to whisper to a virtual entity. Likely the cleanest way to do such a thing would be an independend project with one of the pseudo clients (login and chat commands) However: True this would improve the quality of reports by players. But honestly - most players are stupid anyways so the bug-reports will still be ill written This was actually the main reason why I suggest two commands (one for normal players) and one for a selected group of users - which also can be used in a checking way Also it is slower, especially when it comes to the part of submitting the "working, good or blizzlike" states of quests (which are also usefull information). Because actually we know that 70% of quests are good, so a dialogue is much more work than a copy/paste of ".reportTo udb quest <shiftLink> 3" @UnkleNuke UNfortunately yes, we cannot force anybody to work with/ for us. But we can try to make it easier - and this is where these automated functions come in Also I think that a couple of reasonable bug-reports are woth a few ill reports. I observe that whenever I start playing wow I notice a couple of bugs just while walking around. - And many other informed players will notice such, too. And often such things require very simple fixes (like ie a quest-item drop chance) - but if no one cares to report, it takes ages until they are caught. This is the thing it is about the many small bugs that simply exist and no one knows of

must be fixed with fix by Vinolentus in [11797]. Edit: Also moved to Bug-Reports.

in [11797]. Thank you

Hi, for sake of curiosity: What is your MA thesis about?

Alternate version in [11793] Thank you

alternate version in [11793]. Thank you

@ Unkle Nuke I think not: - Tickets can be written by anybody, hence no security controll (like .reportTo only for some usergroup "tester") - Tickets would have to been parsed, which can get very complicated I think @shlainn "If you want to combine it with a web tracker, obviously the status combinations should be identical..." The problem is that ie quests have very different states than npcs, so I cannot see how we can combine this reasonable About Sending: As you just said in IRC - maybe a "simple" script (python, whatever) is superior and easier to use than to add unneeded stuff to mangos About custom content: Therefore I thought of different states (to-sent, validate, sent) which would enable an admin to give some rough check before forwarding (marking for forward) a report - ie an admin would know that ie DK starting area is totally custom, so he could skip all reports related to this area OT: this Topic is located in "Core Modification" which is a part of "Developer's Corner Forum" I don't care about players.

and this would be blizzlike?

I see absolutely no need for this afk time.

first guess might be outdated localization files for the mangos strings. I suggest to restore the english commands and english strings from <MaNGOS>/sql/mangos.sql (tables ´command´ and ´mangos_string´)

struct SD2 ScriptedAI { <constructor> {m_uiEvadeTimer = 0;} uint32 m_uiEvadeTimer; void Reset() {} void MoveInLineOfSight(Unit*) {} void AttackStart(Unit*) {} void AttackedBy(Unit*) { m_uiEvadeTimer = 5000; } void UpdateAI(uint32 const uiDiff) { if (m_creature->IsInCombat()) { if (m_uiEvadeTimer < uiDiff) EnterEvadeMode(); else m_uiEvadeTimer -= uiDiff; } } }; This should be the reqired structure for such things, assuming that the mob should really enter combat.

you must figure a few things: - should these mobs enter combat? - if they do, when/ how should they evade. For the rest you mainly just need to add a minimalistic UpdateAI function and an empty AttackStart function; However in my view there are similar problems with lots of trigger mobs, so I really think a more generic solution should be tried to figure.

it _should_ be possible, but I would advise some tests if the stuff is running I built some win32 files recently, hey might include custom content (so maybe you won't get over loading creature_template), but this should be good enough to check if they actually run. http://filebeam.com/d15793fd574a000047498cb7162a748e They were built on Win7 64bit with VC100 in 32bit Release mode

this seems to be fixed by now, so alternate version added. Thank you

they must be fixed with the next UDB updatepack that should be released "soon"

you must get a file named server.log in which you will be able to read the errror. If the window closes to fast, go to the directory in which your mangosd.exe is, open a cmd (or git bash here) there and typein mangosd.exe

Accepted in 11784. Thank you Nice catch!