Foereaper

I highly doubt it is related to any recent updates, I'm leaning more towards the pet system as a whole being unstable.. I had the exact same crash with the said pet in Loch Modan. It happened twice, then when I tried a third time it didn't crash anymore. For the hell of it, would you mind disabling the pets scripts (if not in SD2, remove the AI name/spell ID's) from the pet in the database and try again?

This seems to be happening with scripted pets. I also saw it happening with a wolf in Loch Modan not too long ago. Specifically rares?

There we go, correct order now :) [url]https://github.com/mangoszero/server/commit/7853ac0aa0d8937bff3aa83813159f515719a124[/url]

Just built and ran ACE 6.3.0 on Ubuntu 14.04.1 LTS and everything seems to be working as intended. Threading starts as it should, core fires up and everything's all dandy. Will be running for a while to test, however as far as I can see, 6.3.0 should be working perfectly fine on this dist at least. That being said, if 6.3.0 does not work on a distro, you can always use external ACE just like normal. This way we can start fixing bugs that happen with latter ACE versions, (ie. DB threading issue) and offer backwards compatibility for those not wanting to use bleeding edge, in this case external.

Hmm, according to ACE, their latest stable release is 6.3.0. That being said, I think I'm going to upgrade the internal to 6.3.0 and leave it at that for however long. We'll have to fix the issue with the database threadding at some point no matter, rather not postpone it by using an outdated Ace lib.

[url]https://www.youtube.com/watch?v=GhX2A2l9Y-Q[/url] This video was created in fairly early TBC, looking at the change log for the quest it was not changed in between Classic and TBC.

The database thread is not able to exit cleanly on shutdown when using internal Ace. I just updated internal Ace from 6.1.4 to 6.3.0 and still having the same issue. Could you check what version external Ace uses on Linux by default? From my tests, Ace in and of itself isn't really to be blamed, but the database thread handling itself..

Figured as much, we found the issue and we're working on it :)

Are you using internal or external ace, out of curiosity

Odd, not getting this on Win. Will test on Nix soon-ish.

Did you use clone or pull? If you pull you have to manually update the submodules as well :) [COLOR=#444444][FONT=Consolas]git submodule update[/FONT][/COLOR]

Just pushed an update to the latest stable release, Eluna shutdown crash should be fixed :) Please confirm and close accordingly!

Still haven't had the chance to push the latest Eluna source, working on implementing temporary thread locking prior to multithreading, until then the shutdown crash will continue to happen unfortunately. Will update the issue once this is complete.

Tested by setting Rate.Corpse.Decay.Looted to 0.5 as stated above, and it worked as intended. By that I mean the corpse didn't automatically despawn. 0.0 caused instant decay. I suggest we look into the math the core does with the provided variables, then change the variables to the correct values stated in one of my above posts. For now, I will push 0.5 to be the default value. This fixes the decay issue allowing people to skin mobs, at least temporarily until we can check and fix the correct values and math. Edit: Seems this was already changed by Evil on the 21st of Sept. [url]https://github.com/mangoszero/server/commit/3963a3c499730337440932457be0a033814ba20b[/url] Thus everything should now work as intended, if not, update your config files :)

PR is found here: [url]https://github.com/mangoszero/server/pull/272[/url] [url]https://help.github.com/articles/checking-out-pull-requests-locally/[/url]

Tested on Covenant as well as local. Everything is working as intended. Closing.

It is currently not happening, no. Remember this was caused by the mineral system that I temporarily reverted? A new PR with the mineral system has been pushed by Evil, containing what should be a fix for the above crash. Needs testing on Nix systems.

Not able to reproduce, as shown below only applies after 10 seconds of eating: [url]http://prntscr.com/5nzexu[/url] [url]http://prntscr.com/5nzf60[/url]

I'd say keep it as a variable in the config options for those wanting to edit it. I know several custom servers like to decrease the decay rates, don't see why we'd necessarily would want to remove them when we already have them added as a config variable.

This is odd, the loot system hasn't been touched as far as I have noticed since the last bunch of fixes.. It worked like it was supposed to after cedrics last fixes some months ago right?

Tested using the Frostwolf Insignia and Insignia of the Alliance, could not reproduce. Which trinkets triggered GCD exactly?

Found several lockboxes in Redridge, however only two at the bottom of the lake as stated above. I never played a rogue so I can't really confirm whether there used to be more boxes at the bottom or not, but I'm sure someone else can. Found several lockboxes in Zoram Strand as well. What database are you using if I may ask? Official mangos one or? [url]http://prntscr.com/5modvu[/url] [url]http://prntscr.com/5mog26[/url] [url]http://prntscr.com/5moggx[/url]

Evocation tested and working, mana regenerated from 0 to 1500 mana in ticks of ~350 mana. Blink issue somewhat confirmed, when trying to blink uphill, it sometimes says "Failed attempt". This needs to be looked into. Clearcasting does indeed trigger by wands, see below screenshot. This needs to be looked into. [url]http://prntscr.com/5mo8z9[/url]

Confirmed, not sure if this is how the core handles the spell, or if this is a client side issue and spell needs to be overridden. Will test some more.

Tested and working as intended. Overpower is triggered on dodge every single time. Rel20 Win build. [url]http://prntscr.com/5mnxyk[/url]