BThallid

I apologize for the delay. It is available now for one.

I'm not sure if I understood you correctly. If you are refering to when you become a traitor, you can't click on the NPCs at first. This has to do with the client not receiving the reputation changes correctly. It was something I encountered before while working on it. It should work after logging out and then logging back in.

Put the branch name of traitor after the mangos.git part. It should be: git pull git://github.com/BThallid/mangos.git traitor

Please check the Source code section of the forum for help with basic using of git.

Traitor-zero is now available at git://github.com/BThallid/mangos-zero.git on traitor-zero branch Don't forget to apply SQL file to characters table. I did some brief testing with it. Last I checked, it didn't seem to have any conflicts. A merge should be clean, unless I'm just really missing something.

I am able to reproduce this 100% using a version of playerbot modification. The playerbot would play the part of the fast computer as the bot system has no loading to do for an instance. Steps to reproduce: 1. Set a server up using git://github.com/blueboy/portal.git with commit e188dacd30 2. Use an account with two characters (one for your use and one for the bot purposes) that are high enough level for an instance (I was testing Blackrock Depths) 3. Standing just outside of the instance portal to test, add the bot by using the command .bot add (2nd charactername) 4. Invite the bot to your party, the bot will auto accept 5. Walk into the instance portal, (the bot system mimics the CMSG_AREATRIGGER packet) load screen appears then finishes 6. Confirm that you see no other characters with you 7. Select an enemy 8. Party speak 'attack' (/p attack) 9. Watch enemies move towards invisible target and start attacking, which verifies that the bot is invisible to you but there You can have another player already in the instance before you enter with the bot, and the bot will show to the other player after you enter. I am not yet familiar with the way the code works for the m_clientGUIDs, but I think there should be a delayed packet send to anyone that is still loading. Delaying certain packets between the SMSG_NEW_WORLD and CMSG_SET_ACTIVE_MOVER packets might work. SMSG_NEW_WORLD signals the client to begin loading. I think the CMSG_SET_ACTIVE_MOVER packet is sent after the client is done loading everything and can be controlled by player. It might be a different one though. You would only want to delay certain packets though. Another odd thing, if you highlight the bot player icon, it displays the previous location as though the client still thinks the bot character is there instead. I suppose it could also be a case where the server just needs to send the packet that updates the m_clientGUIDs just after the player is finshed loading (after the CMSG_SET_ACTIVE_MOVER packet?). Would that be stored in the compressed or update packets? I hope this at least can give a good testing ground to help resolve this bug.

I have not looked at the sources for zero or 2.4.3. I will have to take a look at it some time.

I looked into part of this a while back before I was away. I had revamped the code for the bots to enter instances by using SMSGs at appropriate points or in response to other pieces (I am a strong believer in trying utilize the server handlers instead of trying to recreate the procedure inside). This process though brought forward a glitch that is in the core code to happen 100% of the time. The glitch in the core is when a you enter an instance with a group of other players, but some (or just one) of the other players are invisible to you. With the instance changes in place that I had, the bots were always invisible to the master. I could have another player already in the instance or enter after the bots were there and everything would be okay. The only way I was able to get around this was to put some delay code with an added bot state in the bot code to have them wait a few seconds before following after the master. After that, it worked great, but I didn't like the idea of using any delay code. I started to investigate which part of the core was the problem, but got busy with the real life stuff that happens to all of us.

It does restore the collection list anytime the SetQuestNeedItems is called (it is called when bots get brought online). That was the reason behind my recent adjustments to the portal/master to make it get called a little less by some of the other code. It might actually be able to be expanded to include game objects that just need to be interacted with (not looted).

Comparison of using hex to binary to dec: 0x0402 = 0000 0100 0000 0010 = dec 1026 0x0001 = 0000 0000 0000 0001 = dec 1 0x0040 = 0000 0000 0100 0000 = dec 64 Add the three together: 0x0443 = 0000 0100 0100 0011 = dec 1091 It's a bit easier to use the hex as opposed to trying to add the decimal values together or subtract back them out.

