Foereaper

Fixed as of [url]https://github.com/mangoszero/server/commit/095d8bd5ea7a704f6a21db54dbb2b4e30e785029[/url]

Tested and working :) Marking as solved!

IsTappedBy does not, however the IsXPOrHonor thing does. That being said, it needs another change in that case, it shouldn't check if either type or xp check, it should check all three things. Will update it again later.

I will have to do some work related stuff today as well, hopefully someone could debug the skinning issue for me at least, so I would know where it stops when in a group :)

[URL]http://prntscr.com/5qlk5u[/URL]

As you can see, realm (mangos-linux) is showing up like it is supposed to.

Edit:

Group loot also works as it does on Windows, and seems to work like it should:

[url]http://prntscr.com/5qll4h[/url]

Compiling now, will test all of the above shortly :)

Resting fixed and pushed: [url]https://github.com/mangoszero/server/commit/095d8bd5ea7a704f6a21db54dbb2b4e30e785029[/url]

Issue was introduced here: [url]https://github.com/mangoszero/server/commit/25df692e5f55343c57b9553a94a7e806d84f0895[/url]

As I posted in the original thread:

[FONT=Verdana]Group loot seems to work for me? Only one member of the group can loot it here.[/FONT]

[URL="http://prntscr.com/5qjogk"]Screenshot by Lightshot[/URL]

I will test with my VM in ~10 min

Original discussion thread here:

[URL]https://www.getmangos.eu/developer-area-private-no-public-access-/10236-rel20-release-showstoppers-please-read.html[/URL]

To recap:

- Soul Shard issue is fixed. Skinning to be done.
- Resting issue fixed and under testing. Will update accordingly.

Edit:

Resting has been fixed, will push a commit for this now.

[url]http://prntscr.com/5qkuzd[/url]

Not through SD2 or the core :) Last option is then DB scripts

As far as I can see this has never been handled by SD2, even original SD2 does not have the said mobs implemented :)

Find the old scripts and PR to the scripts folder, they will be compiled accordingly automatically. Where are these ogres found btw?

EU and US is virtually identical :)

But I got the pet is in combat message even though my pet had enough focus to cast the spell? After a quick look, it seemed to me the pet spell casting logic was a bit.. Stupid.

After testing even more, I'm not able to reproduce the crash with any other tameable mob, even when I use the same spell data id.. This only seems to happen with special case mobs like Barnabus and other rare mobs. What's even more weird is after I removed the spell and tamed him, he would be longer respawn, even though the record is still in the creature table.

Will need some assistance looking into this as I'm at my wits end.. Have checked everything up and down several times, and can't for the life of me figure this one out.

Are these core crashes or client crashes?

Where is this pet found?

Edit:

Found it. This is really odd. I spawned a copy of the creature, taming went perfectly fine. Seems Barnabus and several other creatures are spawned on server reload instead of being a static entry in the database? Could possibly have something to do with it, as I see no specific scripts attached to him.

Edit 2:

Removed [COLOR=#000000]5961 from the PetSpellDataId column in Creature_template and taming worked perfectly fine. What is this table specifically used for?

Edit 3:

Alright so, the PetSpellDataId points to CreatureSpellData.dbc, which contains the specific spells the creature should have upon taming. [/COLOR][COLOR=#000000]5961 points to "Bite" - [/COLOR]17259. Why this crashes I still do not know. Will need further testing.

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.