Lynx3d

no matching function for call to 'Creature::SendMonsterMove(double, double, double, double, SplineFlags, int)'

note: candidates are: void Unit::SendMonsterMove(float, float, float, SplineType, SplineFlags, uint32, Player*)

No idea what your 4th float/double is supposed to be there...

-edit-

And are you sure you want to move them all in 1ms??

You sure like redundant code

Besides the fact that you could simplify that switch statement a lot, why don't you use getTeam() instead?

Just need to make sure you're dealing with a player...but you probably should anyway.

Like:

...
                           switch(caster->getTeam())
                           {
                               // Alliance Lance
                               case ALLIANCE:
                                    m_caster->CastSpell(m_caster, 63914, true);
                                    break;
                               case HORDE:
                                    m_caster->CastSpell(m_caster, 63919, true);
                                    break;
                               default:
                                    break;
                           }
...

Other than that, i haven't really looked into it...

If you have the ultimate check that covers all spells and doesn't produce false positives, please let us know

Spell IDs themselves don't get you anywhere, you sure don't want to create a 50k x 50k matrix of spell-pairs...

@Forusim: That's certainly not a correct fix, there's three different ranks of the talent.

And triggerAmount certainly should be 30 for rank 3, if it's not, find the reason why...

But i have another suspicion, i've looked at the calculation for damagefromticks many many times and then it finally struck me.

I think it should be:

int32 damagefromticks = GetSpellAuraMaxTicks(procSpell) * SpellDamageBonus(pVictim, procSpell, leachAura->GetModifier()->m_amount, DOT);

instead of:

int32 damagefromticks = SpellDamageBonus(pVictim, procSpell, (leachAura->GetModifier()->m_amount* GetSpellAuraMaxTicks(procSpell)), DOT);

And i also think you can save some CPU cycles by replacing GetSpellAuraMaxTicks(procSpell) with lechAura->GetAuraMaxTicks()...

*scratches head*

I'm not sure i can follow you...

I'll just try to explain more comprehensively.

A template is a bit like macro on steroids. It's a piece of code with some place holders to fill in. Without naming specific types, it cannot be compiled to binary code, infact, MSVC will not even check its syntax unless you instantiate it. Instantiate means creating an actual function/class from it by specifying its template parameters. For a function, each set of parameters becomes an own, distinct function that has to be compiled at some point. Most of the time, the templates are instantiated automatically, the compiler sees your template parameters, and if it hasn't created code yet goes to your template definition and actually compiles code for it.

In your case, automatic instantiation works fine in Spell.cpp, since the function is defined there. However you want to use it in another source file where the definition of the template is not available, so the compiler assumes you instantiate it somewhere else so it will be found when linking the program. However, you did not do that either, so linking fails.

So you basically have two options:

a) Move the definition of the template to a header so it becomes available in the source file where you need it, and let it automatically be instantiated

b) Explicitly tell the compiler in Spell.cpp to create functions for the template parameters your need elsewhere so it is available when linking the final binary

That's because templates are just...well...templates. They don't compile to anything unless you instantiate them.

You can either implicitly instantiate it (by using it), or explicitly instantiate it. In both cases its definition has to be available of course.

Since you (only) want to use it in a place where its definition is not available, you need to explicitly instantiate it where it is available.

Although i rarely get the template syntax right in the first try, try adding something like

template WorldObject* Spell::FindCorpseUsing<MaNGOS::RaiseDeadObjectCheck>();

to Spell.cpp (somewhere after the function definition, at global scope)

He compared apples to oranges anyway, i.e. a JIT compiler vs. a pure interpreter.

Compare with interpreted LUA and see quite a bit different numbers...

I'm not familiar with JIT projects for Python, but there are some like PyPy and unladen-swallow (whoever came up with that name...)

And i don't think a JIT compiler is a silver bullet either...

Hm...are you sure?

From gitignore manual:

A gitignore file specifies intentionally untracked files that git should ignore. Note that all the gitignore files really concern only files that are not already tracked by git; in order to ignore uncommitted changes in already tracked files, please refer to the git update-index --assume-unchanged documentation.

Since configure.ac definitely is tracked by git, ignoring it has no effect according to that. And if i understand referenced documentation correctly, using --assume-unchanged will cause the file not to be touched at all, e.g. changes to configure.ac in upstream will not reflect in you working copy, and you need to deal with it manually when it changes.

So for the SD2 patch you basically have the choices:

1) Commit the patch and merge (pull) or rebase to origin/master

2) Reset when git pull tries to update a modified file and gives above error, and reapply patch afterwards

