Lynx3d

There's a very detailed documentation about that called source code

Seriously, if you're interested in who handles what, take a look at the class structure, opcodes being processed (WorldSession and related code) etc.

Some of the anti-cheat threads/patches may also illustrate how it works and why you can cheat the system. Player movement is a typical cheating concern for example...

As your question is not very specific, i don't know what else to tell you...unless player and creature movement generation were the only things you wanted to know...

Actually, aura 262 allows to igore some conditions, like combat, stance(warrior's Warbringer&Juggernaut and Sudden Death) or other states.

Ignoring stance seems to be handled by aura 275 though, see Warbringer and Shadow Dance.

Isn't that one about spells that should NOT stack rather than those which should? I find the name and usage rather confusing ^^'

You don't say...

Maybe just have a second thought about what the opposite behaviour of spells that don't stack is

It means that this value is not available to the debugger, because *drumroll* the compiler optimized it out

Compilers can do many optimizations like inlining, passing arguments in registers etc. so the debugger cannot know where to find it. Turn off optimizations for more precise debugging information.

However being in combat has no own aura state, so that is no precise description for this aura type, and only checking it in HasAuraState will not implement Juggernaut or Warbringer.

Just saw Trinity replaced isFrozen() calls for Shatter with HasAuraState and extended that function with arguments for caster and spell to override it...but for Charge they still could not use that aproach and used another aura #262 check in canCast() to skip some cast requirements...

It's basically some nasty "override basic game mechanics" aura. No idea how to name that...

Your change to isFrozen() confused me at first, why didn't you just add an argument for caster instead of calling isFrozen on caster unit and giving target as argument?

By calling in MaNGOS::FriendlyCCedInRange::operator()() "u->isFrozen(u)", you may screw mages with active Fingers of Frost to be considered frozen, don't you?

Looks like a hack for when no caster is available, IMHO you have to consider that case explicitly though.

I agree it is better to not change isFrozen() at all but add special function that checks if target is just considered frozen, wherever the best place for this may be.

I'm not sure what the problem with Deep Freeze is, do you mean it is displayed castable by client with Fingers of Frost active, but the server refuses to apply it? I'm afraid you have to add extra code for Deep Freeze to check if targets considered frozen too, because Fingers of Frost is not specific to any target to my knowledge, ALL targets are considered frozen when it is active.

Btw, the toughest part is still the correct triggering of FoF, because Frostbite and Fingers of Frost apparently do not proc independently on official.

Also, keep in mind that Aura #262 is not only used with Fingers of Frost, but also Sudden Death, Juggernaut, Warbringer and maybe a few more.

That's probably no bad idea either...

On the other side, checking 6k entries may not be as dramatic as it looks at first...unless there's lots of people toggling armor pieces (including a heirloom) all the time to see which stats they like better.

(Also, i don't have 2000+ friends that want to play with me anyway, but others seem to :eek:)

Hm SkillLineAbility.dbc looks pretty huge to me, my dbc viewer says mail (skillID 413 to my knowledge) is etry #6826 for example.

May i suggest instead that if the player can't already wear the armor class that you look through SkillRaceClassInfo.dbc and check if he may learn it later?

That's at worst 240 entries, SkillRaceClassInfoEntry.skillId and SkillRaceClassInfoEntry.classMask seem to be what we're looking for if a player can't wear mail/plate yet.

-edit-

seems there's two entries for plate and mail in SkillRaceClassInfo.dbc, one with the classMask that have the skill from the beginning, and one with classMask matching classes that can learn it at level 40.

You made "ss" a global variable, no surprise it keeps the garbage from previous calls...very bad idea.

you can modify the DBCHandler itself and add/overwrite the values afterwards in the server code. I saw often such hacks here in the forum you may can search a bit and modify them for your use. A perfect solution would be of course a SQL table like "itemcost_overwrite".

I had almost posted something like this, but then i realized it's not going to work:

The client still looks up the required currencies in his local ItemExtendedCost.dbc and hence it will still display the original values, or if you try to use new IDs, most likely crash.

Where the client gets extended cost from? You'll never find that .cpp file because the client looks it up in ItemExtendedCost.dbc...

-edit-

To be more clear, you can only use those .dbc defined entries for items by setting its ID in the vendor entry, you cannot create new extended cost definitions (unless you modify the client).

Say you want to sell something for a "Delicious Chocolate Cake" you cannot do that, you'll have to do a repeatable exchange quest or similar...

Can you explain a bit more?

If you mean "threat 2.0", it seems to be an outdated threat calculator that works with combat log parsing. That always included a certain amount of guessing, and it may just not know threat values for many current spells...

This patch here does not change the way threat is calculated (AFAIK), it only sends it to the client periodically so new addons like omen 3 are working. There probably are spells that cause incorrect amounts of threat (i remember some SQL fixes posted here...), but omen 3 should still show correct percentage when you pull aggro. If not, the implementation here is also bugged...

Unfortunately i couldn't test in a group yet, only with pets.

Ah thanks for posting it in readable letters

I've seen some links to getmangos.ru but not being able to read anything there i just kept hoping it gets commited soon...

Applying and compiling fine here too with rev. 8502.

Only did a quick test with warlock+pet, but omen3 seems to work fine.

If i had a clue what you're actually trying to do, or why you need PHP for it...

In case you want to port your character DB to 320, maybe have a look at how it's done in 7988_07_characters_characters.sql for the 310 merge.

If that's too complicated, you'll have to wait until 320 gets merged to master and SQL updates for the then supported client build is provided (3.2.2 is still PTR...probably not the final build yet).

Well yea the first 6 digits suspiciously look like 2^32 in the screenshot, which would indicate an underflow (largest possible value of an unsigned int32 is 2^32-1 = 4294967295, which is the result of casting -1 to unsigned).

However when looking closer, the combat log only displays 9 digits while 2^32 has 10 decimal digits, but maybe that has to do with further processing of the underflown value...in any case, that's pretty much sure death even to raid bosses when it happens

Definitely does work on frostbolts for me. No idea why you think it does not affect it...

Oh, so you were not lazy after all

Hm i can't really say i'm an expert when it comes to MaNGOS code, but i'll try to summarize what i understand of it.

Generally, in WoW the conversion of agility and crit rating (and pretty much any other rating) depends on player level. The higher your level, the more you need for one percent critical strike chance. Additionally, player classes may benefit differently from stats, i think crit rating is same for all classes, but agility is definitely not.

For calculating the chance, the core needs these conversion tables which are read from the .dbc files extracted from the WoW client .mpq files.

With these values, critical strike chance is calculated from agility, critical strike rating, talent and other auras.

Editing .dbc is pretty much a taboo...legality issues aside, this would often have unwanted side effects if not all players edit their client files too, because client behaviour depends on those files too (why would they otherwise be part of it) so that's impractical IMHO.

Bending the game mechanics will not be all that easy, it's a very fragile balance that gets tweaked by blizzard ever so often, with varying success...the usefulness of gear will also be heavily impacted. Also most caster spells will not scale with base stats at all but their bonus comes entirely from talents and gear with spellpower...

For soloing instances I'd suggest to look into player bots, different mob stats etc. first before trying to modify basic game mechanics. The only way i see this could work is scaling the values as late as possible, like, increase final damage/healing by factor X, increase health granted per stamina by factor Y etc and leave the base stats and conversions alone.

Maybe you should try doxygen, answers such questions in seconds...

click variable, go through "referenced by" list and you'll see it's filled in LoadDBCStores.

gtChanceToMeleeCritBase.dbc => sGtChanceToMeleeCritBaseStore

gtChanceToMeleeCrit.dbc => sGtChanceToMeleeCritStore

So, no database entries...

Hm we have contradicting descriptions here somehow...

: even if a mob is tagged for you to loot, other players in your group can see the loot when right clicking and they can even loot things like money (divided over all players as usual) or items to roll for (causes the need/greed to pop up)

vs.

You shouldn't even be able to attempt to loot the corpse if it's not assigned to you, unless it has a quest item for you.

So can other players open the loot window or not?

Anyway, let's talk a bit about code.

First, in existing code LootItem::freeforall seems to refer to party loot (everyone gets a "copy" of the item), is that correct? Someone might want to rename that attribute then..."free for all" means the fastest one will get it, so this is confusing...

About the patch code, i have some troubles following it...

The function "RoundRobin" seems not to do anything round robin related to me. I'd expect it to determine the guid allowed to loot below threshold items. But that already seems to be done in Group::UpdateLooterGuid().

Instead RoundRobin() messes with is_underthreshold attributes, which looks hacky to me. Round Robin defines a distrinution method, the threshold is set by methods "falling back" to Round Robin for below-thresold items, which are 'Group Loot', 'Need before Greed' and 'Master Loot'.

So, to me it seems what was missing is basically just a way to block below-threshold items for players other than the one returned by GetLooterGuid(), and remove restriction when said player has closed the looting window.

Also, these lines look weird from a coding standpoint:

uint8 itemSlot = 0;
   for (i=loot->items.begin(); i != loot->items.end(); ++i, ++itemSlot)
   {
       if (!i->freeforall)
           loot->items[itemSlot].is_underthreshold = true;
   }

Isn't "loot->items[itemSlot]" simply "i"? So why not just write:

    for (i=loot->items.begin(); i != loot->items.end(); ++i)
   {
       if (!i->freeforall)
           i->is_underthreshold = true;
   }

While for daze from mobs a certain well known wiki says on that topic:

While it slows movement speed, daze is not considered a movement impairing effect. Thus it cannot be removed by the usual means such as druid shapeshifting

But it also says:

Some playable classes have abilities that apply a daze debuff as well. However, player dazes do not dismount others the same way creature daze does, nor is the daze effect immune to skills/items that remove movement impairements or harmful spell effects.

In other words, daze from player spells should indeed be removable by shape shifting, because in this case it is a "normal" movement impairing effect, from what is statet there...

With "confusive shot", do you mean hunter's scatter shot? That one is an incapacitate effect, i don't think you should be able to shift out of it, as shapeshifting is an action too, and you can't do anything while confused/disoriented. Only PvP trinket, ice block and divine shield are able to break that according to the wiki.

If you meant "Concussive Shot" then the above about player daze should apply...same for typhoon and aftermath.

-edit-

after some more thoughts, if you are sure that family flags for all mage spells only have exclusive bits set (i.e. all pairs of flags combined with bitwise 'and' is zero), this should work.

It looks like every spell (with ranks) has only one bit set, but i never examined that further...

I just gave the patch a try. It bitched a bit at applying with missing newlines at end of file for spell.cpp and item.cpp but those can be ignored...

I enchanted some armor and a weapon vellums, reagents were taken correctly, scrolls generated correctly, and scrolls aswell as enchants were still intact after relog. Other enchants (like rings) also still seem to work just fine.

That was hardly an intensive test, but so far everything looks fine over here.

Yes, basically Fingers of Frost would override the pVictim->isFrozen() calls in Unit::isSpellCrit (Shatter talent) and Unit::SpellDamageBonus (Ice Lance) from what i can tell.

Deep freeze then again should be pretty much like warriors execute, it requires the target to have a specific aurastate, but this requirement is ignored when the talent buff is active.

I'm still not sure what exactly the function of aura 262 from Warbringer is, with Juggernaught it must be the ability to use it in combat, but that's not aurastate related to my knowledge...unless there's some unknows state for this. In any case, it has nothing to do with the target/victim but the caster.

The stance part of Warbringer could be handled by aura 275 which is also used by shadow dance (ignore stealth state, which seems to be a form like warrior stances)

In sum, i just can't find a way to unify those uses of aura 262 in one piece of code...they're too special.

Well, even if blizz does this for some reason (like trading computing efficiency for memory consumption), it makes no functional difference if you delay loot creation until it is actually referenced, so i'd say you're free to chose how to do it.

I would probably also create it on creature death rather than spawning, without multithreading there's just no reason to consume memory early...it would make sense if there's a low-priority thread that takes care of (re-)spawns and loot generation.

And i totally agree that the loot system deserves some care, sometimes loot is even stuck unlootable for all players (no idea if it has been fixed, but i had it happening that the item is lost when a player with full inventory wins a roll...totally forgot about it, i really wanted to post a bug report eventually)

There is not even a server-side check that prevents you from using non-combat spells in combat (except feeding pet or something) unless i'm really blind. So i guess currently you could use charge with cheats even without apropriate talents.

About Fingers of Frost, i also think it has to be "hacked" where the special code for ice Lance and Shatter already is. But the real problem is still that a certain company decided it shall share the proc roll with Frostbite. Current core structure does not allow to re-use a random value for another proc, so you can only do a non-offlike indepentant proc chance which is overpowered on targets that can be frozen. Otherwise, i'd probably already have posted a patch for FoF...

And i still think the damage from my Sudden Death code should be correct, someone has just to decide which way to check for an affecting aura 262 is the most beautiful/generic one...i'm no expert with all the available spell and aura attributes.