FragFrog

Aye - when I checked it last the patch didn't work Ah well

And those scripts are linked to a mob Had the same problem once when a GM spanwed Jaine Proudmore (NPC from Hyjal Summit) in Stormwind. Deleting the mob fixed it though.

That will be a lot more expensive than a simple readout xeross155, especially if it's to be used for multiple characters at once (for example: a list of online characters with their base stats). Not entirely sure it's even possible at the moment either. With that said, is the information not still cached in the big characters.data field? If not, I don't see how you could still implement this - it'd go a bit far to require MicroManager users to apply a core patch before they could use MM...

Must have been gremlins Anyhow, it's not a big issue, seems only to happen on TBC anyway, and reverting the mentioned commit fixes it nicely. Wouldn't worry too much about it really.

I've had a few hunderd users test this patch over the past two days, so far haven't heard any complaints - should probably be considered for acceptation

Awesome, this broke about a dozen quests, some of them important class quests (like the warlock quest for a voidwalker), have been meaning to look into it ever since I found out about the bug. Will test it and let you know! //edit Quest 9529 (The Stone) works again after applying this patch, so far so good.

Do tell Vladimir, he wouldn't believe me

I'd say you'd be halfway there if you can get points 4, 5 and 7 to work - if indeed the LordJZ is correct that you can enable it clientside with a few minor setting adjustments. Trouble however is LordJZ's other remark: voicechat still works even when the server gets disconnected. This could indicate voicechat is routed on to an external voicechat server, which makes sense performance-wise but might be difficult to implement depending on how the client handles it (ie, can you just send the client a packet to connect to a voicechat server on a specific IP and port? And how does it know what channel you are in / who you can talk to?). Would still be an awesome feature to have though

You're the best Balrok - that seems to work fine indeed (turns out I had changed it to the wrong return unit when I rewrote it myself.. Mangos core is tricky ). Will probably put this on our live server in a day or so, if I find any problems with it I'll let you know

Doesn't GridUnload = 0 have the same effect though? And if that is the case - does applying this patch mean the same problems for long uptimes? Specifically, with GridUnload=0 I keep getting reports about mines not being minable, creatures not respawning, etc. after a day or two, three of uptime. Setting GridUnload=1 effectively seems to fix that, but if this patch keeps the same data in memory we might get the same trouble?

Your patch seems not applicable for 0.12 branch unfortunately, will test it on WotLK later. I rewrote it for 0.12 so it compiles, but then SoC never procced at all so I probably did something wrong there

tehavatar: I am using a TBC core based on 9524 and got, at the moment, 7 days 5 hours uptime with 280 max users. Our previous version was 8719 and even with half a dozen crashfixes that only got two, three days usually. Mangos developers really do work on stability That being said, with a week uptime peoples instances are indeed not resetting correctly. This seems to affect heroic instances mostly, raids (like Sunwell Plateau and Kara) do appear to reset every thursday. It is mostly anoying for people that are bound to an instance ID and keep that ID for as long as the server is up, since it means they cannot join another group for heroics. I can't imagine it's hard to write a script that clears all ID's every night, would be pretty much just a matter of executing a few truncate SQL queries and resetting clients.

Agreed, thank you for this. Any chance this can be considered for the official repo's?

