PMs going to wrong person

jake13jake · #1 01-13-2004, 04:12 AM

This is like the deleting pm history on block... One of those things that irritate you but you begin to cope with over time. When you try pming someone and they sign off right before you send the pm, you get a pm from somebody else going "ummm... wtf?" because your pm somehow accidentally went to them.

Python523 · #2 01-13-2004, 01:46 PM

not a lot you can do... the client sends PMs to specific IDs, not accounts

-Ramirez- · #3 01-13-2004, 03:03 PM

Seems to me that it could be made to send to that ID and also check the account name as well, could it not? That would solve this problem.

Loriel · #4 01-13-2004, 04:45 PM

Easy one.
If you have a PM window open, and the respective player logs off, just disable the send/reply buttons.

Thought · #5 01-13-2004, 04:51 PM

This only happens if another player signs on and gets the old players ID I believe. Could be wrong... I havn't seen these problem happen as much as it used to, though, oddly.

-Ramirez- · #6 01-13-2004, 05:23 PM

Quote:

Originally posted by Loriel
Easy one.
If you have a PM window open, and the respective player logs off, just disable the send/reply buttons.

Ok, here's a scenario:
1. Player sends a message.
2. Sender's connection lags during the send, the send is delayed.
3. The recipient logs off.
4. Sender's lag dissipates, the message gets sent.
5. The server receives the message after the recipient has logged off, so it sends the message to the new player with that ID.

Same problem, just less likely.

narkotic · #7 01-13-2004, 05:25 PM

Well then this looks like a problem with the PM system at the code level. Why is it using the unique connection ID of the player? It really should be based on account names. This might create further problems in the long-run that cannot be determined at the moment.

Loriel · #8 01-13-2004, 05:36 PM

Quote:

Originally posted by -Ramirez-

Sender attaches timestamp to message, server checks whether recipient is online since <timestamp> or longer.

-Ramirez- · #9 01-13-2004, 05:56 PM

Quote:

Originally posted by Loriel
Sender attaches timestamp to message, server checks whether recipient is online since <timestamp> or longer.

...*****, the account name method works far more reliably.

zell12 · #10 01-13-2004, 10:12 PM

Or, the client sends information to/from the account... Forget the IDs, why do we bother having them?

Python523 · #11 01-13-2004, 10:23 PM

Quote:

Originally posted by zell12
Or, the client sends information to/from the account... Forget the IDs, why do we bother having them?

You are not connected to every client at once. The server acts as a mediator, you send data to the server, it sends it back, I don't really think it would be safe to be connected to every single player online.

Loriel · #12 01-13-2004, 10:27 PM

So for each PM sent, you want to iterate through about sixty people connected and compare their account name to the one sent with the PM; instead of just going by ID?
How would you decide whether the RC client or Graal client of someone was to receive the PM?

-Ramirez- · #13 01-13-2004, 10:58 PM

Loriel, you jumped a step ahead in assuming that the PM would be sent to the correct account if their ID changed. If the account of the ID the player sends the PM to isn't the account it's supposed to be, the server could send a message back saying something like the PM wasn't received or so.

zell12 · #14 01-13-2004, 11:32 PM

I just don't understand the difference between the numbers of IDs, and the letters of Account Names.

Hevaricubed · #15 01-14-2004, 12:13 AM

Quote:

Originally posted by zell12
I just don't understand the difference between the numbers of IDs, and the letters of Account Names.

If stefan implemented a binary searching algorythym to find a player when they are being pmmed, then it would be hard to implement for account numbers.

You could of course convert the account names into numbers and sort them then do a binary search but that would take as long as going through them one at a time in a loop.

Loriel · #16 01-14-2004, 12:15 AM

Quote:

Originally posted by -Ramirez-
Loriel, you jumped a step ahead in assuming that the PM would be sent to the correct account if their ID changed.

Sounds fine but I was mainly answering to Excalibur anyway.

Excalibur: The ID is two bytes, and the serverside list of players is probably sorted by ID anyway so it is easy to find the player to deliver the PM to. But if you send PMs by account, you need to compare every byte of the account name sent with the PM to every byte of each player's account name until you got the right one

Probably not all that resources consuming, but, eh, got to optimize where you can.

zell12 · #17 01-14-2004, 12:36 AM

