Warning: Client Cannot Receive Packet or Key is Invalid

[evenmonkeys]

I found a thread saying that this error occurs from time to time and the fix for it is just letting the session dissolve. Is there anything that would have caused it? It's a fairly default build. It's never done it on my local client using hairpin, but it's happened a couple of times to people logging into the server from outside the network. I don't remember this happening before.

Thanks.

Code: Select all

[Info] mapsession:#.#.#.#:54090 is coming to world...
[Error] Loading error from char_equip
[Info] parse: 00A : 0001  0000 2E from user: Playername
[Debug] CZone:: Southern_San_dOria IncreaseZoneCounter <1> Playername
[Info] parse: 00A : 0002  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0004  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0005  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0006  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0007  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0008  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Info] parse: 00A : 0009  0000 2E from user: Playername
[Warning] Client cannot receive packet or key is invalid: Playername
[Debug] map_cleanup: Playername timed out, closing session

[Noxus]

Pretty sure it happens to everyone upon new character login. Everytime I make another test char on my server I get the error. I'll create, log in, and log out. On my next login it happens and I'll let my client time out. After the session data clears it should not happen again, assuming zoneip is configured.

[Vivitaru]

In my case, each time i create a character, i'm able to get in the game the first time with it but after i log the char out, i'm unable to get back in with the new char, giving Warning: Client Cannot Receive Packet or Key is Invalid constantly unless i restart the server which obviously is not an option.

I spent a lot of time trying to figure out how to get rid of that error, here's what i noticed and did to resolve it:
(this is using the --hairpin option, not sure if it's relevant)

Whenever a new character is created, i noticed the 'pos_prevzone' value for the character is set to zero by default. I logged the char off and decided to manually edit the entry in the chars table and set pos_prevzone to its neighbor zone. So in my case when i start in zone 230 (south sandy), i set it for 231 or vice versa. Do not set pos_prevzone the same value as pos_zone, it has to be different.

I added this in charutils.cpp, in void LoadChar(CCharEntity* PChar)

Code: Select all

	    PChar->SetPlayTime(Sql_GetUIntData(SqlHandle, 21));
       PChar->m_isNewPlayer = Sql_GetIntData(SqlHandle, 22) == 1 ? true : false;
	}

	+// Prevzone fix //
	+if (PChar->loc.prevzone == 0) {
	+	if (PChar->loc.destination == 232 || PChar->loc.destination == 231) {
	+		PChar->loc.prevzone = 230;
	+	}
	+	else if (PChar->loc.destination == 230) {
	+		PChar->loc.prevzone = 231;
	+	}
	+	else if (PChar->loc.destination == 236 || PChar->loc.destination == 235) {
	+		PChar->loc.prevzone = 234;
	+	}
	+	else if (PChar->loc.destination == 234) {
	+		PChar->loc.prevzone = 235;
	+	}
	+	else if (PChar->loc.destination == 238 || PChar->loc.destination == 240) {
	+		PChar->loc.prevzone = 239;
	+	}
	+	else if (PChar->loc.destination == 239) {
	+		PChar->loc.prevzone = 238;
	+	}
   +
	+	std::string qStr = ("UPDATE chars SET pos_prevzone=");
	+	qStr += std::to_string(PChar->loc.prevzone);
	+	qStr += " WHERE charid=" + std::to_string(PChar->id);
	+	Sql_Query(SqlHandle, qStr.c_str());
	+}

   fmtQuery =
       "SELECT "
         "rank_points,"    // 0

It will do a check on prev_poszone when a character logs in and set one up depending which starting zones that char was in.

Hope this works out for you as well, let me know if it does.

[whasf]

You can probably just set it to something non-zero and it'll work, it doesn't have to be a neighboring zone

[Vivitaru]

You can probably just set it to something non-zero and it'll work, it doesn't have to be a neighboring zone

You're absolutely right, i set it for 65535 without any issues, shaved a few lines.

