Just improved the pcap handling a bit. It now allows the packet server itself to not use pcap itself (even if installed and loaded), instead running an internal loopback. Normally the ethernetcard setting is set to 0 for pcap card detection logging, >0 for selecting a compatible network card to use and -1 (or lower) for disabling the usage of a network card (together with the packet server) entirely.
Now the new option added is -2, where the packet server and pcap handling will be running in loopback mode. That should make it available to use without using any network card (although pcap is still loading in this case, but simply unused for any traffic).
So it's now:
-2: loopback mode packet server (pcap still loaded but not used or required).
-1: packet server disabled (and pcap not required)
0: log pcap device numbers to use
>0: specify an ethernet-compatible 10/100/1000+mB device to use
So in loopback mode, the mac address of the router used normally is replaced by the local mac address (causing everything sent by the server to also be received by the server). Since all clients receive this as normal using this way, pretty much an in-emulator local network is setup.
So computers inside said network can send packets to each other (although sending packets is never failing, receiving of packets depends on whether a client can receive the packet during the next server clock ticked (otherwise, it's discarded, just as with a normal pcap-based connection).
A nice point of being able to put the server's network into loopback mode now is that you can use it to test the server without any compatible network card (for example some/all WiFi network cards) or simply make it a local network when you don't want to or can't use the real network for it.
In my case, pcap can't use the real network card (it's a WiFi card) on one of my developing laptops, but if I can put the packet server's pcap interface into loopback mode (which it can now), the connected clients should be able to still talk to each other using the server (although the internet or any real devices can't be reached because of this). It should also suffice to be able to test the server itself in this case.
Another improvement that I've made now is that the pcap receive handler now runs inside it's own seperate thread. That allows it to much more accurately receive packets that arrive between server ticks. Although the processing and receiving of packets per tick is still limited to only 1 packet (all others are effectively discarded because the pcap interface can't receive them between ticks if the receive buffer is full and a compatible packet is received (causing the double-buffer to get completely filled, making the interface not receive anything on the pcap interface anymore until there's room).