Jump to content

antz

Community Manager
  • Posts

    2819
  • Joined

  • Last visited

  • Days Won

    96
  • Donations

    0.00 GBP 

Everything posted by antz

  1. This is now fixed in the Rel20 DB [url]https://github.com/mangosone/database/commit/38518b5d0ca74661d50a7e02fe296479630c60f1[/url]
  2. This is now in the latest Rel20 DB
  3. Closed in commit: [url]https://github.com/mangos/realmd/commit/15df5d42ae03cabe9cebfbd7534df8af4f739ecb[/url]
  4. That commit must have never been ported to the other cores and needs to be found !!
  5. I have also made a 'hotfix' update to the DBDocs to reflect this information and published to the Wiki, to hopefully prevent anyone else from making the same mistake.
  6. I'm sure of the reason behind why this should take that much longer in debug. In the Build process there is a definition _DEBUG which indicates that it's a debug build The issue with trying to do something with movemaps extractor itself is that it is called multiple times by the build scripts - so it cannot keep track of its overall status beyond the current run Olion has mentioned about setting and using the errorcode to flag the error during the run - This combined with a -DEBUGOVERRIDE flag, might do the trick As I see it, the logic flow would be this.. Are we in Debug Mode ? No... Carry on as normal Yes.... Do we have -DEBUGOVERRIDE set ? Yes... Carry on as normal No.... Do we have an Errorcode >0 No... Generate the Debug warning message and then set Errorcode to be greater then 0 and and Exit Yes.... Exit Thoughts ?
  7. We were attempting to fix a majority of the broken mobs in Zero (especially casters) I reviewed the changes and agreed they looked good to go. In light of you highlighting the potential issue with the change, we are reviewing it to see whether a) We need to revert it and reapplying with extra restrictions b) Apply a correction to the small number of mobs affected by the global change Anything you can add to this would be appreciated
  8. This has been fixed by commit [url]https://github.com/mangosone/server/commit/fea55512f09d25f6a759da630a85ac45eb419b97[/url] Can you please confirm ?
  9. This may have been fixed by commit [url]https://github.com/mangosone/server/commit/fea55512f09d25f6a759da630a85ac45eb419b97[/url] Can you please confirm ?
  10. I have also activated "living world" on my server and will leave it running for a day to collect any world issues.
  11. This commit should allow that. I updated my mangos.conf and continents 0 and 1 stay active and the 'wanderers' seem to be wandering ! [url]https://github.com/mangoszero/server/commit/8113cdc1ebff644088aa08990abb25a7082d1ef4[/url]
  12. Something i'll add to the mix... Transports in Zero work completely different to the rest of the cores. - Ie. There are no transport maps But I can't remember, were there crew in the transports in ZEro ?
  13. [quote=Xenithar]It was not in vanilla at all. I was a HEAVY raider in vanilla. I had top gear and even a Thunderfury. We NEVER got the group loot roll in vanilla. That was added in BC after I took a break. *EDIT* Also, I just built the current R20 and I STILL cannot see any realms listed in the realm selection screen despite having my realm show up when realmd starts. This is a game-breaker. A new player who just built their first server would not even be able to get into it. I can reproduce this on 64bit and 32bit Debian Wheezy. I do not have my Gentoo server up right now. Hardware changes.[/quote] Have you checked there are no 'funny' realmflags set ? - I have on occassion seen a value of 6 in the realmflag column, which prevents the realm from being shown to the client
  14. This is looking like some scripting missing, whether that be SD2 or Eluna
  15. Implemented in commit [URL]https://github.com/mangoszero/database/commit/5456b16ba4382702514783ea41f3a02c953a8cdf[/URL]
  16. This is another dual event like the Pyrewood Village inhabitants
  17. I believe this command should use the value from MaxPlayerLevel in mangos.conf But should gm's be allowed to skip past this check ?
  18. this seems to be fixed now
  19. I believe this is now fixed in 20?
  20. This may now not be necessary based on the recent living world commit [url]https://github.com/mangoszero/server/commit/8113cdc1ebff644088aa08990abb25a7082d1ef4[/url]
  21. thanks for this additional information
  22. I think this has now been resolved
  23. After the recent looting fixes, this should be working as expected !
×
×
  • 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