Neo2003

Hello, I changed the ACE version, 5.8.2 is really the latest. I have made the linux part too (tested on Ubuntu 32 bits), changed the way I remove warning 4996 and also removed the warning about ACE_Atomic_Op without altering ACE files. In fact I changed in src/shared/Threading.h: private: ACE_Atomic_Op<ACE_Thread_Mutex, long> m_refs; Edit: I also used the sources that are in unix format, not MS crlf. I will upload the new patch as soon as I can (not possible from where I am currently). Neo2003

Hello, This is just an update of ACE. Currently MaNGOS uses version 5.6.6. I updated it to 5.8.2 I post it here because there is a warning about using "this" before initialization of the class, and I am a bit lost since they are Virtual classes (in src/shared/Threading.h). I patched the sources to remove C4996 warnings which already spam a log the compilation console with current MaNGOS and added the utf-8 fix. Changes are between // MaNGOS changes begin and // MaNGOS changes end. Tested to work on VC8, VC9 and VC10 with [10602][10605], I need someone to validate it on Linux. Here are the files: http://www.sendspace.com/file/p2381r Oct. 11th: New version 5.8.2 with Linux and all VC support: http://www.sendspace.com/file/3b2sq7 Oct. 21th: Updated the VC80 and VC90 project files the solution files to reflect 5.8.0 to 5.8.2 changes: http://www.sendspace.com/file/3xndih Drop the current dep/ACE_wrappers and use the provided one. Overwrite other files. Neo2003

Hello, I just added VC80 support and fixed the MANGOS_ASSERT problem in proper file. [ATTACH]63[/ATTACH] My very very little contribution. Neo2003

It isn't. If I understood properly, it builds the polygons only if a fixed clearance is available, meaning that you pass a "hardcoded" value to recast and then it produces the polygons that fit this value. On top of this it should also attach to each polygon the real clearance available above it so that there is only one polygons graph created. With this extra info, different path could be built for different object's high, depending on the clearance required.

On offy the path finding is not optimal at all and may fail easiely, then bliz desided to prevent hack: if a creature can't reach you in a simple manner, it becomes immunized to damages then reset health and return to spawn point. With navmeshes, I am sure this will occur a lot less than on offy. I think it's not a necessity here to make the navigation as bugged as on offy, at least not on purpose. Moreover, I am very impressed by the progresses made here. It you look back 1 year in past, we where loading maps and vmaps objects then using a start point to put a point on the ground, then using ray of light to draw the next one... until the grid was full of points... in a BSP-Tree.. And when we did the meshes, we connected the points to make triangles in such a complex tree that it was impossible to make a usage of the data. Now you have a nav-mesh using polygons... I would be pleased to see the same on offy Last note on this (this is maybe done, I did not look at the sources) don't forget to put the high available on top of each polygon attached to the polygon, then the navigation system may know where for example under a small bridge a npc can go and a vehicle cannot. This is also usefull later for flying mobs since you can extend the meshes to "3D" by extruding the polygons in Z direction.

Deathbringer's Will only can proc on physical damages, so if a caster gets this trinket it won't proc until the caster does physical damages, so in mele most probably, then if will most probably never happen. If you have confirmation that it procs haste when used on a warlock, I personally think it's safe to proc this for all casters since this trinket is really useless for them. I can only imagine an elementary chaman who goes in mele range(!) getting one use of this trinket if really he does not even have a lvl 150 caster one Shorter answer: a caster has no chance to get this trinket (ICC 25) except by .item add, so proc haste or nothing for them

I also think this does not apply to 5 men instances, only raids. Moreover, you cannot enter if a boss (level 3) is engaged but you can enter freely when the group fights with trash mobs only.

If you have a PC with around 4GB memory and a 32 bits Windows, compile the extractor with "large address aware" settings and activate "/3GB" inside your C:\\boot.ini OS file. This will just let it use 3GB of memory instead of 2GB by default. Btw I think this is only an interim problem like when I was writing the old version that used 2.8GB of memory just for Stormwind data while at the end it required much much less memory for the same work. Don't forget this is under development.

What bug does the patch fix? What features does the patch add? Just update MySQL libs to latest stable (5.1.49) For which repository revision was the patch created? 10371 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. None I know Who has been writing this patch? Please include either forum user names or email addresses. I compiled Mysql server from enterprise 5.1.49 sources with VS 2005 SP1 Pro. Hello, This is the update part for MaNGOS: http://www.sendspace.com/file/t3aioe Drop current dep/include/mysql folder and use the one included. It's aleady "pragma pack" fixed. Overwrite all libmysql.dll and libmysql.lib in dep/lib with the respective win32_release/win32_debug/x64_release/x64_debug ones provided. Please test and report any problem found. I won't commit it myself since I don't have any GIT tool anymore installed. Neo2003

