We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Results 1 to 5 of 5

Thread: Known issues

  1. #1
    Join Date
    Mar 2007
    Posts
    1,419

    Known issues

    This is a list of the known issues which I have confirmed to be outstanding issues. Each entry contains the link to the original thread and where possible either a description of the issue or example of how to reproduce the issue. This list is not a complete list of known issues as I was not able to verify some of the reported issues due to time and/or environmental challenges such as needing multiple clients. I will continue to review those items that required additional testing and submit them in a future post. The descriptions are color coded with Red=Client Crash/Critical bug, Orange=Bug (non-crash) no workaround, Yellow=Bug with existing workaround, Cyan=Documentation/missing enumerations


    1 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...ity-and-zorder
    Description
    I'm seeing an issue where the EffectDisplay class seems to be ignoring both the SetOpacity() and SetZOrder() methods that it inherited from Control. For the ZOrder, I have a window with two controls
    control1:SetZOrder(100);
    control2:SetZOrder(50);
    and then define an EffectDisplay as a child of control2. Control2 will display behind control1, but control2.EffectDisplay will render on top of control1. I can, however, create a second window and have it display on top of the EffectDisplay, so EffectDisplay seems to be using the ZOrder of it's containing window.
    Confirmed. Turbine.UI.Lotro.EffectDisplay is not being clipped properly.

    Code to reproduce
    Code:
    testWindow=Turbine.UI.Lotro.Window()
    testWindow:SetVisible(true)
    testWindow:SetWantsKeyEvents(false)
    testWindow:SetSize(400,400)
    testWindow.Control1=Turbine.UI.Control()
    testWindow.Control1:SetParent(testWindow)
    testWindow.Control1:SetSize(100,100)
    testWindow.Control1:SetPosition(10,45)
    testWindow.Control1:SetZOrder(50)
    testWindow.Control1:SetBackColor(Turbine.UI.Color.Blue)
    testWindow.Control2=Turbine.UI.Control()
    testWindow.Control2:SetParent(testWindow)
    testWindow.Control2:SetSize(80,80)
    testWindow.Control2:SetPosition(20,55)
    testWindow.Control2:SetZOrder(100)
    testWindow.Control2:SetBackColor(Turbine.UI.Color.DarkGreen)
    testWindow.EffectDisplay=Turbine.UI.Lotro.EffectDisplay()
    testWindow.EffectDisplay:SetParent(testWindow.Control1)
    testWindow.EffectDisplay:SetBackColor(Turbine.UI.Color.Red)

    2 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...never-released
    Description
    If you have a plugin which loads a lot of different images, but never has many images loaded at any one time, over time the memory usage grows out of control when memory could be reclaimed because the images are no longer in use and have not been in use for a while.

    Code to reproduce - note, this code WILL eventually run the system out of memory and lead to a client crash
    Code:
    testWindow=Turbine.UI.Lotro.Window()
    testWindow:SetSize(1024,850)
    testWindow:SetVisible(true)
    testWindow:SetText("Stress test")
    testWindow:SetWantsUpdates(false)
    testID=0x41000000
    count=0
    testPanel=Turbine.UI.Control()
    testPanel:SetParent(testWindow)
    testPanel:SetSize(1024,768)
    testPanel:SetPosition(0,45)
    testStart=Turbine.UI.Lotro.Button()
    testStart:SetParent(testWindow)
    testStart:SetSize(100,20)
    testStart:SetPosition(80,815)
    testStart:SetText("Start")
    testStart.Click=function()
        Turbine.Shell.WriteLine("Stress Test Started")
        testID=0x40000000
        testWindow:SetWantsUpdates(true)
    end
    testWindow.Closed=function()
        testWindow:SetWantsUpdates(false)
        Turbine.Shell.WriteLine("Stress Test Ended")
    end
    testWindow.Update=function()
        -- uses an Update function to avoid "hanging" the client
        testWindow:SetWantsUpdates(false)
        if testID>0xFF000000 then
            Turbine.Shell.WriteLine("Stress Test Completed Successfully")
        else
            for k=1,0x100 do
                testID=testID+1
                local success,result=pcall(Turbine.UI.Control.SetBackground,testPanel,testID)
            end
            -- forced garbage collection just to verify that the caching isn't due to Lua
            collectgarbage("collect")
            testOutput:SetText(string.format("0x%x",testID))
            testWindow:SetWantsUpdates(true)
        end
    end
    testOutput=Turbine.UI.Label()
    testOutput:SetParent(testWindow)
    testOutput:SetSize(640,20)
    testOutput:SetPosition(192,815)

    3 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...ash-to-desktop
    Description
    If you accidentally pass a string to MenuItemList:Add() instead of a MenuItem the client does not trap the invalid parameter type, instead it will crash to desktop, usually not immediately but after several minutes, but always when attempting to unload plugins. I suspect this may be an issue with many of the LUA methods not validating the type of the parameter passed.

    Code to reproduce
    Code:
    menu=Turbine.UI.ContextMenu();
    menu:GetItems():Add("Menu Item");

    4 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...eration-values
    Description
    There are a couple enumerations which have missing values. Specifically, those values returned by Actor:GetRace() and Actor:GetClass() which are not in the Turbine.Gameplay.Race and Turbine.Gameplay.Class enumerations (I haven't yet played with the other enumerations).

    Ransroth is aware of and may be fixing


    5 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...-wrong-font-ID
    Description
    The following are undocumented fonts and what they appear to be (I'm not a font expert so they may not be the named fonts I listed, but they look pretty close)
    TimesRoman12= 0x42000021
    TimesRoman20= 0x4200000e
    TimesRoman22= 0x4200000f
    TimesRoman24= 0x42000010
    Calibri14= 0x4200002b
    Additionally the TrajanPro25 font is incorrect

    Ransroth is aware and may be fixing


    6 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...seWheel-events
    Description
    Windows do not appear to fire MouseWheel events properly. All of the other mouse events seem to fire correctly.

    Code to reproduce
    Code:
    window = Turbine.UI.Window();
    window:SetSize(60, 60);
    window:SetPosition(500, 50);
    window:SetBackColor(Turbine.UI.Color(1, 1, 1));
    window:SetMouseVisible(true);
    window:SetVisible(true);
    window.MouseWheel = function(sender, args)
      Turbine.Shell.WriteLine("Window Wheel");
    end
    window.MouseEnter = function(sender, args)
      Turbine.Shell.WriteLine("Window Enter");
    end
    window.MouseLeave = function(sender, args)
      Turbine.Shell.WriteLine("Window Leave");
    end
    window.MouseClick = function(sender, args)
      Turbine.Shell.WriteLine("Window Click");
    end
    label = Turbine.UI.Label();
    label:SetParent(window);
    label:SetSize(30, 30);
    label:SetPosition(15, 15);
    label:SetBackColor(Turbine.UI.Color(0, 0, 0));
    label:SetVisible(true);
    label.MouseWheel = function(sender, args)
      Turbine.Shell.WriteLine("Label Wheel");
    end
    label.MouseEnter = function(sender, args)
      Turbine.Shell.WriteLine("Label Enter");
    end
    label.MouseLeave = function(sender, args)
      Turbine.Shell.WriteLine("Label Leave");
    end
    label.MouseClick = function(sender, args)
      Turbine.Shell.WriteLine("Label Click");
    end
    This appears to still be an issue but may be working as intended and the documentation may be incorrect.


    7 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...client-crashes
    Description
    Setting the parent of an instance of ScrollableControl causes an instant client crash to desktop. To replicate, create a window with a single control, an instance of ScrollableControl and set it's parent - the plugin will immediately crash. I tried the same exact code, just changing ScrollableControl to Control and it loads fine, as did creating an instance of ScrollableControl so long as you don't set it's parent.

    Code to reproduce
    Code:
    -- include all the usual stuff before this
    TestWindow = class( Turbine.UI.Lotro.Window );
    function TestWindow:Constructor()
     Turbine.UI.Lotro.Window.Constructor( self );
     self:SetSize(400,400);
     self:SetPosition( 200,200);
     self.ScrollPanel=Turbine.UI.ScrollableControl()
     self.ScrollPanel:SetParent(self); -- <<-- causes instant client crash
    end
    -- Instantiate the actual windows, etc
    testWindow=TestWindow();
    testWindow:SetVisible(true);
    If this class isn't meant to be instantiated, it should be noted in the documentation (or hidden from the client and removed from the documentation)


    8 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...tly-documented
    Description
    All of the documentation for ControlList's Members and Methods seem to have been copied from MenuItemList since they all refer to adding, removing, or otherwise manipulating Menu items. The entry for ControlList itself correctly refers to it as containing Controls, it's all of it's child entries that refer to it as containing Menu items.

    Documentation is still incorrect


    9 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...tf8-characters
    Description
    There is a bug with using the shorcut constructor where if you supply the "data" string
    Turbine.UI.Lotro.Shortcut( Turbine.UI.Lotro.ShortcutType. Alias, '/say Wall of Annúminas')
    If you use a shorcut like that, where data is placed as constructor arg, it comes across in chat as mangled like... Wall of AnnA^minas
    However, if you use the SetData('Wall of Annúminas') method instead, it works. So there is a workaround.

    Code to reproduce
    Code:
     testWindow=Turbine.UI.Lotro.Window()
     testWindow:SetSize(200,200)
     testWindow:SetVisible(true)
     testWindow.qs=Turbine.UI.Lotro.Quickslot()
     testWindow.qs:SetParent(testWindow)
     testWindow.qs:SetPosition(10,45)
     sc=Turbine.UI.Lotro.Shortcut( Turbine.UI.Lotro.ShortcutType. Alias, '/say Wall of Annúminas')
     testWindow.qs:SetShortcut(sc)

    10 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...ry-enumeration
    Description
    The ItemCategory enumeration is missing quite a few enumerations.
    Max value in enumeration: 206
    Max known value: 235 (essences) so item categories 207 through 235 are missing from the enumeration
    Holes in existing enumeration (some may be deprecated but some are still in use): 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 90, 92, 93, 94, 95, 112, 165, 169, 186



    11 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...e-and-clipping
    Description
    SetOpacity is documented as a member of Control and all classes derived from Control but the text specifically says "Sets the opacity of the window. (Inherited from Control)". SetOpacity does not appear to affect controls, only windows (which matches the description). It seems as though it should be removed from the documentation for Control and all classes derived from Control.



    12 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...ssing-Tactical
    Description
    The EffectCategory enumeration seems to be missing the Tactical category.



    13 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...cks-are-merged
    Description
    Under certain circumstances, the ItemControl can cache an incorrect quantity. If you set the item to a stack from your vault or shared storage and then merge a stack from your backpack with a sufficient quantity to overflow the max stack size, the full stack will be a new item and the remainder will be put in the original stack. The QuantityChanged event will even correctly fire. However, the ItemControl will continue to display the stack as having the original quantity. A second issue arose from this since assigning the item to a new control will display the correct quantity but assigning the item to the original control will not refresh it, the control will continue to display the wrong quantity until you use SetItem to change the item the control contains and then set it back.

    See the original thread for detailed code and steps to replicate.


    14 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...44-SetRotation
    Description
    SetRotation has two bugs. First, the rotation value is lost whenever the window is not visible. Second, mouse events occur at the location of the unrotated window (try clicking the 'x' to close a window rotated on the Z-axis).
    [/COLOR]
    Note, SetRotation is an undocumented method so this is a low priority.


    15 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...ng-as-expected
    Description
    SizeChanged is listed as an event for all objects derived from Control but does not fire for Labels, Textboxes, Buttons and CheckBoxes. It does fire for Windows, Controls, ListBoxes, ScrollBars and TreeViews.

    To reproduce, simply create a Label, assign a handler for SizeChanged and change the size of the label.


    16 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...()-Not-working
    Description
    When calling GetName on a combat mount it doesn't seem to work.. It only returns the name of the last used standard mount.

    To reproduce, summon a normal mount, call localPlayer:GetMount():GetName () returns correct name. summon combat mount, localPlayer:GetMount():GetName () returns name of regular mount


    17 ______________________________ ______________________________ ______________________________ __________________________
    https://www.lotro.com/forums/showthr...Backpack-items
    Description
    I thought I was crazier than usual when I was trying to fix a control alignment problem in AltInventory when I realized it wasn't me this time (or at least not all me). It turns out, the ItemControl is rendering Backpack items with a three pixel border but if the same exact item is moved to the vault and then set to the ItemControl, it is rendered without the border, causing the item contol to look misaligned.

    Code and steps to replicate are in original thread
    Last edited by Garan; Nov 13 2014 at 11:14 PM.

  2. #2
    Ran into a fun little case that has the potential for a memory leak, I think.

    Code:
    control = Turbine.UI.Control();
    window = Turbine.UI.Window();
    control.window = window;
    control:SetParent(window);
    control = nil;
    window = nil;
    Despite there being no way to get to the window, it will not be freed by garbage collection.

  3. #3
    Quote Originally Posted by Thurallor View Post
    Don't you need to call window:Close() first?
    Nope. There's no way to get a reference to the window at the end of that code (that I can see), so, of course, you can't call any member functions of the window. Also, since there's no way to get a reference to the window, standard garbage collection guarantees mean that it should be garbage collected at that point.

    Also, if you remove either of the two following lines:
    Code:
    control.window = window;
    control:SetParent(window);
    then the window will get garbage collected. It's a bit odd.

  4. #4
    Quote Originally Posted by Thurallor View Post
    What I really meant was "Is that how it works?", not "Is that how it should work?". Just speculating that Window.Close() may remove an internal reference to the Window object, allowing it to be garbage-collected when all of the Lua references expire. Or maybe Window.Close() frees some system resources that are not accessible to the Lua garbage collector. In any case, there must be a reason the Close() function is needed when we already have SetVisible(false).
    Just to test, I threw in a window:Close()
    Code:
    control = Turbine.UI.Control();
    window = Turbine.UI.Window();
    control.window = window;
    control:SetParent(window);
    window:Close();
    control = nil;
    window = nil;
    window is still not garbage collected.

    Also, :Close() better not be cleaning up too many things, because you can do a :SetVisible(true) after a :Close() to bring back the window.

    Quote Originally Posted by Thurallor View Post
    Seems to be a case of cyclic referencing leading to an "island". But Lua uses the mark-and-sweep algorithm for garbage collection, which should be immune to this problem.
    But clearly it's not immune. And that's probably a bug.

    Edit: If you want my guess, all :Close() does is generate the Closing and Closed events before setting a window's visibility to false. It's probably the programatic equivalent of hitting the 'x' button in the upper right corner of a window. (Assuming the window had an 'x' button in the upper right corner, which the basic one doesn't.)
    Last edited by moebius92; Feb 05 2015 at 05:49 PM.

  5. #5
    Join Date
    Jun 2011
    Posts
    1,196
    Moebius92, please check your private messages.

    Another minor bug relating to Warden skills:
    The Turbine.Gameplay.ActiveSkill.I sUsable() function should return true for the builders/masteries when the warden is "Preparing for Battle" (having used the Battle Preparation skill).
    Thurallor, Warden of Landroval
    Author of plugins: SequenceBars, Reminders, others

 

 

Posting Permissions

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

This form's session has expired. You need to reload the page.

Reload