I've updated the loot-fix-bt branch to allow bots to automatically know what game objects to loot in order to get the needed quest item. For example, when your bot is on the quest Milly's Harvest it will automatically add the game object to the collect object list so that you won't even have to tell them survey and get. However, the way I have it implemented right now uses a SQL call for each item in the quest; it may actually cause a bit of overhead that will need to be reduced.

I marked this as partial patch because I quickly put this together when I saw some incorrect define uses. The patch does not contain SQL table update. Description: There is an error/overlook of the character_queststatus itemcount5 and itemcount6 being saved or loaded in the db. The m_itemcount is initialized with a size of 6 which is for QUEST_ITEM_OBJECTIVES_COUNT (6) not QUEST_OBJECTIVES_COUNT (4). I have not included the SQL statement for adjusting the database nor have I tested the patch (it only adjusts minor code). Most recent check of UDB data shows that there are 5 quests that use itemcount5 and 6 quests that use itemcount6 (the 5 that use itemcount5 and 1 additional). Bug reported: Searched forums, but did not find. For version: revision 11429 commit 0f0e430e... Author: BThallid Patch link: http://paste2.org/p/1401464 (does not include SQL table update)

There appears to be a typo with the ItemPrototypeFlags inside of ItemPrototype.h: - ITEM_FLAG_UNK30 = 0x04000000, + ITEM_FLAG_UNK30 = 0x40000000, I stumbled across while referencing flag names.

I have added some text to the bot_readme.txt file. I remembered to add the readme text for the sharedbots branch that was started but missed it on the loot-fix-bt branch. I have been a bit busier than normal on that real life stuff that we all have to deal with, but still have a couple of more pieces to implement into the loot-fix-bt branch before I will consider it finished. That and of course after any bugs are squashed. Blueboy has done an excellent job of keeping up with things on the repo and on the forum.

This is where sniffs would be helpful. Too bad I never checked for this while I was on. I noticed while working a bit with the packets that whenever I send the invite list inside of SMSG_CALENDAR_SEND_EVENT it freezes the client. I have noticed that sending SMSG_CALENDAR_ACTION_PENDING appears to reset the buttons on the interface (Create greys out but then becomes normal after a bit when this packet is sent). SMSG_CALENDAR_EVENT_INVITE_ALERT appears to just to flash the calendar icon near the minimap. CMSG_CALENDAR_EVENT_RSVP was sent when I right-clicked an event that the invite status was not confirmed (ie invited, not signed up) and selected a reason. Perhaps SMSG_CALENDAR_COMMAND_RESULT is used somehow. Also, how should the invite be handled when it is added on the event before creation is finished. It has the eventId as 0, but judging by the interface it should return some confirmation of whether the player exists. Perhaps that's where SMSG_CALENDAR_UPDATE_INVITE_LIST comes into use.

I was just now looking through some of the source on Infinity/core that you have helped on. I feel a bit sheepish now; all the info is already there. I had tried sending the SMSG_CALENDAR_SEND_CALENDAR before but had the packet structure all wrong so it would just freeze the client. If you really just wanted to trigger the packet handler, the playerbot code uses plenty of lines like m_bot->GetSession()->QueuePacket(packet); to have the bots simulate the packets being send to the server. I'm not sure if you have actually tried that or not. It is obvious that you are well ahead of me, but this will certainly give me a boost.