You need PHP version 5.0.1 or later, and it must be compiled using --enable-soap or by manually adding extension=php_soap.dll in your PHP.ini. If that all sounds like abracadabra to you, simply go here and download and install the binaries for PHP 5.3. If you get an 'HTTP Error: 401 Unauthorized' error you are unauthorized. This means, surprisingly enough, authorization failed. Make sure you use a GM account of at least the level specified by RA.MinLevel (not entirely sure if this value is also used by the SOAP service, but can't hurt to be sure) and of course that your username and password are correct. Your username does not have to be in uppercase though.

I got a couple'a client crashes using this patch, 9592/SD2-1639. Nothing too serious, mostly happens when I open the map in the client, but a tad bit anoying still. Would be good to know if that got fixed with the poiID in DB..

I agree with Xeross155 on this. Why use SOAP there, other than just for the sake of using it? If you want to offer services to external applications, SOAP is a great way of doing so - it can provide a description of the services offered (using WDSL) and ensure both applications know how to talk to eachother. But if you control both the server as well as the client it is a hopelessly bloated protocol - performance would probably decrease over just using the database in the first place. Not to mention the current situation is such that you can kill and restart the realm server with no ill effects to online players since all account changes are still stored directly by the world server. Would you send those commands to a realm server, then let the realm server handle them it can lead to inconsistencies and in the worst scenario crashes for the world server whenever the realm server fails.

Aye, some do, there's a few that already take a character name parameter though. As it is, this provides little more than static calls to a few selected commands while in theory a SOAP service can offer direct access to core methods. Would be nice to have, though probably way too much effort to make - needs a WSDL to start with for one. Not that I don't appreciate the work here (quite the contrary, already used this to add the ability to mute and kick online characters directly from GaME), but I think it has the potential to do much, much more There was a post a few days ago in the general help section as well - I am guessing many don't realise SOAP is foremost a way for programs to communicate between themselfs, not something you'd login in on as a user

You forgot to add you have to forward the server's ports as wel - 8085 for the default realm, and each port for additional realms you might run. Forwarding a webserver port on the other hand is generally not required, unless you run a website on the same machine. As for your router address: it is just as often 192.168.0.255, 10.0.0.1, 192.168.1.254 or a variation thereof (I've encountered all these and more with different routers here). An easier way to find out what IP your router is using is by hitting start -> run -> "cmd" -> "ipconfig /all". This gives you a detailed description of your network adapters' status. Find your LAN connection (Usually called something like Ethernet adapter Local Area Connection) and lookup the value for "Default Gateway": this is the IP of the gateway used, if you use a router it will be set to that IP. Alternatively, you can right click your network notification icon in your system tray, hit 'network and sharing center', click 'View status' for your LAN connection, hit the 'Details...' button and read out the value for default gateway there.

No, it is very much not. Never use SQL queries within a for loop if you can avoid it - you are now using no less than 22 queries just to get total char and race counts. You can obtain the same result with a single query for each type: $query = "SELECT `race`, COUNT(`race`) FROM `characters` GROUP BY `race`"; I am not entirely sure, but I don't believe the queue's are stored anywhere - there isn't much point really. If there was a GM command to show them you might be able to use the SOAP interface to obtain these fields, but I can't find any command that would let you do that.

*bump* Still having trouble with instance resets on the TBC branch. In the raid info tab I can see an instance name with ID, but with a reset time "Resets in" without an actual time. Server restart seems to work, but frankly, what's the use of having a stable server when you have to restart it every day anyway?

For windows, using git apply [patchname] works as well vladex. At least, it does for me (windows Vista). Thanks for these cyrex - I've also added them to my patch svn repository (here, in case more people were wondering about that). Testing them out as we speak

While working on some additional features for GaME I noticed certain GM commands appear to be unavailable when connected through SOAP - like the .levelup command, most of the .modify commands, .additem, probably a few others. Awesome though the SOAP interface it, having key character modification commands unavailable through it rather limits its use. I was wondering, if it is not too big a change, is it possible to enable those commands as well? I realise this might be a bit tricky for commands that do not currently take a character name argument, but for example the .recall and .levelup commands do take one and it'd be rather neat to be able to use a remote application to change someone's level who's standing right next to you without having to log on a GM char

There are commands for moving an NPC to your location, as well as making an NPC say certain things and act out emotes. However, it is probably a lot easier to just morph a playchar and use that instead.

Confirmed here Wojta - mostly happens to priests & mages in arenas on our server. Had this bug ever since we updated from 8719 to 9382 (TBC branch) a few weeks ago. The patch prevents it as far as I can tell, though as you said, in a hacky way. That's fine by me (got about two dozen 'hackish' fixes on our server to prevent some of the bigger bugs) but of course not suitable for master

We recently went from 8719-0.12 to 9524-0.12. Where in 8719 we needed reflective shield patch, spell loop patch and a few other tweaks to keep it stable, 9524 runs several days uptime 'out of the box' so to speak. Stability-wise, it's a great improvement. Keep in mind though that upgrading did introduce new bugs - some severe, some minor. We've had trouble with Shadow Weaving (though fixed now), hunter's Kill Command, battleground object buffs (also fixed now), death bug (people being dead but still able to cast), mind control, blink (but that was already bugged), hunters pet getting out of combat too quickly, object-related quests (like the Warlock voidwalker chain - probably due to the new gossip system), warlocks' seed of corruption suddenly hitting friendlies as well and a few other minor inconveniences. Overall, I'd say it's half good, half bad. I strongly advice you to test well before patching