Is it possible to switch NetworkedMultiplayerPeer transfer mode for specific messages?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By unlut

I am working on a simple 2D shooter game, using a client/server architecture for networking. I will mostly use TRANSFER_MODE_UNRELIABLE for game state update messages from server to clients, but I would like to send some important event messages (player joined/left game, chat messages, kill messages…) reliably. Is it okay if I change transfer mode to reliable just before these messages, and change it back to unreliable mode right after? Like this:

#  variable holding NetworkedMultiplayerPeer object
var nmpeer

func _ready():
    #
    #  initialize nmpeer ...
    #

    #  I will mostly use this mode
    nmpeer.set_transfer_mode(TRANSFER_MODE_UNRELIABLE)
    

func _physics_process(delta):
    #
    #    some code here...
    #    
    
    #    check if its time to update clients (currently happens every 2nd frame)
    if ( NeedPublish() )
         SendUpdateToClients()

    #  check if some event happened
    if ( SomethingImportantHappened() )
        #  set transfer mode to reliable
        nmpeer.set_transfer_mode(TRANSFER_MODE_RELIABLE)

        SendImportantMessage()

        #  set transfer mode back to unreliable
        nmpeer.set_transfer_mode(TRANSFER_MODE_UNRELIABLE)
  

Also there are two different methods “rpc_id” and “rpc_unreliable_id”, is the first one always reliable? If so can I use them while sending raw packets (via put_packet) without changing transfer mode?

Hope the question was clear and not too long, thank you for reading.

:bust_in_silhouette: Reply From: unlut

Just to complete this question, I found out that “send_bytes” function already has a parameter for transfer mode so my question is mostly answered.

Also upon looking source code, it seems “rpc_id” always use reliable channel, although I could not find anything in the documentation that confirms this behavior, however its unreliable counterpart is explicitly mentioned.