SMSG_CALENDAR_SEND_CALENDAR should be only sent when the client requests it with CMSG_CALENDAR_GET_CALENDAR when the client logs in. It's one of those initial type packets for setting up bulk stuff. If you don't specify a size, then the default size will be set at 200 based on WorldPacket(uint16 opcode, size_t res=200) inside of WorldPacket.h unless I'm misinterpreting the code (I am still learning). It is better to assign a size so that it is more efficient with memory and buffering. I've been playing around with the calendar opcodes as well for the past day (limited time within thereof). Some of the opcode structure research so far that I've come up with inside of CalendarHandler.cpp: DEBUG_LOG("WORLD: CMSG_CALENDAR_ADD_EVENT"); std::string eventname, eventdesc; recv_data >> eventname; // event name recv_data >> eventdesc; // event description uint8 eventtype, unk4; uint32 unk5, instance, eventtime, unk8, unk9, count = 0; recv_data >> eventtype; // 0=Raid,1=Dungeon,2=PvP,3=Meeting,4=Other recv_data >> unk4; recv_data >> unk5; // always 100? recv_data >> instance; // instance last selected for eventtype 0 or 1 recv_data >> eventtime; // event time recv_data >> unk8; recv_data >> unk9; // flags? 16 = Lock Event and DEBUG_LOG("WORLD: CMSG_CALENDAR_EVENT_INVITE"); ObjectGuid unkObj1, inviter; std::string pName; uint8 unk1, unk2; recv_data >> unkObj1; // event id? recv_data >> inviter; // player that sent invite recv_data >> pName; // invited player recv_data >> unk1; recv_data >> unk2;

I never claimed that it would fix anything. I just saw it as an intermission section for map loading and possibly other processes.

Just thought I would note on here that apparently this was placed into TrinityCore https://github.com/TrinityCore/TrinityCore/commit/e864b0a61176f30ca27961a564c77d5e5c3335b1 with the mention that it "Fixed naked bug for players" which I have not tested.

What does this patch do? Moves the SMSG_NEW_WORLD packet so it is sent after player m_teleport_dest is set and after TeleportFar is set. It seems that the server should do some of the work while the client state is in pending mode instead of just sending SMSG_TRANSFER_PENDING and then SMSG_NEW_WORLD directly afterwards. Rearranging the code like this will also allow the core to do other actions in the future during this intermission. Flow process: 1. Client is teleported to another map 2. Server informs client of pending status (SMSG_PENDING_TRANSFER sent) 3. Client shows load screen for pending map 4. Server removes client from old map, set m_teleport_dest, set teleport far to true 5. Server informs client of new world status (SMSG_NEW_WORLD is sent) 6. Client begins to load new map and loading progress bar moves (MSG_MOVE_WORLDPORT_ACK is sent) What revision/commit is patch for? 11260 - 9359c427 Who has been writing patch? me (BThallid) http://paste2.org/p/1323483 Updated 2011-03-24: Adjusted SMSG_NEW_WORLD for if on transport.

I've been thinking that in some ways it might benefit to use the SMSG_SPELL_START packet more and check it for spells that are cast by master or even enemy (possibly interrupt the spell too). This would make it so the bots would start mounting as soon as the player does instead of afterwards.

Concerning the collect command syntax: it could probably use some changes. Unfortunately, I have always been poor at the ease of use aspect. The collect command just gives you a display of what the bots are set to. The subcommands do the actual work: combat - bot will loot after combat for the options that are set loot - bot will grab all loot available from corpse quest - bot will grab all quest items on corpse profession - bot will grab any profession related item that the bot has from corpse skin - if you have skinning, and corpse has been looted, bot will skin corpse. Most of the time you may want this option and the loot option enabled, but if you are grabbing the stuff as you are going around, the bot will skin afterwards. objects - bot will collect things that are specified by the survey and get <shift-click> commands none - removes any collect options that have been set The default collect options that are enabled are combat, quest, and profession. The syntax is collect <subcommand(s)> (can be stacked with multiple on one line - e.g. collect loot skin). Each subcommand toggles that option; if you use collect loot once, it will set it, when you use collect loot again, it unsets it. I thought about using a negate/no option, but IMHO toggling works fine and is simpler. Opinions are welcome. get while a corpse is selected, will only do the collect options that are enabled. It was put in there for those that may not want the bot to loot after combat.

