XTZGZoReX

Hi, I would recommend using std::vector instead of explicit arrays.

It could be in the same repo and still be licensed under the MIT License. It only matters if we linked this program directly into MaNGOS.

Pushed the source. Ready to push the binaries if that's OK.

I vote for static binary patching. Less possible Win32 bugs to deal with for Wine users.

Well, it's about time we start discussing it, and how MaNGOS will handle it both practically and legally. We won't get around patching in one way or another. We generally have two approaches: * Use a loader that injects a DLL into WoW which then patches the memory. * Patch the executable on disk. Personally, I prefer the latter. It's easier. I wrote this tool a few months ago: https://github.com/Trinity-Encore/Encore/blob/master/Trinity.Encore.Patcher/ClientPatcher.cs It uses pattern scanning to find offsets in the executable to patch, so it works for virtually any 4.x executable.

Here's one for 1.12.1.5875 with a few functions marked. http://filebeam.com/3052d71fb6532918173e38519c300c6e

Yeah, I'm sure that's it. I'm definitely running a public server. I'm definitely in this for the money! Wait...... ... MaNGOS is a development project. If you want "stable" versions, use the damn milestones. A source code repository IS MEANT TO HAVE UNSTABLE CODE; THIS IS WHY IT IS NOT MARKED AS RELEASE-STABLE. If development code was not in the source code repository, then WHERE THE HELL ELSE would it be? Do you think code just magically appears out of nowhere?!

That function is not called, ever, anyway, But, the packet structure you posted is correct.

This patch is currently on hold... Besides, it won't work with the current master at all. I plan to incorporate some of the changes in the patch periodically, and then -- eventually -- implement the TerrainMgr.

In [9905]. Thank you .

Why increase...?

In [9807]. Thank you .

Grid coordinates are never supposed to be "outside" grids in the first place. By checking for it, like this, you're just hiding a crash. You should rather assert it, and attempt to find the source of the problem.

Did you ever look at MapManager::Update()? Also, on retail, the same transport has a different GUID on two different maps - i.e. boat in Booty Bay.

Yes, I was notified of those errors a while ago... And for the life of me, I just can't figure out why GCC won't compile it...

Yet another; http://paste2.org/p/758162 Please try teleporting to groupmates inside instances. It should be fixed, but I can't confirm myself. Before, there was a bug where an instance copy would be made instead of being ported to the existing instance.

Okay - really, REALLY fixed version: http://paste2.org/p/757750 Had a small mistake that broke instance map creation in there...

http://paste2.org/p/757553 "Release candidate" patch. Should have fixed all known issues... SD2 patch (thx Skirnir): http://gist.github.com/356341

Personally, I don't think voice chat is worth the trouble; the quality is terrible compared to Ventrilo, TS3, Mumble, etc. Also, yes, Blizz uses a separate voice chat server. The question is - where is the IP/port for the voice chat server sent?

I have no objections - and I certainly believe his abilities are great. But hey, let's just slavedrive him some more.

It's not needed. Simply because terrain data no longer locks grids (as it's now detached from the grid system) and because we never wanted grid-level threading to begin with. That's also why I plan to completely remove all the threading-related code in the grid/cell code.

Means you gotta do "thread apply all bt full" since it's a different thread that is freezing. Also, this thread is about _client_ freezes, so better create a new thread about your issue.

Found some critical bugs, so not committing just yet. Everything I know of has been fixed now. Latest patch: http://paste2.org/p/749446

Unless anyone reports any serious issues, this patch will be committed in ~2-3 hours.

And again, a new one: http://paste2.org/p/748603 Made for latest master, and fixes a crash at BG updating.