3) Stash when git pull tries to update a modified file and reapply stash afterwards

For any of your own (or non-mangos) code, for gods sake don't work against git and commit it to your branch. If i'm not mistaken, that's what distributed version control was invented for in the first place, because people were sick of having dozens of loose patch files...

Well since the scroll part is in master now (with somewhat different code), you have to remove that on merging obviously...

Kungfu-merged current master branch right into it, though i wonder if i should've just redone the branch...but seems it has worked.

http://github.com/Lynx3d/mangos/tree/vellums

Resulting patch shrunk down about 50 lines (against [9291])

http://paste2.org/p/647052

And i have to emphasize that code is still based on what Lightguard posted and others like timmons contributed.

Stupid question, why don't you just merge his branch? Or, since it's even only a single commit so far, just cherry pick that commit. No need to extract a patch and re-apply it...

For example, to get http://github.com/xeross/mangos/commit/5e4351fcb07dd35fb0cebafe6377704dfed59a99 you can do:

git remote add -f xeross git://github.com/xeross/mangos.git

git cherry-pick 5e4351fcb07dd35fb0cebafe6377704dfed59a99

Voila, you got new commit "External mail, initial commit" in your branch.

Just noticed, this line doesn't make sense to me:

if(m_origDuration - duration != duration)

Don't you just want to check if haste changes the aura duration? Then it should be simply:

if(m_origDuration != duration)

Calculation is still a bit complicated, but it should be numerically stable. I also wonder if "ticks" is ever non-integer...

In any case, since periodictime is what limits the time resolution of the whole haste calculation, so I'd start with something like:

int32 new_periodictime = periodictime * GetCaster()->GetFloatValue(UNIT_MOD_CAST_SPEED)

And i think that if you do what yavi suggested (multiply both with haste factor), new duration can only be slightly larger than periodictime*ticks, never smaller, because in C++ float to int conversion uses truncation.

At least unless people start activating unsafe math optimizations that affect rounding mode...so if you want to be absolutely sure, multiply periodictime with the amount of ticks, but i still have some doubts with using a float to calulate the ticks...

Oh, i noticed another thing. When you do:

float ticks = duration / periodic;

then the division is actually done as integer, since both variables are integer, and after that it is converted to float...so this line will never give fractional results anyway.

Arbitrarily crafted example:

