XTZGZoReX

Hi,

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

hm, i just noticed that this project is under the MIT license. i assume this is no problem because it's in a diff. repo as the rest of mangos, right? (mangos is under GPL (was it GPLv2 ?)).

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

nobody with enough free time would code more then a few months for a open source project just becouse they "want to learn".

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 .

...

UMSG_UNKNOWN_1305 = 0x519, // not found

UMSG_UNKNOWN_1306 = 0x51A, // not found

NUM_MSG_TYPES = 0x51B

...

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.

Transport in not part if map system.. and as i can see boarded creatures too

so that creatures will be not be able to send broadcast packets and etc

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.

If we want to have this working under multithreaded environment it will need real locking (mutex or other primitive) because this and similar operations are not atomic what can cause problems in real multithreaded environment. Even simple ++ -- operations are not atomic! It is good to keep this in mind. It can be solved by some fast mutex or using atomic operations (special CPU instructions for this purposes).

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.