simulating packet loss that way sounds like a good idea. what are you using for your logic process loop? Im not super familiar with godot’s networking API, but i do have some experience with writing packet managers and serialisation. Are you using _process or _physics_process? or is there another update loop you use for this?
if you want to simulate a delay, lets say you were using _physics_process (since it updates at very regular intervals, about 60 times per second) you coul put your packets into one index of an array that gets read//processed per frame, resize the array to be 60 in ready(), and then every frame call push_front() on the array with your new packets (or an empty index if there are none) and use pop_back() to see if anythings come out the other end, and if a new packet comes out then send it. If the array is 60 elments long and the process tick is 60 times per second, thats emulating a second of latency between “sending” the packet, and it actually being sent. Using functions like push_front() are very inefficient though, but it doesnt sound like it matters in this case.
if youre looking to get into optimization, thinking about exactly what data it is you want to send, and how youre processing it and organizing it in your cpu is probably the way to go. are your packets being sent as objects? or are you sending packedbytearrays? if you havent learned about serialisation yet you really should. it can seem very complicated sometimes, but if youre careful about what data youre sending and how its organized its actually pretty simple and packedbytearrays are probably the most efficient data structure in godot. if you can send and receve your packets as a big single packetbyte array, or even as an array[packetbytearray], and you make whatever object that wants to send a packet serialize the packet to that format before sending it im guessing you would see some good improvements to performance (if this was not what you were already doing)
if youre set on sticking with gdscript, learning how to use multithreading could also make a significant improvement, although unlike serialization it can become very complicated if youre not careful. that being said, if you know that the steps between wanting to create a packet, and having it fully processed and sent on the network take a significant amount of processing work, breaking that process into regular chunks and having the threads hand that to one another can make a significant difference as well (as long as theyre not locked on a mutex waiting for each other. Ive done that many times before, having five threads waiting around and only getting as much work done as one). this is a great video on the subject.