Closed Thread
Page 7 of 30 FirstFirst ... 3 4 5 6 7 8 9 10 11 17 ... LastLast
Results 91 to 105 of 439
Like Tree4Likes

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

  1. #91
    Rift Disciple
    Join Date
    Apr 2011
    Posts
    120

    Default

    that works if your settings table is shallow (i.e. it contains no subtables). but if your settings table has subtables, those subtables get copied in their entirety, so you lose new defaults that are buried farther down.

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

  2. #92
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    This does not behave the way I would expect it to:

    Code:
    local context = UI.CreateContext("blah")
    local frame = UI.CreateFrame("Frame", "blah2", context)
    frame:SetBackgroundColor(1, 1, 1, 1)
    frame:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
    frame:SetWidth(500)
    frame:SetHeight(500)
    frame:SetPoint("BOTTOMRIGHT", UIParent, "TOPLEFT", 200, 200)
    This is a contrived example, but the point is that if width and height are set on a frame, then if at some later point BOTTOMRIGHT is set, it has no effect. This is counter-intuitive, since setting BOTTOMRIGHT is implicitly affecting the width and height and should replace the original settings.

    I know I can use ClearAll in before setting the BOTTOMRIGHT but then I have to set up the frame's anchoring from scratch.

    I'm wondering how I can accomplish something like RiftTextfield's default sizing on my own Frame without using SetWidth or SetHeight.

    Edit: A better workaround is to use ClearWidth and ClearHeight.
    Last edited by dOxxx; 10-23-2011 at 04:45 PM.

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

    Default

    Quote Originally Posted by dOxxx View Post
    This is a contrived example, but the point is that if width and height are set on a frame, then if at some later point BOTTOMRIGHT is set, it has no effect. This is counter-intuitive, since setting BOTTOMRIGHT is implicitly affecting the width and height and should replace the original settings.
    On the PTS, doing this will generate an error message. It's possible this should be a warning - we'll be evaluating the actual impact of turning this into an error - but in any case, it's now a loud complaint from the addon system.

    Note that it's not a problem with BOTTOMLEFT specifically, it's an issue with overspecifying frames. You can't set two points *and* a size on an axis because those three values may conflict. Same issue with three points - what happens if we set TOPLEFT=100,100, CENTER=200,200, BOTTOMRIGHT=400,400? There's simply no way to resolve those constraints.

    The reason we can't just replace the original settings is that it's unclear which part of the settings should be replaced. Should it replace width/height or TOPLEFT? Either option would result in a consistent result, but they obviously mean very different things.

    That said, you could change the SetWidth/SetHeight lines to frame:SetPoint("BOTTOMRIGHT", frame, "TOPLEFT", 500, 500) and it would just sort of work.

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

    Default

    Quote Originally Posted by Rumil View Post
    I realize people probably haven't thrown many large tables at the addon system yet, I'd just like to know if this is a fixable limitation or are we stuck at 65K variables? Imagine writing an auctioneer addon with a limit of 65K table entries
    The restriction isn't with the size of a Lua table, it's with the impact on the parser to load a monolithic block of data. Assuming I'm reading this correctly, you're limited to 65536 constants, either in a single file or in a single line of code. I suspect the latter.

    Right now, you have:

    Code:
    RiftItems = {
      ["BigKeyHere"] = {["Parameter"] = "Data"},
      ["BiggerKeyHere"] = {["Parameter"] = "Data"},
    }
    Try transforming things to look more like:

    Code:
    RiftItems = {}
    
    RiftItems["BigKeyHere"] = {Parameter = "Data"}
    RiftItems["BiggerKeyHere"] = {Parameter = "Data"}
    No guarantees, but I suspect that will improve matters.
    Last edited by ZorbaTHut; 10-24-2011 at 12:59 AM.

  5. #95
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Quote Originally Posted by ZorbaTHut View Post
    On the PTS, doing this will generate an error message. It's possible this should be a warning - we'll be evaluating the actual impact of turning this into an error - but in any case, it's now a loud complaint from the addon system.

    Note that it's not a problem with BOTTOMLEFT specifically, it's an issue with overspecifying frames. You can't set two points *and* a size on an axis because those three values may conflict. Same issue with three points - what happens if we set TOPLEFT=100,100, CENTER=200,200, BOTTOMRIGHT=400,400? There's simply no way to resolve those constraints.

    The reason we can't just replace the original settings is that it's unclear which part of the settings should be replaced. Should it replace width/height or TOPLEFT? Either option would result in a consistent result, but they obviously mean very different things.

    That said, you could change the SetWidth/SetHeight lines to frame:SetPoint("BOTTOMRIGHT", frame, "TOPLEFT", 500, 500) and it would just sort of work.
    Thanks for the explanation. I was wondering then how does the RiftTextfield, etc. set their default sizes without us encountering this problem when we then subsequently try to anchor them?

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

    Default

    Quote Originally Posted by dOxxx View Post
    Thanks for the explanation. I was wondering then how does the RiftTextfield, etc. set their default sizes without us encountering this problem when we then subsequently try to anchor them?
    They use a different and easily-overridable method of setting size that isn't available for the outside world to use. Essentially they just change their defaults.

  7. #97
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default Screen Dimensions

    When logging in from character screen, UIParent:GetWidth() and UIParent:GetRight() take their values from the base graphics settings. ie. 1280x960 and such. It doesnt see the values set in the Global UI scale in the interface display settings until you do a /reloadui. Example of this is the addon FooBar. I have the global ui scale set at 75, places my screen about 1700 instead of 1280. When logging in, the addon bar is about 2/3 of the way across my screen. Once I do a /reloadui it will then expand the total screen width.
    If I logout and login on another alt it happens again.

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

    Default

    slider:SetPosition appears not to like non-integer arguments.

    This isn't EXACTLY a bug. But what will happen if no two people working around it pick the same solution will be. Please make SetPosition do something consistent and documented with non-integer arguments, probably just math.floor(x + 0.5) or something cheezy like that.
    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. #99
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    RiftTextfield should automatically lose key focus when it is no longer visible, due to SetVisible(false) being called on either itself or one of its ancestors.

    It is very difficult to workaround this since there is no easy way to determine when a frame is no longer visible, without hooking SetVisible in the frame and all its ancestors, which would be tedious to say the least.

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

    Default

    Code:
    print (Utility.Item.Slot.Bank("main",1))
    print (Utility.Item.Slot.Bank("bag",1))
    These generate incorrect function usage errors.
    a community-oriented site for all things Rift

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

    Default

    Quote Originally Posted by Aieny View Post
    Code:
    print (Utility.Item.Slot.Bank("main",1))
    print (Utility.Item.Slot.Bank("bag",1))
    These generate incorrect function usage errors.
    We'll fix those. Thanks for testing the new API

  12. #102
    Telaran
    Join Date
    Jun 2011
    Posts
    69

    Default RiftTextfield doesn't like braces

    Code:
    local txtFrame = UI.CreateFrame("RiftTextfield", "Texty", parentFrame)
    txtFrame:SetText("{A}")
    print(txtFrame:GetText())
    The above code snippet will print out "A}" rather than "{A}" as it should. Looks like the textfield is stripping the opening brace character.

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

    Default Event.Achievement.Update

    Event.Achievement.Update is being called during startup, which may or may not be a bug, but there is a crash bug that happens if you call Inspect.Achievement.Detail too soon.

    At the end of my core.lua file, I have
    Code:
    table.insert (Event.Achievement.Complete, {altAchievementComplete, "Altometer", "AchievementComplete"})
    table.insert (Event.Achievement.Update, {altAchievementUpdate, "Altometer", "AchievementUpdate"})
    , so the function is being inserted into the event table during the Addon startup.

    The function is
    Code:
    function altAchievementUpdate(params)
    	print ("Achievment Updated!")
    	for key,value in pairs(params) do
    		achDetail = Inspect.Achievement.Detail(key)
    		print ("------------------------------")
    		dump_table(achDetail)
    	end
    end
    After doing some serious work, I isolated the bug to the achDetail = Inspect.Achievement.Detail(key) line, which, when commented out, does not cause a crash. I printed out just the keys in the loop, and they all appear just fine, so there is something going on in the actual inspector that is causing the crash if it is called too early.

    An additional note, this only started happening after the most recent update to the PTS. Before that, it worked just fine. I also haven't had a chance to test if it is an error that happens all the time, but it definitely occurs during startup.
    Last edited by Aieny; 10-31-2011 at 07:45 PM.
    a community-oriented site for all things Rift

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

    Default

    Quote Originally Posted by Aieny View Post
    Event.Achievement.Update is being called during startup
    This isn't a bug - at the very beginning of startup, the client isn't aware of the player's achievement status. .Update will be called once the real data is downloaded and signals that, yeah, you should probably update.

    Quote Originally Posted by Aieny View Post
    but there is a crash bug that happens if you call Inspect.Achievement.Detail too soon.
    This is, though Thanks for the report!

  15. #105
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    If you have two frames attached to each with no space between them (i.e. frame A's right side is attached to frame B's left side), when you mouseover from one from to the other and back, sometimes you will get the MouseIn/MouseOut events out of order. i.e. You will get the MouseIn event of the frame you moving into before you get the MouseOut event from the frame you are exiting. Only seems to happen when moving from one specific frame to the other and not in the reverse order, so it may have something to do with the order in which the frames were created.

Closed Thread
Page 7 of 30 FirstFirst ... 3 4 5 6 7 8 9 10 11 17 ... 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