4) Cheat-checks Tag: xor, seed, codes, results [To be written]

3) Loading and playing a module Tag: win32, libraries, import, export, object data [To be written] Since I won't have time to write more before Monday, this is some files to play with: * My version of Tiawps that run modules to decrypt all traffic It also save modules found in packets but is used to digg the modules so display many addresses Updated 2010-05-11 VC80 (2005) project files and solution added. * A capture with which I play a lot * clientcache.wdb extractor to get encrypted modules

2) Warden trafic encryption and modules Tag: MD5, RC4, SHA1, ZLIB, RSA Opcodes 742 (S->C) and 743 (C->S) are encrypted with RC4. There is 2 keys for this, one for 742 and one for 743. Before entering into the encryption of the packets and how to get the keys, I have to expose a bit what the warden traffic is. a) decrypted traffic The packets always follow the same order - SMSG_WARDEN_DATA (742) type 00 (module info) with a module MD5 and the module RC4 key to decrypt it and module length. (*1) Optionaly [ - CMSG_WARDEN_DATA (743) type 00 (load failed) if the client does not have the module yet - several SMSG_WARDEN_DATA (742) type 01 (module chunk) until the module is transfered. (*2) ] - CMSG_WARDEN_DATA (743) type 01 (loaded) (**) - SMSG_WARDEN_DATA (742) type 05 (seed) (*3) - CMSG_WARDEN_DATA (743) type 04 (seed transformed) (*4) - SMSG_WARDEN_DATA (742) type 03 (setup data) Ex: http://paste2.org/p/816264 ==> http://paste2.org/p/816274 And then begin the alternation of - SMSG_WARDEN_DATA (742) type 02 (cheat-checks) - CMSG_WARDEN_DATA (743) type 02 (cheat-check results) every 1 minute until you disconnect. b) 2 sets of 2 keys: first set I wrote in first part that the warden module uses his own set of keys to encrypt the traffic. You see in the packet sequence wrote above that the module is ready to work only at step (**). This means there is an initial set of keys. This initial set of keys is based on the session key as follow: The session key is 40 bytes long. The pair of RC4 keys (one S->C and one C->S) are generated based on the 2 half of the session key. I will not post the code here. it's SHA1 manipulations, around the session key parts in order to generate 2 keys 16 bytes long each and used as base with RC4_init() to create 2 full 258 bytes keys. I suggest you take a look at warden_set_initial_keys function I wrote in warden.c in the source I will link in last post. You end-up with 2 RC4 keys 258 bytes long. c) 2 sets of 2 keys: second set After point (**) the module is loaded by the client, then it will be used to encrypt the traffic and will expose his keys to the client to decrypt incoming packets. The module export directly the 2 RC4 keys 258 bytes long (256 data + uint8 x + uint8 y). To decrypt the traffic, the C->S new key has to be used after point (*3) and the S->C key has to be used after point (*4). Note: the packet order is very important since using a RC4 key to decrypt a packet alter this RC4 key and make it ready for next packet. As a middle conclusion, you see that you can't decrypt the traffic after step (*4) until you are able to run the module and ask it for the new keys set. d) the module - Raw module (.bin) The first warden packet coming from the server contains a module MD5 (16 bytes long) this MD5 is the way to identify the module. it also contains the RC4 key to be used to decrypt the module. There is 2 ways to get the raw encrypted module: * You extract clientcache.wdb (it's what client does when he does reply immediately 743 type 01 (loaded). * You assemble the module chunks sent by the server together until you reach the module length Since we use the MD5 of the module as name, you end-up with something like C128B52AD08980F905A2FCD5FF7424D1.bin around 17-19Kb in size - decrypted module Use the 16 bytes key given in first packet and build a RC4 key with RC4_init, then use this RC4 key to decrypt the module. - striped module The result of this is still a 17-19kb long piece of data. The last 260 bytes contains "SIGN" + 256 bytes with a RSA footprint of the first part. If we get the "SIGN" char[4] at end-260, we consider the data valid and we just drop the last 260 bytes. This signature is what prevents anyone from making the client able run a custom module, I think client only has the public key to verify the footprint and only blizz has the private key used to create it. TOM do you confirm? - deflated module (.mod) Just use zlib to expand (inflate) the module, you read the first uint32 which contains the size, allocate it and expand the rest in this allocated space. You end-up with a piece of win32 compiled library around 26-34Kb Let's keep it as something like C128B52AD08980F905A2FCD5FF7424D1.mod I know I explain this a bit out of order, but this is the way I understood it. The next part will explain how to play with this win32 code and finally run part of this code to go post steps (*3) and (*4) in traffic decryption they further. [To be corrected or expended]

