BThallid

There was a patch for a chatlog/lexicscutter system that made me decide to put in just a simple chatlog system without the lexics cutter system. I know that there is a lot of controversial/stazi/spying issues that people may come up with, but do you think official doesn't log stuff like this? This patch is using the same log functions that were already there rather than recreating the wheel. It uses familiar log settings in the config file. It could use a little more sprucing up, but it does the job as is. The config option is default to be off. It has undergone basic testing. No load increase checking, but shouldn't be much more. Where to get it? With git at git://github.com/BThallid/mangos.git chatlog or browse

One way it could be used would be for authentication of external processes without the access to the database. I believe there were a couple of columns in the accounts table that are only there for reason of external authentication that accesses the database (primarily web applications). If SOAP was there for authentication, then those columns would no longer be necessary. I suppose it could also be interesting to see an interoperability between multiple development projects other than MaNGOS. Picture using MaNGOS for the login server and two different world server; one world running with MaNGOS and the other running with another. That would of course require the other project to use the same standards, but it would be a start already based on a standard. I have not looked at all the realm database updates that mangosd does. I was not aware of just how many different messages would be passing back and forth. I do see the point however of it being more overhead than needed when you already control both with the exception of possibly having external authentication for other applications.

Could/should realmd and mangosd communicate to each other via SOAP? I cannot remember which thread I remember it being mentioned in, but it was about how the realmd and mangosd don't talk to each other and why something couldn't be done. The mangosd process actually has to connect to the realmd database to update some things in that database. The SOAP protocol could replace this database access and perhaps fix the other issue of process communication. It's just an idea to bounce around.

Not to be rude, but specifically talking about editing DBC files in a MaNGOS forum has gotten it immediately closed. No editing of client allowed, because of various reasons that may or may not be listed in forum rules in an obvious form.

Perhaps an good addition for this would be an impersonate command so that a command that is normally accessed only from a logged in character but in a one line command accessible only from console, RA, or SOAP. Something along the lines of "impersonate #character [full character command such as namego, etc.]" that could be used in one line.

I was looking around at the dbc files just to get idea of what was stored in them with dbcEditer in contrib. I noticed that the SpellDescriptionVariables file column 2 looks like it is some sort of formula. Glancing through the source code I can't find if it is being used. I randomly picked out a row with 64 in column 1 and $bonus=$?s56807[${$m2*1.4}][${$m2}] in column 2. The s56807 seems to match up to in the Spell dbc with Glyph of Hemorrhage which increases Hemorrhage by 40%. The $m2*1.4 would be the original value? * 140%. Here are a few more (some are obvious, others not): $chance=$?s55439[${$m2+$55439m1}][${$m2}] 55439 = Glyph of Earthliving Weapon (Increase chance by 5%) $mult=$?s55673[${1.2}][${1}] 55673 = Glyph of Lightwell (Increase amount healed by 20%) $heal=$?a63279[${$m1*1.2}][${$m1}] 63279 = Glyph of Earth Shield (Increase amount healed by 20%) $opportunity1=$?s14057[${110}][${100}] $percent=$?s14072[${120}][${$<opportunity1>}] 14057 = Opportunity Rank 1 (10% increase) 14072 = Opportunity Rank 2 (20% increase) $aggression1=$?s18427[${103}][${100}] $aggression2=$?s18428[${106}][${$<aggression1>}] $aggression3=$?s18429[${109}][${$<aggression2>}] $aggression4=$?s61330[${112}][${$<aggression3>}] $percent=$?s61331[${115}][${$<aggression4>}] Aggression 18427 = Rank 1 (3% increase) 18428 = Rank 2 (6% increase) 18429 = Rank 3 (9% increase) 61330 = Rank 4 (12% increase) 61331 = Rank 5 (15% increase) This whole dbc may be irrelevant and meant only to be used by client, but I thought I would bring it up in case it would be possible to use in server code for lookup. A few of the variables remind me of a conditional operator. I'm not sure if any of it could be used, or if it was looked at before and decided against using it. The dbc itself appears to only have 27 rows in it, but the values range from 1 to 172 in column 1. Does anyone else see some possibilities here?

