Few questions about pawn.raknet HOT 5 CLOSED

"Why you aren't releasing this on SA:MP forums ?"

It was and it has been removed, I remember clearly for that.

from pawn.raknet.

2. Returning 0 in callback would drop the packet, so kick is not necessary. (or even better, you can overwrite the invalid value with a valid one)
3. I think you didn't understand quite well how those callbacks work.
   OnServerSendPacket/RPC is called right before server sends a packet or RPC to client(s).
   OnPlayerReceivedPacket/RPC is called right before server processes a packet or RPC received from a client.

How can I actually get the playerid this packet is coming from ?
Packets and RPCs are not sent from client to client. Here is a brief explanation of how communication works:

• client sends a packet to the server;
• server receives it;
• server validates some data and then updates its internal structures acording to the packet received;
  And after a while, when current tick = update tick, server broadcasts data read from memory to clients.
  This broadcasted packet might or might not contain invalid data.

4. You could check when the last update was received from that player. If time difference between last update and current time is greater than 2000ms, then the player is either experiencing heavy lag, either he crashed.

from pawn.raknet.

1. @kurta999 I don't see any reason why they would remove something like this. It is only allowing us to handle all packets/RPCs.

2. @spmn Well, that wasn't what I asked, but you explained me this at the point 3. Anyway, I didn't know that returning 0 in those "Received" callbacks would drop the packet/RPC, thanks. I saw it now.

3. So:

• a client sends a packet/RPC to the server;
• the server receives it and calls OnPlayerReceivedPacket/RPC with sender's player_id;
• server is sending that BitStream to other clients and it calls OnServerSendPacket/RPC, but callback's player_id parameter will have the value of receiver's player ID, right ? I don't think you understood my question exactly or I didn't understand mostly of what you said (well, I think I did). So, in OnServerSendPacket/RPC player_id will have the value of the RECEIVER, but how I can also get the player_id of the SENDER (the guy that initially sent the packet/RPC to server) ? I think that it is possible, as the receiver client knows to which character to apply that BitStream received from the server (this is what I can't understand about this, the receiver client knows from the server what character/player sent him that information, and the receiver client will apply that information to the sender character/player). Is the sender_id actually placed somewhere in every packet/RPC, so we need to know the structure of each packet/RPC to get the initial sender in OnServerSendPacket/RPC ? This is needed to track those received packets/RPC by clients, from point 4.

4. This idea is pretty fine I guess, unless there are lots of packets/RPCs sent/received, which I think they are.

About that naming, I think that something like OnServerReceivedPacket/RPC( sender_id, ... ) instead of OnPlayerReceivedPacket would be better now that I think I understood mostly of what spmn explained. Also, OnServerSendPacket/RPC should also contain the sender_id, if possible, see the questions above, at point 3.

This thing needs some proper documentation, it can be really useful if more things would be explained.

from pawn.raknet.

@IstuntmanI
2. It also works at send callbacks.
3. Almost all SA-MP server->client update packets have the following structure: 1BYTE=packetid + 1WORD=playerid to apply the data to(most likely the initial sender of the packet) + x BYTES=update itself
So, the 'sender_id' has to be read from bitstream.

Indeed, the callback naming is a bit confusing.

OnServerSendPacket/RPC can't have a sender_id, because the sender, as the callback name implies, is ALWAYS the server. However, some sent packets (update ones) contain data received from other clients.

About documentation, I think it is not the case here. This plugin just enables scripters access to a few raknet functions, and these functions are documented very well on raknet website.
For more information about the actual packet structure, you can take a look at RakSAMP, sobeit, YSF, SKY, SA-MP 0.2.5/x leak and VC-MP 0.1. (all these projects got their code available on the internet)

from pawn.raknet.

Aw, so it is like I thought: the sender_id is in bitstream (well, when the case needs it).

OnServerSendPacket/RPC can't have a sender_id, because the sender, as the callback name implies, is ALWAYS the server.

I know, I understood that, sender_id should be the initial packet/RPC sender, which sent it to the server. So the callback can't have that parameter because packets/RPCs don't always contain the sender_id.

I know where I can see things about it, but it is pretty complex, I need to check lots of files only for one of those projects, I tried to check YSF to get some ideas about it, but I didn't understand too much (I remember that I saw something about the sender id written in some packets).

Yeah, you are right, if a documentation would be made, it would need to explain the whole RakNet.

Thanks, @spmn !

from pawn.raknet.