MacroQuest64

Funkyness in this.

${Me.GroupMember[4]} is returning my own name, 1-5 should only be groupmembers excluding myself no?

${Group[4].CleanName} is at the same time (while beeing in same zone) return the name of my F5 target. (and of course returns NULL if i zone)

So it looks to me theres an issue with it, can anyone else confirm this oddity?

${Me.GroupMember[4]} is returning my own name

n (in this case 4) will of course vary depending in which order you were invited to group.

Yea...it's goofy ...I think there might actually be 6 slots there instead of 5 ...with one being empty if you're the group leader. ...but I didn't get a chance to test it.

I keep trying to get with Amadeus in IRC to tell him that this fuction was already in MQ2 as a TLO.

The TLO spawn ${Group[n]} already exists. Give that a try instead.

${Group[2].Name} for example.

Since this is on the Group subject, I was reading through the changes figuring I missed something, saw:

Some tweaking to attempt to make ${xxx.Grouped} more consistant

But seems my problem lies within this line:

${If[${Me.Grouped},/g INC blah,]}

When I'm not grouped, I get the EQ error of "Talking to yourself again? Your not in a group" or something along those lines. But works correctly when grouped. Just kind of wondering on that. I know it started doing this since the August 19 2004 02:07:10 patch.

Thanx for any info. Don't mean to badger, if it's a simple fix, I'll simply wait.

I keep trying to get with Amadeus in IRC to tell him that this fuction was already in MQ2 as a TLO.

The TLO spawn ${Group[n]} already exists. Give that a try instead.

This is because the information is stored in two different places. It's stored at EQADDR_GROUPCOUNT (__GroupCount) as well as stored in the Charinfo struct. Therefore, it is valid for it to be called from the charinfo side of things (ie, ${Me.GroupMember[n]} as well as from the group offset itself ${Group[n]}

The reason that Me.GroupMember[] isn't working exactly right is because we don't have the struct tweaked perfectly yet and we're still learning exactly how it's used in the game. However, this is not the only case in MQ(and EQ) where the same information is obtainable in two different ways (ie, your character's name).

However ...next zip I'll probably remove it to avoid confusion. What I don't understand is why people were asking for this feature if it was already in the program.

But seems my problem lies within this line:

${If[${Me.Grouped},/g INC blah,]}

When I'm not grouped, I get the EQ error of "Talking to yourself again? Your not in a group" or something along those lines. But works correctly when grouped. Just kind of wondering on that. I know it started doing this since the August 19 2004 02:07:10 patch.

Thanx for any info. Don't mean to badger, if it's a simple fix, I'll simply wait.

I have another idea on how to fix this ....let me look into it.

Amadeus wrote: However ...next zip I'll probably remove it to avoid confusion. What I don't understand is why people were asking for this feature if it was already in the program.

They don't RTFM...

actually, getting your group members' names when they are not in zone could be useful, and you can't do that using the ${Group} TLO, since it is a spawn type. i actually needed this a while back but came up with a work-around for it by using UI windows. i used this to get the name of someone in group out of zone: of course, i was using this to consent everyone in group, which is now useless that they added a command that does that, but i'm sure there are other uses for it (group window HUDS?)

I knew there was a reason I did it ..that was it: the cross zone thing.

Let me figure out the struct and I'll try to put something in that fixes everything.

Is the new ${Me.Grouped} working when you're in a group of 2 people where you're not in the same zone?

It returns true when you are grouped across zones yes. Not tested with a 2man group though, but works well with full groups.

But still need a way to catch the groupmember names but if you are asking for the purpose of understanding the datastructure in memory, yes this works.

is the groupmember thing being worked on still? i got a nice HUD i'm working on now. just need a way to show group members names when they're not in zone.

It works sort of. But theres something wrong in the array, it cant be 1-5 only cause your own name is in there aswell, so additional research needed.

If you find the correct struct for it Amadeus then I suggest the array should be enumerated the same way as ${Group[n]} also,

if the names are in different order this creates some new...challenges.