Lynx3d

Yes most likely a spell aura.

There was an UDB bug a while ago that gave players permanently this aura:

http://www.wowhead.com/spell=58932

I guess this was also in response to the "our company creates sloppy code" argument from before...just because one company produces shitty code doesn't mean all do or that we should follow them.

And since we are no company, you should understand that we neither are bound to create "production quality" code nor have "industry leading feature portfolio"...

Anyway, Kich0 already told the primary goal, and IMHO other projects of all kinds have sufficiently proven that stuff can easily fall apart if you accept any half-baked solution, for reasons already mentioned too...

hm...grep'ing gives:

GridMap.cpp:47: m_gridHeight = INVALID_HEIGHT;

GridMap.cpp:58: m_liquidLevel = INVALID_HEIGHT;

GridMap.cpp:481: return INVALID_HEIGHT;

GridMap.cpp:484: return INVALID_HEIGHT;

Is this expected?

Actually i wondered if he already has commit rights the other day, because his name showed up in so many commits

He has my vote...if that's actually worth anything

wait a second, in the first post you said you want to have 64373 cast on player, now you use 64886

For example, I am trying to fix the Shaman talent "Feral spirit'

Oh picking the "easiest" one right for the start...you only have to rewrite parts of the pet system for this...

It's impossible to make a tutorial for fixing spells like this one, because for most of the broken ones, there simply is no generic solution.

If there was, someone certainly would've already implemented them instead of writing a tutorial...but reality is, that the majority of the core code is required to handle some kind of spells.

Spirit wolves doesn't work correctly because the core doesn't support multiple controlled pets.

So it's not really the spell that is broken, it's the pets. Search around for pet related patches and you'll see how complex this problem is...

Okay...after looking at some spells, i agree with the patch.

Just took the freedom to name the enum values slightly different, because it seems more inline with the other names.

Just to be sure, the actual bug is that aura #138 increases ranged haste, but shouldn't.

That's basically one line to be removed, the rest is just more logical naming, does that sum it up correctly?

That's not a crash, it exits because your setup is incomplete...just _read_ the output.

While it may work, it looks very inefficient.

I'm not sure if the Auras from multiple rogues stack on the individual party members, but assumed they do, you can do some shortcuts.

If you look at the code for "Lock and Load" in Unit::HandleProcTriggerSpellAuraProc() you can see that even though the aura says 100% proc chance, the basepoints give the real chance, so you could try the same:

    switch(trigger_spell_id)
   {
       (...)
       case 52916:
       {
           if (!roll_chance_i(triggerAmount))
               return SPELL_AURA_PROC_FAILED;
           break;
       }

And in Aura::HandleAuraDummy() for 52916, instead of checking if target is a Rogue and search through his auras for the talent, maybe just check if your own aura has been casted by this target.

if "target != GetCaster()" you know this unit is not the rogue that gave you the aura.

A quick search says that the duration of all these spells gets reduced, no free mana efficiency by extra ticks (which wouldn't scale smoothly anyway).

So no reason to add hacks to it.

ACE is written in C++, so don't forget CXXFLAGS.

ACE_CFLAGS only seems to have an effect when not using ACE that comes with mangos sources

That would be worth a try too btw, use ACE that comes with Fedora...will compile faster anyway.

Just configure with --enable-builtin-ace=no

Well...how about adding commit notes (if you want) and exiting the editor?

I suppose you never saw VIM...which probably means you can't even figure out how to quit it.

It's supposed to be a text editor (opinions on its exact definitions differ...)

If you don't like it, configure git to use another one ^^

Or try git gui, if it's available on whatever variant you are using on windows.

http://en.wikipedia.org/wiki/Loopback

Using your network IP instead of the loopback device is like calling yourself and wondering why the called phone is busy...

And yea, not only realmlist in realmlist.wtf points to retail servers by default.

Added in [10756]

Though after all the testing and reading and writing related patch inbetween i totally forgot to add Agiko as original author...hope you can forgive me.

Commited version is only slightly different from proposed patch, so accepted.

Well i don't really like it either, because it wipes your unread markers pretty soon, just one closer look at a patch or some distraction in chat and you have to look at the dates of each thread.

I know some forums had settings for this, either the time until you're considered logged out or until unread markers are reset, but i couldn't find anything here...

And what do you mean by saying player aren't properly update as for now ?

Just go on a zeppelin, do NOT move and watch for creatures nearby...they will all disappear because the client does not send movement updates and so the server thinks you are still standing where the zeppelin started.

There's only some commented code in Transport::Update(), i guess i didn't really work, since no one implemented the actualy spline movement, so positions would be far off anyway.

We need better innovation from this community!

Sorry i forgot, what was the last innovation you contributed?

Code won't write itself. And writing good code is harder than adding lots of hacks that give the impression as if it was working.

I did briefly look at this stuff and IMHO there's not all that much to build on yet.

You don't need any weird extra table, transports do already have a "virtual" mapid assigned, it will be possible to spawn them like any other creature if you write proper core code.

Also the really difficult part is syncing transport movement properly, infact players are not properly updated either currently.

I see none of that really addressed properly here or in trinity...unless something has signifficantly changed lately.

what the heck is he talking about?

At least it compiles here on Ubuntu 10.04 AMD64

But i think the removed lines here are required to compile on i386, because that header is only available with gcc when SSE is explicitly enabled from what i remember:

 // SIMM include
-#ifdef __SSE__
#include <xmmintrin.h>
-#endif

In any case, a diff to the vanilla g3d code would be nice, i don't remember if i commented the changes i had to make for mangos.

Unfortunately, the devs don't seem to think any of the features that need additional 3rd party libs should be optional...

No but it gives useful infotmation like line numbers

*sigh*

If someone needs me, i'm banging my head on that table over there...

Alternative in [10621].

Separate fields are less confusing and more flexible.

This one is also accepted in [10608]...

The code from tsunamirus doesn't really seem correct to me, just took the slight simplification for dual-wield from it.

Okay...so thrown out the mysterious 0.02% case, the rest seemed good to me, also after testing with boss target dummy, so accepted in [10608].

Note that diminishing returns for player's defense rating is still not implemented, however the necessary parameters aren't really researched for all classes it seems

Also, DR for dodge and parry are much more important i think...

Also thanks Revil for looking into the non-weapon melee/ranged abilities, hopefully no more chain-missing judgements...

-edit-

I'm not really convinced that the 60% cap makes sense, but couldn't find anything on this...