Jump to content

Alex

Members
  • Posts

    61
  • Joined

  • Last visited

  • Donations

    0.00 GBP 

About Alex

  • Birthday 01/01/1

Alex's Achievements

Advanced Member

Advanced Member (3/3)

0

Reputation

  1. [10757] merged patch is here http://pastebin.ca/1996943
  2. I will post updated patch in a few days if nobody is faster
  3. 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
  4. It's better to use SOAP pdump functionality, it guarantees everything will be stored/loaded according to the current version needs.
  5. I've merged the old patch posted above by traponinet with [10677]. Quick tested it, seems to be working. http://pastebin.ca/1982579
  6. 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.
  7. Now that MaNGOS got SOAP, it's much easier and productive to use SOAP interface.
  8. 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.
  9. 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.
  10. 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].
  11. I am building another testbed tomorrow, will re-check this for sure.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use