Alex

[10757] merged patch is here

http://pastebin.ca/1996943

I will post updated patch in a few days if nobody is faster

There must be some reason though, I doubt they would up the requirement just because a new version was released.

There is no errors in autoconf run, so we may assume this requirement is void in our case.

Well... soon is CentOS 6 coming, so we won't need this small fix anymore

It's better to use SOAP pdump functionality, it guarantees everything will be stored/loaded according to the current version needs.

I've merged the old patch posted above by traponinet with [10677]. Quick tested it, seems to be working.

http://pastebin.ca/1982579

Just do the following

--- a/dep/ACE_wrappers/configure.ac     2010-10-30 17:36:27.000000000 +0400
+++ b/dep/ACE_wrappers/configure.ac     2010-10-30 17:37:19.000000000 +0400
@@ -36,7 +36,7 @@

dnl Require GNU Autoconf 2.58 or better.  Previous versions did not
dnl correctly support HP-UX.
-AC_PREREQ(2.61)
+AC_PREREQ(2.59)

dnl Autoconf explicitly forbids patterns containing "_AC_".  This causes
dnl a problem when using MPC to generate the Automake ".am" files since

And it will do with 2.59. Don't know why it was bumped to 2.61. Tested, configures and builds without a scratch on CentOS.

Now that MaNGOS got SOAP, it's much easier and productive to use SOAP interface.

As said, I'm pretty sure these freezes originate from elsewhere...

It may be that wrong/unexpected data is reported in that field. Client expects packed GUID but it does not mean client expects the one sent by us currently. Everyone receiving the crappy update (those who are in the visibility range) get client freeze when this happens.

P.S. Confirmed after [9626] even with GCC 4.3 and -O1.

Reverting [9606] helps. I could not investigate this any further though, sorry.

Exactly told in the 1st post, it gives 100% hang on test.

Maybe it's because I am compiling with GCC 4.4 and -O2, but reverting [9606] fixes these hangs. Will check with GCC 4.3 and -O1 soon.

Nah, it's still reproducible even after [9619]. So that's not just bytebuffer/flag problem. Client does not expect this GUID everytime in the first place, or expect something other.

2 Anti: just revert [9606] before build, and you'll be fine.

May I ask: what was the reason behind adding this GUID? Is it even needed? I could not find any visual differences with and without [9606].

I am building another testbed tomorrow, will re-check this for sure.

If you revert [9606] most people will stop looking for the solution lol

and if don't want to mess with git and you need it working now you can always open text editor and set it the way it was only 3 lines

I had it reverted and working just before I've opened this thread If you revert [9606], most people will stop crying "ARGH! CLIENT FREEZE! WHAT THE FUCK?", and those who know may peacefully look for the solution using bug report.

---

According to the reports, client does not expect having GUID every time there. There must be cases when it is zero. Note: this mostly affect aura triggered spells. May be aura triggered spells must have zero as a caster GUID?

It's not arcane blast. It's this 'missile barrage available' effect causing hang. Something is amiss here.

Bump. This patch is stable by now and itching to be accepted. Many of us are applying it manually, but it's better if it's in the core.

Applied both patches. Still freezing. It's probably better to revert [9606] now and then search for a solution.

The exact way to reproduce the freeze easy and fast is stated in the first post. If someone here is acquainted with client debugging, it's a way to go.

Okay, I do think some DBC override table may be needed. Like dbc_override with fields like dbc, entry, field, value. It may be flexible enough to do necessary changes without resorting to DBC hacking. Will implement this soon.

Rev. [9606] (send packed caster GUID) causes client freezes.

How to reproduce:

1. Create mage.

2. Up his level to 80 (any will do as long as you can tick all talents in step 3).

3. Tick all the talents in Arcane (dont up max, just one tick at each will do, except for the chains).

4. Up Missile Barrage talent to the max.

5. Learn all mage spells from any mage trainer.

6. .go xyz 6701 1144 275 571

7. There will be many skeletons and other undead here, start attacking using just Arcane Missiles (rarely) and Arcane Blast (most often).

8. Arcane Blast will produce some Missile Barrage events with time, and eventually the client will freeze at Arcane Blast cast.

I could not debug this any further, but probably sending packed caster GUID for some spells is incorrect causing these freezes. Reverting 9606 solves this.

Hmm... studying MaNGOS code I cannot find how DBC glitches can be avoided (DBC is not a source to be fully trusted).

One day there was effort to translate DBCs into database and use them that way, but if I remember correctly this was rejected.

Let's explain. Spells 47702, 47722, 50251 must have target type 38 (SCRIPT_TARGET) because they can only target specific creatures. In Spell.dbc they have target type 25, that is duel player target which is incorrect so they can be applied to any creature and that is wrong.

So the question: maybe someone knows how to correct such a DBC glitch in MaNGOS code without making dirty hacks? Or maybe making DBC->SQL transition is worth the effort (I may try to do it then)?

diff --git a/src/mangosd/MaNGOSsoap.cpp b/src/mangosd/MaNGOSsoap.cpp
index fe358d2..09ee0ed 100644
--- a/src/mangosd/MaNGOSsoap.cpp
+++ b/src/mangosd/MaNGOSsoap.cpp
@@ -29,6 +29,8 @@ void MaNGOSsoapRunnable::run()
    struct soap soap;
    int m, s;
    soap_init(&soap);
+    soap_set_imode(&soap, SOAP_C_UTFSTRING);
+    soap_set_omode(&soap, SOAP_C_UTFSTRING);
    m = soap_bind(&soap, m_host.c_str(), m_port, 100);

    // check every 3 seconds if world ended

This small mod will properly allow UTF8 strings via SOAP for i.e. announcements in native languages or native player names.

Does any one knows any new stable revision?

It requires a bit of effort to keep "your" revision stable. Crashfixing inplace at most. So take few hands and a brain and... yes, go for it!

There are no "stable" revisions in MaNGOS, because it is beta quality code with plenty of alpha additions to it every day. Such a large scale singular (not modular) OSS projects rarely go "stable". Even if they announce it.

This is probably more correct version of the patch:

diff --git a/src/game/GameObject.cpp b/src/game/GameObject.cpp
index 0bfb0b9..1826608 100644
--- a/src/game/GameObject.cpp
+++ b/src/game/GameObject.cpp
@@ -438,7 +438,11 @@ void GameObject::Update(uint32 /*p_time*/)
            if(!m_spawnedByDefault)
            {
                m_respawnTime = 0;
-                return;
+
+                if (IsInWorld())
+                    UpdateObjectVisibility();
+
+                break;
            }

            // since pool system can fail to roll unspawned object, this one can remain spawned, so must set respawn nevertheless

Again, this is better done via CLI. Telnet to the server CLI from PHP and do some mail commands

It's just as easy as creating boiled egg from roast chicken. Ever tried?

Erm... this patch may be accepted in its current form, can someone review it more deeply?

Spell family checks eliminate probability of errors, so they seem fit.

Patch version 4

1. Updated for [7940], cleaned up code a bit.

2. No functional changes.

http://pastebin.ca/1444524

First post also updated.