I had tested the idea of trying to have a member of a race from the opposite team react like a member of the other team (e.g. a human with an orc's reputation). The orcs didn't attack my human, but the reputation showed as being hated and at war. The visible reputations showed like the human was an orc, just hated. The PvP symbol for the human was showing as Horde when viewed from someone else, but at human client it appeared to be Alliance. I stopped at that point because I wasn't familiar with the section of code that controls that. It appeared to be client side though. I was storing the race faction in the db instead of retrieving it from the race, then the team from the faction. It would be interesting having traitors, maybe useless, but interesting.

Here is a patch for the changes for allowing the PseuWoW Client to connect to the newer versions. The config file needs to have the proper values put in as well. Index: WorldSession.cpp =================================================================== --- WorldSession.cpp (revision 377) +++ WorldSession.cpp (working copy) @@ -522,11 +522,14 @@ { std::string acc = stringToUpper(GetInstance()->GetConf()->accname); uint32 serverseed; + uint32 sp; + recvPacket >> sp; recvPacket >> serverseed; logdebug("Auth: serverseed=0x%X",serverseed); Sha1Hash digest; digest.UpdateData(acc); uint32 unk=0; + uint64 unk4=0; digest.UpdateData((uint8*)&unk,sizeof(uint32)); BigNumber clientseed; clientseed.SetRand(8*4); @@ -536,7 +539,7 @@ digest.UpdateBigNumbers(GetInstance()->GetSessionKey(),NULL); digest.Finalize(); WorldPacket auth; - auth<<(uint32)(GetInstance()->GetConf()->clientbuild)<<unk<<acc<<unk<<clientseed_uint32; + auth<<(uint32)(GetInstance()->GetConf()->clientbuild)<<unk<<acc<<unk<<clientseed_uint32<<unk4; auth.append(digest.GetDigest(),20); auth << (uint32)0; // TODO: this is not correct value, expected: 160 bytes of addon_data I played around with it a bit. I'm not sure if I agree with the way the GUI is initialized from the CLI. I would expect a separate CLI application and a separate GUI application. Possibly limit the CLI version to be used for administration/debug aspect instead of scripting. I think a git repository may be better for a project this large if it was to continue at least for the source code's sake from what I've understood between SVN and GIT. Anyhow, just my thoughts as an observate noob.

The section for getting the loot under Player::SendLoot helps with those situations where a creature was not attacked by a player, but is still within a certain level range (under the assumption that if the NPC is near the player's level, then they could have killed the NPC on their own if the other NPC wasn't there). However, if the NPC was attacked and killed by a pet, without the player hitting it, then another player could still take the loot. I used the value from the config of Quests.HighLevelHideDiff which has a default value of 7. Originally, I had hard coded this to 10. So, the part of the code that allows a similiar level player to loot if a player did no or less than 50% damage (possibly just 40% if we can get verification or agreed amount), should be taken out of this patch based on how it works on offi? So, if the NPC is PvP, it should work as it is already with first player to hit the NPC gets loot until death of the NPC?

On offi. in a non pvp realm where the NPCs are not PvP, would a player (non-PvP), where the NPC is well above the player's level by at least 15, receive the XP and/or loot from the enemy NPC after it was killed by the friendly NPC in situations A and B described previously? How does the PvP flag change the outcome in those two cases? I realize it may not be necessary to confirm how it is working on offi. if we are not wanting the exact results as offi. I am mainly just concerned as to how players can exploit the current existing functionality of the loot and XP to boost their levels faster and get a huge amount of loot from creatures well above them while other players are doing quests and various things to get their money and XP. This was my attempt to prevent that from happening, but still unaffect the non exploiting players. On a side note (using this patch): If the players were to actually take down a high level creature by damaging over half the NPC's max health, the player that dealt the most damage would actually still be able to receive the loot and xp (which was tested by using the .die command from a lower level GM to a much higher level NPC). Again, any pointers to improve the code are appreciated.

The area on my server that abusing players were using to grind on was south of Vengeance Landing (Bleeding Vale) where lvl 69 NPCs of both side were at using UDB 386. The Horde players that were lvl 35 or so would attempt to land one hit on the opposing NPC and they would get the xp and loot from the enemy NPC after it was killed by the friendly NPC if they landed one hit. It would be nice to know how offi responds to loot and xp when A. One npc kills another npc without the player hitting. Is the NPC lootable? B. One npc kills another npc with the player hitting. Is the NPC lootable and did the player get XP?

I just realized that I probably should have posted this in the core forum according to the description for it. I didn't not mean post patch to incorrect forum first. If the patches that are only up for review are supposed to be posted here, please forgive my mispost and move if possible/necessary.

•What bug does the patch fix? What features does the patch add? This patch is for ticket #12 on lighthouse. I've noticed on my server that there had been players exploiting the attacks between creatures. This is my attempt to fix it and had noticed there was a ticket for it on Lighthouse. It rearranges some of the code in the deal damage method and uses a damage total list to keep track of who took off the most damage so that the loot recipient is only set and xp rewarded if the player did enough damage. There is a more complete description of the patch on Lighthouse as well as the diff file for the patch. •For which repository revision was the patch created? 9278 •Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. Ticket 12 on Lighthouse •Who has been writing this patch? Please include either forum user names or email addresses. BThallid and whoever wrote the original ThreatManager code that I've adapted I submitted this here to the forum to possibly get more criticism brought to it. I mostly used existing code from the threatmanager, so I believe it should be pretty clean. However, it being my first work in C++, I would like to get more comments.