A sample file, core.ini.sample, comes with the GPL 1.1 and 1.2 patches. This is a sample file for documentation purposes only.
Many people try to implement core.ini features, such as Force Feedback or memory allocation for large replays, using this sample file. However, this will not work unless you rename core.ini.sample!
GPL looks for a file called core.ini. The sample file which comes with GPL is called core.ini.sample. GPL will not see this file. If you wish to use sample file for your core.ini settings, you must to rename core.ini.sample to core.ini.
Unless you've set your Windows Explorer options to always show
extensions, core.ini.sample will
show up in Explorer as core.ini
but
under Type it will be listed as a SAMPLE file. If it's
named correctly so that GPL will seei it, it will show up under
Type as Configuration Settings.
You can change your Win98 Windows Explorer options to always show extensions by opening a Windows Explorer window and clicking on View, then Folder Options. Then click on the View tab and uncheck "Hide file extensions for known file types".
8/9/98 - GPL reads several initialization files at startup. One of these, core.ini, can be used to set certain parameters. core.ini is read automatically; you don't need to include any parameters in the shortcut to make GPL read it.
Note: if you'd like to experiment with core.ini values, please download a zip file containing a collection of core.ini files, and read the section below about matching packet sizes.
Here is an example, followed by notes on some of the parameters:
[ Profile ] FrameRateDisplay = 0 ; Show_Times = 0 ; this may not be available in the final version [ Rasterizer ] fullScreen = 1 ; run Full Screen? [ Communications ] bcast_ping_port = 0 ; Ping port number (0=default) bcast_port = 0 ; Broadcast port number (0=default) bcast_recv_disable = 0 ; Disable broadcast reception bcast_send_disable = 0 ; Disable sending broadcasts disable_ipx = 0 ; Disable IPX support disable_network = 0 ; Disable network support disable_tcp_ip = 0 ; Disable TCP/IP support ip_addr_lookup_timeout = 2 ; Timeout to find own IP address log_server_connect_status = 0 ; Issue messages as clients connect mem_client_send_every = 1 ; Client packet freq via memory mem_client_send_size = 276 ; Client packet size via memory mem_server_send_every = 1 ; Server packet freq via memory mem_server_send_size = 516 ; Server packet size via memory net_lan_client_send_every = 2 ; Client packet freq on LAN net_lan_client_send_size = 132 ; Client packet size on LAN net_lan_server_send_every = 2 ; Server packet freq on LAN net_lan_server_send_size = 388 ; Server packet size on LAN net_mdm_client_send_every = 2 ; Client packet freq on dialup net_mdm_client_send_size = 84 ; Client packet size on dialup net_mdm_server_send_every = 2 ; Server packet freq on dialup net_mdm_server_send_size = 84 ; Server packet size on dialup net_server_port = 0 ; Server port number (0 = default)
The values in the example above are the default values used if no core.ini is present, or the parameter is not included in core.ini. Note that this example applies to the Alpha 3 build; the contents of core.ini in the final version may differ.
Below are discussions of some of these parameters and how changes in their values might impact GPL's behavior.
I believe this determines whether chat messages signal the connection and disconnection of clients. I suggest setting this to 1 if playing over the Internet.
This might be used during offline experiments to look for roughly appropriate values for the client and server send sizes during online play. Randy Cassidy says:
"One interesting way to diddle with bandwidth parameters and see how it might affect on-line play is to change the mem_[client|server] values, and play a single player game with lots of AI cars. Changing these values will change the bandwidth of our shared memory communications device - which is used to connect the local client to the server (like I've said, to GPL, a single player game is just a pathalogical multiplayer game where only one person connects). Of course changing the bandwidth only approximates on-line play, since it only changes the bandwidth, and not the latency or quality of the connection."
Randy says,
"The net_mdm_[client|server]_send* parameters are the ones that govern our bandwidth usage of a network connection that we believe is a dialup. The net_lan_[client|server]_send* parameters govern all other net connections (I believe cable modems fall into this category)."
These parameters control how often packets are sent. The unit is ticks, and GPL does 36 ticks per second. The default value of two means that GPL will send a packet to the serial port every 18th of a second. We've found that with more than two clients, the serial port is overwhelmed, and by increasing this value to 3, an additional client could be accomodated.
It's possible that more clients could be accomodated by further increasing this value, but because less data is getting sent, positional quality degrades. This shows up as noticeably increased warping.
It is necessary to adjust these values before hosting (and probably joining) over a cable modem. GPL cannot tell the difference between a LAN and a cable modem connection to the Internet; if it sees a dialup connection, it assumes it's on an analog modem, but otherwise assumes it's on a LAN. The large packet size appropriate for high throughput appropriate for a LAN may be excessive for the bandwidth available over the Internet. Despite the rapid transmission through the cable modem, too much data may be lost during the initial handshake and GPL may time out out before the client ever joins.
Also, crucially, the packets sent by any given GPL machine must not exceed the size expected by another GPL machine which wishes to connect. See Matching packet sizes, below.
LAN/cable modem packet size is calculated from these values the same way as it is for modems (see below). We will need to find an appropriate value for Internet play during empirical testing. Probably the best way to do this would be to start at 84 (the default value for modem connections) and decrease it until positional quality degrades (i.e. there begins to be significant warping).
If all players in a race are running over cable modems, it might make sense to increase the value until connections become difficult to establish or get dropped frequently.
Matching packet sizes. I believe that it's necessary for net_lan_server_send_size to be no larger than the value used for net_mdm_client_send_size, assuming the machine on the cable modem is hosting and the client(s) is/are on analog modems.
The issue is that any given machine, client or server, must not receive packets larger than the size it expects to receive, as specified in the appropriate parameters from its point of view. If oversized packets arrive, the connection will never be established because essential data will be rejected.
The simplest approach, and probably the most reliable, would be to have everyone use the same values as the host, for all net_lan*send_size and net_mdm*send_size parameters.
Adjusting these will hopefully allow more than two players to race successfully over a modem connection to the host without suffering disconnects due to insufficient bandwidth.
Randy says:
"These parameters allow you to reduce the bandwidth of a dialup connection. N = 4+n*16. Currently, the value is 84 (4+5*16).
"It's not strictly necessary that the number be 4+n*16. Most packets are composed of a 4 byte header, and N "chunks" of 16 bytes. If the packet size is M, then we can fit trunc((M-4)/16) chunks into the packet. Only packets that contain ARQ may fill out the packet to M bytes."
The default value is 84, and it makes sense to try smaller values, such as 68 and 52, which might reduce the bandwidth sufficiently to allow more players to race, without sacrificing so much positional information so as to induce excessive warping.
Matching packet sizes. Note that, as mentioned above, any given machine, client or server, must not receive packets larger than the size it expects to receive, as specified in the appropriate parameters from its point of view. If oversized packets arrive, the connection will never be established because essential data will be rejected.
The best way to address this is probably to have all clients and the host use the same value for both net_mdm_client_send_size and net_mdm_server_send_size. Anyone with a cable modem should use the same value in net_lan_client_send_size and net_lan_server_send_size as well.