Hacker News Reader

Comment by markbnj | Hacker News Reader

That's a great story. How would you have fixed it without having to find another channel to transmit over? Could the plugin sense the character's condition and delay until it abated?

View on HN

Send a known-good line to test for it.

"FriendnetStart: Hello, I am speaking normally and am not drunk," as the first message. If the application sees anything but that as the first message it should assume drunk and retry in an hour. Or implement a checksum at the end of every line.

I imagine he also had issues with the profanity filter as well. Some usernames may set it off if they have a string of characters in them like username "Breshith," which would set off the filter for the text "shit."

The character could possibly become drunk immediately after sending the "I am not drunk" message, so you'd need to check if the character was still not drunk after sending the FriendNet messages. But assuming that drunkenness lasts much longer than it takes to send the FriendNet messages, you could be sure that if the character was not drunk before and after, then the messages in between were also valid.

> so you'd need to check if the character was still not drunk after sending the FriendNet messages

Just send a checksum with the message.

Yes this would work, even though the message could get garbled including the checksum, you make the first set of characters be a checksum for the rest. If the checksum or message became compromised it would fail validation. This is the best solution so far. Send it with every message.

Or use error-correcting codes so you can get your list accross even if you're drunk :D

That probably would've worked fine in WoW yeah. Definitely not in EQ though, the "smashed" level made it pretty much impossible to communicate (outside of the channels which were added later on), and the game became… challenging to play

What do you mean by error-correcting codes?

http://en.wikipedia.org/wiki/Error_detection_and_correction#...

I think it's safe to assume that a drunk checksum would fail to match the message, drunk or sober. So check summing the checksum may not be needed.

Or even better, depending on length limits on message, you could prepend every message with a sentence to check. If it is not OK, discard the entire message. If it is, process the rest.

If I remember correctly, there's a probability that a line will end with "...hic!" or that s will be replaced with sh. It won't happen every time, so your first message could go through fine. A checksum is probably best.

Character names will never contain punctuation, so expecting a possible terminating "...hic!" and ignoring it is fine.

Or the character could get drunk halfway through transmitting, after the first (sober) message.

WoW Patch 1.12 released in August of 2006 added a hidden channel for add-on communication that didn't suffer from the drunken text transform. FriendNet was in use and updated well after that patch was released but to the best of my knowledge never moved communication to that channel.

Source: http://www.wowwiki.com/Patch_1.12 New API Functions Add-ons can send hidden chat messages to players in the party, raid or guild, using SendAddonMessage("prefix", "message", "PARTY"|"RAID"|"GUILD"|"BATTLEGROUND").

Convert to hex, replace c with g. That avoids the ...hic and s->sh transforms

The transform looks fairly simple; just approach it the same way you do error-correction (i.e. reed-solomon), find vectors of characters that are far apart in phase space and use them rather than sending messages directly.

ECC's way overkill, just use a CRC and cancel the exchange if users are drunk.

Add a checksum that the client uses the validate the message.

The addon should send a checksum so the receiving end can detect any unexpected changes. Also, the addon should just avoid sending when the character is drunk.

For detection, have the receiver echo back and check that sent == received.

But what if both are drunk?!

If the drunk transformation is 's' -> 'sh'

Sender sends 's'

Receiver receives 'sh'

Receiver sends back 'sh'

Sender receives 'shh', compares it to the 's' it thought it sent, and correctly deduces something went wrong in the communication.

It is overzealous in that it would fail if the sender wasn't drunk but the receiver was.

But if the reciever echoes "sho" (drunken "so") that would just be "sho" again wouldn't it?

Server sends 'so'

Receiver receives 'sho'

Receiver sends back 'sho'

Sender receives 'sho', compares it to the 'so' it thought it sent, and correctly deduces something went wrong in the communication.

Error correcting codes?

If I'm remembering correctly, only certain characters get transformed. So maybe you could use Huffman coding to map the text into a safe character set before you sent it. (might still have to strip out unacceptable characters to get rid of the ...hic)

I would have either just trimmed the ... hic from the received text (if there was only one string causing problems), or maybe even better would be to use control codes to signal the beginning and end of the data.

it looks like it actually transforms the message too, not just adds "..hic"

What about encoding messages with numbers, and then filtering the letters that are added to the message when you are drunk at the receiver side, just before decoding it, would that work?

Please let me know when you guys figure this one out. I always wanted to know the best way to flawlessly communicate with friends while drunk.

Reply on news.ycombinator.com