ReadyForTakeOffMsg received but unable to get an index

[Gangrenous]

Anyone know the cause or a remedy?

[Gangrenous]

Got it doing the exact same condition, zoning on to a boat. This one I have seen many times before. So this is visible in a search, the error is OP_QuestJournalSetVisibleMsg.

If anyone wants further debugging I can reproduce this error at will on my server. I do not have access to the packet analyzer so I am limited in what I can tell you. I am guessing that most of the client data in encrypted, so I doubt WireShark could tell me much.

[Gangrenous]

These are just placeholders for future use.

[Jabantiz]

ReadyForTakeOffMsg is for auto mounts, that error is sent when a flight path id is passed that doesn't exist.

The real issue here seems to be a desync between the client and server, when that happens you can get a bunch of errors in the console with the client eventually closing or crashing.

[Gangrenous]

ReadyForTakeOffMsg is for auto mounts, that error is sent when a flight path id is passed that doesn't exist.

The real issue here seems to be a desync between the client and server, when that happens you can get a bunch of errors in the console with the client eventually closing or crashing.

That would not make any sense on the flight path, none should had been sent. I was simply zoning into Antonica.

[neatz09]

flightpaths are sent the moment you zone in

[Gangrenous]

flightpaths are sent the moment you zone in

I think it is all related to the conditions when I am zoning. For notation this is another one I saw today while zoning. Of course I had no active quest nor had I completed a quest.

Code: Select all

13:56:25 E Client: num_quests = 3885153422 - quantity too high, aborting load.

[Jabantiz]

And again i said the issue is with the client desync.

Encryption goes haywire when the server and client fall out of sync so during the decryption process it decrypts wrong and thinks it got packets it never actually got. This also explains the invalid values for those packets because they server tries to handle it for the packet it thinks it is when it is not actually that packet.

[Gangrenous]

Looking back, this is very much related to the infamous sits bug.

viewtopic.php?f=13&t=4392&p=32994&hilit ... sts#p32994

[Gangrenous]

There is definitely something strange going on. I noticed several strange things and was able to duplicate the issue on the official server. One player going on the raft, normally the other player cannot see them. Also I would have one player able to see the raft, but with the other player it would be on the other shore. Even stranger when the first player walked up to the raft there was suddenly an invisible wall blocking them.

[Gangrenous]

In this sreenshot they are standing side by side on the raft but neither see each other. Also camping on the raft seems to crash the client most of the time. Several times the raft would move toward the other shore on one screen, but for the second player it will be still. I believe this all boils down to widgets not being right, Jabantiz has said before that when they think they have widgets figured out, they find something new. Neither are major problems really, just for notation.

UPDATE:
I think I crashed the main server just now by camping on a widget (a tent) from testing.