Hi. I wonder if anyone has encountered this problem before. I've already done searches using google and of BFSP and the bfeditor forum.In Forgotten Hope when running a Coop server, even though tests show good network performance and plenty of computing power, sometimes single shot weapons will fire off a multiple salvo. I've been told this is "lag" but I don't think it is as I have eliminated any other server performance problems. The problem *never* happens in a coop game started from inside the BF2 client. It's only a server problem.I went back to running the Windows server on the same machine to rule out any problems between my Windows and Linux machine.This is the reported ping from my Windows machine to the Linux machine ...Code: [Select]michaelzfreeman@DESKTOP-QOJ2SDI:~$ ping 192.168.1.92PING 192.168.1.92 (192.168.1.92) 56(84) bytes of data.64 bytes from 192.168.1.92: icmp_seq=1 ttl=64 time=0.920 ms64 bytes from 192.168.1.92: icmp_seq=2 ttl=64 time=8.41 ms64 bytes from 192.168.1.92: icmp_seq=3 ttl=64 time=1.01 ms64 bytes from 192.168.1.92: icmp_seq=4 ttl=64 time=0.990 ms64 bytes from 192.168.1.92: icmp_seq=5 ttl=64 time=1.31 ms64 bytes from 192.168.1.92: icmp_seq=6 ttl=64 time=5.35 ms64 bytes from 192.168.1.92: icmp_seq=7 ttl=64 time=5.08 ms64 bytes from 192.168.1.92: icmp_seq=8 ttl=64 time=0.993 ms^C--- 192.168.1.92 ping statistics ---8 packets transmitted, 8 received, 0% packet loss, time 7006msrtt min/avg/max/mdev = 0.920/3.010/8.413/2.701 ms(It's using Ubuntu CLI for Windows 10 before anyone get's confused).Here's the reported ping within Windows 10, straight through it's own IP. Loop back basically.Code: [Select]michaelzfreeman@DESKTOP-QOJ2SDI:~$ ping 192.168.1.80PING 192.168.1.80 (192.168.1.80) 56(84) bytes of data.64 bytes from 192.168.1.80: icmp_seq=1 ttl=128 time=0.115 ms64 bytes from 192.168.1.80: icmp_seq=2 ttl=128 time=0.112 ms64 bytes from 192.168.1.80: icmp_seq=3 ttl=128 time=0.113 ms64 bytes from 192.168.1.80: icmp_seq=4 ttl=128 time=0.111 ms64 bytes from 192.168.1.80: icmp_seq=5 ttl=128 time=0.114 ms64 bytes from 192.168.1.80: icmp_seq=6 ttl=128 time=0.125 ms^C--- 192.168.1.80 ping statistics ---6 packets transmitted, 6 received, 0% packet loss, time 5004msrtt min/avg/max/mdev = 0.111/0.115/0.125/0.004 msAs you can see there's not inherently anything wrong with network speeds.Then I thought the server might not have enough CPU and memory as I noticed the server FPS is 33 in Linux and 35 on Windows. My Linux machine has an older Intel Quad Core Q9650 3 Ghz and 4gigs of memory which maybe could curtail server performance in some circumstances. But my Windows machine is a much more powerful i5 4690k 3.5Ghz with 8 gigs of memory so there should be no problems there, yet the effect of single shot weapons firing multiple times still happens on the Windows machine.I removed the other lagging effects I was getting by setting the server IP to the correct IP - the IP of the machine it's on. So I'm not seeing any other lagging effects now. No skooting or skating. Yet all tank guns and AT guns that have to reload after every shot still, occasionally, fire multiple times.Rifles and hand held AT guns (that also have to reload after every shot) do not do this multiple firing thing.The effect is not anything to do with a problem with unofficial maps and this kind of thing. It does it on freshly installed latest FH maps and unofficial one's.I found an article about a similar problem with another game (Minecraft) that showed a fix that was disconnecting the local LAN from the internet so the only networking going on is between machines on the LAN. That does not make any difference.The effect is also intermittent. Even though tests show networking performance and computing power is OK the game will run OK for a while with tanks and AT guns (it's *ONLY* tanks and AT guns !) but suddenly it will start again and a tank (with a single shot weapon) will fire off a 3 round salvo.I seem to remember that other mods running on my server that also have tanks that need to reload after every shot *DO NOT* do this (such as AIX), although I need to confirm that again.So any ideas ? For me the problem breaks immersion a bit in a mod that is known for its historical accuracy.