Closed Thread
Page 6 of 24 FirstFirst ... 2 3 4 5 6 7 8 9 10 16 ... LastLast
Results 76 to 90 of 357
Like Tree30Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Changelog Discussion

  1. #76
    Telaran
    Join Date
    Nov 2010
    Posts
    59

    Default

    Quote Originally Posted by Thuggernaught View Post
    Came across this in my addon.



    Anyone else get this error? I'm kinda puzzled by it.

    Code:
    cti.target.epbar:SetPoint("BOTTOMLEFT",cti.target.hpbar,"TOPLEFT")
    is what's throwing the error out of context.
    I'm guessing you have not set another of the frames' points on the Y-axis as well as setting the width of the frame.

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

    Default

    Quote Originally Posted by Thuggernaught View Post
    Came across this in my addon.



    Anyone else get this error? I'm kinda puzzled by it.

    Code:
    cti.target.epbar:SetPoint("BOTTOMLEFT",cti.target.hpbar,"TOPLEFT")
    is what's throwing the error out of context.
    An example:

    Code:
    local newframe = UI.CreateFrame("Frame", "name", context)
    newframe:SetWidth(400) -- awesome, the frame is 400 units wide
    newframe:SetPoint("TOPLEFT", UIParent, "TOPLEFT") -- and it's in the top-left of the screen
    newframe:SetPoint("TOPRIGHT", UIParent, "TOPRIGHT") -- and it's . . . in the top-right of the screen?
    -- Oh no that doesn't work, it can't be in the topleft *and* the topright *and* 400 units wide!
    -- Abort, abort

  3. #78
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    I've just been trying to adjust my LibSimpleWidgets for the deprecation of GetDefaultHeight/etc. and, I have to say, it's damn awkward. The main problem is that my custom widgets whose primary frame is just a normal Frame type cannot have the same "default height until set" behavior that the native frame types do. And that makes it very hard to treat custom and native widgets the same when doing automatic layouts that need to know things like default heights.

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

    Default

    Quote Originally Posted by Thuggernaught View Post
    Came across this in my addon.



    Anyone else get this error? I'm kinda puzzled by it.

    Code:
    cti.target.epbar:SetPoint("BOTTOMLEFT",cti.target.hpbar,"TOPLEFT")
    is what's throwing the error out of context.
    Sounds like you didn't test your addon on the PTS, its quite a good idea to do the additional testing there as well as testing on live. I appreciate that it gets tricky but you can check against specific new behaviour before the patch goes live so your addon doesn't break when a patch comes out. Your issue is due to the breaking change we've had a months notice of ie: Frames no longer need to force SetWidth & SetHeight if they are setting relative height & width (relative to another frame's position). If you set specific width you cannot then anchor a frame to two points. So the old test examples in Zorba's Buff Bars for instance no longer work. I think Zorba put up refreshed versions of the ZorbaBuffBars that actually work in 1.6 so that you have new examples to check against (if not then hint hint this is needed )

    What you will find is that you are setting the height or the width of the frame in two different ways and those two different ways are conflicting. Check the earlier in this changelog thread and in the breaking changes thread for specific details.
    Last edited by Levva; 11-17-2011 at 06:14 PM.

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

    Default

    Quote Originally Posted by dOxxx View Post
    I've just been trying to adjust my LibSimpleWidgets for the deprecation of GetDefaultHeight/etc. and, I have to say, it's damn awkward. The main problem is that my custom widgets whose primary frame is just a normal Frame type cannot have the same "default height until set" behavior that the native frame types do. And that makes it very hard to treat custom and native widgets the same when doing automatic layouts that need to know things like default heights.
    Hmm. That's a reasonable point.

    Would it work to add SetDefaultHeight/SetDefaultWidth functions to Frame and only frame? (Conceptually, everything that inherits from Frame now would inherit from some common ancestor, and Frame would be turned into a leaf - this is something I've been thinking about doing anyway.)

    No guarantees this will happen, won't be until 1.7 at earliest, but let me know if that would solve the problem.

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

    Default

    Quote Originally Posted by Levva View Post
    So the old test examples in Zorba's Buff Bars for instance no longer work.
    It actually turns out that ZBB still works, just the hacked and modified versions I play the game with don't ;)

    All that said, yeah, this was a pretty bad breaking change and one I agonized over. I'm hoping to avoid anything of this magnitude in the future. However, it's always a good idea to test on the PTS - I'm getting reports of slow addon rendering, for example, and that's the kind of thing that would have been great to know a week earlier. As it is, might take a bit to fix.

    If you're running a popular addon, test on the PTS!

  7. #82
    Rift Disciple
    Join Date
    Jun 2011
    Posts
    142

    Default

    My ZBB version is still working. The only thing that is annoying me is that it's telling me something about an infinite loop on the y-axis. I'll figure that out I guess
    There is no rogue dev. Prove me wrong.

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    It actually turns out that ZBB still works, just the hacked and modified versions I play the game with don't ;)
    I was actually meaning to emphasis OLD test examples as clearly some people haven't updated. Otherwise Noerkel wouldn't be saying

    Quote Originally Posted by Noerkel View Post
    The only thing that is annoying me is that it's telling me something about an infinite loop on the y-axis.
    This is clearly the pre-breaking change version he is running.

    I have no problems with breaking changes, they are sometimes required to avoid things just getting messy further down the line and often its better to revamp and break things than try to continue to support an old method. Just please avoid the old Blizzard trick of "lets add a new return parameter to our function and stick it in the middle of the return parameter list so that all old code breaks" type of breaking change.

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

    Default

    Quote Originally Posted by Levva View Post
    Just please avoid the old Blizzard trick of "lets add a new return parameter to our function and stick it in the middle of the return parameter list so that all old code breaks" type of breaking change.
    This exact problem is why all the combat log events give you tables, not long lists of parameters

  10. #85
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Hmm. That's a reasonable point.

    Would it work to add SetDefaultHeight/SetDefaultWidth functions to Frame and only frame? (Conceptually, everything that inherits from Frame now would inherit from some common ancestor, and Frame would be turned into a leaf - this is something I've been thinking about doing anyway.)

    No guarantees this will happen, won't be until 1.7 at earliest, but let me know if that would solve the problem.
    I *think* it would help. It would certainly help custom Frame-based widgets behave more like native widgets. The trick is then to be able to calculate the default height and width to set before any anchoring is done that would alter the inner frames' default heights and widths. I'll experiment and see if the code would make sense if those functions were available.

  11. #86
    Plane Touched
    Join Date
    Nov 2010
    Posts
    253

    Default Zbb

    Could you please post a link to the Zorba Buff Bars addon that is currently working with 1.6 -- I've searched and cannot find this anywhere?

    Thank you in advance

  12. #87
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Quote Originally Posted by Ytek View Post
    Could you please post a link to the Zorba Buff Bars addon that is currently working with 1.6 -- I've searched and cannot find this anywhere?

    Thank you in advance
    The only ZBB link is ftp://ftp.trionworlds.com/rift/addon/ which was in the Example Addons thread.

  13. #88
    Plane Touched
    Join Date
    Nov 2010
    Posts
    253

    Default 1.6

    If I remember correctly the version of ZBB that is on the ftp does not work with 1.6

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

    Default

    Quote Originally Posted by Ytek View Post
    If I remember correctly the version of ZBB that is on the ftp does not work with 1.6
    To the best of my knowledge, it works. If it doesn't, give me a bug report.

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

    Default

    1.6 LIVE CHANGELIST:

    BUGFIXES:

    * Fix a layout issue with calling SetParent() as a result of a keypress event.
    * Fix an uncommon crash with changing text fonts.
    * Add toughness, valor, and vengeance to the returned stats from Inspect.Item.Detail().
    * Fix rare crash involving errors generated in events.
    * Fix performance issues involving moving text frames around.
    * Fix common crash involving text allocation.

Closed Thread
Page 6 of 24 FirstFirst ... 2 3 4 5 6 7 8 9 10 16 ... 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