Closed Thread
Page 12 of 30 FirstFirst ... 2 8 9 10 11 12 13 14 15 16 22 ... LastLast
Results 166 to 180 of 439
Like Tree4Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Addon system bug reports

  1. #166
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    in nkRebuff there's a functionality which crashes the client. It does it each and every time. The problem is, that I was not able to pinpoint the exact area of problem. In the end it has to do with changing the parent of an existing frame to another and reverse.

    Unfortunately a small test addon I did, didn't show the effect so I can't tell you exactly what it is. Looks like the source of the problem is more complicated than just the SetParent command which finally does crash the client.

    If you're interested you could take Version 1.4.5 of nkRebuff and do the following:
    - Open configuration through minimap button or /nkrebuff
    - Click on the 'locked' checkbox (this will show the 'move' frame)
    - Re-Click on it
    - Click on it a third time

    => Crash

    Apart from creating / showing the frame to move things around the only other thing it does is changing the parent of another frame towards that 'move' frame. That works the first time, but crashes on the second for no reason.

    So in the end I can't tell you exactly why the API crashes and what circumstances happen, but hopefully this information is of help anyway. It's definitely the SetParent command, cause if I remove that the crashes are gone. Well I was planning to rewrite some parts anyway so I'll shift priorities ...

    Cheers
    N.
    Last edited by Naifu; 11-25-2011 at 05:47 AM.

  2. #167
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    Quote Originally Posted by Naifu View Post
    in nkRebuff there's a functionality which crashes the client. It does it each and every time. The problem is, that I was not able to pinpoint the exact area of problem. In the end it has to do with changing the parent of an existing frame to another and reverse.

    Unfortunately a small test addon I did, didn't show the effect so I can't tell you exactly what it is. Looks like the source of the problem is more complicated than just the SetParent command which finally does crash the client.

    If you're interested you could take Version 1.4.5 of nkRebuff and do the following:
    - Open configuration through minimap button or /nkrebuff
    - Click on the 'locked' checkbox (this will show the 'move' frame)
    - Re-Click on it
    - Click on it a third time

    => Crash

    Apart from creating / showing the frame to move things around the only other thing it does is changing the parent of another frame towards that 'move' frame. That works the first time, but crashes on the second for no reason.

    So in the end I can't tell you exactly why the API crashes and what circumstances happen, but hopefully this information is of help anyway. It's definitely the SetParent command, cause if I remove that the crashes are gone. Well I was planning to rewrite some parts anyway so I'll shift priorities ...

    Cheers
    N.
    Yeah, I use a recycling system for almost every frame type in the game (so I don't load everything under the sun in one chunk). So, like my addon, the latest "fix" really screwed me over.

    I spent all night debugging an error I couldn't see, and came to a similar conclusion to you. My remedy was to queue frame removing to the main Event.System.Update.Begin loop and unlink them there. But, it's something to do with frames and their parents, and possibly any extra data pinned to them. This hasn't totally fixed it, but the circumstances required for it to crash the client would never appear during a raid, or any normal use of my addon, only during extreme stress testing and even then it takes some doing.

    To be honest, if we could de-allocate frames cleanly and have them removed from memory none of this would be an issue our end. This whole recycling business is very messy, and I don't like it one bit. Allocation and de-allocation should of been hand-in-hand and supported as the bare minimum of the API.. unless of course Trion haven't found how to cleanly remove resources from memory themselves.

    I feel let down that I'm one of the few developers who is conscious about memory management for the end user, and minimal CPU usage, and get screwed over whenever Zorba caters for the memory hogs out there. You say "don't use too much memory" when you don't actually support correct development practices of memory management.
    Last edited by Semele; 11-25-2011 at 02:21 PM.
    Rank 76 Guardian Mage

  3. #168
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    I think the underlying issue is that allowing deallocation of frames ALSO creates, at the very least, a potential for crashes. It's hard to make it bulletproof.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  4. #169
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    Quote Originally Posted by the_real_seebs View Post
    I think the underlying issue is that allowing deallocation of frames ALSO creates, at the very least, a potential for crashes. It's hard to make it bulletproof.
    When "changing" frames parent crashes the client at the moment, I think that's a worthless comment. And no, de-allocation of memory should be the best way to do it. When a frame is no longer referenced, should it really be able to sit in memory unreferenced? Nice memory leak.

    So, the best way is to have an actual interface to allow freeing of frames (any element for that matter), and the client then queues these in a bin to dump on the next garbage collection.

    Hardly a valid argument for not having it when the current method is horribly flaky as is.

    I don't appreciate "fixes" coming out silently server side that screw over several hundred (players who use my addon) people and it never once touched PTS. It was working, the server fix went out, then it wasn't working. Nothing changed in my code while I slept.
    Rank 76 Guardian Mage

  5. #170
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    After 3 sleepless nights and not actually getting to enjoy any of the game, fixing things I didn't introduce. It's come to my attention you should remove :SetParent() entirely until it's "safe". Currently it can and will crash the client with no errors.

    As it stands, there's no real way to replicate (maybe there is, I really can't be bothered finding it), but it usually happens in a dynamic frame environment (where the parent is free to change). I instead moved to a dynamic object environment where the parent of frames never changes.

    Anyhow, I'm now at the point I was before the change. Time to move forward.
    Rank 76 Guardian Mage

  6. #171
    Rift Disciple
    Join Date
    Apr 2011
    Posts
    120

    Default

    Code:
    /script for k,_ in pairs(Inspect.Ability.List()) do dump(Inspect.Ability.Detail(k)) end
    I noticed that while "Omen Sight", "Planar Lure" and "Lure of the Eye" appear in the output, the following abilities do not (I'm supposing these are the "nil" entries that appear):

    Bless Wardstone
    Guardian's Flare
    Holy Champion
    Planar Protection (guild perk)
    Blood Thirsty (guild perk)
    Summon Guild Rally Banner (guild perk)
    Summon Banner of Rage (guild perk)
    Summon Banner of Zeal (guild perk)
    Summon Banner of Precision (guild perk)
    Call of the Ascended (guild perk)
    Fire Lure (from Planar Attunement)
    Water Lure (from Planar Attunement)
    Life Lure (from Planar Attunement)
    Air Lure (from Planar Attunement)
    Summon Cadbury (veteran reward)
    Activate Ancient Wardstone (this one I kind of understand)

    the Planar Attunement abilities are the ones I'm particularly interested in today.

    -ken
    Snowreap Yellowtail Preyz Taralin
    < The Purge > Guardian Seastone

  7. #172
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    This may well be a bug that is not in the addon system per se, but:

    Inspect.Item.Detail() of an Eternal Puresource (the level 48 "planar loot" container item) says it is "crafting material gem" for category. While I can think of many categories I would place it in, those are three of the categories I would not count it as being in.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  8. #173
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Oh, while I'm at it:
    It is an inconvenience to me that I can't find a specifier for "all the items which are contained in my inventory, but which are not the bags themselves", likewise for bank. Basically, since Utility.Item.Slot.Inventory() includes sibg.*, it's much harder than I'd like to express a concept like "move all crafting materials to-inventory". There's no slot specifier that denotes "the contents of my inventory". It seems like it would be really handy to have a way to express that.

    And similarly, now that I'm messing with that kind of shuffling, the inability to tell whether the bank slots are currently movable is a bit of a pain.

    And I cannot comprehend the distinction between crafting "material" and crafting "ingredients".
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  9. #174
    Shadowlander
    Join Date
    Sep 2011
    Posts
    29

    Default

    Inspect.Mouse is acting weird. It's returning negative numbers at top and left, and the numbers to the right and bottom are less than width and height. Is there some scaling thing I don't know about?

  10. #175
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default Unit Frames

    Having troubles setting up unitframes for party or raid. The problem is when it shows player, it doesnt show the corresponding group##. So if I start a group and there are 3 ppl in it. It would be player, group02, group03. If I join a group it could be group01, group02, player. No way that I can see what group# the player is. In a raid, same thing. Shows all the group## except the spot I am in. If I do an Inspect.Unit.Lookup for each of the frames, it will tag each frame to the group#. If I do a lookup(group) OR lookup(player) then it will fill all the empty frames with player. It would be nice if Inspect.Unit would inject group# as well as player but it doesnt. Please help, someone :P
    Last edited by TinnerKB; 12-05-2011 at 07:51 PM.

  11. #176
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    Quote Originally Posted by TinnerKB View Post
    Having troubles setting up unitframes for party or raid. The problem is when it shows player, it doesnt show the corresponding group##. So if I start a group and there are 3 ppl in it. It would be player, group02, group03. If I join a group it could be group01, group02, player. No way that I can see what group# the player is. In a raid, same thing. Shows all the group## except the spot I am in. If I do an Inspect.Unit.Lookup for each of the frames, it will tag each frame to the group#. If I do a lookup(group) OR lookup(player) then it will fill all the empty frames with player. It would be nice if Inspect.Unit would inject group# as well as player but it doesnt. Please help, someone :P
    Should really be a separate thread, as I don't think this is a bug just an understanding issue.

    There is no guarantee that your group members are group01, group02 etc. Initially yes it will be like this but with adding/removing group people as happens a LOT during things like invasion events, you can quite easily have a group of 2 where one person is "group02" and other is "group19" (in a raid setup ofc).

    Note that if your group is group01, group02, group03 it MIGHT show up as group01, player, group03 or it might show up as player1.target, player, group01.pet.target if you are targeting the first player and the first player's pet is targeting the 3rd player. HOWEVER in this circumstances doing an Inspect.Unit.Detail("group02") will still give you back details for yourself just as if you had used Inspect.Unit.Detail("player"). The reason for this is that multiple specifiers can refer to the same unit ID, its just that Inspect.Unit.List only returns a single specifier for each unit randomly chosen. (cf. Inspect.Unit.List documentation "Units with multiple valid specs will have one chosen at random.").

    Personally I'd like to have Inspect.Group.List() to return a table of unit IDs of the members of your group. With Event.Group.Add and Event.Group.Remove firing when a player joined or left your group.
    Last edited by Levva; 12-06-2011 at 03:25 AM.

  12. #177
    RIFT Fan Site Operator Aieny's Avatar
    Join Date
    Feb 2011
    Location
    Earth
    Posts
    472

    Default

    Quote Originally Posted by Levva View Post
    Should really be a separate thread, as I don't think this is a bug just an understanding issue.

    There is no guarantee that your group members are group01, group02 etc. Initially yes it will be like this but with adding/removing group people as happens a LOT during things like invasion events, you can quite easily have a group of 2 where one person is "group02" and other is "group19" (in a raid setup ofc).

    Note that if your group is group01, group02, group03 it MIGHT show up as group01, player, group03 or it might show up as player1.target, player, group01.pet.target if you are targeting the first player and the first player's pet is targeting the 3rd player. HOWEVER in this circumstances doing an Inspect.Unit.Detail("group02") will still give you back details for yourself just as if you had used Inspect.Unit.Detail("player"). The reason for this is that multiple specifiers can refer to the same unit ID, its just that Inspect.Unit.List only returns a single specifier for each unit randomly chosen. (cf. Inspect.Unit.List documentation "Units with multiple valid specs will have one chosen at random.").

    Personally I'd like to have Inspect.Group.List() to return a table of unit IDs of the members of your group. With Event.Group.Add and Event.Group.Remove firing when a player joined or left your group.
    You can create your own Inspect.Group.List() function:
    Code:
    Inspect.Group = Inspect.Group or {}
    
    function Inspect.Group.List()
        local unitSpec = {"group01", "group02", "group03", "group04", "group05", "group06", "group07", "group08", "group09", "group10", "group11", "group12", "group13", "group14", "group15", "group16", "group17", "group18", "group19", "group020"}
        local retList = {}
    
        for _,unit in pairs(unitSpec) do
            if Inspect.Unit.Lookup(unit) then
                retList[unit] = Inspect.Unit.Lookup
            end
        end
    
        return retList
    end
    Your current group position as player should return your unit ID when you lookup by group, so you can compare Inspect.Unit.Lookup("groupXX") with Inspect.Unit.Lookup("player") to see what position you are within the group. Specifiers that are returned are the shortest, most convenient way to address a unit.....it's easier to address "player" than "group02", for example.
    a community-oriented site for all things Rift

  13. #178
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    Quote Originally Posted by Aieny View Post
    Specifiers that are returned are the shortest, most convenient way to address a unit.....it's easier to address "player" than "group02", for example.
    This is what I thought should happen however the documentation for Inspect.Unit.List() says "Map of unit ID to unit specifier. Units with multiple valid specs will have one chosen at random."

    Is this wrong and its the shortest specifier and not a random specifier?

    In passing I think the documentation should say "specifiers" rather than "specs" as specs in a MMO tends to have a very different meaning to do with talent tree setups. I know specs for talent trees is out of context in this location and specifiers makes sense I just don't mentally quickly identify specs as an abbreviation for specifiers.
    Last edited by Levva; 12-06-2011 at 05:34 AM.

  14. #179
    RIFT Fan Site Operator Aieny's Avatar
    Join Date
    Feb 2011
    Location
    Earth
    Posts
    472

    Default

    I doubt it's actually "random"....to me, that is a disclaimer that you may not get the specifier you expect when you call the Lookup if there are multiple ways to reach it. I suspect it's more a case of the longer the path, the more random the returned path will be. And once it has found a specifier, it returns without looking for more possibilities.

    In other words, if my pet is targeting a mob, and a group member is targeting a mob, then the Lookup for the mob unit id could be player.pet.target or group02.target. Whichever the code finds first, wins. I'm also going to go out in a limb and say that, under the exact same circumstances, you'll invariably get the same specifier. However, it could be based in which unit specifier first applied to the unit...to expand my example, if my pet was the first to target the mob, then the group member, it would return player.pet.target; if the group member targeted first, Lookup would return group02.target.
    a community-oriented site for all things Rift

  15. #180
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default

    Quote Originally Posted by Aieny View Post
    You can create your own Inspect.Group.List() function:
    Code:
    Inspect.Group = Inspect.Group or {}
    
    function Inspect.Group.List()
        local unitSpec = {"group01", "group02", "group03", "group04", "group05", "group06", "group07", "group08", "group09", "group10", "group11", "group12", "group13", "group14", "group15", "group16", "group17", "group18", "group19", "group020"}
        local retList = {}
    
        for _,unit in pairs(unitSpec) do
            if Inspect.Unit.Lookup(unit) then
                retList[unit] = Inspect.Unit.Lookup
            end
        end
    
        return retList
    end
    Your current group position as player should return your unit ID when you lookup by group, so you can compare Inspect.Unit.Lookup("groupXX") with Inspect.Unit.Lookup("player") to see what position you are within the group. Specifiers that are returned are the shortest, most convenient way to address a unit.....it's easier to address "player" than "group02", for example.
    In my code I have 4 tables instead of 1 to use on 4 columns.
    For the code for the 1st column for example...
    for i = 1, 5 do
    if Inspect.Unit.Lookup(rhogroupstr1[i]) then
    ----show frames if exists.
    end
    end
    SO..testing just with my brother and myself, it would show a frame for group02, not group01 because the Lookup returned nil for group01. Kinda hard to compare Lookup("group01") with Lookup("player") when the first returns nil.


    EDITisregard all above. I got it to work and it does report correctly. I forgot to advance a variable in the loop so it was being overwrote and made it look like it wasnt found at all.

    However, this is a bug. Inspect.Unit.List() does not ALWAYS show a pet in the list. 9 times out of 10 it will but there is always a chance it wont. I have also noticed using Archimedes addon that the pet frame doesnt always work as well, wether on loadup or through zoning. A reloadui does fix it.
    Last edited by TinnerKB; 12-06-2011 at 08:21 AM.

Closed Thread
Page 12 of 30 FirstFirst ... 2 8 9 10 11 12 13 14 15 16 22 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts