EQEmulator Forums - In Game Message System

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Feature Requests (https://www.eqemulator.org/forums/forumdisplay.php?f=612)

- - In Game Message System (https://www.eqemulator.org/forums/showthread.php?t=26868)

In Game Message System

The idea for this is to make a system almost like in-game email. It should be pretty simple and work similar to petitions. Basically, a player would run a command and include a character name to send the message to. Then, the message would be stored in a table. And, when the other character that the message was sent to logs in, they would get a chat line saying that they have unread messages.

The only possible downside to this is that they would have to be aware that their messages could potentially be read by the server admin(s). Unless they were able to be encrypted in some way.

An example of this might be:

Playera sends a message:
#message playerb Hey man, we are raiding tonight, so let me know when you get on.

Playerb logs in and sees:
You have 1 unread message.
They then type:
#listmessages (or maybe #lm for an alias)
Which then lists:
Message 1 from Playera
Message 2 from Playerc

Then, they type:
#viewmessage 1 (or #vm 1 for alias)
And it displays the message from Playera:
Playera wrote, "Hey man, we are raiding tonight, so let me know when you get on."

And last, they type:
#delmessage 1 (or #dm 1 for alias)

Another option for deleting messages could be "#delmessage all" to delete all messages. I imagine that is something any admin would require lol.

I don't think this would be too hard to work out the code for. I will try to work on it some if I get time. I am pretty sure people would like it. Any thoughts?

Why not just implement mail? I'm sure Derision could be convinced to find the opcodes if asked nicely.

Quote:

Originally Posted by cavedude (Post 160632)

Why not just implement mail? I'm sure Derision could be convinced to find the opcodes if asked nicely.

It doesn't appear to be quite so simple. When you try to send an in-game email in EQEmu, the client gives the message:

Code:

Please wait until we reconnect you with the Universal Chat service. Your request has not been sent.

which would indicate to me that the in-game mail is handled over a totally separate connection than the client/world or client/zone streams we are familiar with.

So it would probably take quite a while to figure out how to get it to work. I'm insanely busy at work for the next few weeks, but I'll take a look at it if I get some free time.

I wasn't suggesting you write the whole system, just grab the opcodes for it ;)

Though, we do have a mail server option in our config file. I wonder if somebody already thought ahead and partially implemented that.

This is what happens with OP_EnterWorld:

world/client.cpp

Code:

                        EQApplicationPacket *outapp2 = new EQApplicationPacket(OP_SetChatServer);

                        char buffer[112];

                        sprintf(buffer,"%s,%i,%s.%s,%s",

                                Config->ChatHost.c_str(),

                                Config->ChatPort,

                                Config->ShortName.c_str(),

                                this->GetCharName(),"067a79d4"

                        );

                        outapp2->size=strlen(buffer)+1;

                        outapp2->pBuffer = new uchar[outapp2->size];

                        memcpy(outapp2->pBuffer,buffer,outapp2->size);

                        QueuePacket(outapp2);

                        safe_delete(outapp2);



                        outapp2 = new EQApplicationPacket(OP_SetChatServer2);

                        sprintf(buffer,"%s,%i,%s.%s,%s",

                                Config->MailHost.c_str(),

                                Config->MailPort,

                                Config->ShortName.c_str(),

                                this->GetCharName(),"067a79d4"

                        );

                        outapp2->size=strlen(buffer)+1;

                        outapp2->pBuffer = new uchar[outapp2->size];

                        memcpy(outapp2->pBuffer,buffer,outapp2->size);

                        QueuePacket(outapp2);

                        safe_delete(outapp2);

                        

                        EnterWorld();

We currently default to eqmail.eqemulator.net:7779 for mail & eqchat.eqemulator.net:7778 for chat, unless set to something different in eqemu_config.xml:

common/EQEmuConfig.h

Code:

                // Mail

                ChatHost="eqchat.eqemulator.net";

                ChatPort=7778;



                // Mail

                MailHost="eqmail.eqemulator.net";

                MailPort=7779;

So it looks like the client communicates directly with these mail & chat servers.

Googling around, I found this old thread:

Quote:

Originally Posted by sfisque (Post 131311)

ok, barring that option, is it possible to wire up my own irc server to "expose" the server chat to my own irc server if i wanted? or does it require some specialized "add on" to the irc server to get this connectivity?

Quote:

Originally Posted by sfisque (Post 131368)

simple solution... talk to doodman. i dont know what the "criteria" or whatnot is, but i asked nicely, and he set it up.

then all you have to do is create the #channel you want to use, let doodman know what the channel name is (along with some other config info from your config.xml file) and bingo.

a caveat: the connectivity between the eqclient/server/irc is sensitive and drops fairly often, though zoning or camping fixes it for the particular user in question. i dont know if it is an artifact of bandwidth or just plain old latency that causes the chat pipe to drop.

Quote:

Originally Posted by Doodman (Post 131377)

No criteria, except:

1) Register your channel.
a) Which implies that you've registered your nick
2) PM me your servers short name and the channel you want people placed in and choose the "type" of channel:
a) Auto - People are placed in the channel, can talk and leave.
b) Forced - People are placed in the channel and can talk, but cannot leave
c) Admin - People are placed in the channel, but cannot talk or leave

If we did decide to create a new Mail/Chat server, we would still need to get some OpCodes:

Code:

#mail opcodes

OP_Command=0x0000

OP_MailboxHeader=0x0000

OP_MailHeader=0x0000

OP_MailBody=0x0000

OP_NewMail=0x0000

