<snip> This is not correct. Valid party unit tokens are "party1" through "party4", and refer to the other players in your party. No new unit token is created for the "player" unit (yourself) when you are in a party.
When you are in a raid, though, there will be a duplicate unit token; valid raid unit tokens are "raid1" through "raid40", and one of those will be the same unit as "player"... though which one it is is not fixed, so if you ever needed to know which one, you'd have to loop through all of the "raidN" tokens and call UnitIsUnit("player", "raidN").
I sit corrected, and I should have known better, at that! A more correct way to identify yourself in a party is if you are NOT party1 through party4, then you must be the player. However, given what I've read of this thread, I do not see why or how distinguishing yourself would matter.
Actually, I think you're always the highest raid index, aren't you?
I'm not 100% certain about that. In a raid, the player could be in group 3, position 4 on someone else' screen, but on the player's screen, he/she would be in group 3 position 1, as the UI always shows you first in a group.
We used to have this issue handing out loot like Onyxia's Hide Bag. The loot master would do a /roll 40 and we would have to correct him if his screen indicated himself.
You are never partyN on in a party, you are always "player" ; partyN always refers to other players. Look at how the SecureGroupHeader code handles the showPlayer attribute in party.
For the raid question, if you are in a raid with 22 players, the tokens from "raid1" to "raid22" are valid and one of them yields true for UnitIsUnit(token, "player"). The raid subgroup in which each player is isn't related to the suffix number, e.g. raid7 isn't necessarily the 2nd member of the 2n group. You have to get the third return value of GetRaidRosterInfo(7) to know that. There is no predefined order inside each raid subgroups.
I can't really quote right now since I'm doing this from my phone but...
I need it to identify if it has a target, so that if it doesn't, then it will print "You have no target to --". I,m mainly doing this because if I did not the client would "pause" for a very breif moment whenever the player had no target and tried pressing one of the buttons.
The party identifying I need for, if the player is not in a party print "You are not in a party" because if there was nothing for it to do, if the player was not in a party, that would also cause a client 'pause'.
How I have it now doesn't cause lag and prints it doesn't have a target when it doesn't, and prints it can't do that action to the current target if the current target is an NPC or monster. But if you target a friend, player, and press any of the buttons besides leave party, it does nothing but do the 'lag' thing.
A more correct way to identify yourself in a party is if you are NOT party1 through party4, then you must be the player.
Also incorrect... even when you're not in a party, you are not "party1/2/3/4". Those unit tokens never refer to the same unit as "player". Also, you are always "player", so there's never any reason to check if you are "player" before running some code.
The correct way to determine whether you are in a party is to check if GetNumPartyMembers() > 0. If you need to also check that you're not in a raid group, you would want to additionally check that GetNumRaidMembers() == 0.
The line: UnitIsFriend("target") is what caused the errors.
UnitIsFriend requires two parameters, so it should be UnitIsFriend("target", "player") to check if the "target" unit is friendly toward the "player" unit. That's probably my mistake, but if you had a real error display (hint: the Blizzard one sucks), we'd have figured that out already. :p