Those look to be the default XUB settings now (I'm on 1.9 beta 18), but they give me an error on the party frames:

"Unable to find PitBull4_Groups_partyUnitButton1"

From a post elsewhere, it looks as though Pitbull 4 group frames are named "PitBull4_Groups_xxxxxUnitButton1" (etc.), where xxxxx is the group name. The default Pitbull4 party group is "Party" (capital P), so no match. Similar problem, presumably, on the "Partypet" group.

It's possible to fix the problem quite simply inside Pitbull (by creating a new group called "party" - and I can confirm that that works), but the XUB and Pitbull4 defaults should match.

Just downloaded it, and will give it whirl.

Any bug reports/comments, I'll post in the comments section for that build (http://www.wowinterface.com/download....html#comments).

First off, thank you for your help, appreciate it.

Second, while I don't KNOW if I was moved around, I do remember, when first joining the raid, I wasn't in the last position, but at the time the error happened, I was. Coincidence or the cause, your guess is as good as mine. /shrug

Third, I'll try out the new code (haven't checked yet, but based on your comments I'm assuming you've uploaded it already?) and see how it affects the problem, and report back.

Fourth, enjoy your vacation!

EDIT: I just checked, and didn't see a new version in the "Optional Files" section (http://www.wowinterface.com/download....html#optional). I guess you didn't get a chance to upload it before going on vacation? I also checked the old Google dev areas too (http://groups.google.com/group/develop_xub/files)(http://code.google.com/p/extremeunit...downloads/list).

UPDATE! I was in a Naxx raid, nobody zoning in/out, but the raid leader started rearanging people already in the raid into different groups! As soon as this happened, the same error came up again. So it has to do with moving people around.

UPDATE 2: Same raid, someone left, same error happened. No position switching.

I was inside the instance already with many members, and other members were zoning in. I can't say if members were being moved around, as I was not the leader, and things were kind of hectic (as usual when a PUG is getting its act together).

I can definately say though that people were zoning in at the time.

Yes, this is with the latest downloadable versio, RC8.

Sorry to add to the woes. For what its worth, XUB doesn't seem to be in a healthy condition when used in a raid.

Got a "We are here because aUnit is NOK or aFrameNo~=1" message.

I have a screenpic to show the problem, but basically it was the following info...

We are here because aUnit is NOK or aFrameNo~=1.
XUB-Error: aUnit is NOK or aFrameNo~=1.
aFrame: (RaidPullout5Button4)
aUnit: (raid22)
aDestinationUnit: (raid22)
aSpellName: (Dispell Magic)
aRank: ()
aThreshold: (0)
aExtra: (Magic)
aToolTip: (
Starts blinking when unit has these debuffs: Magic)
aExcludeUnits: ()
aWidth: (25)

This happened while in a 25 man Vault run, and I was inside the zone and people were zoning in.

I actually had two disconnects while inside Vault too so whatever XUB is freaking out about is bad enough to potentially destabilize the client.

Using ag_UnitFrames as my UI (ag_UnitFrames-r685.zip).

I was in the last raid position in the last group, and the error happened with my character. This may be significant, as in the past, I've been in the same instance and have not had disconnects and/or XUB errors. Maybe its an array index out of bounds problem?

Here are the screenpics showing my UI at the time of the error...

http://img2.imageshack.us/img2/7712/...0809201653.jpg
http://img2.imageshack.us/img2/9869/...0809201700.jpg
http://img2.imageshack.us/img2/6076/...0809201706.jpg

FYI, please note in the screenpics the the bars to the right of each character is higher up than it should be. Whenever someone enters/leaves the raid, this happens, and I have to type a "xub /p" to get them to line up to the right of the right character name. Not sure if this is related to the problem or a completely different problem, but as I said, a "xub /p" fixes that problem right away.

Apologies, didn't notice the "/XUB p <some_not_existing_profile>" statement earlier in your same post.

As I wrote, the profile 'c' does not need to exist.

Would I have to actually create the 'c' profile to get this trick to work? Will XUB work if I supply a profile name that doesn't exist?

Instead of /console reloadui you could use this (because it's faster):
/XUB p <some_not_existing_profile>
/XUB p <your normal profile>

Lets say your normal profile is called 'normal'.
Then in thsi example you could write:
/XUB p c
/XUB p normal

I know this is only a workaround, but I have no time for XUB at the moment.

cu
tay