Windrose: Update UserLeaveRegex and UserJoinRegex

[KairuByte]

More encompassing account disconnection regex which includes ungraceful disconnects (such as client crashes or taskkill -f -im Windrose-Win64-Shipping.exe)

[KairuByte]

Cant for the life of me get this to hit on improper disconnects even though the message is identical for both proper and improper. I suspect I may be running into an issue where the edited GenericModule.kvp file isnt being properly honored, but was unable to determine if that was the case in the time I had available. Will look into this further in the near future.

[Greelan]

AMP doesn't behave well when the join matches on name and id but the leave only on id

[KairuByte]

Changed UserJoinRegex to handle a Windrose disconnect edge case. When Windrose disconnects an account it moves the account into the "Disconnected Accounts" list using the state the account was last in. Clean disconnects use state SaidFarewell, but unclean disconnects often leave the account in ReadyToPlay. That causes AMP to log a proper disconnect (MoveAccountToListOfDisconnected) and then immediately treat the same account as connected again (ReadyToPlay in the disconnected list). This change prevents duplicate reconnect handling by accounting for the ReadyToPlay-on-disconnect case.

[Greelan]

By removing ReadyToPlay from the join regex though, will this match on logs for other states that it should not match on?

[KairuByte]

The original join regex is looking for either of those, the first match in the group is one that I have seen during every single connection and never outside that context. The second match in the group does indeed come up during connection, but it also crops up if you just pull the plug on the connection for whatever reason, and it will show up again and again for ever user that disconnects, as that match is on the disconnected accounts list.

The first match seems to still reliably fire on connection, and only connection. The second match was problematic and doesn't seem to actually add a layer on top of the first match.

[Greelan]

Ah, I think I added the second bit because someone gave me logs that showed a user joining without the first bit. So idk

If you have reliably tested this on a running server then I guess that is good enough for me

[KairuByte]

It does work reliably on my live server. I will say there may be an edge case where it doesn't work, but the second match is "reliably unreliable" so it likely shouldn't stay in place even if there is a situation where it was showing while the other wasn't.