• 0

    posted a message on Guide: Using UIDropDownMenu in your addon
    I'm trying to pass additional data via the Info.value pointer, from what I understand, this means I would have to put the data into a table.

    Eg: info.value ={subMenu="someMenu",data=table_a}

    The question is, would this be a good idea memory wise, as it seems to create alot of tables that would only be used for a short time.

    The current implementation i have is to have info.value in a formatted string where i string.match to pull values out, but I need to add a pointer to a table, which makes the current method invalid. Any insights? Thanks
    Posted in: Tips, FAQs, and Guides
  • 0

    posted a message on Guide: Using UIDropDownMenu in your addon
    Thanks for the workaround. That makes more sense now.

    Did you notice this scenario:
    Menu 1
    --Item 1 to 40
    --Item 1 to 40

    If i hard code a loop in menu A and mouse over / populate it, menu b works fine. However if I remove the loop code in menuA, menu B is limited to 30
    Posted in: Tips, FAQs, and Guides
  • 0

    posted a message on Guide: Using UIDropDownMenu in your addon
    I'm having some strange issues with UIDropDownMenu.

    If there are more than 30 entries in a submenu/ level, it seems that anything above 30 will get grayed out / un-clickable.

    Is this something to do with the UIDROPDOWNMENU_MAXBUTTONS taint?
    Posted in: Tips, FAQs, and Guides
  • 0

    posted a message on Converting higher ascii characters
    I'm trying to convert strings to capitalize the first character

    string.gsub(value, "^.",string.upper )
    works fine for normal values.

    But when the value starts with a higher ascill character(Ă–string), it seems to skip it. Is there a way for that to work?

    Posted in: Lua Code Discussion
  • 0

    posted a message on AceEvent3
    Is there an alternative way on creating user defined delay events as ScheduleEvent in AceEvent2 provided?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Dynamic Frames
    Side note, about GC

    I have placed the frames into an array. What is needed for the GC to clean it up? Do I just need to set the value of the key to null?


    local dynFrames = {}
    local f = CreateFrame('Frame', 'name', 'parent', 'xmlTemplate')
    local f2 = CreateFrame('Frame', 'name2', 'parent', 'xmlTemplate')
    etc.. etc
    table.insert(dynFrames ,f1)
    table.insert(dynFrames ,f2)

    So to destroy to f2 frame do I just dynFrames [2] = nil ?

    Posted in: Lua Code Discussion
  • 0

    posted a message on Dynamic Frames
    Solved it. Thanks for the help
    Below is an extract of the code

    <Frame name="myTemplateFrame" virtual="true" hidden="true" parent="UIParent" toplevel="true" movable="true" frameStrata="DIALOG" enableMouse="true" enableKeyboard="true" clampedToScreen="true" frameLevel="2">
    frame = CreateFrame("Frame", "myTemplateInstance", UIParent, "myTemplateFrame")
    I had a FauxScrollFrameTemplate in the template, for which I passed the self parameter back to the lua file for the OnVerticalScroll and OnShow events

    CLASS:EventHandler(self, offset)
    and in the lua code, using
    GetParent() and GetName() method, was able to reference the UI objects
    Posted in: Lua Code Discussion
  • 0

    posted a message on Dynamic Frames
    What would be the best practice to create a handler for multiple instances of the same gui frame?

    I've tried creating the gui components in lua, but I would prefer to have it implemented in XML and have lua create a new instance of it. Thanks
    Posted in: Lua Code Discussion
  • 0

    posted a message on HeadCount - Raid attendance and loot tracker
    Manual Event addition.

    Would it be possible to add a command line functions that allows the capture of custom user events?

    For example, currently, when taking attendance for ontime players, this would require another mod that allows a 'snapshot' function. It would be useful if HC allows creation of user maintain 'events' and allow the use to fire such events.

    In CTRT, the snapshot function does just that and also the MagicDKP has the option to create user events that can be triggered via command line.

    Just an update since my last post, for item DKP maintainance, I have managed to edit the CTRT importer to read dkp values off sql. I reckon it would be easier to maintain in the long run by handeling it on the server side and taking the load off ingame resources.

    As for the waitlist, while awaiting for it to be included into the next version of HC, we have taken a quick hack approach to it. Every time a event is captured in HC, a message is sent to the guild channel for waitlist players to reply in a formated string in the guild chat. After which, i written a script to phrase the wowchatlog to read the string and manually pick up the waitlist players.

    I have a few question with regards to the WaitList Group configuration. Currently I have set Raidlist Group to G1-G5, and Waitlist group to nothing.
    When an event is taken, strangely players in G6 are captured. Is this a misconfiguration on my part? I'm trying to only capture players in G1-G5 via HC and manually adding WL players.

    Posted in: Raid AddOns
  • 0

    posted a message on HeadCount - Raid attendance and loot tracker
    The format of the CTRT Import specification does have its limitations. Depending on the dkp policy, when items are set as Bank or DE, it does not really pose an issue. Its offspec or 'discounted price' items that are tricky to track. Our guild offer off-spec items at a flat discounted rate, so the challenge for the person taking DKP is to remember what items are offspec. We currently work around this by entering a keyplace value in the DKP cost text field. For normal priced items, we leave it as zero. When importing into CTRT, we will manually enter the dkp cost of the normal items, and when we see the keyplace value, we replace it with the discounted cost.

    Having the mod read the default values, off-spec values from a user maintained lua file would speed the administration process up. For normal priced item, the default value is picked up, and if the user selects off-spec, the mod can read the discounted value. If this approach is taken, it might be a good idea to add another button on the screen, so the user can select 'Normal', 'Bank', 'DE', Offspec'.

    As the 'Bank' and 'DE' options in a non-zero sum dkp system would mean that no dkp is awarded or deducted, its serves more as a listing purpose. However, the offspec bid would indicate that the item is semi-unwanted, and as such the cost is reduced to prevent sharding. In a zero-sum dkp system, the same approach can be taken, for the mod to read 'DE' values to allocate a dkp value, if the dkp policy states that de items cost less.

    All in all, i think this would be a generic implementation that can be customized by the end user to fit their needs. It is preferable that the values be read from a standalone file, so the user can edit it externally with existing text editor tools. Having a global setting/default calculation for offspec items would be a nice feature. Eg (-50%), so the user only needs to maintain the normal dkp cost, and the mod can calculate discounted items on the fly. If there is a user specified offspec value, the mod can read that value, instead of the global value, hence this would allow individual item customization

    Integrating waitlist functionality is, in my opinion one of the hardest feature, as different guilds award waitlist dkp differently. In most cases, this would result that the mod's logic would only apply to guilds subscribing to the implemented approach.

    What I propose is to split the functionality to allow generic WL features, but allow the user to handle exception cases.

    Most guilds award DKP to players on the waitlist, the difference is the condition in which a player is entitled to DKP.

    Case A - Ontime Waitlist
    Player is in raid before raid start, get placed on waitlist, and is treated as if they are in the physical (5/25man)raid . When the raid gets awarded dkp, these players get the same dkp value as players in the raid. However, players that are not ontime, but joined the waitlist late, although they are in the walitlist, they are not awarded any dkp.

    Case B - Free for All Walitlist
    As long as a player is on the waitlist, irregardless of when they joined it, they get dkp for that event.

    I believe those 2 are the main differences in guild DKP policies. The difficulty in administrating Case A is inherent in tracking limitations, as such most guilds and mods adopt the Case B approach.

    However, if we treat waitlist attendance as an exception instead of the norm, its possible to create a generic package that would work out of the box, but still allow the user the ability to manually add/edit waitlist players.

    Generic Waitlist
    - Allow players to add /remove themselves to the list via priv msgs
    - Listing players on waitlist.
    - Tracking the time a user join/left the waitlist.

    Integration to attendence & DKP
    When an event is triggered, the mod will broadcast a message for players to take roll-call. Waitlist players need to respond to that message to be included into the attendance list. The user can set a time frame for the reply before closing the roll-call.

    [Optional user specified logic : If a player is not on the waitlist, his rollcall will be ignored. If set to true, if player adds himself to the list when rollcall is announced, he gets on to the list, but roll call for that event is ignored. This ensures that all players register themselves on the waitlist before hand.]

    GUI Interface
    The players in the specified 'Raid List Group' (G1-G5) will always be tracked.

    Players that responded to rollcall and is valid goes onto a separate listbox gui.
    |#<Player A>###|`````|#<WLPlayer G> [ChkBox]##|
    |#<Player B>###|`````|#<WLPlayer H> [ChkBox]##|
    |#<Player C>###|`````|#<WLPlayer I> [ChkBox]##|

    In order for waitlist players to get awarded dkp, the checkbox need to be toggled. If none is selected, the xml exported string would only contain the [Raid List] players.

    This allows the mod to handle both cases, by adding a [Check All] button, the user can easily flag all waitlist players. This will handle Case B Free for all, and Case A will require the user to manually select the eligible players.

    By setting G1 to G5 & G8 as the Raid List group, the user can move standby players to G8 to always get dkp, or set G1-G5 and have everyone else handled as normal waitlist players.

    On a side note, I understand that works are also in the way to create user generated events. This would be a very nice feature, as it can be used to take ontime and raidend attendance. This would also allow the possibility to Auto toggle waitlist players that are found on the ontime event list.

    I've noticed that players that go offline for extended periods of time still get recorded as long as they are in the raid. Is this a feature that is working as intended, or a settings issue?

    I hope the feedback would be helpful when implementing the upcoming waitlist feature.

    Posted in: Raid AddOns
  • 0

    posted a message on HeadCount - Raid attendance and loot tracker
    Manage Loot : Offspec

    When selecting the Offspec option in the Manage Loot popup window, the Looter's name will be replaced with 'offspec'.

    I am unclear if that is the intended purpose, as when the xml string is imported into RT, the looter's name would be replaced with Offspec, which results in the lost of tracking of the original bidder.

    Is there a plan to allow users to populate items with a default dkp value, and specify the offspec value? Just having the mod read from a manually maintained lua file would save alot of time. This would allow the possibility for the user to specify the offspec price of each item.

    I understand that the waitlist function is in the works.
    One feature that helps in waitlist dkp management would be a 'roll call' check.

    For example, when an event is triggered, the players in raid (G1-G5 or however configured) gets recorded by default. The players that are on waitlist need to message the player that is running the mod to indicate that they are still online and ready. After a set duration, no more tells will be recorded and the final list of in-raid players + waitlist players for that event is recorded.

    Having the option for this check ensures that people on the waitlist is available and ready, and filter out offline players or players that are unavailable.

    Great mod. Fantastic work.

    Posted in: Raid AddOns
  • To post a comment, please or register a new account.