NPC objects, spawn and control

[zkowie]

I'm having trouble implementing NPCs in my server - if I send only the spawnnpcpacket, everything's working well. However, if I'm sending the controlnpcpacket as well, the encryption between the client and me breaks, causing the server to fail.

I've been looking at moople and vana as bases - and whereas vana spawns and controls all the npcs when the map changes, moople is doing something entirely different. First, moople is sending all the spawn and control packets, then it's sending spawn and control packets for all npc's within the players screen (viewrange), and keeps sending spawn and control packets on update.

Currently, I'm only sending them on mapspawn - any ideas?

[MentaL]

[SYJourney]

I think the way moople does it is correct, altough it's not really necessary for the gameplay. What the player can't see he can't see, and it can actually cause problems too (monster stops attacking and moving) when a player goes out of viewrange but the control is not passed by your server. I've seen this happen in multilple servers where it was also frequently abused as a glitch.

The way the control thing works is the first client available (or remain in the map) receives control of the mobs, and they then send packets back to update the position with the server. The server then also sends those to the other clients.

About your specific issue with encryption breaking, do you have thread safety for your iv updates? If you don't it's possible that it breaks because the client sends a large amount of movement packets with other stuff going on as well, I've had this issue one time too and it was resolved by simply adding a lock.

[zkowie]

Thanks for the explanation. I do agree that it seems like a lock problem, but I just checked the order of ins/outs (the update iv function should be the problem) and it's always a 1:1 correlation - as I am using a lock. Any other ideas on fixing the encryption breaking? It definately has something to do with a shitton of packets being sent - as suddenly it breaks. Maybe my server isn't as reliable in terms of receiving packets.

[SYJourney]

Thanks for the explanation. I do agree that it seems like a lock problem, but I just checked the order of ins/outs (the update iv function should be the problem) and it's always a 1:1 correlation - as I am using a lock. Any other ideas on fixing the encryption breaking? It definately has something to do with a shitton of packets being sent - as suddenly it breaks. Maybe my server isn't as reliable in terms of receiving packets.

The only other thing I could think of is that your server has some upper limit for how many packets at once it can process. Not a hardcoded one but one that results from the way you process them. You should make sure that when you receive multiple packets in an instant, they don't all get processed as one or else decryption will fail too.

[zkowie]

Do the packets need to be processed in the exact order it was sent? That's impossible to know from a server-standpoint. TCP isn't really reliable in that way, is it? As far as I can tell, I'm getting all the packets expected, and responding in the right order.

[ExtremeDevilz]

maple decrypt packets in 1460 bytes to work around its limitation.

[zkowie]

Understood the error - all of a sudden I was getting 5-6 packets at once, so I had to manually split them up based on the headers. Thanks for the help guys.