We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Results 1 to 10 of 10
  1. #1
    Join Date
    Jun 2011
    Posts
    0

    Unable to acces PluginData while Plugin is running.

    I have a file named test.plugindata saved at C:\Users\Username\Documents\Th e Lord of the Rings Online\PluginData\AccountName\ AllServers.

    The file contains the following data:
    Code:
    return "Hello"
    If I want to access the data, I can do this with:
    Code:
    import "Turbine";
    
    data = Turbine.PluginData.Load(Turbine.DataScope.Account, "test");
    Turbine.Shell.WriteLine(tostring(data));

    But what if I want to MANUALLY access data?
    Code:
    import "Turbine";
    import "Turbine.UI";
    import "Turbine.UI.Lotro";
    
    window = Turbine.UI.Window();
    window:SetSize(300, 300);
    window:SetPosition(300, 300)
    window:SetBackColor(Turbine.UI.Color(0,0,0));
    window:SetVisible(true);
    
    button = Turbine.UI.Lotro.Button();
    button:SetParent(window);
    button:SetSize(100, 20);
    button:SetPosition(100, 100);
    button:SetText("Load");
    button.MouseClick = function()
    	data = Turbine.PluginData.Load(Turbine.DataScope.Account, "test", dataLoadCompleteEventHandler);
    end
    
    dataLoadCompleteEventHandler = function()
    	Turbine.Shell.WriteLine(tostring(data));
    end


    Why does loading data work as expected when the plugin is loading (returns "Hello") but not when it's already running (returns "nil")? Am I missing something?
    Any help would be greatly appreciated!
    Last edited by Eruadarion; Oct 27 2017 at 12:17 PM.
    Eruadarion | Captain | on Gwaihir [EU-DE]
    www.avorthalier.eu

  2. #2
    Join Date
    Jun 2011
    Posts
    2,190
    From the Turbine API documentation:
    If the data is immediately available it will be returned. If the data is not immediately available this will return nil and the data loaded handler will be invoked later once the data is available.

    Therefore, in your case, data is being set to nil, and it tries to pass the results to dataLoadCompleteEventHandler() later. But your dataLoadCompleteEventHandler() function doesn't accept any arguments.

    Also, dataLoadCompleteEventHandler() needs to be defined before you call Turbine.PluginData.Load(), so I think you need to define dataLoadCompleteEventHandler() before button.MouseClick(). (It may work without doing that; I'm not exactly sure of the variable scoping rules in that scenario.)

  3. #3
    Join Date
    Jun 2011
    Posts
    0
    I changed:
    Code:
    dataLoadCompleteEventHandler = function(loadedData)
    	Turbine.Shell.WriteLine(tostring(loadedData));
    end

    Everything is working now! Didn't even need to define the dataLoadCompleteEventHandler() before button.MouseClick().

    Thank you Thurallor!
    Eruadarion | Captain | on Gwaihir [EU-DE]
    www.avorthalier.eu

  4. #4
    Join Date
    Mar 2007
    Posts
    0
    Quote Originally Posted by Eruadarion View Post
    I changed:
    Code:
    dataLoadCompleteEventHandler = function(loadedData)
        Turbine.Shell.WriteLine(tostring(loadedData));
    end

    Everything is working now! Didn't even need to define the dataLoadCompleteEventHandler() before button.MouseClick().

    Thank you Thurallor!
    Eruadarion, can't wait to see what you got cooked up.

  5. #5
    Join Date
    Mar 2007
    Posts
    1,590
    As Thuralor already answered, there is a callback used to implement a delay for saving and loading data to plugindata files when the plugin is running. This is covered in the Plugin State and Saved Data section of the Writing LoTRO Lua Plugins for Noobs thread:
    https://www.lotro.com/forums/showthr...96#post5784196.

    Turbine's declared original reason for this was to prevent bots but anyone who knows about modern bots knows they don't depend upon reading and writing files, they use screen scraping and keyboard/mouse simulators. Fortunately if you find the delay is seriously handicapping your plugin, there is a workaround although it can get pretty complicated if you want to save/load large amounts of data. One example of this is the Annotation loading for TerrainMap - as the user scrolls the map, the plugin loads and unloads a "helper" plugin which passes it the annotation information encoded in user defined commands. This is necessary as there are far too many annotations to efficiently load them all and keep them all in memory without impacting the game.

    The plugin I've been working on for authoring/reading user interactive stories takes this a step further. It uses a more generic system that allows it to save/load any specific value from a plugindata file as well as a callback routine for handling that data. The benefit is the data is read/written on the next screen refresh and the callback called immediately (about 1/60th to 1/100th of a second depending on your frame rate instead of 30 seconds) so if you are loading 100 settings it takes 1 second instead of 30, or you can load 3000 settings in the time the standard function takes for its delay so it is almost always faster (usually much, much faster). It will probably be improved in a future release to return an entire table structure or potentially the entire plugindata file in a single read - I have to further explore the limits of user defined commands. One caveat, it expects all data to be saved/loaded with the Vindar patch so as implemented it won't be compatible with the standard (flawed) Turbine plugindata files.

  6. #6
    Join Date
    Jun 2011
    Posts
    2,190
    Quote Originally Posted by Garan View Post
    The plugin I've been working on for authoring/reading user interactive stories takes this a step further. It uses a more generic system that allows it to save/load any specific value from a plugindata file as well as a callback routine for handling that data. The benefit is the data is read/written on the next screen refresh and the callback called immediately (about 1/60th to 1/100th of a second depending on your frame rate instead of 30 seconds) so if you are loading 100 settings it takes 1 second instead of 30, or you can load 3000 settings in the time the standard function takes for its delay so it is almost always faster (usually much, much faster). It will probably be improved in a future release to return an entire table structure or potentially the entire plugindata file in a single read - I have to further explore the limits of user defined commands. One caveat, it expects all data to be saved/loaded with the Vindar patch so as implemented it won't be compatible with the standard (flawed) Turbine plugindata files.
    This is hilarious. Unfortunately there aren't many people reading this who can fully appreciate it.

    In a nutshell, you are loading and unloading a plugin 30+ times per second, publishing the data to another plugin by creating a convoluted gibberish chat command. I guess you can create multiple chat commands to increase the bandwidth of this kludgy IPC mechanism. Or maybe you've got a separate chat command that acts as a semaphore, so you can rapidly redefine your data-carrying chat command(s) over and over again.

    I'd be interested to hear whatever performance numbers you get while investigating this.

    Why the urgency, though? Why do you need to access .plugindata files within a fraction of a second? Why can't you just load everything at startup, like a normal plugin?
    Last edited by Thurallor; Oct 27 2017 at 04:42 PM.

  7. #7
    Join Date
    Jun 2011
    Posts
    0
    Quote Originally Posted by Thurallor View Post
    In a nutshell, you are loading and unloading a plugin 30+ times per second, publishing the data to another plugin by creating a convoluted gibberish chat command. I guess you can create multiple chat commands to increase the bandwidth of this kludgy IPC mechanism. Or maybe you've got a separate chat command that acts as a semaphore, so you can rapidly redefine your data-carrying chat command(s) over and over again.
    I used this mechanism für a DPS meter. It reads out the combat log using the same parsing function as combat analysis and then saves it to a plugindata file. At the same time another Application written in Java reads that data and sends it via a Server-Client TCP connection to all connected raid members and saves the data in another plugindata file which can be then visualized by the plugin.

    This is what the result looks like: https://www.youtube.com/watch?v=eIGSHeJ9RdI
    Eruadarion | Captain | on Gwaihir [EU-DE]
    www.avorthalier.eu

  8. #8
    Join Date
    Jun 2011
    Posts
    0
    EDIT: Nvm ... figured it out... I'm an idiot
    Last edited by Eruadarion; Oct 27 2017 at 05:56 PM.
    Eruadarion | Captain | on Gwaihir [EU-DE]
    www.avorthalier.eu

  9. #9
    Join Date
    Mar 2007
    Posts
    1,590
    Quote Originally Posted by Thurallor View Post
    I'd be interested to hear whatever performance numbers you get while investigating this.

    Why the urgency, though? Why do you need to access .plugindata files within a fraction of a second? Why can't you just load everything at startup, like a normal plugin?
    I considered the semaphore route, especially when I started considering loading the entire plugindata file in one pass. I'm not sure the performance hit would be worth it, I prefer to break up the reading/writing over several frame refreshes so the user never notices any game hitching as a result.

    As to why read files on the fly? Because the user could have dozens or hundreds of stories to choose from and all I read at start up is the story name, author, description and ID so that I'm not trying to carry hundreds of story definitions in memory all the time. Once the user picks a story, the rest of the detail for that story is loaded dynamically, either with a small delay for editing (it's easier on the editor if the whole story is loaded at once) or chapter by chapter as the player interacts with the story - I only see a hitch if the descriptions are really long or there are a lot of defined objectives for that chapter. It's really a performance trade off, little or no hitching while keeping memory footprint as small as possible. Pretty much the same reason I don't load all of the annotations at startup for TerrainMap, the resource hit would be quite noticeable on some lower end systems. Yes, most of my plugins will still load and run fairly smoothly even on memory and CPU challenged Windows XP systems, although a few like the latest IRV are for my use only and would never run on my old XP test box anymore - the library of images and search indexes alone would send it into fits Besides, it's a fun challenge.

  10. #10
    Join Date
    Jun 2011
    Posts
    2,190
    Quote Originally Posted by Eruadarion View Post
    I used this mechanism für a DPS meter. It reads out the combat log using the same parsing function as combat analysis and then saves it to a plugindata file. At the same time another Application written in Java reads that data and sends it via a Server-Client TCP connection to all connected raid members and saves the data in another plugindata file which can be then visualized by the plugin.

    This is what the result looks like: https://www.youtube.com/watch?v=eIGSHeJ9RdI
    That's pretty cool. Unfortunately it requires everyone to trust an external executable, get Java working on their system, configure their firewall, remember to run the external application... Which necessarily limits its popularity. I've thought of using user chat channels to share data, but it would require the user to click a shortcut each time data needs to be transmitted.

    Quote Originally Posted by Eruadarion View Post
    Speaking of the Vindar patch...
    You can't consider yourself a serious plugin author until you've written your own version of Vindar's patch. See http://lotrointerface.com/forums/showthread.php?p=5424
    Last edited by Thurallor; Oct 27 2017 at 06:00 PM.

 

 

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