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.