LoTROInterface - New Combat stats plugin

LoTROInterface (https://www.lotrointerface.com/forums/index.php)

- Chit Chat (https://www.lotrointerface.com/forums/forumdisplay.php?f=2)

- - New Combat stats plugin (https://www.lotrointerface.com/forums/showthread.php?t=3495)

New Combat stats plugin

Hi all Trilesch here only been playing lotro for a bout 3 months now and realy enjoying the the game.

So let me start with why I am doing with this plugin. With the news that combat analysis has been pulled due to an exploit I have decied to write a new plugin that will hopefully replace combat analysis.

This plugin will do most of the same stuff but with a lot less bloat that i found with combat analysis and was not realy needed. Think of recount for wow and you might get an idea of what i want to do.

Also i am going to try and make sure that it can not be exploited in any way.

So fingers crossed in the next few weeks i will have a alpha version up and running. for ppl to bug test and report back.

cheers all.

Before we start (yes, we, OP and I are working on this together) - is there anything we should know about copyright licenses? Right now, we're licensing the code under the LGPL, but if the plugin were to be published, do we require something else or nothing at all?

You can license it however you want. It's completely your choice.

Quote:

Originally Posted by Cairenn (Post 11344)

You can license it however you want. It's completely your choice.

Okay, thanks.

If you guys make an efficient and complete chat log parser (the main guts of the Combat Analysis plugin) it would be nice if you'd upload it as a class to be used in other plugins.

I forgot to say:

Also you can choose not to include a license in all, which means it would default to ARR.

Quote:

Originally Posted by Thurallor (Post 11346)

If you guys make an efficient and complete chat log parser (the main guts of the Combat Analysis plugin) it would be nice if you'd upload it as a class to be used in other plugins.

we will consider this.

also I have been speaking to my partner about other plugins that we can make and since lotro.data is no longer we have thought about making a plugin the pulls all the character info and saves it as a xml file to be uploaded to a website aswell and kinship info and such.

Quote:

Originally Posted by Trilesch (Post 11348)

also I have been speaking to my partner about other plugins that we can make and since lotro.data is no longer we have thought about making a plugin the pulls all the character info and saves it as a xml file to be uploaded to a website aswell and kinship info and such.

FWIW, I had already considered making AltInventory and AltViewer data available as a replacement for data.lotro but there are a number of significant issues. The biggest problem is the bug in GetEquipment that crashes the client which is also why AltViewer got sidelined and never updated - Narrel indicated that he will be working on some bug fixes, particularly focusing on crashes for a future update so there may be hope for a fix. The second biggest problem is preventing abuse of the upload mechanism (people purposely uploading bogus data to harass others) but I had already worked out a fairly good solution for that. The third issue is the lack of other data via the API such as kinship/quest/deed data - just providing basic character info like name, class and level isn't worth the effort. A fourth issue is the inability to derive an itemID programmatically which makes keeping track of item data more difficult and in some cases impossible atm - we've already requested that Narrel look into this but it may take quite a while before we see itemIDs in the API, if ever. The last major issue is that an external executable would have to be distributed to perform the actual uploads and that leads back to potential for malicious code.

Another concern is the lack of graphic resources (particularly item icons) - we used to be able to link to Turbine's site to display item icons and popup info but that source is no longer updated so any graphics would have to be hosted on the web server which would get into copyright issues (using a few icons could be considered fair use but hosting all item icons would definitely require written permission from Turbine which is unlikely to happen). Since Narrel indicated that some of the data.lotro functionality may get resurrected at some distant point in the future there may also be hope for a solution to this issue.

So, while it sounds like a nice idea, publishing character data isn't really feasible at this time.

I have also been working on a strictly local solution that would allow users to see their character info while off-line and supporting multiple accounts (Lua can't support characters from multiple accounts without using symbolic links and that messes up the per account "ALL" category)

Okay, so the plugin's coming along nicely.
Just wondering, so I don't have to dump the environment, what standard libraries are available to Lua in plugins?

So far, I've discovered that practically all of the default functions are available (Not sure about newproxy, I haven't tried making userdata yet.) and the math, string and coroutine libraries are enabled. Anything else I should be aware of

Quote:

As far as I know, packages, I/O and OS operations, and debug functions have been stripped. I don't think coroutines work either. So basically you have access to the basic (most of it), string, table and math libraries. Well, I've been checking that stuff a long time ago though. Anyway, you might want to check the global scope to see what's in there, I wrote a plugin that lets you do that within LotRO: http://www.lotrointerface.com/downlo...BeDragons.html

the plugin is comming along nicely so we have damage done damage taken healing done and healing taken in a nice little box we are now working on the dps side and diffrent attacks side of things.

Coroutines do work, sort of. The following code

Code:

local func = coroutine.create(function(num)

    num = coroutine.yield("a" .. tostring(num));

    num = coroutine.yield("b" .. tostring(num));

    num = coroutine.yield("c" .. tostring(num));

    return "d" .. tostring(num);

end);



result, value = coroutine.resume(func, 1); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 2); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 3); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 4); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 5); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

