Current behavior:
Lets say that you have a player with 4 alts or something like that. Lets call them accounts A, B, C and D.
You first find out that B is an alt of A and connect them.
Then you find out that D is an alt of C and connect them.
After that you realize that B and D is the same person so you set D as an alt of B.
What this will do is to "steal" the connection from C and instead connect it to A and B leaving C hanging without any connection.

Expected behavior:
You connect A and B, then you connect C and D.
When you connect B and D you would expect a merge of A, B, C and D to happen.

Alternative:
You connect A and B, then you connect C and D.
When you try to connect B and D you get a message saying something like this:
"D is already connected to C, what do you want to do?"
| Merge all | Change connection | Cancel |

I just noticed this. Sorry for the long delay. The complexity of adding alts to a group is deceivingly simple.

For example,let's say your scenario, A and B are connected, then C and D are connected. You now have 2 separate groups. I could add all these things like asking for confirmations what you want to do and so on, but instead I handle it slightly differently, and this has been somewhat updated .It prioritizes 2 things: Who is already in a group, and which group has a main designated. I would never merge 2 groups because too often there are times where someone gets accidentally added to another group and so t hey want to just pull that 1 player away. I'd rather not have to deal with popup confirmations, personally. But here, is an example of a logic flow of just your scenario and how every single situation has to be considered:

• Player 1 has alts, but player2 is main without alts.
  - Player 1 has a main, with alts, player2 is also a main.
  - Player 1 has NO main, with alts, player2 is also a main

• Player 2 has alts, but player1 is main without alts.
  - Player 2 has a main, with alts, player1 is also a main.
  - Player 2 has NO main, with alts, player1 is also a main
  - Player 1 and Player 2 both have alts with sub-scanrios OR, neither has alts:
  - Player1 has alts and a main designated, Player2 only has alts
  - Player2 has alts and a main designated, Player1 only has alts
  - Player1 and Player2 have alts and both have main designated, or neither have alts.
  - Player1 and Player2 have alts, neither have mains

   So, as you can see, just in the situation of comparing the 2 players who already are part of alt groups, and deciding the logic of should I add one or pull one away, I have to follow this logic, and just personal preference, I prefer to have GRM work where it will always prioritize the group who has the main. If they both have main, then I am just going to do base action of just pulling the 1 player away.
   
   Anyway, I appreciate your effort in putting this out there. The alt/main system was completely rewritten in the Aug 25th release 1.9912, and I would encourage you to check it out. Much of the behavior has been enhanced further and should improve the user experience a little.
  

The problem we have had is that we have players with like 10+ chars and we have added a group together and then someone sees an alt of some char and adds that to that char and we have several groups for one player and every time its updated we just end up moving the chars between the groups.

I will check out the update and come with feedback if there is something that is difficult.

Ya, so check with the latest update - there was an error in syncing previous to 1.9913 that could cause some alt groups to be disassociated on sync, which might have been your case.

This should now be fixed. The syncing of alt groups is handled as a group as a whole. Let me know if there are any issues going further as this SHOULD be resolved now. I think I just misunderstood what you were saying, but in reality you were probably experiencing the known bug issue where the same group of alts was getting disassociated on sync.