But then the account name is transferred into binary when a player logins? Wouldn't that take as many resources as checking for the whole account

Thought · #18 01-14-2004, 01:28 AM

You guys are misinterpreting player IDs.

When a player logs on, they are given an open 'slot' in a list of players.

The ID# is basically the 'slot' number in the list.

Instead of having a huge list that takes up lots of memory, the GServer reuses empty slots (which is why player B get the same ID as player A when player B logs on after player A logs off).

There is no searching involved, it automatically knows which 'slot' to send the PM to, which is also why player B gets the PM you tried to send to player A, but player A logged off.

zell12 · #19 01-14-2004, 05:31 AM

When a player logs off the ID should be void until it cycles through all the numbers, like 250 or something

Kristi · #20 01-14-2004, 10:22 AM

The simpliest solution if you want an easy fix without destroying the optimism of the server would be to continue using the system, but sending the accountname in the beginning of the packet and let the CLIENT check it.

if it doesnt match the accountname you're currently using, well let the client reject it.

konidias · #21 01-14-2004, 12:25 PM

The account name check would work fine, as long as it's setting that sender account as soon as you open the message window. Otherwise it would be checking the account name of the ID after the other person logged off.

Like:

PlayerA opens PM to PlayerB

PlayerA is typing message

PlayerB signs off

New PlayerB takes their place

PlayerA sends message

Message checks the account of PlayerB

PlayerB account matches and sends message

That would be the bad way to do it, the easiest way, would be to just check PlayerB as soon as PlayerA opens the PM to start typing.

I don't see why the account check wouldn't be sufficient. There should also be an option to sort the playerlist by accountname, like on RC.

Python523 · #22 01-14-2004, 02:19 PM

you're forgetting about mass messages... massing to all on a highly populated server would make a pretty large packet in this case

Loriel · #23 01-14-2004, 07:05 PM

Quote:

Originally posted by Kristi
If it doesnt match the accountname you're currently using, well let the client reject it.

So I could hack my client to receive strange PMs as well.

Kristi · #24 01-14-2004, 07:25 PM

Quote:

Originally posted by Loriel

So I could hack my client to receive strange PMs as well.

You could yes, but that becomes pointless ; )
You wouldnt be affecting anyone.

and yes the construction of the packet would including getting the account as soon as you open the window

and phython, if you send soemthing to 50 players, youre sending out 50 packets, which can be arrayed with their own account.

jake13jake · #25 01-14-2004, 09:58 PM

Quote:

Originally posted by Python523
you're forgetting about mass messages... massing to all on a highly populated server would make a pretty large packet in this case

Yea, come to think about it... Mass Messaging should be limited by the number of people you can send it to except for with staff. toalls work perfectly fine... AND that way it's not as easy to mass profanity because you can't skip over the GPs on the playerlist.

EDIT: Before I'm done, how about somebody fixes the quotation marks in guild pms bug?

Also, how about a second ignore where you can ignore mass messages from certain, specific players, but not have to ignore pms from them? and at the same time not ignoring mass messages that you might want to hear?

Thought · #26 01-15-2004, 01:57 AM

Quote:

Originally posted by Kristi

You could yes, but that becomes pointless ; )
You wouldnt be affecting anyone.

and yes the construction of the packet would including getting the account as soon as you open the window

and phython, if you send soemthing to 50 players, youre sending out 50 packets, which can be arrayed with their own account.

Wrong, you're sending one packet, with a list of all players to send to.

Kristi · #27 01-15-2004, 02:41 AM

Quote:

Originally posted by Thought

Wrong, you're sending one packet, with a list of all players to send to.

bite me =P
that makes sense but still bite me

well dont have it apply to mass messages? usually a mass message is intended for everyone anyway.

jake13jake · #28 01-15-2004, 03:38 AM

Quote:

Originally posted by Kristi

bite me =P
that makes sense but still bite me

well dont have it apply to mass messages? usually a mass message is intended for everyone anyway.

Why not just revamp the messaging system? having:
-toalls go to all (instead of how mass messages are usually used).
-guild messages with the fixed quotation mark thing.
-mass messages going to a max of (maybe 5?), also checking for accounts, unless staff uses it, then goes same was as a toall.
-private messages checking for accounts.
-ability to ignore an individual's toalls, mass messages, guild messages, private messages, or all as seperate options.