SWGuard
-
Posts
18 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by SWGuard
-
-
Curious why the structure for CreatureFamily considers field 1 the "minScale"
Using a DBC table viewer, it shows that as a foreign key to PetPersonality.dbc and clicking on
the "1" in that field, brings you to a table that shows happiness values and the damage bonus /
penalties for each happiness rating.
I understand this is now used primarily for Hunter and Warlock pets to get the correct size per
level but after reviewing it, I don't believe it is the correct approach.
Assuming you use the DBC data for size info, the min/max is the same for Warlock pets which
indicates they should never change (and on official they don't) but the current new code will make
them grow.
Sorry I don't have any suggested solution as of yet but I thought I'd open it for discussion.
-
Greetings,
I noticed today that the flag UNIT_STAT_ATTACKING has been changed to UNIT_STAT_MELEE_ATTACKING
and the function Unit::Attack() has been changed from:
Unit::Attack(*victim, bool playerMeleeAttack)
to
Unit::Attack(Unit *victim, bool meleeAttack)
The problem with this is pets that are caster pets should not get a UNIT_STAT_MELEE_ATTACKING flag
but the Attack() function no longer sets UNIT_STAT_ATTACKING for casters which the old one did.
The new PetAI calls Attack() with a "true" value for bool meleeAttack but again, this is incorrect for
caster pets (I'll be changing this with the PetAI updates).
I think Unit::Attack() would be better handled by using an enum for the function parameter to indicate melee attacks
or ranged attacks and then set either a melee attack flag or ranged attack flag...
Something like this:
enum AttackTypes { ATT_MELEE = 0, ATT_RANGED = 1 }; Unit::Attack( Unit* victim, AttackTypes attackType) { // normal code here if (attackType == ATT_MELEE ) addUnitState(UNIT_STAT_MELEE_ATTACKING); if( attackType == ATT_RANGED ) addUnitState(UNIT_STAT_RANGED_ATTACKING); // normal code here }
The fix for pets reaching far targets may not work without this since caster pets shouldn't have a MELEE_ATTACKING
flag. I haven't tested it yet, just brainstorming.
Thoughts?
-
Greetings,
Not sure if this is a core or DB issue so before posting a bug report I thought I'd get some
input from the community. I will provide GUIDs and other information if and when an
actual bug report is filed. For now this is just an overview.
The issue:
Trainers that also give quests don't display the proper mouse-over icon after you accept
their quest.
Example(s)
The Hunter Trainer in Stormwind
The Paladin Trainer in Goldshire
Both these trainers offer quests (Hunter: level 10, Paladin: level 12) as well as training.
Until you are the correct level to get the quest, the mouse-over icon for them is a little
book. Once you can obtain the quest (or actually take the quest) the mouse-over icon
changes to an "!" and stays that way.
After the trainer no longer has a quest for you, the icon should change back to the book
type icon. Is this a core issue or is there some flag that needs to be toggled in the DB
after you accept the quest?
I'm leaning toward a core issue since toggling a flag in the DB would break the NPC for
people who don't yet have the quest.
Thanks
PS:
To reiterate, I will provide NPC names, locations and GUIDs when the proper place to file
the bug report is determined.
-
Greetings,
I was looking at my vmaps folder and was curious about a couple things:
1) Do we need the .vmdir files?
These appear to hold nothing but a reference to the actual vmap. I haven't looked in the core but are these
actually used or does the vmap load directly based on it's filename?
2) If we do need the .vmdir, what happens with vmaps that don't have one?
I noticed a .vmap for BT which doesn't have a corresponding .vmdir file:
564_xxx_0000015.vmap
Will this vmap not load without the .vmdir? If it does then why would the other vmaps need .vmdir files?
If it does need a .vmdir then why didn't the vmap_extract / assembler create one?
Note: the "xxx" above is the name of the instance. I removed the name to avoid copyright issues
-
Greetings,
I saw the following comment in SVN for rev. 6042 that I don't quite understand:
"Move 5 sec after last cast rule to unit code and apply it to creature/pets casting"
Is this related to delay in mana regen after last cast? If so, I don't believe that gets
applied to NPCs or pets but only players.
-
Greetings,
While testing my PetAI code with a Warlock, I noticed that DOTs are not being handled by MaNGOS
correctly for any unit.
If a Warlock casts a DOT on you, the Warlock gets added to your attacker list through: Unit::_addAttacker().
The problem is that Unit::_removeAttacker() never gets called for that same caster if you drop combat without
being killed.
This causes problems with any function that checks your attacker list (m_attackers) and returns m_attackers.begin()
because that Warlock will always be in the list (until you die in which case all attackers get erased).
Here's a scenario where this becomes a problem for pet classes:
1) Warlock casts a DOT on you and is added to m_attackers
2) You do nothing but stand around
3) Some random mob attacks you
4) Your pet calls owner->getAttackerForHelper() to defend you
5) m_attackers.begin() returns the Warlock because it's on the top of the list but it should be attacking the random mob
So, should getAttackerForHelper() return m_attackers.end() instead so you always get the most recent attacker
or should we put code somewhere (like ClearInCombat) to remove the DOT caster?
I wrote a function: getAttacker() that does return m_attackers.end() but this seems incomplete to me because the DOT
issue itself still hasn't been remedied. The caster remains with you forever until you die or perform some action that
clears your attacker list (like take a flight somewhere or log out).
-
Thanks for the reply. I'll take a look at "charm effects" when I can get my server up and running again.
-
Greetings,
I'm doing the final testing on my Improved PetAI and wanted to make sure I covered all the bases. In my
code I check to see if victims are pets or players with pets / charmed pets. I then check to see
if it's controlled (if pet or charmed pet).
For the purposes of PetAI, do only units that qualify as isPet() use that? I'm just curious because it seems
like a waste of CPU cycles to check ( isPet() || isCharmed() ) if Charmed pets never get a PetAI.
I tried using Mind Control but none of my "sLog.outDetail" items printed in my console so I assume those
don't get a PetAI? Or perhaps it's because Mind Control is kinda broken?
In other words, would the PetAI as far as aggressive / defensive only apply to Warlock / Hunter pets? If not
kindly list which types of pets use that AI so I can test them.
Thanks
-
Greetings,
I wanted to use 'isLineOfSightCalcEnabled' that's in the VMAP::IVmapManager to determine
if I should check LOS before allowing pets to attack but I wasn't able to get a reference to
the IVMapManager using a unit / creature / world / map object.
I realize I could add the #include and create my own function but I thought I'd check here
before doing that for a single function that already exists somewhere else.
My feeling is it's counterintuitive to be checking isInLOS() if LOS isn't enabled but I didn't
see any other method for determining that.
What I was looking to do is add a line in the LOS checks that simply returns true if LOS
isn't enabled, otherwise it performs it's normal duties. After all, if the user doesn't want to
use LOS it doesn't make sense to be checking LOS all over the place and failing things for it.
Thanks.
-
To be honest, the thing that annoys me the most is that Microsoft doesn't even offer this
DLL for download. I wouldn't care so much if I knew I was getting the DLL from a 'trusted'
source.
I have a copy of VS 2003 retail but I can't install it alongside VS 2008 since according to MS
they're not compatible. I suppose I could stop being lazy and search the CD for the DLL
-
To update using the patch file with Tortoise SVN:
- * Right-Click on the root folder that contains all your MaNGOS core subfolders / files
* Choose 'Tortoise SVN' then 'Apply Patch'
* Browse to and choose the patch file
When the patch preview opens, you can right-click on one of the patch files listed in the
small dialog and choose 'Patch All' or you can just do each file one at a time
For example:
If I've checked out MaNGOS to: C:\\SVN\\MaNGOS\\rev 5787\\
I'd see a bunch of subfolders listed in 'rev 5787' such as: .svn, bin, doc, dep, src
You'd want to right-click on the "rev 5787" folder and choose "Apply Patch" since this is
the root that contains all your MaNGOS subfolders.
- * Right-Click on the root folder that contains all your MaNGOS core subfolders / files
-
Greetings,
Not a pressing issue but rather a small request. MaNGOS for some reason requires the Visual Studio 2003
debug runtime msvcr71d.dll.
I saw a few old threads about this from last year but it still hasn't been updated. Since we're now into VS 2008,
would it be possible for someone to update the core to use the newer debug dll? I'm not really sure which part
is asking for this DLL or I'd fix it myself
I had a hard time finding msvcr71.dll online and even though I found it, I was reluctant to download a DLL from
a source I don't know.
Thanks
-
Thanks for the explanation, that makes sense.
I did change the code to check for NULL instead of simply crashing itself.
Works better, IMO.
-
Greetings,
Putting the finishing touches on my improved PetAI when I ran into a strange issue.
In PetAI::UpdateAI I have the following code to determine if a pet on "stay" can
still attack it's victim:
if(i_victimGuid) { // Pet has a target if( !i_pet.GetCharmInfo()->HasCommandState(COMMAND_STAY) ) bShouldAttack = true; else if( i_pet.canReachWithAttack(i_pet.getVictim())) bShouldAttack = true; }
You'll notice this calls the following function (which I did not write):
bool Unit::canReachWithAttack(Unit *pVictim) const { assert(pVictim); float reach = GetFloatValue(UNIT_FIELD_COMBATREACH); if( reach <= 0.0f ) reach = 1.0f; return IsWithinDistInMap(pVictim, reach); }
It is in this function that pVictim is sometimes NULL (0x00000000). What I'm confused
about is if my pet has a victimGuid and a victim (i_pet.GetVictim()) then why / how does
pVictim go out of scope in "canReachWithAttack"?
I have a fix for it but I'm just not seeing why it's happening in the first place. I'm thinking
it's because the victim has died and my pet's victimGuid hasn't been cleared but the victim
no longer exists.
I plan to replace the "assert(pVictim)" with an "if(pVictim)". The function will still work and it
won't halt the server if the victim is invalid.
Your input would be appreciated.
Thanks
-
Posting some new information:
It would appear after some more debugging, defensive is not acting like 'aggressive'
so to speak but rather the pet is simply attacking too early.
It seems that the pet on defensive attacks anything that targets either the pet or
the owner, as soon as the mob aggros. When this happens, your pet runs out to
meet the incoming attacker.
The way this should work is your pet on defensive should only attack if
either the owner or pet receives damage (in case of melee or spells) or has a
harmful spell / debuff cast on them (such as a curse).
So what needs to be changed in the core is to only have defensive pets attack
on damage taken or debuffs cast, not on aggro gain. I've been unable to pinpoint
exactly where in the core that aggro is initiating combat though.
-
Greetings,
Before tackling the Beastmastery talents, I thought I'd take a stab at fixing the fact
that pets on 'defensive' behave as if on 'aggressive'.
With your pet on 'defensive', if you walk within 10 yards or so of a hostile mob, your
pet will take off to attack it even if the mob didn't initiate combat.
I started debugging here: PetAI::UpdateAI() but quickly learned that by the time this
function is called, my pet is already attacking the mob. I then tried some tricks in
Unit::Attack() but unfortunately it always reported me as "in combat" even though
in the game I wasn't.
I also tried a few other functions where I tested things like owner->isInCombat()
and tested for GetCharmInfo()->HasCommandState(COMMAND_ATTACK) and / or
GetCharmInfo()->HasReactState(REACT_DEFENSIVE) but each attempt failed for
some reason or another.
Would one of the devs. be so kind as to explain a bit how the AI works? Where exactly
does it decide "hey, there's a hostile target"? It seems to me there's a function somewhere
that does this which needs to say "wait a minute, is my owner in combat?" and not attack.
Side note: No matter where I checked owner->isInCombat() it always evaluated to true
even though I was never in combat.
I'd like to get this fixed since it's one of the important aspects of a Hunter (pet control).
I don't mind taking a stab at it if someone could outline the sequence of events regarding
pet AI.
Thanks
-
Greetings,
While testing my pet family stats code, I noticed certain pets (such as Bears) walk much too fast.
In the official version they kindof lumber alongside you but in MaNGOS they sort of sprint.
Is this a database or core problem? I also noticed that their wild counterparts (before taming) are
walking their patrol routes too quickly.
Lookup Spell Adds Localization To Name?
in OldGeneral discussion
Posted
Greetings,
Just curious, I noticed that using ".lookup spell Wing Clip" shows results such as:
xxx - Wing Clip [Rank 1 enUS] [known]
or something to that effect (don't remember the syntax off hand). I'm cuirous if
the added "enUS" is something new with MaNGOS or the client (2.4.3). Also, will
the "enUS" be needed in macros now to cast spells?