F1 Challenge 99-02 Online Multiplayer Guide
One of the most important aspects in F1 Challenge (F1C) that has been almost completely overhauled from F12K2 is the multiplayer code. In this short guide I would like to first describe the major differences between F12K2 and F1C netcode. I will then go over the multiplayer parameters in the plr file, explain what they mean and how to set them in order to unleash the full potential of F1C's new netcode. The main weakness of F12K2 netcode is the inefficient bandwidth usage of the server (the upload speed of the server). For example, at a data rate of 12, a single player requires ~10Kbps (Kbit per second). If we run a session with 4 clients the server will send ~40Kbps (4*10) to each client. Hence, for a session of 4 clients at a data rate of 12 the server will send ~160Kbps (4x40). In general, the required bandwidth for a session is equal to the number of players squared multiplied by the bandwidth of a single client (10Kbps in our example). You can now see how quickly bandwidth runs out as the number of clients' increases. For example 4 clients requires ~160Kbps, if we now add 1 more client, we will need 250Kbps (5x5x10). If we double the amount of clients from 4 to 8 the needed bandwidth will jump from 160Kbps to 640Kbps!! The second main problem in F12K2 netcode occurs when the load of the server exceeds its bandwidth. For example, when a server that has a 500Kbps upload speed host a session with 8 clients which require 640Kbps (at a data rate of 12). As a result, the whole session explodes, i.e. all the cars will badly warp and quality will drop significantly. With the introduction of the throttling code in F1C, all of these problems are now in the past. The throttling code introduces a significant leap forward to the multiplayer experience, as it is much more advanced and smarterthan F12K2 code in many aspects. Among many improvements here are the most significant ones: a) The session will never explodethe code will always use the bandwidth available to the server and divide it into the clients. If there is not enough bandwidth to accommodate all of the clients at the defined data rate, the code will throttle down the data rate and reduce packet size to a value that is manageable by the server. In addition, if a client does not have enough bandwidth, the server will throttle down the amount of data sent to this particular client. This will enable players with sub-broadband connection to participate in larger sessions. b) Efficient bandwidth management - there is really no need to render all of the cars at the same data rate (like in F12K2). For example, if there are 4 cars running on the other side of the track that you can't even see, F12K2 netcode will still render them at the full data rate taking away precious bandwidth for no real reason. The new code will throttle down the data rate based on the distance between your car and the remaining field. Thus, cars further away from you will be rendered at a lower data rate and therefore will consume much less bandwidth. How does all of this come to play in the real world? In our testing we were able to run a session with 10 players on a 300Kbps server with overall better quality than F12K2!! We don't think that 10 is the upper limit, but due to a limited number of available beta testers at that time, we could not try a larger number of players. Furthermore, one of the clients was on a sub 56K modem connection!! Obviously he does not have enough bandwidth to transmit and receive data at high rates but it was certainly playable. In F12K2 a client on 56K connection could only dream of participating in a 10 player session... One has to remember though, that since the session will never explodeas the number of clients increases, there is a tradeoff. The tradeoff is a reduced data rate that would be most obvious at the start of the race when the field is heavily packed. You will have to experiment and determine your personal compromise between acceptable quality and field size for your specific network performances, since quality is very subjective... The new code will also affect replay quality. As mentioned above, at the clients end, various cars will be rendered at different data rates, based on their distance to the client car. This will result in a low quality replay when watching those cars in the replay. Only the server will have the complete data for the full field and thus a high quality replay for all clients. Finally, from a bandwidth stand point I think that a full grid is at last a reality for powerful servers (T1 or even some more powerful ADSL servers). In my opinion, the current limiting factor for a session size is frame rate both at the clients and especially at the server end. You really want to make sure that at any given time frame rate will not drop below 30, as this will cause glitches in the session quality. Based on your computer system strength, you will have to adjust (if at all) your graphic settings accordingly so that frame rate will always remain above 30. I think a good idea would be to create 2 player profiles one for offline and one for online with a reduced graphic setting (if needed). The plr file multiplayer options parameters The new throttling netcode comes with several new parameters under the Multiplayer Options section in the plr file. Let's go over the important ones:
Extra goodies Cheating in multiplayer This area has been significantly improved in F1C. First, each time you hope into your car, the game checks and verifies that the relevant files (*.exe, terrain.ini and HDV) are authentic. If the game detects that a player modified one of those files, a mismatch error message will be sent to the server as well as to the rest of the players. Further, the game will always compare those crucial files to those found on the server. This will finally solve problems most online leagues encounter. Let me explain: many online leagues dictate single car physics for all cars or allow each player to choose any car physics (*.hdv file) as long as it is from the 11 authentic teams. As a result, in F12K2 each time those players joined a race the server showed a mismatch error, and it was impossible to verify if their hdv file is genuine. In F1C, if the server has the hdv file that the player is supposed to have (for example the server will have the Williams hdv file as well as the engine file * ) there will be no mismatch error. This applies also to other files such as the terrain.ini file if a group of drivers wish to play with pre-determined modified parameters they can now enforce that only those changes will be used. Again, if the server's modified terrain.ini file matches those of the players no mismatch error! This will be particularly useful for finally having cheating free online races with various mods! * In F1C, to drive a car with a different physics (for example: a Minardi with the Williams physics) one has to copy the engine file from the Williams to the Minardi folder in addition to the *.hdv file. Name tags and latency If you hit the tab key (you can assign any key you wish including buttons on your controller), each car will be shown with the player name and the latency between you and this particular player. Unfortunately, enabling this mode has a serious impact on frame rate when there are large amount of players in the session. When a player experiences serious packet loss a blinking disconnected symbol will appear above his car indicating that there is currently a problem with his connection. This is an extremely useful feature that helps identify the source of the problem when experiencing warping. Password protected session You can now create a password protected game which will be announced on GameSpy, but only those who have the password can join your session. There is no need to share your IP address and remember IP's in order to join private games! To create a password protected session click on the blank area under the game name entry, and type the password in the new text entry area (as shown in the screenshot below). Formation and reconnaissance lap Yes - we now have it fully functional in multiplayer!! (formation lap is now functional in offline races) To enable it make sure you have the following entries in your plr file: MULTI Reconnaissance="1" and MULTI Formation Lap="1" . You also need to set the following parameters to your liking: Recon Pit Open="300.00000" , Recon Pit Closed="150.00000" and Recon Timer="1" . These values are well explained in the plr file. This is how it works: When you move to the race session, you will start from your pit stall. You can go out and drive around the track, but remember: don't cross the start/finish line since the pit-girls are on the track as well as other cars that may be waiting on their grid position. To run another lap you must drive through the pits. Remember to leave the pits before they are closed, and park your car in the appropriate grid position (based on your qualification). A pit girl holding a flag with your car number and your national flag will help you identify your position. You will then get a message to start the formation lap. After you complete the formation lap park your car in your grid position. If your car is not properly aligned or in the wrong position you will get a message indicating so and the race will not start. Once all of the cars are aligned properly the race will start. Alternatively, if the server at any time hits the space bar the cars will be placed in their grid position and the race will start. |