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

Comment Options

04-01-12, 09:02 AM
Mere Zombie Forum posts: 3 File comments: 59 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.

03-31-12, 01:33 PM
Snarty   Forum posts: 0 File comments: 220 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.

03-31-12, 01:10 PM
Snarty   Forum posts: 0 File comments: 220 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.

03-31-12, 06:40 AM
Mere Zombie Forum posts: 3 File comments: 59 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

10-27-11, 12:45 PM
Snarty   Forum posts: 0 File comments: 220 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.

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.