Hello all, As the title states, it's my turn to expose Warden and share what I did and found around it. I will make several posts in order to split explanations in parts and to not bother TOM reading all Note that I won't post on how to make the warden blind, and the goal of these posts is not to provide a hacking how-to. This first part is focuses only on describing what is called "Warden" 1) What the warden is The warden is a peace of code inside the client which discuss more or less directly with this official server with its own encryption. The discussion between the warden on the client and server is done exclusively in opcode 742 (client to server) and 743 (server to client). Even if the session is encrypted, these warden packets are encrypted more. The warden on client is a hoster for some libraries sent by the server. These libraries are win32 compiled part of code which are around 30kb in size and that we call modules. Each module embed his own encryption algorithm to encrypt the warden outgoing packets. From what I did read, there is an unknown number of different modules, and each module is written / compiled in several form so that a reverse engeneering is very difficult. It's this module sent by the server which is used to do the check tasks on the client, to provide the decryption keys for the client to decrypt incoming warden packets, and the module encrypt outgoing packets itself. The overall goal of this warden functionality is for blizz to ensure: * Wow does not run in a debugger * There is no hook between the client MPQ reading function and the MPQ themselves * Wow read-only memory remain unaltered * No LUA banned addon is installed * No hacking drivers are installed * No known cheating process is running (I did not see this in use) Practically, all these checks are done by the module itself and the server requests a new set of checks every 1 minute. [To be refined, corrected or expended]

This part is wrong. If you are a Draenei you have the buff on you always whatever you are in a group or not. (I play a Shaman Draenei and a DK Draenei on offy).

Hello woweur, Last time I looked into this problem about mobs on transports, I found that transports are just moving maps like 588 which is 'Transport: Menethil to Auberdine'. I could not take a look at your code since I cannot access filebin from here, but spawns could just be added to normal creature table with coords related to this moving map I think. Then the movement packet sent has the movement related to the base map and transport entry has follower reference. Then when I tried to make a patch, I just added a column to transport table to know the map id and be able to make the movement packet properly. Btw I did stop because I did miss time and it was not as simple as I thought to make all movement handlers still work when mobs were on transports. My 2 cents. Neo2003

Hello all, I had some free time and wanted to work a bit on this project again Here are files updated to run with current maps/vmaps. I am not able to make a diff since the GIT repository is very strange and all files have end line problem. src/mmap/GridMapManager.h: http://pastebin.ca/1821114 src/mmap/GridMapManager.cpp: http://pastebin.ca/1821115 And some changes to be done to fix bugs: In src/mmap/MoveMapBoxContainer.cpp line 361, inscrease the mmapname char array a bit, it's too short. char mmapname[25]; And a cosmetic one: In src/mmap/MoveMapBoxContainer.cpp line 352, add a line feed: printf("Processing %s\\n", filename); For the viewer to work, remove this *40 in src/viewer/ModelContainerView.cpp line 62 iVARAreaRef = VARArea::create (settings.window.width * settings.window.height * 60 + 8); and forget about the command "load *" Anyway, it seams to me that settings.window.width * settings.window.height * 60 is completly non sens, this VarArea should have the size of the objects we put inside, not related to window size if I am correct. Have fun going on with this project Neo2003

On my point of view about the algorithm to be used for searching a path, I would also recommend a LRTA* like (Learning Real Time A*), but not right this one, better use MTS (Moving Target Search) which is LRTA* on moving target (like pet following a player who has jumped above stair). MTS just reduce itself to LRTA* when the target is fixed.

