Jump to content

[Help]Packets and CalendarSystem


Guest singlem

Recommended Posts

Hey

I have been playing around with the in game Calendar the past two days but now I have a few questions.

"SMSG_CALENDAR_SEND_CALENDAR" is handled by HandleCalendarGetCalendar, but it seems that is only being ran when the player logs in. How can I force the server to run HandleCalendarGetCalendar(to be more exact what do I use a parameter).

Second: Does the packet size make a diff at all?

WorldPacket data(SMSG_CALENDAR_SEND_EVENT);

or

WorldPacket data(SMSG_CALENDAR_SEND_EVENT, some Value);

See why I ask. I got it to add a event to the calendar, but player must relog to see the event. I got the calendar more or less after I figure this out, its over to invites and all the other things. Then major code cleanUp:)

Link to comment
Share on other sites

SMSG_CALENDAR_SEND_CALENDAR should be only sent when the client requests it with CMSG_CALENDAR_GET_CALENDAR when the client logs in. It's one of those initial type packets for setting up bulk stuff.

If you don't specify a size, then the default size will be set at 200 based on WorldPacket(uint16 opcode, size_t res=200) inside of WorldPacket.h unless I'm misinterpreting the code (I am still learning). It is better to assign a size so that it is more efficient with memory and buffering.

I've been playing around with the calendar opcodes as well for the past day (limited time within thereof). Some of the opcode structure research so far that I've come up with inside of CalendarHandler.cpp:

   DEBUG_LOG("WORLD: CMSG_CALENDAR_ADD_EVENT");

   std::string eventname, eventdesc;
   recv_data >> eventname;                             // event name
   recv_data >> eventdesc;                             // event description

   uint8   eventtype, unk4;
   uint32  unk5, instance, eventtime, unk8, unk9, count = 0;
   recv_data >> eventtype;                             // 0=Raid,1=Dungeon,2=PvP,3=Meeting,4=Other
   recv_data >> unk4;
   recv_data >> unk5;                                  // always 100?
   recv_data >> instance;                              // instance last selected for eventtype 0 or 1
   recv_data >> eventtime;                             // event time
   recv_data >> unk8;
   recv_data >> unk9;                                  // flags? 16 = Lock Event

and

   DEBUG_LOG("WORLD: CMSG_CALENDAR_EVENT_INVITE");

   ObjectGuid unkObj1, inviter;
   std::string pName;
   uint8 unk1, unk2;

   recv_data >> unkObj1;           // event id?
   recv_data >> inviter;           // player that sent invite
   recv_data >> pName;             // invited player
   recv_data >> unk1;
   recv_data >> unk2;

Link to comment
Share on other sites

BThallid I have the packet data that is sent and received by server(might still need some work). Thanks for the packet info. I'll be forking mangos clean soon and doing a repo for the calendar, so if want you have info or have something to add feel free to commit.

But now the question comes in how or what packet is sent to update the calendar at the creation of an event?

Might just some code error, but Player needs to log out and back in to see the created event. This is what I have so far in a custom mangso repo

Link to comment
Share on other sites

I was just now looking through some of the source on Infinity/core that you have helped on. I feel a bit sheepish now; all the info is already there.

I had tried sending the SMSG_CALENDAR_SEND_CALENDAR before but had the packet structure all wrong so it would just freeze the client. If you really just wanted to trigger the packet handler, the playerbot code uses plenty of lines like m_bot->GetSession()->QueuePacket(packet); to have the bots simulate the packets being send to the server. I'm not sure if you have actually tried that or not. It is obvious that you are well ahead of me, but this will certainly give me a boost.

Link to comment
Share on other sites

hmmm OK now I hit a wall:(

How the does the invite part work?

"CMSG_CALENDAR_EVENT_INVITE" need to have "SMSG_CALENDAR_EVENT_INVITE" but what does this do?

Then you get "SMSG_CALENDAR_EVENT_INVITE_ALERT" witch I guess is the invite message?

"CMSG_CALENDAR_EVENT_RSVP" I guess is when the player state if he is joing or not(many more)

If anyone has an Idea please share...this is more or less the last part that I need to figure out then I can do major cleanup on it. Very messy writing at this point:o

Link to comment
Share on other sites

This is where sniffs would be helpful. Too bad I never checked for this while I was on.

I noticed while working a bit with the packets that whenever I send the invite list inside of SMSG_CALENDAR_SEND_EVENT it freezes the client. I have noticed that sending SMSG_CALENDAR_ACTION_PENDING appears to reset the buttons on the interface (Create greys out but then becomes normal after a bit when this packet is sent).

SMSG_CALENDAR_EVENT_INVITE_ALERT appears to just to flash the calendar icon near the minimap.

CMSG_CALENDAR_EVENT_RSVP was sent when I right-clicked an event that the invite status was not confirmed (ie invited, not signed up) and selected a reason.

Perhaps SMSG_CALENDAR_COMMAND_RESULT is used somehow. Also, how should the invite be handled when it is added on the event before creation is finished. It has the eventId as 0, but judging by the interface it should return some confirmation of whether the player exists. Perhaps that's where SMSG_CALENDAR_UPDATE_INVITE_LIST comes into use.

Link to comment
Share on other sites

Sniff would have been nice, if I just started this a month or two ago:|

OK, seems I will have to sit and do some major packet processing. BThallid if you look at the infinty repo the "SMSG_CALENDAR_SEND_EVENT" is done...I just need to do the invites part then. Will sit today and run tests on everything, seems that will be the only way to get the data

Link to comment
Share on other sites

  • 1 month later...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use