Jump to content

SWGuard

Members
  • Posts

    18
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

SWGuard's Achievements

Member

Member (2/3)

0

Reputation

  1. 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?
  2. 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.
  3. 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?
  4. 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.
  5. 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
  6. 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.
  7. 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).
  8. Thanks for the reply. I'll take a look at "charm effects" when I can get my server up and running again.
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. Thanks for the explanation, that makes sense. I did change the code to check for NULL instead of simply crashing itself. Works better, IMO.
  15. 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
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use