Hnd

very interesting point, Frag, The latest ADSL offering is PPPoE (PPP over Ethernet). From what you said that means that poorly configured ADSL (PPP MTU less than Ether frame payload, for example) should cause huge waste of bandwidth. Ie low pings, but very low actual transfer performance. That is exactly what i saw on some ADSL lines.

I am not sure about list of players (too much bandwidth + extra load on the master server) but "play time left" info will be fantastic.

I wonder if it is possible to modify the #userlist command to - indicate the id, name, ping, bandwidth and desync It will help to identify the pattern better than current 'P ' command where you have to switch between players. The session log with the same data in the external file would be even better. The test version could have a cmd line option for that with n-sec logging interval. BTW, wheeled vehicles are climbing almost vertical slopes...

That's the whole idea of NAT - all your comp has to see is the NAT firewall. Server sends packet to client saying "hi, there! join in" _without_ specifing IP address. (The source and destination IP addresses are set in the special header of the packet by the TCP stack already.) The NAT system checks header of the packet and changes server's private ip to routable public ip, then forwards it to the client. If client is behind NAT system then server really sends this packet to client's NAT. Client's NAT has to modify packet header using the translation table and only after that it can send the packet to destination. So in theory: Server -> NAT1 (Rewrite source IP) -> NAT2 (rewrite destination IP) -> Client. That is why the programm must not embed the IP (or any other routing information for that matter) into the body of the package - NAT (or any other router/firewall) cannot handle it. TCP/IP is good, isn't it?

Hey KeyCat good job! Thanks for port listing. To BIS guys: I cannot understand your attitude here: you give us a product to test and then refuse the information which is vital for testing? Very wierd...

Ports 2234-2235. TCP or UDP? Or both?

Actually the new net code is a huge improvement in this area. I am using Linux ipchains firewall and IP masquerading (NAT). On the old version i could not connect (as a client) to any outside servers without extensive port forwarding setup. The 1.55 connects just fine to Placebo's 80.4.183.106 server _without_ any explicit port forwarding. Very good. The port forwarding will be needed for server hosting (don't see how firewall would know where to send incoming connect request :-)) and it would be very nice if BIS provide the port and protocol info.

Alaska, thanks for tip but I've already tried that. Did not work. It does look like Dx8.1 is the source of problem. I'll try to downgrade to 8.0

or even better make those effects 3-D, that should solve it :-)

Have the same problem with Dx8.1 and TNT card drv v12.43 OFP v1.30. Hey BIS how about publishing recommended (or at least, tested) combinations of OS, DX, VidCard and Driver, SoundCard and Driver?