Code: Select all

       PChar->SetPlayTime(Sql_GetUIntData(SqlHandle, 21));
       PChar->m_isNewPlayer = Sql_GetIntData(SqlHandle, 22) == 1 ? true : false;
   }

   +// Prevzone fix //
   +if (PChar->loc.prevzone == 0) {
   +   PChar->loc.prevzone = 65535;
   +   std::string qStr = ("UPDATE chars SET pos_prevzone=");
   +   qStr += std::to_string(PChar->loc.prevzone);
   +   qStr += " WHERE charid=" + std::to_string(PChar->id);
   +   Sql_Query(SqlHandle, qStr.c_str());
   +}

   fmtQuery =
       "SELECT "
         "rank_points,"    // 0

[kjLotus]

You can probably just set it to something non-zero and it'll work, it doesn't have to be a neighboring zone

You're absolutely right, i set it for 65535 without any issues, shaved a few lines.

Code: Select all

       PChar->SetPlayTime(Sql_GetUIntData(SqlHandle, 21));
       PChar->m_isNewPlayer = Sql_GetIntData(SqlHandle, 22) == 1 ? true : false;
   }

   +// Prevzone fix //
   +if (PChar->loc.prevzone == 0) {
   +   PChar->loc.prevzone = 65535;
   +   std::string qStr = ("UPDATE chars SET pos_prevzone=");
   +   qStr += std::to_string(PChar->loc.prevzone);
   +   qStr += " WHERE charid=" + std::to_string(PChar->id);
   +   Sql_Query(SqlHandle, qStr.c_str());
   +}

   fmtQuery =
       "SELECT "
         "rank_points,"    // 0

hope you don't log in to your mog house and then try and leave

[Vivitaru]

hope you don't log in to your mog house and then try and leave

Good point, it would no doubt be safer to assign a neighboring zone afterall.

[TeoTwawki]

Just use Lower Jeuno. It's where the char reset command puts you anyway.

[atom0s]

For a more proper implementation, the lobby server should be setting the users previous zone on account creation to the a partnered zone within the starting city that they are placed. Anytime the issue occurs the same implementation should happen rather than just forcing a user to a zone they may not even have the ability to get to yet.

For a legit server that wants a player base to level normally, forcing their character to Lower Jeuno on an issue like this is not very handy. What if a level 1-10 player is stuck and logs back into Jeuno where they have never been to before? That kind of throws them into a loop of then needing to start randomly asking for help cause they have no idea where they are.

[TeoTwawki]

For a more proper implementation, the lobby server should be setting the users previous zone on account creation to the a partnered zone within the starting city that they are placed. Anytime the issue occurs the same implementation should happen rather than just forcing a user to a zone they may not even have the ability to get to yet.

For a legit server that wants a player base to level normally, forcing their character to Lower Jeuno on an issue like this is not very handy. What if a level 1-10 player is stuck and logs back into Jeuno where they have never been to before? That kind of throws them into a loop of then needing to start randomly asking for help cause they have no idea where they are.

Perhaps I'm missing something here...
The code he posted was changing prevzone from zero. I didn't see anything changing the characters currentzone. The only thing that comes to mind that would send you to prevzone during normal gameplay is exiting the mog house. If you enter your moghouse, your prevzone is already non zero yes? How often is anyone going to actually land in Jeuno if we're only touching prevzone? I'd have said set it to homepoint, but he said that if current zone and prevzone are same value he still gets problems and when you first login a new character your initial homepoint is also your current zone.

I was replying about what I hoped was a temporary workaround to an issue that shouldn't even be occurring in the first place. Your previous zone shouldn't (but does?) have anything to do with your ability to log in. I'm not going to be more concerned that somebody might be confused than I would be if they were unable to log in at all. And definitely beats using zoneIDs that don't exist. But for what its worth, forcing ppl to jeuno when using @resetplayer isn't very handy either.