Download
(13 Kb)
Download
Updated: 07-26-12 05:44 PM
Updated:07-26-12 05:44 PM
Created:09-30-11 06:03 PM
Downloads:5,000
Favorites:5
MD5:
Safe's Raid Manager  Popular! (More than 5000 hits)
Version: v1.1.8
by: Snarty [More]
Requires LibUnitChange

First public release of my Raid library. This is the core of what I use to code all my addons and thought it may be useful to fellow developers.

It will be improved upon if need be, but I want this to be as streamlined as possible.

Events
Event.SafesRaidManager.Group.Join <-- Returns UnitID, GroupXX Specifier
Event.SafesRaidManager.Group.Leave <-- Returns UnitID, GroupXX Specifier
Event.SafesRaidManager.Group.Change <-- Returns UnitID, OldSpec, NewSpec
Event.SafesRaidManager.Player.Join <-- Returns Players UnitID
Event.SafesRaidManager.Player.Leave (Players is now solo)
Event.SafesRaidManager.Player.Ready <-- use this to wait for player details. (First Run)
Returns PlayerID {string}, PlayerDetails {table}
Event.SafesRaidManager.Pet.Add <-- Returns PetID {string}, OwnerID {string}
Event.SafesRaidManager.Pet.Remove <-- Returns PetID {string}, OwnerID {string}
Event.SafesRaidManager.Player.Pet.Add <-- Returns PetID {string}
Event.SafesRaidManager.Player.Pet.Remove <-- Returns nil

Commands
LibSRM.Group.Inspect(index) <-- Returns Specifier {string}, UnitID
LibSRM.Player.Grouped() <-- Returns True/False
LibSRM.Player.Ready() <-- Retruns True/False (details loaded)
LibSRM.Group.UnitExists(UnitID) <-- returns GroupXX Specifier if it exists, or nil
LibSRM.Group.PetExists(PetID) <-- returns GroupXX Specifier and OwnerID if exists, or nil
LibSRM.GroupCount() <-- returns 0 (ungrouped) or 2-20 if grouped.
v1.1.8
* Change: Forced dead Party/Raid members in to an out of combat state.

----
v1.1.7

Unit Tracking
* Change: Offline Party/Raid members are now forced out of combat.
* Change: Combat states are now monitored and updated more aggressively, but with less CPU overhead.

----
v1.1.6

Unit Tracking
* Fixed: Possible nil name values are now caught.

----
v1.1.5

Rift Version
* Change: Now compatible with 1.9.

Events
* Group
** New: Event.SafesRaidManager.Group.Reload = string, string (UnitID, Specifier)

System
* Initialization
** Change: Now uses the new Event.Unit.Availability.Full event to initialize the start-up procedure.
* Units
** Change: Now uses the new Event.Unit.Availability.Full event to Load unit details.

----
v1.1.4
* Rift Version
* Change: Now compatible with 1.8.
* New: LibSRM initialization string now gives its Version number.
* New: SRM will now maintain a Name List look-up table for quick name searches. See new command below.
* New: Command - LibSRM.Group.NameSearch(UnitName) -- returns Specifier, UnitID if available or nil.
* New: Event.SafesRaidManager.Group.Mode -- string("raid"/"party"). This is an educated guys on if you're in a raid or party.
* New: Event.SafesRaidManager.Group.Offline -- Group member is now off-line/on-line (true/false)
* Change: The player ready event (Stall) will now trigger only once the player is actually available.
* Change: SRM now replaces its existing event table entry with a new one, rather than deleting it.
* Change: SRM no longer runs an infinite Time check loop while waiting for Player available status.
* Engine Fixes
** Fixed (By Mere): Changes made to new Unit match break code was epic fail.
** Fixed (By Mere): Optimized condensed loop had incorrect UID variable name for Pet matching.
** Fixed: Several non-local local variables are now local.
** Removed: Redundant code from original engine.

----
v1.1.3
* Engine Tuning
** Change: Function SRM_UnitAvailable is now down to a single loop iteration when checking for queued units.

----
v1.1.2
* Player Ready
** Change: The .Player.Ready event will now only fire once the players name is available.
* Death Monitoring
** Fixed: New group members now correctly add to LibSRM.Dead
** Change: Adjusted how .combat state is registered for new group members.

