This is a read only copy without any forum functionality of the old Modcraft forum. If there is anything that you would like to have removed, message me on Discord via Kaev#5208. Big thanks to Alastor for making this copy!
I was wondering what tools or things you would like automated to aid in your development process making content.
Things like going DBC <-> MySQL, doing data processing/transforming scripts, website scripts, and such. I can't really contribute to projects like Neo because I don't know about how 3d graphics and OpenGL works, and don't really want to spend so long learning it at this point in time, but I can automate manual tasks that are time consuming and help speed up development processes.
[paragraph:1wfg1q1l]The Hunger Games project is a server that is built around a single game mode. It utilises a Warcraft 3 styled interface for matchmaking inspired by the old . This is the only game mode that can be played on the server.[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]Upon starting a game, every player starts as the same generic class with equal stats and items at random locations on the map. The objective is to be the last person standing as you only have one life. There is a lot of PvE content within the island that will help you make your character stronger in order to defeat other players.[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]Players can use and unlock 'perks'. Each player can have up to 4 perks which will benefit them in a game. A image of perk selection can be seen below:[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]A day and night cycle (24 hours) takes 20 minutes exactly to pass in the game. There are different mechanics and perks that will benefit you at certain times of the day.[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]This project is a small and casual one. The primary objective is to get the first map done and playable with ranked and unranked play and leaderboards. This project is great because it can be extended easily with updates, such as allowing for different map selection and new mechanics and features.[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]The video below shows the prototype of the matchmaking interface:[/paragraph:1wfg1q1l] [media:1wfg1q1l]https://www.youtube.com/watch?v=mUOWkibcTAI[/media:1wfg1q1l] [paragraph:1wfg1q1l]Various other screenshots can be seen below:[/paragraph:1wfg1q1l] [paragraph:1wfg1q1l]Contributors to the project are currently:[/paragraph:1wfg1q1l]
Stoneharry
Foereaper
Hanfer
Terrorblade
[paragraph:1wfg1q1l]There is no date for completion as it is very much a casual project with simple objectives.[/paragraph:1wfg1q1l]
This is the first time I am writing a WoW interface from scratch and I am not sure on the correct way to relatively position elements so that they appear in the correct locations on all resolutions.
At the moment I have the following:
However at other resolutions it can break:
So my question is how do I get this to work at all resolutions?
On a side note, this happens when I set it to the lowest resolution:
The resolution I am detecting is correct and I set the background model to this resolution. Yet it isn't scaling to the resolution I tell it to at this low a resolution. The code I use can be seen below for this:
-- Set up background model local model = CreateFrame("Model"--[[, "BackgroundF", MainFrame]]); model:SetCamera(0); model:SetPoint("CENTER",0,0); --model:SetFrameStrata("HIGH"); model:SetFrameLevel(0); -- This gets the width/height of the screen local res = GetCVar("gxResolution") local vars = 1 for value in string.gmatch(res, '([^x]+)') do if vars == 1 then model:SetWidth(value) vars = nil else model:SetHeight(value) end end res = nil model:SetLight(1,0,0,-0.5,-0.5,0.7,1.0,1.0,1.0,0.8,1.0,1.0,0.8);
-- Set background model function mainFrameLoaded() model:SetModel("Interface\Glues\Models\UI_Orc\UI_Orc.m2"); end
Any help on either of the two issues (first being more urgent) would be greatly appreciated.
I was wondering what is the exact process to adding a new spell visual?
I have messed with the spell visual DBC's to try and create a new ID but I am unsure how it all links together and it is not easy to debug what you have missed.
Replacing existing M2's works fine so I know the model is fine. I need to add a new entry however and link it together somehow.
The executable has a .torrent file attached to the end of the file which can be extracted. It also has a MPQ attached that contains all the images the downloader uses.
The torrent file can be edited using any normal default torrent editor tool. However it also appears to have some unknown data attached to the end:
This seems to contain information such as the IP and file that is allowed to download this file (directly going to the URL will tell you that you cannot access that file). MD5, and such also appears to exist. There is also an image URL that overwrites the background for the Blizzard Downloader as well as the name of the file being downloaded.
I am requesting some clarity on all of this information:
Why there is two places the downloader can get the torrent from (URL & end of file)
The structure of the information at the end of the torrent file
Any other research done on the matter
With this information it should be possible to then just create a normal torrent tracker and to seed a torrent, then attach that torrent with the downloader info after to the installer executable.
I made a spell editor GUI. I made it for private use and rushed it, so the code is very bad and it does not support everything. But it is a base and a tool that people can use if they want to. :-)
It jumps from 1024 ro 1026 to 2048 which doesn't even follow the ^2 representation that is normally used for flags. This means flags cannot be combined properly if this was true.
I thought 1026 might just be a known flag combination (2 + 1024) but that doesn't make sense either.
Can anyone provide some insight into the correct flags? Tallis seems to have them but I was unable to find the structure definition in the source code for it.
TARGET_FLAG_NONE = 0x00000000, TARGET_FLAG_UNUSED_1 = 0x00000001, // not used TARGET_FLAG_UNIT = 0x00000002, // pguid TARGET_FLAG_UNIT_RAID = 0x00000004, // not sent, used to validate target (if raid member) TARGET_FLAG_UNIT_PARTY = 0x00000008, // not sent, used to validate target (if party member) TARGET_FLAG_ITEM = 0x00000010, // pguid TARGET_FLAG_SOURCE_LOCATION = 0x00000020, // pguid, 3 float TARGET_FLAG_DEST_LOCATION = 0x00000040, // pguid, 3 float TARGET_FLAG_UNIT_ENEMY = 0x00000080, // not sent, used to validate target (if enemy) TARGET_FLAG_UNIT_ALLY = 0x00000100, // not sent, used to validate target (if ally) TARGET_FLAG_CORPSE_ENEMY = 0x00000200, // pguid TARGET_FLAG_UNIT_DEAD = 0x00000400, // not sent, used to validate target (if dead creature) TARGET_FLAG_GAMEOBJECT = 0x00000800, // pguid, used with TARGET_GAMEOBJECT_TARGET TARGET_FLAG_TRADE_ITEM = 0x00001000, // pguid TARGET_FLAG_STRING = 0x00002000, // string TARGET_FLAG_GAMEOBJECT_ITEM = 0x00004000, // not sent, used with TARGET_GAMEOBJECT_ITEM_TARGET TARGET_FLAG_CORPSE_ALLY = 0x00008000, // pguid TARGET_FLAG_UNIT_MINIPET = 0x00010000, // pguid, used to validate target (if non combat pet) TARGET_FLAG_GLYPH_SLOT = 0x00020000, // used in glyph spells TARGET_FLAG_DEST_TARGET = 0x00040000, // sometimes appears with DEST_TARGET spells (may appear or not for a given spell) TARGET_FLAG_UNUSED20 = 0x00080000, // uint32 counter, loop { vec3 - screen position (?), guid }, not used so far TARGET_FLAG_UNIT_PASSENGER = 0x00100000, // guessed, used to validate target (if vehicle passenger)
To begin the patching process, the client logs into WoW and a patch is sent to them (see here: viewtopic.php?f=61&t=1771) or the user launchers the launcher.
The launcher is a executable file with an attached MPQ. The MPQ contains all the images of the launcher - overwriting these images with your own will allow you to change them.
If you open up the launcher with a hex editor, there are various strings to modify. At C8830h I found the window title (something like '%s - V%s - Title', representing 'World of Warcraft - V3.0 - 12340').
At D5B80h I found the URL's for the window display (originally: http://launcher.worldofwarcraft.com/2.0/index.xml). Note any file extension will work - I found XML did not load correctly so I used a php file.
Note that you need to keep the number of characters the same to maintain file integrity. Use full stops for empty space where required to fill up, and do not exceed the number of characters you have deleted to add your content.
The results are shown below:
Note that throughout this you can find logs of what is happening in the WoW folder. This is useful for identifying what is happening.
When the launcher starts up, it is going to look at the patch list file as described earlier. Upon finding a valid update, it will download it:
16:30:51.8109 Launcher version 2.1.1.1897 16:30:51.9211 Reverting to old PSF patching system. 16:30:52.3149 Fetch version information from 127.0.0.1 (http://127.0.0.1/update/PatchSequenceFile.txt). 16:30:52.3463 Received version information from http://127.0.0.1/update/PatchSequenceFile.txt. 16:30:52.3514 A game update is required. ... This will download the contents of the file you have targeted in the patch list file, and save it into wow-update.mpq inside your WoW folder. Note, this is the same result as receiving a patch through the WoW.exe as linked to earlier, and follows the same format.
Subsequently, for the patch to be installed correctly, the WoW.exe must be patched to allow unsigned patches (viewtopic.php?f=59&t=1829) and for the contents to contain a list file detailing what instructions to carry out.
My patch that is downloaded consists of two files, as does Blizzard's:
16:57:30.3841 IPC Monitor Cancel Patch: Timeout, State = ready_downloader I am not sure why this is happening. Need to investigate it further. However, the WoW client will install it upon logging in as wow-patch.mpq exists:
Now we need to add to the patch list for the downloader:
[BACKGROUND] 12340=WoW-3.3.5.12340-3.3.5.12341-{CPU}-{OS}-{LANG}.torrent 12341=WoW-3.3.5.12340-3.3.5.12341-{CPU}-{OS}-{LANG}.torrent The downloader targets this torrent file and... torrents it. At the downloader start up it sends a message to the global tracker to announce it is online (these are urls:3724 in the downloader if you wish to modify). Trackers must be http to work I found from testing.
The torrent file goes in the ..background directory:
backgroundWoW-3.3.5.12340-x86-Win-enGB-BKGND.torrent updateDownloader.ini updatePatchSequenceFile.txt updateWoW-3.3.5.12340-3.3.5.12341-x86-Win-enGB.mpq Note these file locations are important (and their names).
The Downloader.ini's contents should look like this:
20:19:03.4414 Downloader v2.2.0.1329 20:19:03.4415 Checking for server side config http://127.0.0.1/update/Downloader.ini 20:19:03.7671 Server-side background download settings applied 20:19:03.7965 Checking for background download http://127.0.0.1/background/WoW-3.3.5.12340-x86-Win-enGB-BKGND.torrent 20:19:03.7984 Starting download of http://127.0.0.1/background/WoW-3.3.5.12340-x86-Win-enGB-BKGND.torrent 20:19:03.8857 Downloader initializing... 20:19:04.1020 Creating Firewall interface 20:19:04.1278 Success! 20:19:04.1299 Enabling Microsoft Firewall UPnP Framework 20:19:04.1532 Error - Microsoft firewall(service) put_Enabled failed: -2147024891 20:19:04.1553 Enabling Blizzard Downloader on Windows Firewall 20:19:04.2002 Error - Microsoft firewall(EnableFirewallProgram) Add: failed: -2147024891 20:19:04.2030 Creating Firewall interface 20:19:04.2379 Success! 20:19:04.2400 Creating Microsoft Firewall Rule: Blizzard Downloader: 3724 20:19:04.2648 Error - Microsoft firewall(EnableFirewallPort) Add: failed: -2147024891 20:19:04.2677 Creating UPnP interface 20:19:04.2698 Getting UPnPDevice Information 20:19:04.2716 Found Bonjour service and registering a local peer. 20:19:09.4547 UPnP device Found: 20:19:09.4585 Manufacturer: D-Link 20:19:09.4617 Model: DIR-615 20:19:09.4652 Model Number: 1 20:19:09.4683 Device URL: http://www.dlink.com.tw 20:19:09.5508 Could not find port mappings on UPnP Device. 20:19:09.5548 Add UPnP Device port forward: 3724 20:19:09.6378 Unable to successfully forward port. 20:19:09.6415 Creating Windows UPnPEngine interface 20:19:09.6447 Getting UPnPDevice Information 20:19:14.3498 Connecting to: http://127.0.0.1:80/announce with 1 20:19:14.4935 Connected in 7+134 ms 20:19:14.4970 Received an error code from tracker: 404 20:19:14.6008 Connecting to: http://127.0.0.1:80/announce with 3 20:19:14.6965 Connected in 5+87 ms 20:19:14.7002 Received an error code from tracker: 404 20:19:14.8105 Restoring UPnP value to false under Windows Firewall 20:19:14.8979 Error -- Microsoft firewall(service) put_Enabled failed: -2147024891 20:19:14.9015 Removing port 0 from Windows Firewall 20:19:14.9234 Success! 20:19:14.9256 Disabling Blizzard Downloader for Windows Firewall 20:19:14.9474 Error -- Microsoft firewall(EnableFirewallProgram) Remove: failed: -2147024891 20:19:18.6588 UPnP Device Found: 20:19:18.6628 Manufacturer: D-Link 20:19:18.6663 Model: DIR-615 20:19:18.6696 Model Number: 1 20:19:18.6729 Device URL: http://192.168.9.6/ 20:19:24.0460 Could not find port mappings on UPnP Device. 20:19:24.0499 Add UPnP Device port forward: 3724 20:19:24.0574 Unable to successfully forward port. 20:26:13.1085 Saving meta data file... In the above log, I tried to use localhost as the tracker which failed (I have no idea what I am doing with torrents half the time).
Once the downloader has finished (it will download to WoW DirectoryUpdate) it will attempt to execute what it downloaded - this is being worked on here: viewtopic.php?f=12&t=4309 But you can attach any executable file if you wish.
The installer will display patch notes and move/delete/add all the necessary files. Once installation is complete, then WoW.exe will launch and the installer will close.
Now the updated WoW version with your new patches should be running. Congratulations on completely automating the patching process using Blizzard's methods and tools.
I'm working on replicating the full Blizzard patching process, whereby your login to WoW and a patch is sent to you containing a downloader, the downloader downloads a installer that then installs the patch and starts WoW back up updated.
With the help of Schlumpf, all but the last stage has been achieved.
The Blizzard Installer is made up of a series of parts in a single file:
The main installer program
An attached MPQ archive
BsnI data (installer data)
Signature data
Schlumpf wrote a tool to extract the base program from it, and then to be able to assemble a patch onto the installer program with the necessary BsnI data.
However, both the assembler and extractor through exceptions when I try to use them. Inflation is failing. For example, in the extractor, this line of code:
int result = inflateInit (&stream); // this returns -2 if (result) { return result; } int inflateResult = inflate (&stream, 4); if (inflateResult == 1) { *written_output = stream.total_out; return inflateEnd (&stream); } else { inflateEnd (&stream); if (inflateResult != 2 && (inflateResult != -5 || stream.avail_in)) { return inflateResult; } return -3; } } If anyone is able to reproduce and fix this, then it would be greatly appreciated. I have no idea what could be wrong. I have tested it with the 3.0.1 to 3.0.2 installer and the 3.3.5 to 3.3.5a installer.
I have been relatively active on the forum boards here and I thought I'd finally post about the project I have been working on to answer any questions anyone should have.
The Edge of Chaos project is something that I have been working on (and off) for almost four years. The project was founded in patch 3.0.9, after my Hyperion project came to a close. The inception of the project began under the name 'Kronos', and revolved around the following concept.
Players began at level 1 in either Searing Gorge or Burning Steppes, in the midst of a battle over Blackrock Mountain and the resources that it obtains. The Alliance and Horde do battle and you follow this through (questing, exploring and dungeoning) till you reach level 19, at which point you discover through quests the greater threat of a impending demon invasion, and the Horde and Alliance must thus work together to defeat this threat. This leaves players in the 'mall' area (Nefarian lair uninstanced). Here they can quest further, dungeon, PvP or generally do other end-game content.
The entire server was based around rebuilding Blizzard's world into my own vision, using the same gameplay and design concepts but through my own content. We are all about quality - meeting or exceeding Blizzard's standards. Implementing new and fun mechanisms that actually made the game enjoyable. Players who previously hated questing suddenly loved our server and really had a great time. This was quite a success, and was available to play as a server for quite a while. Then we saw some flaws in the design.
We marketed the server as a twink server since the level cap was 19; and it really is not. Furthermore, we had underestimated how quickly players could clear content, and there was a limitation as to what you could do once you reach the end of the game. And then we started encountering issues with our emulator.
This all led to the decision to close the realm and rebuild it, learning from our mistakes. This led on to the Edge of Chaos expansion. We decided to use client modifications to further our aims and to extend the level cap to 30. This has allowed us to have our own maps, to use our own user interface, to use server <-> client communications, to use custom cinematic cameras, to use the Blizzard downloader and installer, to do what has not been seen before in the public emulation scene. We are quite excited about the product we are developing.
But progress is slow - as is always the case with large projects. Our staff literally consists of two main developers and two who help around a lot. That is four of us - four of us to build a world that Blizzard did not. Our estimations keep getting later and later, but at the same time more and more progress is being made.
Most projects focus on client side work or server side work and never end up switching to the other. We are working on both at the same time, and have achieved great success. In fact, as I write this post now, over seven dungeons and two raids have been created, levels 1-27 are almost perfected and streamlined, and we are drawing ever closer to the eventual beta. I am really excited to see the end of the project, and for the public to seek access to the server. We are being sponsored by one of the largest servers in the current emulation scene, giving us great resources to call upon when we need it. To give you an idea of how much work has gone into this project, in scripts alone there are over 60,000 lines of hand-written code by ourselves.
[paragraph:1dmoi0by]In this post I will be explaining the processes I took to achieve this desired implementation, but at the end I will draw up some questions that I am asking the community so that we can solve some flaws with the system together.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]This entire thread is designed for the 3.3.5a WoW client, but it should work on any other client as well.[/paragraph:1dmoi0by]
Explanation
[paragraph:1dmoi0by]The World of Warcraft client has had account messaging implemented for a very long time, but never actually used by Blizzard.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]Account messaging is the process of being able to send unique messages to certain accounts upon successfully authentication with the server. Messages can be clicked away or marked as read, and when marked as read they will no longer show up on login. Multiple messages can be queued at once.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]This is demonstrated in the following video: [/paragraph:1dmoi0by]
Implementation
[paragraph:1dmoi0by]The main logical steps of account messages are as follows:
Player logs in
Server challenges player
Player challenges server
Server response has a flag that needs to be marked, to show that the client should check for account messages
Client goes to URL defined in strings to retrieve XML code to be displayed as message
Client displays message if retrieved successfully, other buttons can call different URLs to mark it read (etc)
When client visits URL, it parses a hash of its session key, the account name, and the message ID. The servers and clients session keys should match in theory.
[/paragraph:1dmoi0by]
The Client Changes
[paragraph:1dmoi0by]There is only one file that needs to be changed to get the client working with account messages.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]Find the gluestrings.lua file in the GlueXML folder of the interface. Note that changes to the glueXML files will not work unless the WoW executable is 'cracked'.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]There are some strings that need to be changed:[/paragraph:1dmoi0by]
ACCOUNT_MESSAGE_BODY_NO_READ_URL = "http://www.blizzard.com/getMessageBodyUnread.xml"; ACCOUNT_MESSAGE_BODY_URL = "http://www.blizzard.com/getMessageBody.xml"; ACCOUNT_MESSAGE_HEADERS_URL = "http://www.blizzard.com/getMessageHeaders.xml"; ACCOUNT_MESSAGE_READ_URL = "http://www.blizzard.com/markMessageAsRead.xml";[paragraph:1dmoi0by]Note that the file extension makes no difference, as long as the text is formatted correctly.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]These need to be changed to the URL of your website so that it executes your scripts and not Blizzard's. I found that changes to the gluestrings.lua here was not always successful since apparently there is another file somewhere else that overwrites these strings (I forget where). To counter this, I set these strings again just before the client checks for account messages. This can be found on line 241 of GlueParent.lua.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]I set ACCOUNT_MESSAGE_BODY_URL to nil as I never see it used, and no error is ever spat it saying that it is nil when something tries to reference it, so I assume it was never implemented.[/paragraph:1dmoi0by]
The Emulator Changes
[paragraph:1dmoi0by]In this document I am describing the changes relevant to ArcEmu. But obviously, TrinityCore uses exactly the same packets. It should be a simple matter to implement it in TrinityCore as well, or any other emulator for that matter.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]The function to take note of is in AuthSocket.cpp in the logonserver:[/paragraph:1dmoi0by]
memcpy(&buffer[2], M2, 20); buffer[22]= 0x01; //<-- ARENA TOURNAMENT ACC FLAG! buffer[30]= 1; // Unread messages Send(buffer, 32); } [paragraph:1dmoi0by]You can see that I flag that there are unread messages here:[/paragraph:1dmoi0by]
buffer[30]= 1; // Unread messages[paragraph:1dmoi0by]Since the session key is generated upon login, account messages need to be updated with the most up to date session key so that when the client uploads their hashed session key, it is the same as the servers.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]The following algorithm is wrong. This is the hash that Schlumpf thought was correct, however upon testing we found it generated a completely different result to the client. The correct hash needs to be figured out.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]However, in:
[paragraph:1dmoi0by]This sets the account to have that session key. Immediately after, I do the following to get a hashed session key and store it:[/paragraph:1dmoi0by]
// Disabled because the server algorithm seems to be unable to generate the same result as the client.
// Hash the session key so that the logon DB can know static const unsigned short hash_constant (0x7a0b); Sha1Hash newone; newone.UpdateBigNumbers (&m_sessionkey, NULL); newone.UpdateData ((uint8*)&hash_constant, sizeof (hash_constant)); newone.Finalize(); BigNumber hashed_session_key; hashed_session_key.SetBinary (newone.GetDigest(), newone.GetLength());
// Let the DB know sLogonSQL->Execute("UPDATE `account_messages` SET `hash` = '%s' WHERE `account` = '%s';", hashed_session_key.AsDecStr(), m_account->UsernamePtr); [paragraph:1dmoi0by]This is the first flaw with the current implementation.[/paragraph:1dmoi0by]
Website Additions
[paragraph:1dmoi0by]Schlumpf has provided the following information that shows the data flow and operations in the processes:[/paragraph:1dmoi0by]
sessionKeyHash: static const short hash_constant = 0x7A0B; SHA1_Init(&sha_context); SHA1_Update(&sha_context, ClientServices::Connection()->GetSessionKey(), 40); SHA1_Update(&sha_context, &hash_constant, sizeof (hash_constant)); SHA1_Final(keyhash, &sha_context); [paragraph:1dmoi0by]This allowed me to create three PHP scripts to handle each event. I am by no means an expert at PHP, so I am sure my scripts could easily be improved.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]First I have, getMessageHeaders.php:[/paragraph:1dmoi0by]
/* echo "<headers>"; echo "<header_entry id="0" priority="0" opened="0">"; echo "<subject>{$account}! {$hash}</subject>"; echo "</header_entry>"; echo "<header_entry id="1" priority="0" opened="0">"; echo "<subject>Message 2</subject>"; echo "</header_entry>"; echo "<header_entry id="2" priority="0" opened="0">"; echo "<subject>Message 3</subject>"; echo "</header_entry>"; echo "</headers>"; */ ?>[paragraph:1dmoi0by]Things to take note of here is that the account name and hashed session key are passed in as parameters to the script. I store account messages in a database, hence why I select the necessary data from this database. I loop through each unread message and display XML code as I go along. The structure of the XML code can be seen commented out at the bottom.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]I have also commented out the comparison to see if the database hash is the same as the client hash, because of the incorrect hash I was generating server side. This makes it insecure.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]The next file is getMessageBody.php, which follows a similar structure:[/paragraph:1dmoi0by]
mysql_close($con); ?>[paragraph:1dmoi0by]This just gets the text of the message depending on it's ID.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]The next script is markRead.php, which is used to mark the message as read to stop it showing up:[/paragraph:1dmoi0by]
$q = mysql_query("SELECT `id`,`hash`,`read` FROM `account_messages` WHERE account = '{$account}' ORDER BY `id`") or die(mysql_error());
if (mysql_num_rows($q) != 0) { while($row = mysql_fetch_array($q)) { //if ($hash == $row['hash']) //{ if ($row['read'] == 0) { if ($count == $id) { $id_found = $row['id']; break; }
$count = $count + 1; } //} } }
if ($id_found != 0) { mysql_query("UPDATE `account_messages` SET `read` = '1' WHERE `id` = '{$id_found}'") or die(mysql_error()); }
mysql_close($con); ?>[paragraph:1dmoi0by]It follows a similar structure to the other two scripts. The ID of the message is a little hard to obtain, so the majority of the script is spent finding this ID. If the message ID is found, then a query is executed to update the account message and set it as read.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]This is all that is needed web side.[/paragraph:1dmoi0by]
Current Bugs
[paragraph:1dmoi0by]The first bug is that the hashed session key generated by the server is different to that of the client, making it very insecure. This needs to be fixed. This is described in more detail previously in the thread.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]The second bug is that it makes the client quite unstable for unknown reasons. If your account is flagged for account messages, I have found that upon next exiting the game a WoW error will be generated. This WoW error can also be generated at random often as well, by simple things such as pressing escape. I have been unable to make any progress on diagnosing this issue. A image of the error is shown below:[/paragraph:1dmoi0by] [paragraph:1dmoi0by]Happy messaging, and please post if you think you can, or have, solved the issues described here.[/paragraph:1dmoi0by] [paragraph:1dmoi0by]Thanks, Harry & Schlumpf[/paragraph:1dmoi0by]
We edited one of Blizzard's test maps when we built our new land instead of creating a entire new map for it, and now we have realised that whenever we go in game the map has lines all over it (shown in image below).
Is there any way we can fix this? I assume it is a flag with the ADT or something, but it is game breaking and would be too much effort to rebuild the entire map.