Closed Thread
Page 6 of 30 FirstFirst ... 2 3 4 5 6 7 8 9 10 16 ... LastLast
Results 76 to 90 of 439
Like Tree4Likes

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

  1. #76
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default Weird X, Y parameters for MouseMove events with Mask frames

    I have a Mask frame (ScrollView) with another Frame (ScrollBar) parented to the ScrollView frame and located inside the ScrollView frame. I've attached handler functions for LeftDown, LeftUp, LeftUpoutside and MouseMove to the ScrollBar frame. When I left click and drag inside the ScrollBar frame, if I move the mouse out of the ScrollBar frame into the ScrollView, I get correct X and Y parameters in the MouseMove handler. However, if I move the mouse (while dragging) outside of the ScrollView frame, I get X and Y values of -1000000000 in the MouseMove handler.

    Is this intended behaviour?

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

    Default No LeftDown/MouseMove/etc. events for RiftWindow frames?

    Code:
    LRW_TestWindow = UI.CreateFrame("RiftWindow", "LRW_TestWindow", context)
    LRW_TestWindow:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
    function LRW_TestWindow.Event:LeftDown()
      print("LeftDown")
    end
    This prints nothing when I click in the RiftWindow frame.

    I've worked around the problem with a translucent frame on top of the RiftWindow frame which gets the events and moves the RiftWindow frame.
    Last edited by dOxxx; 10-15-2011 at 05:50 PM.

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

    Default

    SetLayer showing odd behaviour. I'm trying to create a tooltip and have it on top of bars however the order the layers are shown is not honoring what is set in code. see http://forums.riftgame.com/beta-addo...-setlayer.html

    I'm not entirely sure what the common factor is that determines how the ordering works. However there definitely seems to be a bug with the way a fixed layer frame is displayed when overlaid over another frame. SetLayer should be forcing things with a higher layer number to be in front of a frame with a lower number but this isn't always getting honored.

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

    Default

    Quote Originally Posted by dOxxx View Post
    Code:
    LRW_TestWindow = UI.CreateFrame("RiftWindow", "LRW_TestWindow", context)
    LRW_TestWindow:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
    function LRW_TestWindow.Event:LeftDown()
      print("LeftDown")
    end
    This prints nothing when I click in the RiftWindow frame.

    I've worked around the problem with a translucent frame on top of the RiftWindow frame which gets the events and moves the RiftWindow frame.
    The issue here is that RiftWindow has two children windows, the Border and Content, and the Border is set by default to trap mouse events. Either modify the events on :GetBorder() or do what you did

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    The issue here is that RiftWindow has two children windows, the Border and Content, and the Border is set by default to trap mouse events. Either modify the events on :GetBorder() or do what you did
    I can't seem to modify the events on the border:

    Code:
    local testWindowBorder = LRW_TestWindow:GetBorder()
    function testWindowBorder.Event:LeftDown()
        print("LeftDown")
    end
    Gives me an error "Unknown event LeftDown".

    EDIT: Seems to work on PTS though.
    Last edited by dOxxx; 10-16-2011 at 11:07 AM.

  6. #81
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default RiftWindow Content frame too close to the border

    This is a minor nitpick, but comparing the spacing of default UI windows such as the Quest Log and Character windows, it looks like the Content frame of the RiftWindow frame is a little too close to the border. Could probably stand to come in a few pixels. Otherwise, if you have a frame which fills the content frame, it overlaps the border art slightly at the top and comes too close at the other edges to look nice.

  7. #82
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    RiftWindow Border frame doesn't have GetParent function. Or perhaps the "self" implicit variable in an event handler attached to the Border frame is not correct.

    Code:
      local window = UI.CreateFrame("RiftWindow", "LW_Window", context)
      local border = window:GetBorder()
    
      function border.Event:LeftDown()
        self.leftDown = true
        local mouse = Inspect.Mouse()
        self.originalXDiff = mouse.x - self:GetLeft()
        self.originalYDiff = mouse.y - self:GetTop()
      end
      function border.Event:LeftUp()
        self.leftDown = false
      end
      function border.Event:LeftUpoutside()
        self.leftDown = false
      end
      function border.Event:MouseMove(x, y)
        if not self.leftDown then
          return
        end
        self:GetParent():SetPoint("TOPLEFT", UIParent, "TOPLEFT", x - self.originalXDiff, y - self.originalYDiff)
      end
    I worked around this by using 'window' as an upvalue in the MouseMove function instead of self:GetParent().
    Last edited by dOxxx; 10-16-2011 at 12:50 PM.

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

    Default

    Quote Originally Posted by dOxxx View Post
    I can't seem to modify the events on the border:

    Code:
    local testWindowBorder = LRW_TestWindow:GetBorder()
    function testWindowBorder.Event:LeftDown()
        print("LeftDown")
    end
    Gives me an error "Unknown event LeftDown".

    EDIT: Seems to work on PTS though.
    Ah, yeah, forgot about that - the Border and Context elements were kind of hacked in on the live server. The PTS has a major cleanup of that code. On live, the overlay is going to be the only way you can accomplish what you want.

  9. #84
    Shadowlander Rumil's Avatar
    Join Date
    Apr 2011
    Posts
    29

    Default Addon can "only" have 65K constants?

    I created parser to generate a LUA Table from the Rift Items.XML file. It looks like this:

    Code:
    RiftItems = {
    
    ["AAE6838D0201AEC0D6C9072C78"] = { 
    	["ItemKey"] = "AAE6838D0201AEC0D6C9072C78",
    	["English"] = "Venerable Hammer of the Warfront",
    	["Value"] = "937",
    	["Rarity"] = "Rare",
    	["Icon"] = "item_icons\1h_mace_079",
    	["IsAugmented"] = "False",
    	["Slot"] = "OneHand",
    	["WeaponType"] = "1h_mace",
    	["MinimumDamage"] = "18",
    	["MaximumDamage"] = "33",
    	["Speed"] = "2.700000",
    	["Range"] = "3.000000",
    	["Strength"] = "7",
    	["Dexterity"] = "5",
    	["Endurance"] = "4",
    	["RequiredLevel"] = "20",
    	["RunebreakSkillLevel"] = "1",},
    
    ["B6BBBD1F01D2D6F7D805663C"] = { 
    	["ItemKey"] = "B6BBBD1F01D2D6F7D805663C",
    	["English"] = "Templar's Bow of the Sinister",
    	["Value"] = "2350",
            ....

    As you can see it parses the different item types and generates the specific properties for armor, weapons, etc. The resulting file is 23K (nice slimdown compared to the 500K XML).

    When I tried to load this file into a Rift addon, I had a rather unexpected surprise:

    http://www.imgplace.com/viewimg593/7...addonerror.png

    ERROR: Object has more than 65536 constants

    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

    A zip with the Lua table is available here

    For more details on why I'm creating this table, see this thread
    Last edited by Rumil; 10-22-2011 at 04:40 PM. Reason: added Lua Table file link

  10. #85
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Quote Originally Posted by Rumil View Post
    ERROR: Object has more than 65536 constants
    Good old unsigned integer. Modern IT runs into the same old problems forever

    Cheers
    N.
    Last edited by Naifu; 10-23-2011 at 02:46 AM.

  11. #86
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Yeah that may be a limitation of the LUA implementation. You'll probably have to split the tables into subtables, grouping by the first N characters of the original string ID.
    Last edited by dOxxx; 10-23-2011 at 05:22 AM.

  12. #87
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default Unit.Available event on login is bending the truth

    When in a group and you logout and login again, the Unit.Available event fires with both player and group unit IDs. However, calling Inspect.Unit.Detail for the group IDs while in the event handler function returns a table with only name, player and role fields. None of the other fields like calling, etc. are set.

  13. #88
    Rift Disciple
    Join Date
    Apr 2011
    Posts
    120

    Default

    the following code doesn't work as you'd expect on first glance:
    Code:
    local SV = {}
    MyAddonName_SavedVariables = SV
    on the surface, the intent is fairly obvious: publish "MyAddonName_SavedVariables" to the global namespace so that the RIFT addon loader can read from and write to it, and also create a shorter local name for internal addon use.

    what's not obvious is, when the RIFT addon loader sees that you have a SavedVariables file, it reads that file into a new table, then changes the "MyAddonName_SavedVariables" binding to point to that new table. but your addon's local "SV" binding remains unchanged, pointing to the old table.

    there are two unfortunate outcomes here:

    1. unless you correct for this by either avoiding the use of a local alias, or making sure you update it, then saved variables won't work. updating the alias isn't hard (just a matter of putting "SV = MyAddonName_SavedVariables" somewhere where it will run after your saved variables are loaded), but you have to know to do it.

    2. when you test or release a new version of an addon, you can't add new entries to your SavedVariabiables table with default values and expect them to stick -- any default values your addon defines are used only if there is no save file at all. but if a save file exists, all your defaults are discarded and a new table is loaded containing only what was in the save file and nothing else.

    this may be another "not really a bug, but needs to be documented better" situation. I can guess why this is happening, and a "fix" may be more trouble than it's worth -- a shallow table copy isn't good enough, if you consider a case like this:
    Code:
    MyAddonName_SavedVariables = {
      UI = {
        MainWindow = {
          TitleBar = {
            DefaultColor = {
              r = 0,
              g = 0,
              b = 0.5,
              a = 0.5, -- this value is new in this version, and addon title bar won't appear without it
            }
          }
        }
      }
    }
    -ken
    Last edited by Snowreap; 10-24-2011 at 03:40 AM.
    Snowreap Yellowtail Preyz Taralin
    < The Purge > Guardian Seastone

  14. #89
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    RiftButton seems to include innate spacing around the actual drawn edge of the button. At the top and left this seems to be ~6. At the bottom, it seems to be ~12.

    It would be nice if the height (and width) of the frame were to better represent the actual drawn button. This makes automatic widget layout code easier to produce nice looking results.

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

    Default

    Quote Originally Posted by Snowreap View Post

    2. when you test or release a new version of an addon, you can't add new entries to your SavedVariabiables table with default values and expect them to stick -- any default values your addon defines are used only if there is no save file at all. but if a save file exists, all your defaults are discarded and a new table is loaded containing only what was in the save file and nothing else.
    I've noted this behaviour and my solution is as follows :

    Code:
    		
        BossReady.SetDefaults()
        if BossReady_Settings then
            for k,v in pairs(BossReady_Settings) do 
                BossReady.saved[k] = BossReady_Settings[k]
            end
        end
    First call copies BossReady.saved with default values ie: same as your SV. I prefix everything in my code with the addon name to give AddonName.value or AddonName.function. This ensures that the code is not leaking to global space.

    BossReady_Settings is the table loaded by RIFT addon loader. So the effect is to fill the table of used values ie: BossReady.saved with all the defaults including any new ones in this release. Then to overwrite the defaults with the values from the users saved variables if they exist. This means that you DO get all new defaults + old saved variables.

    Save routine remains unchanged as
    Code:
    BossReady_Settings = BossReady.saved
    Hope this helps. Not ideal I know but easily fixed with the above solution.
    Last edited by Levva; 10-23-2011 at 02:18 PM.

Closed Thread
Page 6 of 30 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