----
v1.1.1
* Directory Structure
** Change: Addons only require that SafesRaidManager be Embedded or be a dependency.
----
v1.1.0
* Engine
** Various engine improvements and tweaks
* Group Events
** New: Event.SafesRaidManager.Group.Combat.Enter - Single Group member enters combat
** New: Event.SafesRaidManager.Group.Combat.Leave - Single Group member leaves combat
** New: Event.SafesRaidManager.Group.Combat.Start - Group now flagged as in combat
** New: Event.SafesRaidManager.Group.Combat.End - Group now flagged as out of combat
** New: Event.SafesRaidManager.Group.Combat.Damage - Group damage done
** New: Event.SafesRaidManager.Group.Combat.Heal - Group healing done
** New: Event.SafesRaidManager.Group.Combat.Death - Group member deaths
** New: Event.SafesRaidManager.Group.Combat.Res - Group resurrects
* Player Events
** New: Event.SafesRaidManager.Player.Combat.Enter - Player enters combat
** New: Event.SafesRaidManager.Player.Combat.Leave - Player leaves combat
* System Events
** New: Event.SafesRaidManager.Combat.Enter - Non-Raid/group unit enters combat
** New: Event.SafesRaidManager.Combat.Leave - Non-Raid/group unit leaves combat
** New: Event.SafesRaidManager.Combat.Death - Non-Raid/group unit deaths
** New: Event.SafesRaidManager.Combat.Heal - Non-Raid/group unit Heals
** New: Event.SafesRaidManager.Combat.Damage - Non-Raid/group unit damage
----
v1.0.0
* Status pushed to stable release.
* Now includes Zorba's LibUnitChange
----
v0.0.4 Beta
* Small change to the Event message firing order for Group.Join and Group.Leave. Player.Leave will now fire after the last Group.Leave event message, and Player.Join will now be the first event message to fire before a list of Group.Join event messages (inclusive of the player) to populate a newly created group or raid.
----
v0.0.3 Beta
* Bug Fix: Pet.Add returning nil incorrectly, or not firing at all.
* Non-Breaking Changes:
** Changed Initialization order, and events will not fire now until the player has fully loaded.
----
v0.0.2 Beta
* Added full Player and Group internal pet management, events and commands
* New Events
** Event.SafesRaidManager.Pet.Add < Returns PetID {string}, OwnerID {string}
** Event.SafesRaidManager.Pet.Remove < Returns PetID {string}, OwnerID {string}
** Event.SafesRaidManager.Player.Pet.Add < Returns PetID {string}
** Event.SafesRaidManager.Player.Pet.Remove < Returns nil
* New Commands
** LibSRM.Group.UnitExists(UnitID) < returns GroupXX Specifier if it exists, or nil
** LibSRM.Group.PetExists(PetID) < returns GroupXX Specifier and OwnerID if exists, or nil
** LibSRM.GroupCount() < returns 0 (ungrouped) or 2-20 if grouped.
----
v0.0.1 Beta
* Initial Release
Optional Files (0)


Archived Files (6)
File Name
Version
Size
Author
Date
v1.1.1
11kB
Snarty
02-25-12 01:58 PM
v1.0.0
6kB
Snarty
10-07-11 03:21 PM
v0.0.4 Beta
3kB
Snarty
10-04-11 03:58 PM
v0.03 Beta
3kB
Snarty
10-02-11 04:53 AM
v0.02 Beta
3kB
Snarty
10-01-11 06:07 PM
v0.01 Beta
2kB
Snarty
09-30-11 06:03 PM


Post A Reply Comment Options
Unread 06-29-13, 01:10 AM  
Snarty
 
Snarty's Avatar
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 226
Uploads: 6
Re: Plans to update?

Quote:
Originally Posted by Solsis00
Are you planning to update this library for the upcoming 2.4 patch? Would be extremely helpful and much appreciated.
I updated the library but it's now called LibSUnit (Safes Unit Library). You can find the folder in Modules for KBM. There's not much to change in your code, just changing over the events.

The reason for an entire change is because of the new event system, and because I wanted to optimize the library.

I'll be uploading the library as it's own addon shortly, along with full documentation.
Snarty is offline Report comment to moderator  
Reply With Quote
Unread 06-28-13, 05:57 AM  
Solsis00
Claw of Regulos
 
Solsis00's Avatar
AddOn Author - Click to view AddOns

Forum posts: 13
File comments: 212
Uploads: 1
Plans to update?

Are you planning to update this library for the upcoming 2.4 patch? Would be extremely helpful and much appreciated.
Solsis00 is offline Report comment to moderator  
Reply With Quote
Unread 04-01-12, 09:02 AM  
Mere
Zombie
AddOn Author - Click to view AddOns

Forum posts: 4
File comments: 84
Uploads: 0
Re: Re: Bug when group members leave

Quote:
Originally Posted by Snarty
Hiya Mere.
Anyhow, any changes I make won't effect existing addons since I won't make a change which breaks KBM, which uses the entire library. It's just about time for an optimization and extra layer of stability and plug that hole you found.
I've made a change to my embedded version. I don't think it's an API break, as it'll just push a group leave event where there should be one. I did a minor version bump so hopefully it'll be the version loaded.