OP_SentConfirm=0x0000

The client tries to initiate a new connection to the UCS that we never complete too *I think*. When I was fiddling with packet viewing I noticed that after the UCS packets were sent to the client the client kept sending a connect request to the server every couple seconds that was never responded to.

Not sure what client this is for, but here's some old, commented out code referring to the chat system:

Code:

        // @bp This is the chat server

        /*

        char packetData[] = "64.37.148.34.9876,MyServer,Testchar,23cd2c95";

        outapp = new EQApplicationPacket(OP_0x0282, sizeof(packetData));

        strcpy((char*)outapp->pBuffer, packetData);

        QueuePacket(outapp);

        delete outapp;

        */

It appears 64.37.148.34 is Sony's chat server:

Code:

C:\>nslookup 64.37.148.34



Name:    eqchannel1.station.sony.com

Address:  64.37.148.34

A little bit more random info in the source:

common/EQStream.cpp

Code:

void EQStream::SetStreamType(EQStreamType type)

{

        _log(NET__NET_TRACE, _L "Changing stream type from %s to %s" __L, StreamTypeString(StreamType), StreamTypeString(type));

        StreamType=type;

        switch (StreamType) {

                case LoginStream:

                        app_opcode_size=1;

                        compressed=false;

                        encoded=false;

                        _log(NET__NET_TRACE, _L "Login stream has app opcode size %d, is not compressed or encoded." __L, app_opcode_size);

                        break;

                case ChatOrMailStream:

                case ChatStream:

                case MailStream:

                        app_opcode_size=1;

                        compressed=false;

                        encoded=true;

                        _log(NET__NET_TRACE, _L "Chat/Mail stream has app opcode size %d, is not compressed, and is encoded." __L, app_opcode_size);

                        break;

                case ZoneStream:

                case WorldStream:

                default:

                        app_opcode_size=2;

                        compressed=true;

                        encoded=false;

                        _log(NET__NET_TRACE, _L "World/Zone stream has app opcode size %d, is compressed, and is not encoded." __L, app_opcode_size);

                        break;

        }

}

We also have Message Types for chat channels 1-10, so at the very least, we could patch together a secondary chat system using # commands:

Code:

#define MT_Chat1Echo                        315

#define MT_Chat2Echo                        316

#define MT_Chat3Echo                        317

#define MT_Chat4Echo                        318

#define MT_Chat5Echo                        319

#define MT_Chat6Echo                        320

#define MT_Chat7Echo                        321

#define MT_Chat8Echo                        322

#define MT_Chat9Echo                        323

#define MT_Chat10Echo                        324

Sounds like we would need to have a completely separate application built and running to handle mail. I never played when they had mail on Live, so I don't know anything about it. Either way, I can probably get the message system I described running pretty quickly and easily. It would probably work well enough until the real mail system can be done. Unless someone thinks that it won't be long to get the mail system working.

I'm betting this system could also be used to create /tell queing like on Live for when a person was zoning. Sounds like what you're proposng Trev and what Derision and KLS are saying is happening with the code is similar to what happened on Live when you sent someone a tell while they were zoning. The system would just save the messages up and then they'd be displayed to you when you finished zoning.

After spending a couple of days looking at this and almost giving it up as 'too hard', I finally made a bit of progress:

http://www.rama.demon.co.uk/eqemumail.jpg

All I have right now is a little 'mailserver' app which listens on the mailserver port specified in eqemu_config.xml and sends hardcoded responses to the client requests as a 'proof of concept', so plenty of work left to do to turn it into a working mail system.

Mail is in Rev247 for those that can compile.

I've started work on chat channels, as it uses the same opcodes as mail. I have the basics working (create, join, leave, and of course talk in a channel). Still need to implement the moderator stuff.

Thanks for the effort Derision!

This is awesome!!! :) Hey Derision, previously we have relied on Doodman to for connectivity between EQEMU and IRC . Do you have any ideas so that we can work around this?

Currently using 245, downloaded mail.sql and sourced into db.

Included following rules into peq/tables/rules_values

1 Mail:EnableMailSystem 1
1 Mail:ExpireTrash 0
1 Mail:ExpireRead 31536000
1 Mail:ExpireUnread 31536000

#

[Debug] [RULES__CHANGE] Set rule World:ExemptAccountLimitStatus to value -1
[Debug] [RULES__ERROR] Unable to find rule 'Mail:EnableMailSystem'
[Debug] [RULES__ERROR] Unable to interpret rule record for Mail:EnableMailSystem

[Debug] [RULES__ERROR] Unable to find rule 'Mail:ExpireTrash'
[Debug] [RULES__ERROR] Unable to interpret rule record for Mail:ExpireTrash
[Debug] [RULES__ERROR] Unable to find rule 'Mail:ExpireRead'
[Debug] [RULES__ERROR] Unable to interpret rule record for Mail:ExpireRead
[Debug] [RULES__ERROR] Unable to find rule 'Mail:ExpireUnread'
[Debug] [RULES__ERROR] Unable to interpret rule record for Mail:ExpireUnread
[Debug] [WORLD__INIT] Loaded default rule set 'default'

#

Everything else loads without errors, any ideas?

Mail was implemented in Revision 247, for which there are no Windows executables available for download yet.

And Richardo, I'll look into an IRC interface to chatserver. I don't know a lot about IRC, but I'll have a look at the RFCs and setup a private IRC server to play with.

One thing I am unsure about is authentication, i.e. you don't want a random person logging into a server chat channel from IRC and being able to spam it.