Ally Party

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. 
Commission List: Aesi, Kenway, Shimi, Kythra, Trey, Sholen .... 5/5 CLOSED
I will not draw them in the order that they are requested... rather in the order that I get inspiration/artist block.
«1

Comments

  • 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?
  • It's not a bad idea, though it would be fairly easy to script yourself.
  • AchillesAchilles Los Angeles
    except for those gem people (or chameleoned) ones who don't show up on pwho.
    image
  • 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.

  • 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.
    Current scripts: GoldTracker 1.2, mData 1.1
    Site: https://github.com/trevize-achaea/scripts/releases
    Thread: http://forums.achaea.com/discussion/4064/trevizes-scripts
    Latest update: 9/26/2015 better character name handling in GoldTracker, separation of script and settings, addition of gold report and gold distribute aliases.
  • 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
  • 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 don't like it for the same reason that you guys seem to want it. To get around chameleon/gems.
    Current scripts: GoldTracker 1.2, mData 1.1
    Site: https://github.com/trevize-achaea/scripts/releases
    Thread: http://forums.achaea.com/discussion/4064/trevizes-scripts
    Latest update: 9/26/2015 better character name handling in GoldTracker, separation of script and settings, addition of gold report and gold distribute aliases.

  • 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.
  • I'm a little confused. As in, if ALLY PARTY went in, it shouldn't bypass gems, or ENEMY PARTY?

  • 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.
  • Now that I've thought about ENEMY PARTY, I can't find a use for ALLY PARTY anymore.
  • As a gem owner, I don't really understand why circumventing gem/chameleon is such a big deal.
  • 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.
  • 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.


                   Honourable, knight eternal,

                                            Darkly evil, cruel infernal.

                                                                     Necromanctic to the core,

                                                                                             Dance with death forever more.



  • 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
    I like my steak like I like my Magic cards: mythic rare.
  • 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.
    Current scripts: GoldTracker 1.2, mData 1.1
    Site: https://github.com/trevize-achaea/scripts/releases
    Thread: http://forums.achaea.com/discussion/4064/trevizes-scripts
    Latest update: 9/26/2015 better character name handling in GoldTracker, separation of script and settings, addition of gold report and gold distribute aliases.
  • Paranoia needs to become an invisible hypnosis affliction for great lols.
  • Wish the name of the person in the party would be coloured up like clan who, cwho, hwho, who and such

  • 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). 
    Commission List: Aesi, Kenway, Shimi, Kythra, Trey, Sholen .... 5/5 CLOSED
    I will not draw them in the order that they are requested... rather in the order that I get inspiration/artist block.
  • 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).
  • 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".
  • 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.
  • I second Tael.
  • 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*
    (The Midnight Crew): Cain says, "You on your period lynara?"

    (The Midnight Crew): Micaelis says, "Lynara coded periods out of his DNA."
  • CardanCardan The Garden
    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?
  • 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 :|

  • edited March 2013
    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'.
  • 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.

Sign In or Register to comment.