You can see the change on:
http://git.riftui.com/?a=commitdiff&...222ae5417c109a

It fixes the issue for me in the short term

Look forward to seeing what you do with SRM_UnitAvailable stuff, as I'd quite like to avoid having to reproduce this code in some form for my own tracking of the group.
Last edited by Mere : 04-01-12 at 09:02 AM.
Mere is offline Report comment to moderator  
Reply With Quote
Unread 03-31-12, 01:33 PM  
Snarty
 
Snarty's Avatar
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 226
Uploads: 6
Just a quick note. Within 5 seconds of looking at the first function (SRM_UnitAvailable), I'll be reducing it to a single loop. Looks like I bolted pets on after and never really integrated it. Should be a far less expensive CPU method than the current one, which leads me to thinking there will be some more like that.

Well, this should be a fun little tidy up.
Snarty is offline Report comment to moderator  
Reply With Quote
Unread 03-31-12, 01:10 PM  
Snarty
 
Snarty's Avatar
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 226
Uploads: 6
Re: Bug when group members leave

Hiya Mere.

Nice find on that. I think you may have stumbled upon the issue I was having with it sometimes losing track of combat states. As, if this first event list were true it'd never take Tirla out of combat (if in combat when they left/got kicked).

Since I currently have KBM running an alpha pause right now to establish stability, I think I'm going to look over that entire engine to be honest. It was the first thing I wrote pretty much in Lua, learned a bit since that point.

Anyhow, any changes I make won't effect existing addons since I won't make a change which breaks KBM, which uses the entire library. It's just about time for an optimization and extra layer of stability and plug that hole you found.
Snarty is offline Report comment to moderator  
Reply With Quote
Unread 03-31-12, 06:40 AM  
Mere
Zombie
AddOn Author - Click to view AddOns

Forum posts: 4
File comments: 84
Uploads: 0
Bug when group members leave

Hi Snarty,

I've been using your raid manager for tracking group membership.

It appears that there's a logic bug when people leave the group.

I've a group of 3 members, and the player who is "group01" leaves the group, then the libunitchange events fire for all 3. This fires off the code in Unit:Change().

However, the raid manager doesn't pickup that the player who was group01 has left the group.

This happens when anyone leaves, and the code shuffles the players up.

An example sequence is: (MHF is my addon trying to consume the events)
11:55:42: [Tirla] has left the party
11:55:42: [Dev] Event.Unit.Unavailable {u04E3800018586094 = false}
11:55:42: [LibSRM] Unit Change Check: u04E3800017BDAC68
11:55:42: [LibSRM] Unit Changed position: Rahasana
11:55:42: [MHF] GroupChange: u04E3800017BDAC68, group02, group01
11:55:42: [MHF] GroupChange, removing Tirla
11:55:42: [MHF] GroupLeave, unitId u04E3800018586094, specifier group01
11:55:42: [MHF] relaying 0 panels
11:55:42: [MHF] id 1, userName Mere
11:55:42: [MHF] id 2, userName Rahasana
11:55:42: [MHF] GroupChange, moving Rahasana from group02 to group01
11:55:42: [MHF] relaying 0 panels
11:55:42: [MHF] id 1, userName Mere
11:55:42: [MHF] id 2, userName Rahasana
11:55:42: [Dev] Event.SafesRaidManager.Group.Change u04E3800017BDAC68 group02 group01
11:55:42: [LibSRM] Unit Change Check: false
11:55:42: [LibSRM] Unit possibly left group: Mere
11:55:42: [LibSRM] Unit Changed ignoring leave message.
11:55:42: [LibSRM] Unit Change Check: u04E38000175EDD8A
11:55:42: [LibSRM] Unit Changed position: Mere
11:55:42: [MHF] GroupChange: u04E38000175EDD8A, group03, group02
11:55:42: [MHF] GroupChange, moving Mere from group03 to group02
11:55:42: [MHF] relaying 0 panels
11:55:42: [MHF] id 1, userName Mere
11:55:42: [MHF] id 2, userName Rahasana
11:55:42: [Dev] Event.SafesRaidManager.Group.Change u04E38000175EDD8A group03 group02
11:55:42: [Dev] Event.Unit.Remove {u04E38000175EDD8A = "player", u04E3800017BDAC68 = "group01", u04E3800018586094 = false}
In this sequence, the raid manager never removes Tirla (the original group01 member) (MHF compensates) but eventually when everyone leaves the group, the raid manager doesn't detect that has occured, because it never processes that Tirla left the group.

To fix this I've taken the code that handles a normal removal from the group, and made it a seperate function. I can then call it from before we overwrite the player in group01, and so be sure that the player is either still in the group but also moving, or that they've left the group.

This has the nice effect that I can now be certain that all the group leave events occur, rather than having to guess that if the group change event overwrites an existing unitId that unitId has left the group.

