Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
The layout inheritance thing seems like a good idea, but how would the config UI work? what would determine whether a setting is inherited rather than overridden?
Add a new value with "From Parent: X" to each option and set it as default value?
I didn't even use the blank bar or anything to get it. Just placed the text above the frame.
Ah yes, the blank bar was actually just a work-around because I couldn't find the option to position the name outside the frame - but I just had to attach it to the frame instead of a specific bar.
I know it is possible, but changing the size of text X on "player" won't affect "target".
Wouldn't it be far more elegant if frames could override the layout, or if layouts would inherit their attributes until specifically overriden instead of copying them?
This would be according to the intended design, too - if I understand this paragraph correctly ;)
The layout system is handled entirely differently. In 3.0, every unit group had settings attached to it that defined its look and feel, this made configuring many frames at once hard without resorting to horrible hacks like the "All Frames" menu. In 4.0, every unit group has a "layout" attached to it. Let's say player has the layout "Normal" and target has the layout "Normal" as well. Making a change to the "Normal" layout will change both the player and the target, as well as any other frames that inherit from that layout. Individual units can override specific things in a layout, such as if you want the target to mirror horizontally (so bars fill up in reverse and such) or if you want it to be a different size. This is all possible and far easier to manage.
You can turn portraits on and off for individual layouts. If you want to turn portraits off for a particular frame just make a new layout for it with portraits turned off. Hint: Making a new layout with an existing layout selected copies the existing layout's settings to your new layout.
Isn't the change to the new layout design partly because modifying all frames at the same time needed workarounds up to now?
This would result in the same, or even a worse situation.
I was just playing around with PB4 myself and came here because I had the exact same problem:
I created a Blank Space to place the playername above HP and would like to mirror the orientation on player vs target. This was possible in PB3, and isn't in PB4 without copying the layout to a new one for each frame that differs from the main one.
I can understand the use of a different layout for something completely different (see ToT, Screenshot #1), but would like to avoid it for small changes.
Are there any plans to support customizations of layouts per-frame like that?
BTW:
I still have to find a way to use the Background module only for the lower part of the frame (e.g. disable it for the Blank Space) or somehow replicate it's look and disable it without using eePanels.. suggestions? Edit: Would probably be doable with borders.
Just let it read something like "Bloodsurge" or "Shield Slam", save it to .wav and copy that file to your Addons directory, the rest should be straight forward :)
Sorry, don't have the revision anymore, but we updated right before our raid last tuesday - April 1st, around 18:30. Should have been something like ~67000 iirc.
We killed Illidan today again with no problems, most of us (~15 ppl) using an up-to-date version of Omen. We had nearly the same lineup as last time though.
How could such a lockup happen anyway? I mean, even a while(true) would still be killable..?
Just to clear that up - I really appreciate your work Antiarc, and I was really looking forward to the new GUID system implemented in Omen2.
However, as many have stated, even Blizzard assumes we do have something like a working threat meter.
Try Bloodboil as a tank without it, or RoS - it's not like we can't play without it, it's just a major PITA.
I do understand that you want to use the opportunity to rewrite everything if the parser is broken. But I wasn't even questioning that. What I would love to see is a back-port for Threat-1.0 to parse the new combat log.
You already rewrote the parser, so maybe that would be a possibility to get a working non bleeding edge version while actual feature development could continue on Omen2?
On the lockup-thing:
22 of us had the most recent version of Omen2 with embedded libs, 22 of us had simultaneous lockups. Not lags, lockups. Like we could still talk on TS, but only some of us could even kill WoW without a hard reset.
This happened 5 times in a row in P1, until someone of those without lockups suggested disabling Omen - and the lockups stopped. That sure does seem like it was caused by Omen/Threat, right? =)
Sorry to disappoint you, but even in single target mode our entire guild hat lockups (not disconnects, lockups - some had to restart their computer, others could ctrl+alt+del) on Illidan yesterday.
Worked fine for those without Omen, so we turned it off.
Unfortunately it was already too late and we had to cancel our raid, but we won't be using it again until it is ready for actual use again.
I second that question - why not get Omen1 to work with 2.4 and then rewrite it? That way we would have at least had a working threat meter, even with less functionality.. now we have none at all and I'll have to convince my guild again that Omen is still superior to KTM =\
Is there an option to manually reassign items to other players?
So our disenchanter won't have to pay for all those unneeded epics while all players still get their dkp as normal? We currently use a dummy character to give disenchanted items to, any way to implement that?
I thought of adding a note to the disenchanted item and filter that when parsing the log, but as notes are stored per itemid I don't think that'll work :\
0
Add a new value with "From Parent: X" to each option and set it as default value?
Everything else would be override, of course.
0
Ah yes, the blank bar was actually just a work-around because I couldn't find the option to position the name outside the frame - but I just had to attach it to the frame instead of a specific bar.
Oh, my bad. Screenshots work again, guess the vhost didn't like me playing around so much.
The thing I don't like when I mirror the whole frame is that Bars fill up in the "wrong" direction. Take a look at Screenshot #2 to see what I mean.
#1 (PB3), #2 (PB4)
0
They do for me.
0
Wouldn't it be far more elegant if frames could override the layout, or if layouts would inherit their attributes until specifically overriden instead of copying them?
This would be according to the intended design, too - if I understand this paragraph correctly ;)
0
Isn't the change to the new layout design partly because modifying all frames at the same time needed workarounds up to now?
This would result in the same, or even a worse situation.
I was just playing around with PB4 myself and came here because I had the exact same problem:
I created a Blank Space to place the playername above HP and would like to mirror the orientation on player vs target. This was possible in PB3, and isn't in PB4 without copying the layout to a new one for each frame that differs from the main one.
I can understand the use of a different layout for something completely different (see ToT, Screenshot #1), but would like to avoid it for small changes.
Here's a screenshot (using PB3) for clarification. With PB4 it looks like this.
Are there any plans to support customizations of layouts per-frame like that?
BTW:
I still have to find a way to use the Background module only for the lower part of the frame (e.g. disable it for the Blank Space) or somehow replicate it's look and disable it without using eePanels.. suggestions? Edit: Would probably be doable with borders.
0
You can create those yourself by using a text-to-voice program.
Guess you could do it with Windows somehow, but my voice of choice is http://www.research.att.com/~ttsweb/tts/demo.php - Audrey.
Just let it read something like "Bloodsurge" or "Shield Slam", save it to .wav and copy that file to your Addons directory, the rest should be straight forward :)
0
We killed Illidan today again with no problems, most of us (~15 ppl) using an up-to-date version of Omen. We had nearly the same lineup as last time though.
How could such a lockup happen anyway? I mean, even a while(true) would still be killable..?
0
However, as many have stated, even Blizzard assumes we do have something like a working threat meter.
Try Bloodboil as a tank without it, or RoS - it's not like we can't play without it, it's just a major PITA.
I do understand that you want to use the opportunity to rewrite everything if the parser is broken. But I wasn't even questioning that. What I would love to see is a back-port for Threat-1.0 to parse the new combat log.
You already rewrote the parser, so maybe that would be a possibility to get a working non bleeding edge version while actual feature development could continue on Omen2?
On the lockup-thing:
22 of us had the most recent version of Omen2 with embedded libs, 22 of us had simultaneous lockups. Not lags, lockups. Like we could still talk on TS, but only some of us could even kill WoW without a hard reset.
This happened 5 times in a row in P1, until someone of those without lockups suggested disabling Omen - and the lockups stopped. That sure does seem like it was caused by Omen/Threat, right? =)
0
Worked fine for those without Omen, so we turned it off.
Unfortunately it was already too late and we had to cancel our raid, but we won't be using it again until it is ready for actual use again.
I second that question - why not get Omen1 to work with 2.4 and then rewrite it? That way we would have at least had a working threat meter, even with less functionality.. now we have none at all and I'll have to convince my guild again that Omen is still superior to KTM =\
0
We could of course change the owner of the item when we insert the raid, but that kind of defeats the purpose of automatic tracking addons.
In our case it would be something like 70% manual edits.
0
So our disenchanter won't have to pay for all those unneeded epics while all players still get their dkp as normal? We currently use a dummy character to give disenchanted items to, any way to implement that?
I thought of adding a note to the disenchanted item and filter that when parsing the log, but as notes are stored per itemid I don't think that'll work :\