Not meaning to bump this, but would it better if a feature such as this would be handled through other means. For example, all functions required to do this should be able to be done by using GM commands and normal client clicks, why not attempt to use a modified version of PseuWoW. PseuWoW is already scriptable, it just needs a few pieces (possibly more) added to make it work doing something like this. Create one or two GM accounts (depending on one or two sided interaction) for using with PseuWoW that is allowed to use the needed additem command to add the items from a list. Perhaps I don't fully understand the extent of it, but if something could be done outside of the core, why not?

I'm not sure if all my ideas would be suitable for the repo. One part that I had been working on was to utilize more of the SMSG handling instead of accessing the core's functions. For example, sending a CMSG_CAST_SPELL packet instead of accessing the CastSpell function directly. Also, there is a leak some where in the handling of the get part of HandleCommand function that I was able to remove for mining and herb gathering by replacing it, but I still need to do further testing and add back in the rest of the get capabilities. I had also added in SMSG_SPELL_FAILED, SMSG_SPELL_START, and SMSG_LOOT_RESPONSE for various pieces of it. I was looking at moving all the buff related code into the function BuffPlayer(Player* target) but then renaming that function to BuffTarget(Unit& target) because more than just players could be buffed (escorts, pets, etc). The only additional check I was going to include was a function for checking if spell reagents were available. It might be a good to make it an option for the master to set whether the bot should use reagents or not. Here is the HasReagents(uint32 spellId) code that I adapted from the core's TakeReagents() function: diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp index 08d674e..b86fe36 100644 --- a/src/game/playerbot/PlayerbotAI.cpp +++ b/src/game/playerbot/PlayerbotAI.cpp @@ -2541,6 +2541,30 @@ bool PlayerbotAI::HasPick() return false; } +bool PlayerbotAI::HasReagents(uint32 spellId) +{ + const SpellEntry* const pSpellInfo = sSpellStore.LookupEntry(spellId); + if (!pSpellInfo) + return false; + + if (m_bot->CanNoReagentCast(pSpellInfo)) + return true; + + for (uint32 i = 0; i < MAX_SPELL_REAGENTS; ++i) + { + if(pSpellInfo->Reagent[i] <= 0) + continue; + + uint32 itemid = pSpellInfo->Reagent[i]; + uint32 count = pSpellInfo->ReagentCount[i]; + + if (!m_bot->HasItemCount(itemid, count)) + return false; + } + + return true; +} + // extracts all item ids in format below // I decided to roll my own extractor rather then use the one in ChatHandler // because this one works on a const string, and it handles multiple links diff --git a/src/game/playerbot/PlayerbotAI.h b/src/game/playerbot/PlayerbotAI.h index 8341580..eea1249 100644 --- a/src/game/playerbot/PlayerbotAI.h +++ b/src/game/playerbot/PlayerbotAI.h @@ -181,6 +181,7 @@ public: bool PickPocket(Unit* pTarget); bool HasPick(); + bool HasReagents(uint32 spellId); uint8 GetHealthPercent(const Unit& target) const; uint8 GetHealthPercent() const;

I tested this. Did you read my note after the code? I guess it was kind of vague, but I noticed the different totem categories myself. I used the army knife as a test for the bot before I submitted. Here is the mentioned code from the core: bool IsTotemCategoryCompatiableWith(uint32 itemTotemCategoryId, uint32 requiredTotemCategoryId) { if(requiredTotemCategoryId==0) return true; if(itemTotemCategoryId==0) return false; TotemCategoryEntry const* itemEntry = sTotemCategoryStore.LookupEntry(itemTotemCategoryId); if(!itemEntry) return false; TotemCategoryEntry const* reqEntry = sTotemCategoryStore.LookupEntry(requiredTotemCategoryId); if(!reqEntry) return false; if(itemEntry->categoryType!=reqEntry->categoryType) return false; return (itemEntry->categoryMask & reqEntry->categoryMask)==reqEntry->categoryMask; } It checks it already in the core.