produces the following output:

result = true; value = a1
result = true; value = b2
result = true; value = c3
result = true; value = d4
result = false; value = cannot resume dead coroutine

However, I don't think you can call any API functions within a coroutine (e.g. Turbine.Shell.WriteLine doesn't work), so it seems pretty useless. You can access global variables, though. So if you had a big number crunching task, you could put it in a coroutine that is resumed in an Update() event handler, and spread out the computations over time until complete. I haven't tried this, but it seems like it would work. :D

Edit: I suppose you could pass a function and arguments to coroutine.yield(), and call the function in Update() when it's returned by coroutine.resume().

Quote:

Originally Posted by Equendil (Post 11361)

Quote:

Originally Posted by Thurallor (Post 11370)

Coroutines do work, sort of. The following code

Code:

local func = coroutine.create(function(num)

    num = coroutine.yield("a" .. tostring(num));

    num = coroutine.yield("b" .. tostring(num));

    num = coroutine.yield("c" .. tostring(num));

    return "d" .. tostring(num);

end);



result, value = coroutine.resume(func, 1); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 2); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 3); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 4); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

result, value = coroutine.resume(func, 5); Turbine.Shell.WriteLine("result = " .. tostring(result) .. "; value = " .. tostring(value));

produces the following output:

result = true; value = a1
result = true; value = b2
result = true; value = c3
result = true; value = d4
result = false; value = cannot resume dead coroutine

Thanks for the info, guys. I did an environment dump (which was weird, because I'm used to a slightly different environment setup where I don't have to use a pairs loop on _G) and I found that a few functions are disabled;

loadfile
io and os libraries

And a few others which I probably didn't notice. :P

In fact, I'm actually surprised at how little sandboxing of the environment that LoTRO has; I can escape environment sandboxes using the __gc metamethod (I'm used to that being disabled, in fact, I hardly use it at all!) and make custom userdatas using newproxy.

Just curious, what does making custom userdatas allow you to do?

Quote:

Originally Posted by Thurallor (Post 11372)

Just curious, what does making custom userdatas allow you to do?

Well, in layman's terms, it allows you to create an OOP system. In Lua, most types of data are forms of userdatas; that is, file handles and similar. You can check the type of something using the 'type' function; you'll find that tables are used more in LoTRO, which don't allow for very detailed OOP systems.

Here's more on the subject; http://lua-users.org/wiki/HiddenFeatures

What bloat was in CA? I think it was pretty efficient tbh (for the amount of data reported)

Quote:

Originally Posted by Evendale (Post 11379)

What bloat was in CA? I think it was pretty efficient tbh (for the amount of data reported)

Well, it wasn't as much bloated, but more just simply all over the place. I had a hard time finding out how some basic features like the Gui worked.
Right now, the new code is split into four scripts as of right now, most of which is just my way of setting up chat parsing and a custom Gui class for creating the interface.
Here's some snippets of code, the things which you can do with it:

Code:

main = Gui.new("Window")

main.Rect = {X=10, Y=10, Width=100, Height=100}

main.BackgroundTransparency = 0.5 -- sets the background transparency (not opacity, it uses the alpha channel)

main.BackgroundColor = Turbine.UI.Color(1, 0, 1) -- sets the colour. Not sure if it retains transparency though.



local a = Gui.new("Label")

a.Name = "TextLabel"

a.Parent = main



main.TextLabel.Text = "Hello World!"



main.Visible = true

Quote:

Originally Posted by Garan (Post 11349)

. Since Narrel indicated that some of the data.lotro functionality may get resurrected at some distant point in the future there may also be hope for a solution to this issue.

"Distant" is probably an understatement. I asked Sapience in one of the recent TTHTI runs if any thing was happening --- his response was nothing in the foreseeable future.