Ally Party

Averi

This is a small detail, but I was wondering if we could have an ALLY PARTY or something that allows us to automatically ally all the people in one's party?  

That would just be a large convenience instead of like checking the party and my allies list repeatedly to make sure I got everyone on it. 

Eld

Would be fine with this, I think. If you don't have enough slots left, just ally no one? And only ally people you can see on PARTY MEMBERS?

Tael

It's not a bad idea, though it would be fairly easy to script yourself.

Achilles

except for those gem people (or chameleoned) ones who don't show up on pwho.

Eld

That's why I said only ally those you can see on PARTY MEMBERS. Hadn't considered chameleon; not sure what to do about that.

Trevize

Averi said:

This is a small detail, but I was wondering if we could have an ALLY PARTY or something that allows us to automatically ally all the people in one's party?  

That would just be a large convenience instead of like checking the party and my allies list repeatedly to make sure I got everyone on it. 

Just attempt to ally everyone. It fails without any fanfare if you already have them allied.

Valden

It's not a hard script to write, just gag PARTY MEMBERS read in the line with the names and split it or use this

local names = string.gmatch(n, "[A-Za-z]+")

for name in names do send("ally " .. name, false) end

I would share my script but it ties into a couple of other systems I'm running and hacking it out would be messy

Awan

Just coding it works if you don't mind it missing gemmed people and chameleoned people, and allying random folks (who may be enemies or random newbies or who knows what) that your party members were chameleoning.

That seems like a pretty compelling reason for why a command in the game to do it would be a better idea if it wouldn't be much trouble for the coders. Having the ability to ally your whole party without being misled by those silly factors seems pretty reasonable and commonsensical.

Might as well have an "enemy party" command too, for the monks. :P

Trevize

I don't like it for the same reason that you guys seem to want it. To get around chameleon/gems.

Eld

Awan said:

Just coding it works if you don't mind it missing gemmed people and chameleoned people, and allying random folks (who may be enemies or random newbies or who knows what) that your party members were chameleoning.

That seems like a pretty compelling reason for why a command in the game to do it would be a better idea if it wouldn't be much trouble for the coders. Having the ability to ally your whole party without being misled by those silly factors seems pretty reasonable and commonsensical.

Might as well have an "enemy party" command too, for the monks. :P

I was actually thinking that if it did go in, it should NOT bypass gems/chameleons/etc.

Tvistor

I'm a little confused. As in, if ALLY PARTY went in, it shouldn't bypass gems, or ENEMY PARTY?

Eld

Tvistor said:

I'm a little confused. As in, if ALLY PARTY went in, it shouldn't bypass gems, or ENEMY PARTY?

Yes. I was specifically thinking of ALLY, but I think, as I said in my first reply, that either of them should only ALLY/ENEMY people you actually see on PWHO.

Valden

Now that I've thought about ENEMY PARTY, I can't find a use for ALLY PARTY anymore.

Delphinus

As a gem owner, I don't really understand why circumventing gem/chameleon is such a big deal.

Eld

It's not a huge deal, I don't think, I'd just prefer that it not. Basically, having gemmed and chameleoned people in a party is a (quite minor) complication that on some level requires a trade-off between whatever advantages those things grant and whatever complications they cause in keeping track of your party members. I don't see any particular reason those complications should be eliminated in the addition of a convenience function. But don't really care much either way.

Katzchen

Considering those people on partywho are most likely on cwho, or you're actively engaging with them, I don't see why it's a big deal for it to bypass gem/chameleon.

Xith

If you're in a party, I'm not sure you're entitled to give a damn about people that are partied allying you or something. Why would you? So gem/cham isn't a factor.

And similarly, what about this: ENEMIES <TRANSFER|SYNC> <TO|WITH> <adventurer>

If the other person AGREEs, their enemies list is matched with the transferrer's.

It's another thing that can be (and is) coded per person, but it's commonly needed in group conflict even by people who might not have a clue how to set that up themselves.

Don't see a means of abusing either function. Could even add a balance cost like party invite to each.

ALLY PARTY - require empty ally list, uses balance

ENEMIES TRANSFER TO <person> - require empty enemy list for the receiver, use balance for the giver

Trevize

Xith said:

And similarly, what about this: ENEMIES <TRANSFER|SYNC> <TO|WITH> <adventurer>

If the other person AGREEs, their enemies list is matched with the transferrer's.

I like that.

Tvistor

Paranoia needs to become an invisible hypnosis affliction for great lols.

Veldrin

Wish the name of the person in the party would be coloured up like clan who, cwho, hwho, who and such

Averi

I don't care if gemed people show up or not. 

Being a bard, my typical beginning of party fight thing goes something like this. Set harms. Ally person A B C in party oh wait, person A B just left my party and person D E F Just joined. Unally person A B, ally person D E F. WTF IS GOING ON!!!!!????? >.<  It's also simple if people have like spellable names but then there are times when i'm like ally hewquirqhrkhakdh wait does the q go before or after the h? Oh oops, I accidentally switched those two. 

And thank you! for the script ideas. I will try making it!  (I'm terrible at scripting so I wasn't exactly sure how to start it out). 

