I'm using the latest GIT always. I've tried the mem patch as well. So we have a common theme. I'm guessing it is a virtual memory problem. I know when WoW uses above 4g virt it will crash. So that is probably the story here. I might have too many mods going and Prat is the goose that pushes it over. Or Prat is doing something interesting on new window popups that pushes it over.
But since we use an unsupported format of playing the game I guess it is "nothing to see here move along, problem is our side". :-)
Merry Christmas all!
p.s. Debian Sid here although that shouldn't matter.
Getting crit error for a long time now in the following situations:
Have the bank open and dont close it but run away to auto close it.
With Prat-3.0 as only enabled addon i get a crit error and wow crashes.
Similar error i get together with skillet when i close that window via the x button of that window but only when prat is enabled.
Even disabled highcpu/mem modules but i still get that crit error.
Anyone else getting these errors?
Haven't on bank yet, but trainer by doing the same thing. And on new mail when BeanCounter is also enabled. But it looks like only 3 people have this problem. You, me, and a guy posting on Auctioneers site. I run under Linux so I'm wondering if that is a common bound.
Exactly. This is the place you communicate how a spec works in action. After the big "label" debate I noticed quite a few LDB plugins changing from text to label. So the authors read this and take action when they see a good idea / issue.
An example of current communication over an issue is Fortress grabbing HitCrits config and embedding it. The authors are talking it over and I'm sure a solution will be found. No spec needed. Just communication. No man is an island. And bug reports have a way of enforcing common practice.
Especially considering how tiny many data providers are, I think it's much more common that people will write/use the one that displays things how they like, instead of there being one uber-addon that makes every user happy in their own way.
So much /nod I have whiplash! Mod does what I want and how I like it. Now if a user submitted a patch to add a config option I'd probably include it. But I can't see myself going out of my way when things are working as intended.
LUA isn't hard to learn. Most DO's are so incredibly small and easy to read that it shouldn't be a huge issue. And about not caring about users. I released it. If it works for you I'm not stopping you from using it. I'm just not selling a product. I couldn't care if I'm the only one who uses it. I made it for me. Adding features I want to use is a lot easier then adding "person wants the mod to smile at them upon login". If you really care you would put your effort in (for free) as well :-)
Ok /rant over. Back to topic. I think it is a mistake to change the DO's fields in the display. But that is on the display's author. If they can deal with the 'love messages' from users that have an actual use case that conflicts then all is well.
The nice thing about LDB is that you have so many choices it really shouldn't be an issue for the user.
It is early. No coffee yet. I'm sure I'll reread it in 10 minutes and edit for clarity :p
I'd rather impliment ways to change the data in my DOs rather than have Displays edit them for me. Now, that being said some authors would rather that way being "change line 32 from xxx to xxx" but that's not necessarily a bad thing.
I'm lazy enough to be that author :) Positives are that more eyes see the code. Negative is if it is my code they see. But perhaps they learn from it.
Eh, that adds a layer of complexity that I don't think is really necessary. The LDB specification allows data objects to specify a "label", a "text", and an "icon" for display purposes. It seems pretty silly to say "okay, this data object specifies that its label is X, but we want to show Y here and Z there". I can't really think of too many reasons why you'd need to show a plugin on more than one display, and can't think of any reasons why you'd need to use a different label for the same plugin on each display. Thus, what you're suggesting is just extra bloat for no real purpose.
I don't even think it matters. Certainly doesn't to me. I was just trying to argue on the side of common practices. I was under the impression that changing the DO's fields from the display was considered wrong. If I remember correctly, that was brought up when talking about the minimap button with DO's. Displays shouldn't change DO fields seemed to be the consensus at that time.
Not really; all it's doing is changing the LDB object's label attribute. It's the same thing a plugin does when it sets its text or icon attributes; all display addons pick up on the changes. The only difference in this case is that instead of the plugin changing its own label, a display is doing it. Since most plugins are designed to be simple, and do not provide a full-fledged GUI through which something like configuring the label would be feasible, I think it's quite reasonable for a display addon to provide the interface for doing this.
Perhaps "internal label" for the display would be better? Have the display save a set label to its own config and use it if the label is edited.
It's easy to get the spec wrong or do things that later down the road will make things gnarly or limited. I do think that the current spec is very workable if not already good. There are minor things that can easily make it better without really affection almost anything that currently exists on the current spec.
It's kind of common practice to support OnTooltip schtuff for launchers too, so it's kind of just making it official to move that into the spec for example.
Well it is a matter of what is important. Can 1 DO that is very popular make the spec. Or 1 display that is popular? And then others conform to that. Anything that is broken can be fixed because almost everything is OS. Or at least source code is out there. It could be worse. We could be forced to use a certain tooltip library, a certain menu library, a certain config library.... etc. We have choices to shoot ourselves in the foot with instead of blowing our legs off.
And welcome back :-) You were much missed. Let me Recount the ways....
Just reread the beginning of the thread and it seems that the suggestion to merge specs isn't new and in fact there was openess to it. Any reason why it didn't happen?
You can blame either the displays or the DO's but this flexibility isn't bad. Fortress lets you config every bit of how the DO is displayed on a case by case basis.
And I'm with you on the merging of specs and making label a requirement. Text should be the optional one. Label should just be the mod name. Make it easier on users to find which Broker that icon is to.
But I think this is shooting for perfection rather then a real problem in foundation :-)
p.s. My mods do not adhere to the spec and I'm proud of it.
I do not know what you are doing but please delete the entire folder and go load up the latest Currency. You will find that it requires the following according to the includes:
All right, I added too many Ace3 things in a fit of pique when they started sucking in more of each other than I thought necessary. I seem to have forgotten to remove them from the pkgmeta file when I finally slimmed it down to the basics. I will remove AceConsole, AceEvent, AceHook and AceLocale from it.
Have you downloaded Broker_Currency v3.00.02.04 beta release off of Curse.com to see? Those are included under LibDataBroker. The pull went bad. Pulling BigWigs pulls *ALL* the libraries it has in with it. That is how Curse is doing it.
Which libraries are not needed? Keep in mind that anything removed can not leave it in an unusable state if only Broker Currency and say Fortress are loaded.
I know that part. But look at what is under LibDataBroker's folder.
EDIT: I pulled a 40 hour hackathon on my build system so I was very tired and didn't explain the situation well. I didn't mean "stop using this or that library". I meant, you aren't using them and they look to be included by accident.
0
ChocolateBar or Bazooka or Titan Panel or Fortress or any of the other high quality mods that display LDB.
Ask yourself what you get out of FuBar. Probably quick access to information? Well all those mods I listed give you that :-)
0
Not a replacement. Just an interface for Jostle.
0
I'm using the latest GIT always. I've tried the mem patch as well. So we have a common theme. I'm guessing it is a virtual memory problem. I know when WoW uses above 4g virt it will crash. So that is probably the story here. I might have too many mods going and Prat is the goose that pushes it over. Or Prat is doing something interesting on new window popups that pushes it over.
But since we use an unsupported format of playing the game I guess it is "nothing to see here move along, problem is our side". :-)
Merry Christmas all!
p.s. Debian Sid here although that shouldn't matter.
0
Haven't on bank yet, but trainer by doing the same thing. And on new mail when BeanCounter is also enabled. But it looks like only 3 people have this problem. You, me, and a guy posting on Auctioneers site. I run under Linux so I'm wondering if that is a common bound.
0
Exactly. This is the place you communicate how a spec works in action. After the big "label" debate I noticed quite a few LDB plugins changing from text to label. So the authors read this and take action when they see a good idea / issue.
An example of current communication over an issue is Fortress grabbing HitCrits config and embedding it. The authors are talking it over and I'm sure a solution will be found. No spec needed. Just communication. No man is an island. And bug reports have a way of enforcing common practice.
0
So much /nod I have whiplash! Mod does what I want and how I like it. Now if a user submitted a patch to add a config option I'd probably include it. But I can't see myself going out of my way when things are working as intended.
LUA isn't hard to learn. Most DO's are so incredibly small and easy to read that it shouldn't be a huge issue. And about not caring about users. I released it. If it works for you I'm not stopping you from using it. I'm just not selling a product. I couldn't care if I'm the only one who uses it. I made it for me. Adding features I want to use is a lot easier then adding "person wants the mod to smile at them upon login". If you really care you would put your effort in (for free) as well :-)
Ok /rant over. Back to topic. I think it is a mistake to change the DO's fields in the display. But that is on the display's author. If they can deal with the 'love messages' from users that have an actual use case that conflicts then all is well.
The nice thing about LDB is that you have so many choices it really shouldn't be an issue for the user.
It is early. No coffee yet. I'm sure I'll reread it in 10 minutes and edit for clarity :p
0
I'm lazy enough to be that author :) Positives are that more eyes see the code. Negative is if it is my code they see. But perhaps they learn from it.
0
I don't even think it matters. Certainly doesn't to me. I was just trying to argue on the side of common practices. I was under the impression that changing the DO's fields from the display was considered wrong. If I remember correctly, that was brought up when talking about the minimap button with DO's. Displays shouldn't change DO fields seemed to be the consensus at that time.
0
Perhaps "internal label" for the display would be better? Have the display save a set label to its own config and use it if the label is edited.
0
Well it is a matter of what is important. Can 1 DO that is very popular make the spec. Or 1 display that is popular? And then others conform to that. Anything that is broken can be fixed because almost everything is OS. Or at least source code is out there. It could be worse. We could be forced to use a certain tooltip library, a certain menu library, a certain config library.... etc. We have choices to shoot ourselves in the foot with instead of blowing our legs off.
And welcome back :-) You were much missed. Let me Recount the ways....
0
You can blame either the displays or the DO's but this flexibility isn't bad. Fortress lets you config every bit of how the DO is displayed on a case by case basis.
And I'm with you on the merging of specs and making label a requirement. Text should be the optional one. Label should just be the mod name. Make it easier on users to find which Broker that icon is to.
But I think this is shooting for perfection rather then a real problem in foundation :-)
p.s. My mods do not adhere to the spec and I'm proud of it.
0
Might be better for .pkgmeta.
Have you downloaded Broker_Currency v3.00.02.04 beta release off of Curse.com to see? Those are included under LibDataBroker. The pull went bad. Pulling BigWigs pulls *ALL* the libraries it has in with it. That is how Curse is doing it.
0
Updated to newest on Curse. I think Jostle was fixed.
0
I know that part. But look at what is under LibDataBroker's folder.
20 ./LibDataBroker-1.1/Libs/CallbackHandler-1.0
36 ./LibDataBroker-1.1/Libs/AceOO-2.0
32 ./LibDataBroker-1.1/Libs/AceModuleCore-2.0
24 ./LibDataBroker-1.1/Libs/AceHook-2.1
116 ./LibDataBroker-1.1/Libs/Dewdrop-2.0
20 ./LibDataBroker-1.1/Libs/LibSharedMedia-3.0
36 ./LibDataBroker-1.1/Libs/AceLibrary
8 ./LibDataBroker-1.1/Libs/LibBabble-Boss-3.0/LibStub
280 ./LibDataBroker-1.1/Libs/LibBabble-Boss-3.0
80 ./LibDataBroker-1.1/Libs/AceDB-2.0
16 ./LibDataBroker-1.1/Libs/LibDBIcon-1.0
28 ./LibDataBroker-1.1/Libs/AceLocale-2.2
140 ./LibDataBroker-1.1/Libs/Waterfall-1.0
12 ./LibDataBroker-1.1/Libs/LibStub
8 ./LibDataBroker-1.1/Libs/LibBabble-Zone-3.0/LibStub
120 ./LibDataBroker-1.1/Libs/LibBabble-Zone-3.0
60 ./LibDataBroker-1.1/Libs/CandyBar-2.0
12 ./LibDataBroker-1.1/Libs/PaintChips-2.0
56 ./LibDataBroker-1.1/Libs/AceAddon-2.0
100 ./LibDataBroker-1.1/Libs/AceConsole-2.0
36 ./LibDataBroker-1.1/Libs/LibSink-2.0
40 ./LibDataBroker-1.1/Libs/AceEvent-2.0
1268 ./LibDataBroker-1.1/Libs
And none of it is even in the embed.xml :-)
So it is all unused.
EDIT: I pulled a 40 hour hackathon on my build system so I was very tired and didn't explain the situation well. I didn't mean "stop using this or that library". I meant, you aren't using them and they look to be included by accident.
0
Love the mod! Nice work.