So lets kick this off with a discussion of one thing that sucks in 3.1:
It is no longer compressed. For AutoBar this bloats the data by 500k in the 4 major files that are included vs the exact sets needed. Is there a reason its not compressed? Do we want to start compressing again? human readable is nice for debugging of course.
I am open to suggestions:
One thing I want to do is roll a custom file that AutoBar needs with the exact sets required. Especially under current conditions this saves a lot of memory.
Another idea I had is to pre (post?) process PT3.1 and just save off the results and refresh that when the minor rev changes and then not load the lib when not necessary. So basically for a login session, set access is tracked and the result sets saved off. On next login these sets are available already or if an unknown set is queried PT3.1 loads and gets the new set. Not sure how you would dump stuff that stops being used. Maybe track logins with some ascending number & use cache algorithms to dump apparently unused stuff.
This works great for static PT3.1 use like in AutoBar. Browsing mods would have to skip the mechanism and use the current API. I guess that implies doing this as an API layer on top of PT3.1
I'll repost this in this thread (btw I locked the old one for you Toadkiller)... PeriodicTable-3.0 included an ItemSearch function for searching data; this was useful, for example, for finding out which boss dropped a specific item. Here's an adapted version for 3.1 that works from within an addon (I'm using it in my branch version of TooltipExchange):
local periodic = LibStub:GetLibrary("LibPeriodicTable-3.1")
local function periodic_ItemSearch(item)
assert(type(item) == "number" or type(item) == "string", "Invalid arg1: item must be a number or item link")
item = tonumber(item) or tonumber(item:match("item:(%d+)"))
if item == 0 then
self:error("Invalid arg1: invalid item.")
end
local matches = {}
for k,v in pairs(periodic.sets) do
local _, set = periodic:ItemInSet(item, k)
if set then
local have
for _,v in ipairs(matches) do
if v == set then
have = true
end
end
if not have then
table.insert(matches, set)
end
end
end
if #matches > 0 then
return matches
end
end
["Reputation.Reward.Shattered Sun Offensive"]="34675:8,34676:8,34677:8,34680:8,34679:8,34678:8,35753:8,35754:8,35752:8,35755:8,35270:8,35265:8,35245:8,35242:8,35258:8,35267:8,35257:8,35247:8,35221:8,29193:7,34674:7,34666:7,34670:7,34673:7,34671:7,34672:7,34665:7,34667:7,35708:7,35698:7,35699:7,35696:7,35695:7,35697:7,35502:7,35505:7,35271:7,35766:7,35241:7,35259:7,35767:7,35768:7,35769:7,35252:7,34872:6,35500:6,35254:6,35269:6,35268:6,35253:6,35240:6,35239:6,35266:6,35251:6,35238:6,34780:5,35261:5,35250:5,35249:5,35264:5,35263:5,35260:5,35248:5,35262:5,35256:5,35246:5,35255:5,35245:5",
Full listing of rewards for Shattered Sun Offensive Rep.
I noticed that trash mob drops aren't in LibPeriodicTable-3.1-InstanceLoot.lua, could they be added simply by doing ["InstanceLoot.Hyjal Summit.Trash Mobs"] for instance?
I noticed that trash mob drops aren't in LibPeriodicTable-3.1-InstanceLoot.lua, could they be added simply by doing ["InstanceLoot.Hyjal Summit.Trash Mobs"] for instance?
I think that the problem here is generating the data. Get me a good wowhead filter and I'll add them :-)
I don't know that you can filter specifically for trash drops on wowhead. You'd have to start with a list of everything that dropped in the instance, and then remove all items that appeared on a boss's drop list.
["Reputation.Rings.The Violet Eye"]="29276,29277,29278,29279,29280,29281,29282,29283,29284,29285,29286,29287,29288,29289,29290,29291",
["Reputation.Rings.The Scale of the Sands"]="29294,29295,29296,29297,29298,29299,29300,29301,29302,29303,29304,29305,29306,29307,29308,29309",
These are the rings ya get after certain reputation milestones with Karazhan and Hyjal, would these work in the reputation file? I'm not really sure on where to put them etc.. :)
All right, apparently compression was dumped in favour of performance.
Quote from Toadkiller »
...One thing I want to do is roll a custom file that AutoBar needs with the exact sets required...
All right so I did this as a kind of proof of concept. For AutoBar alone this saves quite a chunk of memory (300-500k iirc). However the current aproach is flawed in that for some of the set files it only has a few of the sets and they get overriden by any mod that includes that set file. Additionally the current aproach is no good for being extended to a second mod. One way to fix it is to version individual sets on load, or have a version table that can get chucked after loading is complete.
So to go further requires changes to PT3.1. Do we want to do that or not?
Personally I'd prefer that PT3.1 remain a generalized library, without any addon-specific stuff in it at all. Meaning your special AutoBar set would be moved to its own LibPeriodicTable-3.1-AutoBar addon. :P
Personally I'd prefer that PT3.1 remain a generalized library, without any addon-specific stuff in it at all. Meaning your special AutoBar set would be moved to its own LibPeriodicTable-3.1-AutoBar addon. :P
I agree. However that requires adding mixin granularity beyond the current misc, gear, consumable, etc. file level. I am happy to write that code, and it would allow more mods than just 1 to cut down on unwanted sets, as well as making blending of such custom sets flawless.
The implementation is simple: during startup, each set added is recorded in a table with the version. Additional sets then replace them if newer or not if older. The table is dumped when no longer needed so memory use is identical except that you can get away with loading way fewer sets. All mods benefit from this except for PT3Browser which loads absolutely everything.
Seems like a lot of work to save static memory. Is it worth it?
AutoBar went from about 600k to 2.2 mb. This is 500k of that.
For people with lots of memory, indeed it makes no difference. For people without a ton of memory, or smaller cpu cache sizes etc. it makes a difference. For authors having to listen to bitching about memory size, it makes a difference. For a lot of Ace people, already obsessed with disembedding, it makes a huge difference.
For me, I was told originally when I converted to PT2.x that its the greatest thing since sliced bread, super compact and fast. Its not compact any more, and toast with Nutella is greater.
Yeah i bet the size of the CPU cache and the 500kb of memory being used by AutoBar will bring your system down! </sarcasm>
Seriously, RAM is cheap. If someone lacks it, tell them to buy some. Any system running WoW should really _NOT_ care about 500kb of memory anymore, or just stop using addons. And if you as a author listen to people bitching, its your own fault. Just blend that into the white noise.
I absolutely agree that AutoBar should have never been allowed to add its own part into PT3.1 and i ask you to move it to an external source.
We cannot have authors start adding their own stuff to generic libraries, or we end up with the mess Ace2 and all its sub-libs had become (hello to you Toadkiller, i wish Nargs had noticed the changes to Waterfall earlier and reverted it).
Generic Libraries are what their name says, generic. Providing features that alot of addons use, and very specific code tailored for ONE addon has no place there.
I absolutely agree that AutoBar should have never been allowed to add its own part into PT3.1 and i ask you to move it to an external source.
If you were to read this thread you would also know it is a proof of concept and not a permanent thing.
All right, since everyone is in agreement on this now and nobody objected or made any other alternate suggestions, I will make the necessary changes to PT3.1 so I can move this file out of PT3.1
This is not a super high priority for me so don't expect it tomorrow. It will get done tho.
Quote from Nevcairiel »
...(hello to you Toadkiller, i wish Nargs had noticed the changes to Waterfall earlier and reverted it)...
I cleared the addition of dragLink and other changes to waterfall with nargs, I also posted changes made in the WaterFall forum and had some PM conversations with him. I did not just go in and modify his code. If he wanted waterfall left alone that would have been simple to do with a post on the AutoBar forum or WaterFall forum or a PM on this site. None of that happened so I am not seeing the point you are trying to make here.
Quote from Nevcairiel »
Generic Libraries are what their name says, generic. Providing features that alot of addons use, and very specific code tailored for ONE addon has no place there.
PT3.1 is not such a thing. There are a handfull of specific mods which drive its use. Go look at the commits to it and this becomes quite clear. AutoBar is one such mod.
Quote from Nevcairiel »
Yeah i bet the size of the CPU cache and the 500kb of memory being used by AutoBar will bring your system down! </sarcasm>
Denying that some users have crappy computers or telling them to just go buy a new computer is fine. You are welcome to take that attitude. I choose not to.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I take no responsibility for this lib as I would like to completely blame Nymbia who is the actual author.
It is no longer compressed. For AutoBar this bloats the data by 500k in the 4 major files that are included vs the exact sets needed. Is there a reason its not compressed? Do we want to start compressing again? human readable is nice for debugging of course.
I am open to suggestions:
One thing I want to do is roll a custom file that AutoBar needs with the exact sets required. Especially under current conditions this saves a lot of memory.
Another idea I had is to pre (post?) process PT3.1 and just save off the results and refresh that when the minor rev changes and then not load the lib when not necessary. So basically for a login session, set access is tracked and the result sets saved off. On next login these sets are available already or if an unknown set is queried PT3.1 loads and gets the new set. Not sure how you would dump stuff that stops being used. Maybe track logins with some ascending number & use cache algorithms to dump apparently unused stuff.
This works great for static PT3.1 use like in AutoBar. Browsing mods would have to skip the mechanism and use the current API. I guess that implies doing this as an API layer on top of PT3.1
local periodic = LibStub:GetLibrary("LibPeriodicTable-3.1") local function periodic_ItemSearch(item) assert(type(item) == "number" or type(item) == "string", "Invalid arg1: item must be a number or item link") item = tonumber(item) or tonumber(item:match("item:(%d+)")) if item == 0 then self:error("Invalid arg1: invalid item.") end local matches = {} for k,v in pairs(periodic.sets) do local _, set = periodic:ItemInSet(item, k) if set then local have for _,v in ipairs(matches) do if v == set then have = true end end if not have then table.insert(matches, set) end end end if #matches > 0 then return matches end endFull listing of rewards for Shattered Sun Offensive Rep.
LibPeriodicTable-3.1\LibPeriodicTable-3.1-Reputation\LibPeriodicTable-3.1-Reputation.lua
I think that the problem here is generating the data. Get me a good wowhead filter and I'll add them :-)
Hehe, I was gonna use the AtlasLoot data - bad idea? :o
These are the rings ya get after certain reputation milestones with Karazhan and Hyjal, would these work in the reputation file? I'm not really sure on where to put them etc.. :)
missing from curatives
All right, apparently compression was dumped in favour of performance.
All right so I did this as a kind of proof of concept. For AutoBar alone this saves quite a chunk of memory (300-500k iirc). However the current aproach is flawed in that for some of the set files it only has a few of the sets and they get overriden by any mod that includes that set file. Additionally the current aproach is no good for being extended to a second mod. One way to fix it is to version individual sets on load, or have a version table that can get chucked after loading is complete.
So to go further requires changes to PT3.1. Do we want to do that or not?
I agree. However that requires adding mixin granularity beyond the current misc, gear, consumable, etc. file level. I am happy to write that code, and it would allow more mods than just 1 to cut down on unwanted sets, as well as making blending of such custom sets flawless.
The implementation is simple: during startup, each set added is recorded in a table with the version. Additional sets then replace them if newer or not if older. The table is dumped when no longer needed so memory use is identical except that you can get away with loading way fewer sets. All mods benefit from this except for PT3Browser which loads absolutely everything.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatornot per set, only per file...
AutoBar went from about 600k to 2.2 mb. This is 500k of that.
For people with lots of memory, indeed it makes no difference. For people without a ton of memory, or smaller cpu cache sizes etc. it makes a difference. For authors having to listen to bitching about memory size, it makes a difference. For a lot of Ace people, already obsessed with disembedding, it makes a huge difference.
For me, I was told originally when I converted to PT2.x that its the greatest thing since sliced bread, super compact and fast. Its not compact any more, and toast with Nutella is greater.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorSeriously, RAM is cheap. If someone lacks it, tell them to buy some. Any system running WoW should really _NOT_ care about 500kb of memory anymore, or just stop using addons. And if you as a author listen to people bitching, its your own fault. Just blend that into the white noise.
I absolutely agree that AutoBar should have never been allowed to add its own part into PT3.1 and i ask you to move it to an external source.
We cannot have authors start adding their own stuff to generic libraries, or we end up with the mess Ace2 and all its sub-libs had become (hello to you Toadkiller, i wish Nargs had noticed the changes to Waterfall earlier and reverted it).
Generic Libraries are what their name says, generic. Providing features that alot of addons use, and very specific code tailored for ONE addon has no place there.
If you were to read this thread you would also know it is a proof of concept and not a permanent thing.
All right, since everyone is in agreement on this now and nobody objected or made any other alternate suggestions, I will make the necessary changes to PT3.1 so I can move this file out of PT3.1
This is not a super high priority for me so don't expect it tomorrow. It will get done tho.
I cleared the addition of dragLink and other changes to waterfall with nargs, I also posted changes made in the WaterFall forum and had some PM conversations with him. I did not just go in and modify his code. If he wanted waterfall left alone that would have been simple to do with a post on the AutoBar forum or WaterFall forum or a PM on this site. None of that happened so I am not seeing the point you are trying to make here.
PT3.1 is not such a thing. There are a handfull of specific mods which drive its use. Go look at the commits to it and this becomes quite clear. AutoBar is one such mod.
Denying that some users have crappy computers or telling them to just go buy a new computer is fine. You are welcome to take that attitude. I choose not to.