Tael

I feel like I'm missing something. Why wouldn't you want gem/cham people to show up?

If you don't want people in the party to see you, why are you joining the party? And people can already see the invitation and joining, no?

The only possible situation I can see where this would be a problem is someone inviting an enemy to a party by mistake and then the enemy using this to collect all the names of party members. But that seems completely fine if not straight-up desirable to me - a mistake like that has consequences (and that's a relatively minor consequence).

In fact, I had absolutely no idea that gem and cham worked on PWHO. That should just be changed. The purpose of a party is a short-term grouping and you should be visible if you elect to join it. I can't think of any time you would ever have a good reason to hide from your own party and it just makes keeping track of everyone during a raid or whatever harder.

Eld

Ok, since I obviously didn't explain my point clearly, I'll give it one more shot before giving up because it's really not important.
As it stands, gem and chameleon affect how you show up on PWHO. Generally, this serves no particular purpose, it's just an added (minor) complication to the business of keeping track of everyone in your party. It's a small cost to people using those defenses, which is probably minor enough that no one is likely to drop those defenses to avoid it, but in principle it's one more thing that you have to consider when using them.
I don't really care if this continues to be the case or not. It's really minor. But in adding convenience functions like this, I'd prefer that they observe the same restrictions as other things that provide the same information. Basically, I'd prefer that the proposed function provide a convenient way of getting the same information you can get off of PWHO, rather than providing additional info that you can't normally get there. Whether that ends up being both of them respecting gems and chameleons or both of them ignoring them, I really don't care. I'd just prefer that they be consistent (and really that's not a strong enough preference that I'm going to lose sleep over it, however it turns out).

Tvistor

Gems are great because when people are ranting they post "Well, you had like 50 people + gems", and "gems" can be varied until it has a value equal to "you bastards are timezone-abusing harlots that brought 200 more raiders than defenders".

Tael

Eld said:

Ok, since I obviously didn't explain my point clearly, I'll give it one more shot before giving up because it's really not important.
As it stands, gem and chameleon affect how you show up on PWHO. Generally, this serves no particular purpose, it's just an added (minor) complication to the business of keeping track of everyone in your party. It's a small cost to people using those defenses, which is probably minor enough that no one is likely to drop those defenses to avoid it, but in principle it's one more thing that you have to consider when using them.
I don't really care if this continues to be the case or not. It's really minor. But in adding convenience functions like this, I'd prefer that they observe the same restrictions as other things that provide the same information. Basically, I'd prefer that the proposed function provide a convenient way of getting the same information you can get off of PWHO, rather than providing additional info that you can't normally get there. Whether that ends up being both of them respecting gems and chameleons or both of them ignoring them, I really don't care. I'd just prefer that they be consistent (and really that's not a strong enough preference that I'm going to lose sleep over it, however it turns out).

Agreed.

Which is why PWHO just shouldn't respect gems or cham. It makes very little sense mechanically to be hidden from an impromptu grouping that you elected to join and that shows you joining the channel and it's such a slight "drawback" for the gemmed person that it's effectively meaningless balance-wise, especially compared to how frequently annoying it is for other people in the party.

Tvistor

I second Tael.

Lynara

My opinion on bypassing gems is that it should most decidedly NOT. The reasoning behind this is quite simple - currently, it's quite feasible to 'sneak' a gemmed person into a party as you're starting it... start the party with the gemmed person, then invite whoever else, and they'll never know there is a spy there. ALLY PARTY bypassing gem would alert people to the presence of the spy... This is the single biggest reason for having it NOT bypass gems.

As far as chameleons go, I'm really ambivalent about it. On the one hand, there's no way to know who the chameleoned person really is. On the other hand, you know they are there, it's only a matter of asking to figure it out... But once you ask, then you may as well manually ally then. On the other hand, NOT having it ally the chammed person means that you'll know that the chammed person is in fact chammed, since they didn't get allied... unless the 'ally party' allies the chammed person's cham target... I could see that working too. *shrugs*

Cardan

Currently gems/chameleons are respected by PARTYWHO as parties are by and large, treated as IC. If this is approved, then such a command would respect gems in the same manner so that there is no functional benefit from using either this command or a triggered PARTYWHO to build your player list from (other than this being a single command). 

Now for the technical questions - 

Should it append to the ally list or replace it? If the former and there isn't enough slots left, should it error at the start or just ally as many as it can?

Antidas

Cardan said:

Currently gems/chameleons are respected by PARTYWHO as parties are by and large, treated as IC. 

I know this is way off topic, so there's no need to respond...but I feel obliged to point out that there was a ruling a while back about how illusioning an ally calling targets on PT was against the rules because parties are OOC in nature. Just had to say it

Tvistor

Yeah, I don't know. Assuming parties are OOC always bugs me because the communication leads to IC actions (mainly in the case of raid parties).

'parties are/should be IC in nature' is slang for 'I'm a noob'.

Antidas

I wasn't saying I agreed with the ruling. Just saying that was what the ruling was. Agree that parties are/should be IC in nature.