Player has UNIT_MOD_CAST_SPEED value of 0.7294 (that's about 37% haste)

Let's take Blizzard (8000 duration, 1000 periodic time) and your calculations.

duration = int32(8000*0.7294) = 5835

diff = 8000 - 5835 = 2165

diff = int32(2165/8.0) = 270

periodictime = 1000-270 = 730

Now 8*730 is 5840 which is larger than 5835, the last tick would happen 5ms after the aura expired...

Hm i think you risk to lose the last tick with your calculations...integer math will lose the fractional parts on divisions, so be careful.

I think it's better to either recalculate periodic time by the amount of ticks and the new channeling time, or recalculate the channeling time by calculating the new periodic time with haste and multiplying it by the number of ticks.

Like you did it, periodictime*ticks can be greater than duration, which leads to loss of the last tick.

I still believe this health check simply must be removed, because Execute requires AURA_STATE_HEALTHLESS_20_PERCENT, so it already fails at aura states checking before even reaching this line.

I'm pretty sure i tried to explain that like two major patches ago...

I don't know if this check really has been necessary when it was added, but it definitely does seem redundant since ages.

No what he means is that after upgrading to 3.3 existing rogue characters still have stealth with rank other than 1 in spellbook, which they must not.

Though the fix is wrong IMHO, you'll attempt to create duplicate keys with that query. You have to delete old ranks from character_spell and set rank 1 active instead.

I just finished cleaning up the integer types (i hope), and made made sure unused bytes are not written as random garbage. Now vmaps should be identical on each run.

Any platform should now be able to read the vmaps that have been created on it, and existing vmaps from win32 vmap_assembler should still work on all little-endian machines (32bit and 64bit compiles).

I don't know if it builds without any modifications on windows, but the Makefiles already had all include paths set for the ACE integer definitions.

Would be nice to get some feedback.

I created a branch on my github fork:

http://github.com/Lynx3d/mangos/tree/vmap_cleanup

Next step could be bumping the vmap version and drop the unused bytes aswell as adding endian conversion so vmaps are truly cross-platform.

Since there's already "magic bytes" in the file headers, it can be made backwards compatible.

@kaio: Uhm...are you sure you posted in the right thread?

It always seems to reset to walk when you dismount...

As said, toggling walk/run fixes it, also engaging combat seems to, but each time you used your mount...pet becomes a snail again.

Aren't they in the G3D namespace?

D'oh...yes you're totally right.

It's just a matter of replacing "using namespace G3D;" with some more selective "using" directives.

Btw. i just used my above patch with [9175], still working fine for me on 64bit Linux. So i think i'll go from there and use fixed width integers from Define.h where apropriate.

Well if stdint.h was actually part of the C++ standard...but it's only officially part of C99. So assuming its existence somewhat just as portable as assuming that int is 32bit IMHO

Hm g3dmath.h which is indirectly included already also defines int32 etc. so including Define.h will probably conflict.

Though the definition in g3dmath.h is as sophisticated as "typedef int int32;"...so you might aswell just stay with (unsigned) int in vmap code...

Any good idea left?

It's 8 bytes on most 64-bit systems, as well as PPC archs.

Hm i beg to differ.

From http://en.wikipedia.org/wiki/64-bit

Data model  short    int    long    long long    pointers    Sample operating systems
LLP64       16       32     32      64           64          Microsoft Win64 (X64/IA64)
LP64        16       32     64      64           64          Most Unix (like Solaris) and Unix-like systems (like Linux)

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the LLP64 model.

But i agree, proper integer defines never hurt.

Maybe i'll try to make code more strict, am going to switch to 3.3 soon now

I worry that this still not let compatible results for platforms.

but sizeof(unsigned int) is platform dependent size

Well yes, the size of "int" is not set in stone, although it i can't name a relevant platform where it differs from 32bit...

As i said, it doesn't make the vmap code really platform independent because there's at least still the endian problem too.

The main goal was to make the code read and write the vmaps in the same format on the same platform.

Before, on 64bit linux for example, the written vmaps could not be read again on the very same system.

Since it uses sizeof(unsigned int) for writing and reading, it should work at least in this regard.

But maybe it's time for some bigger cleanup than this...

i've been thinking about trying to add something like that too, because there are unpretty things going on not only if you fly away.

If there's some vale or hill between you and the mob it will currently still just run to you in a straight line, either jumping through the air or sinking into the ground, and actually also die right there if killed with ranged attacks, possibly being unlootable.

Though you probably distort movement speed quite a bit by only adjusting the z value with constant horizontal movement speed...not to mention you'll have a lot of fun with proper vmap support-

Hm simply giving some percentage bonus is definitely not correct.

It seems to add a specific stats budget, depending on the level and type (flasks getting twice as much as elixiers, probably because they take both elixir slots at once).

For stats cost, see http://www.wowwiki.com/Item_level

For the northrend elixiers it's always 20.something budget points, e.g. 20 of some combat rating, 41 AP, 23 spell Power, 10 mp5, 280 armor etc.

For buffs that increase more than one stat, it seems to follow the same formular as items too, e.g. Guru's Elixier does not give a bonus of 20/5 = 4 to all stats, but 8 to all stats because the budget is calculated as (5*8^1.709)^(1/1.709) = 20.something.

The bonus of northrend flasks also matches the buff of Flask of the North, which you cannot use while having regular elixier/flask buffs, so Flask of the North is clearly designed to give you the same profession benefit where you cannot use flasks (read: arena).

Unfortunately there are very few comments about lower level elixiers and flasks, i cannot conclude a formula based on item level or required level to use yet.

I think miss chance against players is actually a lot more complicated than that. Since 3.0, there are diminishing returns for dodge, parry and chance to be missed that are gained from items stats (defense rating in this case). Hence you cannot calculate miss chance solely based on skill difference anymore.

For more information see: http://elitistjerks.com/f31/t29453-combat_ratings_level_80_a/

Also for some strange reason wowwiki gives two different formulas for the case where skill difference is below 10.

http://www.wowwiki.com/Miss says:

5% + (Defense Skill - Weapon Skill)*.1%

and http://www.wowwiki.com/Hit says:

5% + (Defense Skill - Weapon Skill)*.04%

If i may slightly bump this topic, i just came across the same problem and came to the same conclusion, period leech also needs to check if the aura is able to crit.

However i wonder if these lines from SPELL_AURA_PERIODIC_DAMAGE case also need to be added to SPELL_AURA_PERIODIC_LEECH (the resilience part has been added shortly after this suggested patch though):

06637             // send critical in hit info for threat calculation
06638             if (isCrit)
06639             {
06640                 cleanDamage.hitOutCome = MELEE_HIT_CRIT;
06641                 // Resilience - reduce crit damage
06642                 pdamage -= m_target->GetSpellCritDamageReduction(pdamage);
06643             }