Hello, I still cannot get source behind a http proxy which requires auth. I export the http_proxy value successfully but these do not support http: git://git.assembla.com/mangos-mirror.git git://gitorious.org/mangos-mirror/mangos-mirror.git git://mangos-mirror.git.sourceforge.net/gitroot/mangos-mirror/mangos-mirror I always get something like: fatal: [url]http://gitorious.org/mangos-mirror/mangos-mirror.git/info/refs[/url] not found: did you run git update-server-info on the server? And http://github.com/mangos/mangos.git has the following problem: Initialized empty Git repository in /home/stephane/mangos/.git/ got 23ddaba9a863cbabf25281fc55940e94d6e3b1ff walk 23ddaba9a863cbabf25281fc55940e94d6e3b1ff got eee42e2f5821775412d70f8ad0c5fb19d3f71126 got 815000938eee183aad4ba731cc31f0096909b325 walk eee42e2f5821775412d70f8ad0c5fb19d3f71126 walk 815000938eee183aad4ba731cc31f0096909b325 Getting alternates list for [url]http://github.com/mangos/mangos.git[/url] Getting pack list for [url]http://github.com/mangos/mangos.git[/url] got 098de341b62b4cb9b2f3c8eb062e2e4aebd21c88 got a894943d091f527e6c494f1811ba35cdd50796e1 Getting index for pack 69e69e44777b1b7ead3e67e7c9437425a66f241b got 1d2a4c43a9db140417adec733cfb61dc258504c6 got 1e38a1788b9de8a6d1cd39fa12ee2e7e333b3b34 got 270ba19c2ba116b12c0316645a9b2918ab4dc449 got 37521422f0f69a8b2c49bdc1f0993c881f9046c1 Getting pack 69e69e44777b1b7ead3e67e7c9437425a66f241b which contains 7367b1e2d9179b9969979c10f8fa739bc126669a error: Unable to get pack file [url]http://github.com/mangos/mangos.git/objects/pack/pack-69e69e44777b1b7ead3e67e7c9437425a66f241b.pack[/url] The requested URL returned error: 502 error: Unable to find 7367b1e2d9179b9969979c10f8fa739bc126669a under [url]http://github.com/mangos/mangos.git[/url] Cannot obtain needed object 7367b1e2d9179b9969979c10f8fa739bc126669a while processing commit 815000938eee183aad4ba731cc31f0096909b325. fatal: Fetch failed. Seams like git and http don't like each other.

I do agree on this. It's more a matter of converting code to mangos patch and adapt to proper mangos code style and quality. In any case, there is no need to duplicate studies already done.

Offy servers are offen lagy, you get the "That would be stealing!" when you try to loot a corpse (you are allowed too) and someone else in your group (which was allowed too) did loot everything on the mob at the time server receive your click. The happens also when you try to mine a corpse and someone else already did faster than you. For "You do not meet the requirements to loot that item", it's in the rolling part. When you have the loot window open and you try to pick an item for which rolls have not completed or you did not win. This happens mainly because offy has a small bug. Sometime the server does not send loots to the winner. The winner has to go loot the boss again to get the item, and if you auto-loot the boss to get the quest items for example, you get the message telling "You do not meet the requirement" about the other loots still on the boss.

I think proper content of firebomb.sql should be this instead of current. There is missing 11 for event_type and one 0 to remove. -- Execute on MaNGOS DB -- Fire bomb script DELETE FROM `creature_ai_scripts` WHERE `creature_id` = 18225; INSERT INTO `creature_ai_scripts`(`creature_id`,`event_type`,`event_inverse_phase_mask`,`event_chance` ,`event_flags`,`event_param1`,`event_param2`,`event_param3`,`event_param4`,`action1_type`,`action1_param1` ,`action1_param2`,`action1_param3`,`action2_type`,`action2_param1`,`action2_param2`,`action2_param3`, `action3_type`,`action3_param1`,`action3_param2`,`action3_param3`,`comment`) VALUES (18225,11,0,100,0,0,0,0,0,11,31961,0,4,0,0,0,0,0,0,0,0,'Fire Bomb Target cast Fire Bomb on Spawn'), (18225,11,0,100,5000,0,5000,0,0,37,0,0,0,0,0,0,0,0,0,0,0,'Fire Bomb Target Despawn'); UPDATE creature_template SET AIName = 'EventAI', ScriptName='' WHERE `entry` = 18225;

I don't talk about coding style since I did not even read the code. The fact is that this bot is probably a functionality that can be included since Offy seams to have same kind of bot too. But the way it currently uses a user account and a character is the reason it was never considered.

That is a good news. If you finally use one/several auctioneers NPC to sell/buy items, then this AH bot patch may be considered to be included in core.

It's probably not a so good idea to add again fields to creature_template for vehicle. There is maybe 150 vehicle on around 27000+ template, so more fields = wast of space in memory and more time to query from DB. Btw, this apply also to some existing fields mainly unused and not in SMSG_CREATURE_QUERY packet like pet spellid and totem spells. We had a long discussion on UDB dev channel between some devs about this. Nofantasy and me think that a new table should be made to host all Totem/Pet/Vehicle data and get rid of some fields in creature_template like spellx and petspellid. This is not the purpose of this patch in any way, but just consider not adding fields to creature_template. When we find the existing flag in template which tells if mob is a Totem/Vehicle or Pet I will make another post to explain more what we discussed.

I checked again and your right, the don't run but walk fast. I will try to make same for both when they flee and when they return.