should process_packet_function receive the endpoint in its parameters?

[aghiles]

Not an issue but more of a philosophical question.

When processing a packet, it would be a normal operation to reply on the same endpoint using reliable_endpoint_send_packet. As of now we receive a <context,index> pair (btw, not sure what is the index utility).

[aghiles]

Alternatively, reliable_rendpoint_receive_packet could return 1 if it called the processing function. This allows to send a reply right there if needed. This would be ABI-compatible with the current implementation.

Just a feeling that something is lacking for a very smooth and natural operation of these functions. Basically, if some data is received, it should be super easy to send back data on the same endpoint.

[gafferongames]

The general idea is that you have the endpoint stored internally inside the context, so you can get it if needed. Usually, the endpoint is not the only thing you need, to reply right away.

Can you explain your use case more?

[gafferongames]

ps. utility of index is that it lets you support a server, with multiple data per-client, it tells you which client index this packet corresponds to.

[aghiles]

Yes I understand your point of view. I have a server with a pool of endpoints. I managed to do things a bit differently. Although I think that having a extra "local context" when calling the receing_packet would have helped me have a cleaner implementation. Not a biggie.

[gafferongames]

Yes, at this point I acknowledge it would be better to have both, it's best not to be backwards incompatible for such a small fix.

[aghiles]

I agree.