This change makes the event sequence appear as:
12:27:09: [Tirla] has left the party
12:27:09: [Dev] Event.Unit.Unavailable {u04E3800018586094 = false}
12:27:09: [LibSRM] Unit Change Check: u04E3800017BDAC68
12:27:09: [LibSRM] Unit Changed position: Rahasana
12:27:09: [LibSRM] Unit possibly left group: Tirla
12:27:09: [LibSRM] Tirla has left the group.
12:27:09: [MHF] GroupLeave, unitId u04E3800018586094, specifier group01
12:27:09: [MHF] relaying 0 panels
12:27:09: [MHF] id 1, userName Mere
12:27:09: [MHF] id 2, userName Rahasana
12:27:09: [Dev] Event.SafesRaidManager.Group.Leave u04E3800018586094 group01
12:27:09: [MHF] GroupChange: u04E3800017BDAC68, group02, group01
12:27:09: [MHF] GroupChange, moving Rahasana from group02 to group01
12:27:09: [MHF] relaying 0 panels
12:27:09: [MHF] id 1, userName Mere
12:27:09: [MHF] id 2, userName Rahasana
12:27:09: [Dev] Event.SafesRaidManager.Group.Change u04E3800017BDAC68 group02 group01
12:27:09: [LibSRM] Unit Change Check: false
12:27:09: [LibSRM] Unit possibly left group: Mere
12:27:09: [LibSRM] Unit Changed ignoring leave message.
12:27:09: [LibSRM] Unit Change Check: u04E38000175EDD8A
12:27:09: [LibSRM] Unit Changed position: Mere
12:27:09: [LibSRM] Unit possibly left group: Rahasana
12:27:09: [LibSRM] Unit Changed ignoring leave message.
12:27:09: [MHF] GroupChange: u04E38000175EDD8A, group03, group02
12:27:09: [MHF] GroupChange, moving Mere from group03 to group02
12:27:09: [MHF] relaying 0 panels
12:27:09: [MHF] id 1, userName Mere
12:27:09: [MHF] id 2, userName Rahasana
12:27:09: [Dev] Event.SafesRaidManager.Group.Change u04E38000175EDD8A group03 group02
12:27:09: [Dev] Event.Unit.Remove {u04E38000175EDD8A = "player", u04E3800017BDAC68 = "group01", u04E3800018586094 = false}
12:27:09: [Dev] Event.Unit.Add {[false] = false, u04E38000175EDD8A = "player", u04E3800017BDAC68 = "group01"}
Do you want me to send over a patch? or is my description of the bug good enough?

Thanks,
Mere
Mere is offline Report comment to moderator  
Reply With Quote
Unread 10-27-11, 12:45 PM  
Snarty
 
Snarty's Avatar
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 226
Uploads: 6
Quote:
Originally posted by reilwin
Is there any particular reason for the unconventional jump from 0 to 2 in LibSRM.GroupCount()? Couldn't it simply return 1 (since while ungrouped, there's technically 1 person in the group). It would also make it easier to iterate through the group without having the check whether the player is currently grouped or not.

Also, LibSRM.Group.Inspect() returns nil for the UID when the player isn't in a party, is this expected behahviour?

Thank you for sharing this, it looks like it provides some handy functionality!
Yeah, it's something I toyed with. It all links with Player.Join/Leave messages. I guess I could easily change it so Group.Inspect would return if the player isn't in a party, and always return 1 base for group counts. The idea behind it was to give you a few ways to find if the player is solo or grouped. ie, any command which is group related would always return nil/0/false if they're not grouped.

I'll possibly add it so LibSRM.Group.Inspect() returns data, just a tough call, it could quite possibly break existing addons, with several already using the Lib.

The commands are just an extension of the message system, which is the key to the lib, so that you never have to register directly to Unit.Add/Unit.Remove.
Snarty is offline Report comment to moderator  
Reply With Quote
Unread 10-26-11, 02:16 AM  
reilwin

Forum posts: 0
File comments: 1
Uploads: 0
Is there any particular reason for the unconventional jump from 0 to 2 in LibSRM.GroupCount()? Couldn't it simply return 1 (since while ungrouped, there's technically 1 person in the group). It would also make it easier to iterate through the group without having the check whether the player is currently grouped or not.

Also, LibSRM.Group.Inspect() returns nil for the UID when the player isn't in a party, is this expected behahviour?

Thank you for sharing this, it looks like it provides some handy functionality!
Last edited by reilwin : 10-26-11 at 02:17 AM.
reilwin is offline Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump:

Support AddOn Development!

You have just downloaded by the author . If you like this AddOn why not consider supporting the author? This author has set up a donation account. Donations ensure that authors can continue to develop useful tools for everyone.