Jump to content
TrinityCore

Search the Community

Showing results for tags 'group'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Releases and Announcements
  • Help and Support
    • Help and Support
  • Offtopic
    • Trinitycore.org Website issues
    • Chillout Room

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. Hello everyone. Thank you for creating such a wonderful project. My wife and I loved playing wow but could not stand most of the people on the live servers. So we setup trinity core 3.3.5a on Ubuntu here and are having a blast with it. Well done! We play a priest and a pally and bot 3 in the background windows. We are trying to play within the rules and let our characters develop normally so the game lasts longer. I have a (hopefully) simple question: 1. Is there a way to make the default group loot "Free for all" when you enter a dungeon finder instance. It is currently unchangeable and being we are running three characters in the background, we miss 3/5s of the loot in a dungeon unless we take the time to go through each window.
  2. I was trying to locate if Group::Disband is safe to call anywhere or if it is not thread safe. My assumption was that it is not thread safe since it is calling ObjectAccessor::FindConnectedPlayer, Player::GetGroup and Player::SetGroup I tried tracking where Group::Disband is called and everywhere it was in opcode handlers that were marked as threadunsafe. However I found one or more that were not threadunsafe. WorldSession::HandleBfEntryInviteResponse is STATUS_LOGGEDIN, PROCESS_INPLACE, which would mean it is executed when received. And since it seems packets are handled on a separate thread the code must be safe to call anywhere (is thread safe). The function however calls Battlefield::PlayerAcceptInviteToWar which calls Battlefield::AddOrSetPlayerToCorrectBfGroup which calls Group::RemoveMember which calls Group::Disband and that was assumed not to be thread safe. Conclusion is that if someone sends the packet for HandleBfEntryInviteResponse and someone in the same group is also removed from the group in any other code (for example the normal group leave opcode?) it would cause a race condition. Is there something guaranteeing the safety or is this a possible race condition? FFR: I used 3.3.5a https://github.com/TrinityCore/TrinityCore/commit/239f0b4ad0e83da9d31c8031aa2e50c294bfc913
×
×
  • Create New...