Closed Thread
Page 10 of 30 FirstFirst ... 6 7 8 9 10 11 12 13 14 20 ... LastLast
Results 136 to 150 of 439
Like Tree4Likes

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

  1. #136
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Another thing which came up today:

    Trinkets retrieved through Utility.Item.Slot.Equipment() do not have an information about onUse or onEquip effects.

    Cheers
    N.

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

    Default

    ".owner" is not working with summoned ability pets (such as Empty the Crypts). Works fine for normal pets as they are seen, I'm confident the problem is that the ability pets are never actually added to the specifier tree when summoned (there's no raw Event.Unit.Add for them).

    The .owner member is present in the Rift raw combat log.

    20:13:37: ( 3 , T=N#R=O#9223372046003492381 , T=N#R=O#9223372038247298264 , T=P#R=C#221239331907804514 , T=X#R=X#0 , Shambling Corpse , Runebroken Golem , 141 , 96431209 , Auto Attack ) Shambling Corpse's Auto Attack hits Runebroken Golem for 141 Physical damage. (29 overkill)

    The bold unitID is the owner.
    Rank 76 Guardian Mage

  3.   Click here to go to the next Rift Team post in this thread.   #138
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Naifu View Post
    Another thing which came up today:

    Trinkets retrieved through Utility.Item.Slot.Equipment() do not have an information about onUse or onEquip effects.

    Cheers
    N.
    There's still a few holes in the API like this - I wasn't able to come up with a good interface as yet.

  4. #139
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    When you create a Text frame, it's default height and width are a square box, it only resizes properly when you call SetText. It would be nice if the default height with no text was the same as if it had a single line of text in it.

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

    Default

    I'm having a little inconsistency with Event.Unit.Detail.Combat and Event.Combat.Death.

    While doing my usual day of testing with my new engine in HK Chronicles, Prince Dollin (on death) will throw an Event.Unit.Detail.Combat as false but never seems to throw an Event.Combat.Death to my usual handler any longer.

    But, with the above in mind, the Incorporeal Revenants do the exact opposite, they'll trigger an Event.Combat.Death but never an Event.Unit.Detail.Combat.

    For both examples I've had them both targeted myself upon death, or my pet had them targeted. The only consistent thing about it is that they both always seem to trigger the same way. If you get one message, you'll unlikely get the other, and I'm yet to see both sent at the same time (ideally I think the Death event should be first, or at least override the Combat one consistently).

    I'll work around this however with some checks in my Library and send both messages upon a units death to my addon, and any addon which uses it.
    Last edited by Semele; 11-17-2011 at 04:37 PM.
    Rank 76 Guardian Mage

  6. #141
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    With further testing, I removed the capturing of the Event.Unit.Detail.Combat events altogether and I still don't get the Event.Combat.Death event. So, I'm at a loss.

    Does explain the strange behavior of my addon since 1.6 though. Anyhow, raid in an hour, need to see if I can fix this before then.
    Rank 76 Guardian Mage

  7. #142
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    More feedback on what's going on. Problem with Prince is he apparently never dies (perhaps), always has hp left, and then the corpse is unavailable. So, maybe not the best test in the world.

    As for the revanant, I would imagine that the Combat.Death event overrides the Unit.Detail.Combat event, which is ok. I'll implement it as is tonight, and ensure there's no glitches. Could just be a case of fake deaths not triggering the API death event. Lessons learned either way.
    Rank 76 Guardian Mage

  8. #143
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    So, after some better testing with Bosses and Trash, I'm happy with the current messages from Death and combat, so far Combat leave messages appear after Death ones, and that's spot on. Sorry for the initial scare.
    Rank 76 Guardian Mage

  9.   Click here to go to the next Rift Team post in this thread.   #144
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Semele View Post
    So, after some better testing with Bosses and Trash, I'm happy with the current messages from Death and combat, so far Combat leave messages appear after Death ones, and that's spot on. Sorry for the initial scare.
    No problem, thanks for tracking down what was going on

  10. #145
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    This could totally be my bad, but the FIRST time I try to iterate over a frame item, I get the "Event" table twice. I'm using my SlashPrint addon (locally tweaked to be a little less buggy), but this is really just iterating over pairs(x).

    So if I grab some RiftWindow's :GetBorder(), and iterate it, I get two Event members... once. After that I only get one. (The two Event members appear to be the same table object.)
    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!)

  11. #146
    Shield of Telara Adelea's Avatar
    Join Date
    Mar 2011
    Posts
    734

    Default Client crash bug

    The following code will cause the client to crash when it first loads, but not after a /reloadui :

    Code:
    local RAW = {}
    
    function RAW.VariablesLoaded(addon)
    	if not (addon == "RAW") then
    		return
    	end
    	RAW.CreateTracker("Flamebound Defense")
    end
    
    function RAW.CreateTracker(name)
    	for k,v in pairs(Inspect.Achievement.List()) do
    		local d = Inspect.Achievement.Detail(k)
    		print (d.name)
    	end
    end
    
    table.insert(Event.Addon.SavedVariables.Load.End, { RAW.VariablesLoaded, "RAW", "VariablesLoaded" })
    The actual problem line is

    Code:
    		local d = Inspect.Achievement.Detail(k)
    This was working fine with 1.6, it's only since the hotfix #1 it has caused a problem.

    If I use Event.Addon.Startup.End as the initial trigger event it all works OK.
    Last edited by Adelea; 11-19-2011 at 02:12 AM.
    http://forums.riftgame.com/image.php?type=sigpic&userid=125779&dateline=13553  38065

  12. #147
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    If Inspect.Item.Detail is called a number of times repeatly it will throw an error.

    The following code illustrates the problem:

    Code:
    local list = {"I4573F16A106292BD,421D20CB2FAA6850,,,,,,", "I2154D82F5ECCAC6E,BF8E4C3D21726EEA,,,,,,", "I07DEA434464F1870,7C757A4FF5F2A906,,,,,,", "I223142862791758F,C57038A8D779F112,,,,,,", "I2281D65F7A332014,0D0C39131C6DCA71,,,,,,", "I0B6617AA1D80AC66,E89AFAB643DC1B78,,,,,,", "I3A9518E93375D0F7,0306EAEC391637B1,,,,,,"}
    
    for k, v in pairs (list) do
    	
    	print ('get ' .. v)
    	
    	local RiftItem = Inspect.Item.Detail(v)
    	dump (RiftItem)
    	
    end
    This will throw an error on one of the itemtypes provided. However if the itemtype throwing the error is then manually entered like this it will work:

    Code:
    /script dump(Inspect.Item.Detail('I07DEA434464F1870,7C757A4FF5F2A906,,,,,,'))
    So the itemtypes are not the problem, but calling Inspect.Item.Data a couple of time in fast succession it will stop working and throw an error.

    Cheers
    N.

  13.   Click here to go to the next Rift Team post in this thread.   #148
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Naifu View Post
    If Inspect.Item.Detail is called a number of times repeatly it will throw an error.
    Actually, there's something a bit more complicated going on here.

    The client doesn't have full item detail when it starts up (in fact, it's got very, very minimal item detail.) If you request item type data for an item you don't yet have, it'll throw an error, but it'll also send the server a request for that item. A later request - i.e. one server round-trip later, probably a few frames if you're on a good connection - will succeed.

    I bet if you call those manually, in a session *without* the loop that calls them in a row, you'll get the same error on the first call.

    Right now the intended fix is to use pcall() to trap the error. Still coming up with a better fix.

  14. #149
    Rift Disciple chuckySTAR's Avatar
    Join Date
    Feb 2011
    Posts
    152

    Default

    Quote Originally Posted by chuckySTAR View Post
    Code:
    Event.Combat.Damage(info)
    Inspect.Unit.Detail(info.caster)
    Inspect.Unit.Detail() is returning nil if event was triggered by pets like "split personality" and not accessible via unit specifiers like "target/groupXY/pet/owner/...".
    But info.caster is always a valid unit id.

    When i mouseover a split personality pet (now it's accessible via "mouseover") Inspect.Unit.Detail() is returning valid values and not nil
    And Inspect.Unit.Detail has another bug...
    On AoE'ing Event.Combat.Damage(info) triggers for everyone who got hit by that one ability. the first Inspect.Unit.Detail(info.target) will return valid values. but the other calls will return nil while info.target isn't nil!

    Same problem as in the quote... The other targets aren't accessible via the unit specifiers, so Inspect.Unit.Detail() returns nil...
    Last edited by chuckySTAR; 11-19-2011 at 12:54 PM.

  15. #150
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Actually, there's something a bit more complicated going on here.

    The client doesn't have full item detail when it starts up (in fact, it's got very, very minimal item detail.) If you request item type data for an item you don't yet have, it'll throw an error, but it'll also send the server a request for that item. A later request - i.e. one server round-trip later, probably a few frames if you're on a good connection - will succeed.

    I bet if you call those manually, in a session *without* the loop that calls them in a row, you'll get the same error on the first call.

    Right now the intended fix is to use pcall() to trap the error. Still coming up with a better fix.
    Hmmm that will be a problem for me then. What I need to do for my addon is to request the information for the items of a specifc loot table. So the addon knows it needs x items and will try to get the details. So this means in reality I will have to stick with extracting the neccessary information from the FTP XML file in future? DOH!

    Or do you mean by waiting a couple of frames to actually capture with pcall and retry until the item is there?

    Using pcall is was able to capture the error. Funny enough on around the 7th call (not the same item, 7 different items in a row) the error is not really captured by pcall and will be reported in the chat.

    Cheers
    N.
    Last edited by Naifu; 11-19-2011 at 02:30 PM.

Closed Thread
Page 10 of 30 FirstFirst ... 6 7 8 9 10 11 12 13 14 20 ... 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