Some useful (and not so useful) console commands I tested

Black Mamba · 2018-10-17 06:28:53

I have been trying out some unused game commands for a while. According to 4cShy, a well known AI scripter for BF1942 who is no longer active, there are a bunch of unused console commands, possibly hundreds of them, which we don't know about and that do pretty cool things, as I discovered myself. This is a quote from 4cShy, found on his website, http://www.velotech.net/battlefield/index.php:

4cShy wrote:

I'm still exploring thru the commands. I've found many that provide very useful information. Out of the almost 2000 commands available to the game engine, a little over 500 are actually used in creating maps and mods. I've compiled a List Of BF Commands using the debugger for those who would like to take a look at them. Almost 3/4 of these commands are used to develop and debug maps. You can use the debugger to find out more about them.

Here are some of the game and console commands which I have recently tried.

1) A "ping graph" command

Name: console.showNetGraph 1 (uses 0 or 1 as the argument, boolean)
This command creates a series of graphs that allows players to see how their ping fluctuates with time. It works only on Internet servers. Using this command on a local server produces no graph. It's a fun command to use to see how your ping varies in different servers. Unfortunately, there is no way to change the location of the graphs on your screen. Perhaps by editing the EXE it could be accomplished. The red and blue graphs display the variation of your ping over time, I am not sure what the other graphs do. The advantage of using this command is that you don't always need to press Tab to see how your ping changes in a game server, you can see it right in front of you. I would recommend using this command when you spectate/are not active in game because the information displayed by the graphs hides certain portions of your HUD.

2) A "FPS graph" command

Name: console.drawFPSGraph 1 (uses 0 or 1 as the argument, boolean)
This command creates a red graph that shows the variation of your FPS (frames per second) over time. It's a visual command that you can use to see how your FPS fluctuates over time. To use this command, you must first enter console.showFPS 1 into your console or it will not work. The command works in local and Internet servers.

Here is where this command can be useful. On the map Kharden Khaos, the FPS has a tendency to fluctuate a lot. This is confirmed by the following graph:

You can see the spikes in the FPS, caused by too many buildings on the map.

There are also a bunch of commands which I have tested that do not seem to do anything. The first is a command called "game.useAutoPingAdjust 1". It is not used in any game file and I have no idea what it does, although I suspect it is a command that is used on Internet servers. I have tested the command by adding it to my serverautoexec.con file, but it does nothing. Adding it to a CON file inside a map folder also does nothing. The BF1942 debugger accepts the command but produces nothing out of it (nothing happens). If someone knows what this command does or how it is used, please let me know.

The second command, which looks more adapted to Internet server game clients, is called "game.packetDropRatio x", where x is a float value that goes between 0 and 1. I guess that this command is only useful for players that experience packet loss while playing in their favorite servers. Since I do not have this problem, I do not need to use the command. I have nonetheless tested it on a game server (HOKKAIDO JPN#2) gives me 100% packet loss while using the ping command in a command prompt. The command does not seem to change anything, or the change I have seen is very minimal, or could be due to a coincidence. I am not sure what this command is for or how it is used. If anyone knows anything about it, please let me know.

Please use this thread as a place to discuss these unused commands and see if there are more commands out there that haven't been used and that could have some sort of used, especially to solve ping issues.

Last edited by Black Mamba (2018-10-17 06:34:22)

Trench · 2018-10-17 21:07:46

Black Mamba wrote:

The first is a command called "game.useAutoPingAdjust 1". It is not used in any game file and I have no idea what it does, although I suspect it is a command that is used on Internet servers. I have tested the command by adding it to my serverautoexec.con file, but it does nothing. Adding it to a CON file inside a map folder also does nothing. The BF1942 debugger accepts the command but produces nothing out of it (nothing happens).

What comes to mind for me with this is that "game.useAutoPingAdjust 1" is probably already the default. Meaning its something the game is doing for network play, but as a debugging option there was a way to "turn it off" and see what would happen without the prediction / compensation / whatever the hell its doing. So maybe "0" is the way to "see something different", not that this implies anything about whether the difference will be substantial enough to notice.

Black Mamba wrote:

Since I do not have this problem, I do not need to use the command. I have nonetheless tested it on a game server (HOKKAIDO JPN#2) gives me 100% packet loss while using the ping command in a command prompt.

For what it's worth, 100% packet loss using the PING command just means the server does not respond to ICMP Echo requests, and/or that one or more routers between you and that server do not forward ICMP Echo requests. You might very well have 0% packet loss on that server for the actual game traffic; PING can only show what happens when trying to reach that server over ICMP. So just another valid reason for "I didn't see a difference", because you may very well have 0% packet loss to that server for the actual game traffic this setting is concerned with.

Black Mamba · 2018-10-17 23:17:53

Trench wrote:

What comes to mind for me with this is that "game.useAutoPingAdjust 1" is probably already the default. Meaning its something the game is doing for network play, but as a debugging option there was a way to "turn it off" and see what would happen without the prediction / compensation / whatever the hell its doing. So maybe "0" is the way to "see something different", not that this implies anything about whether the difference will be substantial enough to notice.

My question is what evidence do we have from the game files that the command is already turned on by default, if it does not exist anywhere? From the tests I have done, I have seen only a very small difference in how my ping varied over time. When it is on, my ping (I use Wi-Fi) seemed to stay at the same number for maybe 10-15 seconds; when the command was off, my ping was fluctuating a bit more frequently, but again, it could have been caused by other factors. As you already mentionned, the difference, if there is one, is minimal.

What are your thoughts on the game.packetDropRatio command? Any idea on how is should be used? Is it a command that should be used server-side, or client side?

Last edited by Black Mamba (2018-10-17 23:18:25)

bud · 2018-10-17 23:27:26

Trench wrote:

is probably already the default. Meaning its something the game is doing for network play

Its a bit of a headwrap, but as you where on to its basically for smoothing between client/server (if i understand this right)

useAutoPingAdjust has the ClientConnection class analyze latency every 8 ticks. It uses it to program NetworkManager's interpolationTime and extrapolationTime. interpolationTime and extrapolationTime are basically globals, so applies to all connections and are used in the predict function of several Networkables

Black Mamba · 2018-10-17 23:49:07

bud wrote:

Trench wrote:
is probably already the default. Meaning its something the game is doing for network play
Its a bit of a headwrap, but as you where on to its basically for smoothing between client/server (if i understand this right)
useAutoPingAdjust has the ClientConnection class analyze latency every 8 ticks. It uses it to program NetworkManager's interpolationTime and extrapolationTime. interpolationTime and extrapolationTime are basically globals, so applies to all connections and are used in the predict function of several Networkables

Thanks for the info. Any idea on where this command goes?

Arkos · 2018-10-18 00:37:46

...

Could it be, those commands would work, if they would be active on the server and client?

...

Trench · 2018-10-18 07:00:55

Black Mamba wrote:

My question is what evidence do we have from the game files that the command is already turned on by default, if it does not exist anywhere?

Without any configuration present, there is still a default state in the code itself. In absence of any configuration, the behavior is either on by default, or is off by default. There is no basis to assume "everything will have been written to be off until turned on." Some things will be on unless turned off.

Based on the great additional info Bud was able to provide, this one sounds like a server-side configuration since its "a global affecting all client connections."

Black Mamba · 2018-10-18 18:30:28

Trench wrote:

Black Mamba wrote:
My question is what evidence do we have from the game files that the command is already turned on by default, if it does not exist anywhere?
Without any configuration present, there is still a default state in the code itself. In absence of any configuration, the behavior is either on by default, or is off by default. There is no basis to assume "everything will have been written to be off until turned on." Some things will be on unless turned off.
Based on the great additional info Bud was able to provide, this one sounds like a server-side configuration since its "a global affecting all client connections."

So placing this command in the serverautoexec.con file of my server should be the right thing to do?

What I will do is test both states of the command (0/1) and use the showNetGraph 1 command over a period of 10 minutes to see if the difference between both states of the command can be detected.

Arkos · 2018-10-18 21:16:09

...

"Console.ShowNetGraph 1" on Simple

And what does it mean now? What i can say, it was very spongy and switching the view while flying had massive delay. Some bombs were falling through a tank and didn't explode.

...

Last edited by Arkos (2018-10-18 21:18:18)

Black Mamba · 2018-10-18 23:36:12

Your bottom graph has three different colors, I wonder why. Not sure which graph actually produces the results we want.

Btw, what are the red lines at the top left corner of your screen?

Arkos · 2018-10-18 23:49:36

...

In my opinion those are jitters, which produces this spongy gameplay and 20-30 bullet/no hits effect.

...

ABAS · 2018-10-19 19:48:27

Those game. Commands do not works it says unauthorizrd method

Black Mamba · 2018-10-19 20:14:13

ABAS wrote:

Those game. Commands do not works it says unauthorizrd method

Which commands give you that error?

Insane · 2018-10-20 11:25:02

For "game.useAutoPingAdjust 1" and "game.packetDropRatio x" the game responds with "unauthorised method".
The command "console.drawFPSGraph 1" has no effect.

Black Mamba · 2018-10-20 16:35:22

Insane wrote:

For "game.useAutoPingAdjust 1" and "game.packetDropRatio x" the game responds with "unauthorised method".
The command "console.drawFPSGraph 1" has no effect.

console.drawFPSGraph 1 only works if you type console.showFPS 1 before in the console, as I mentionned in my first post. The other commands are trickier to use and I’m still trying to figure out how to make them work. All I know is they cannot be typed in the console directly, but run from a separate CON file client side.

Arkos · 2018-10-20 17:03:26

...

Run from a separat con file?

...

Insane · 2018-10-20 20:47:40

Here is my "Console.ShowNetGraph 1" result on Stalingrad on Simple

Black Mamba · 2018-10-20 20:54:38

Insane wrote:

Here is my "Console.ShowNetGraph 1" result on Stalingrad on Simple
https://preview.ibb.co/dqUy6L/Screen-Shot40.jpg

Looking at the graph, your ping looks like it is pretty stable. Is is actually stable when you play online?

Insane · 2018-10-22 13:03:35

Black Mamba wrote:

Insane wrote:
Here is my "Console.ShowNetGraph 1" result on Stalingrad on Simple
https://preview.ibb.co/dqUy6L/Screen-Shot40.jpg
Looking at the graph, your ping looks like it is pretty stable. Is is actually stable when you play online?

Not really, but I believe the problem is in my provider and wi-fi, not the server.

Black Mamba · 2018-11-06 01:03:27

I stumbled across some interesting commands while looking at 4CentsShy's website. These commands are:

game.joinServer string bool AND game.connectToServer string string. Any idea on what the arguments are? I imagine you need to enter the hostname/IP address as one of the arguments in the first command, but everything I tried so far failed.

Russ · 2018-11-06 09:45:32

game.packetDropRatio is only for debug. It randomly drops a percentage of outgoing packets which is almost never what you want.

Russ · 2018-11-06 09:52:09

Black Mamba wrote:

I stumbled across some interesting commands while looking at 4CentsShy's website. These commands are:
game.joinServer string bool AND game.connectToServer string string. Any idea on what the arguments are? I imagine you need to enter the hostname/IP address as one of the arguments in the first command, but everything I tried so far failed.

game.joinServer <host> <isInternet>

Not sure what the two arguments on connectToServer are. You'd probably just have to experiment. Pretty sure game.joinServer only works on startup, but game.connectToServer works anytime.

Black Mamba · 2018-11-06 15:45:49

Russ wrote:

Black Mamba wrote:
I stumbled across some interesting commands while looking at 4CentsShy's website. These commands are:
game.joinServer string bool AND game.connectToServer string string. Any idea on what the arguments are? I imagine you need to enter the hostname/IP address as one of the arguments in the first command, but everything I tried so far failed.
game.joinServer <host> <isInternet>
Not sure what the two arguments on connectToServer are. You'd probably just have to experiment. Pretty sure game.joinServer only works on startup, but game.connectToServer works anytime.

I tried setting a known IP address as the host (with port) but it didn’t seem to work, maybe it only accepts the name of the domain like team-SiMPLE.fr?

Black Mamba · 2018-11-09 19:00:24

Trench wrote:

Black Mamba wrote:
The first is a command called "game.useAutoPingAdjust 1". It is not used in any game file and I have no idea what it does, although I suspect it is a command that is used on Internet servers. I have tested the command by adding it to my serverautoexec.con file, but it does nothing. Adding it to a CON file inside a map folder also does nothing. The BF1942 debugger accepts the command but produces nothing out of it (nothing happens).
What comes to mind for me with this is that "game.useAutoPingAdjust 1" is probably already the default. Meaning its something the game is doing for network play, but as a debugging option there was a way to "turn it off" and see what would happen without the prediction / compensation / whatever the hell its doing. So maybe "0" is the way to "see something different", not that this implies anything about whether the difference will be substantial enough to notice.
Black Mamba wrote:
Since I do not have this problem, I do not need to use the command. I have nonetheless tested it on a game server (HOKKAIDO JPN#2) gives me 100% packet loss while using the ping command in a command prompt.
For what it's worth, 100% packet loss using the PING command just means the server does not respond to ICMP Echo requests, and/or that one or more routers between you and that server do not forward ICMP Echo requests. You might very well have 0% packet loss on that server for the actual game traffic; PING can only show what happens when trying to reach that server over ICMP. So just another valid reason for "I didn't see a difference", because you may very well have 0% packet loss to that server for the actual game traffic this setting is concerned with.

I can confirm that game.useAutoPingAdjust is already set to 1 by default. Turning it off creates huge amounts of lag, no matter what values you set for the game.interpolation/extrapolation values. Not so sure what these two commands do by the way.

Black Mamba · 2018-12-02 03:21:35

Does anyone know what game.numDeltasPerBaseLine do and what the default value for it is? Seems to be a server-side command by the looks of it. It accepts uint as the argument (any integer bigger than 0) if that's of any help.

Last edited by Black Mamba (2018-12-02 03:22:24)

Arkos · 2018-12-02 11:52:51

...

Nope, the only thing i found is http://www.battlefieldsingleplayer.info … egory=game

...

bud · 2018-12-02 18:49:43

Black Mamba wrote:

and what the default value for it is?

5

ziba128 · 2018-12-02 21:37:16

Black Mamba wrote:

Does anyone know what game.numDeltasPerBaseLine do and what the default value for it is? Seems to be a server-side command by the looks of it. It accepts uint as the argument (any integer bigger than 0) if that's of any help.

Probably this

First person shooters often implement delta compression by compressing the entire state of the world relative to a previous state. In this technique, a previous complete world state or ‘snapshot’ acts as the baseline, and a set of differences, or delta, between the baseline and the current snapshot is generated and sent down to the client.
This technique is (relatively) easy to implement because the state for all objects are included in each snapshot, thus all the server needs to do is track the most recent snapshot received by each client, and generate deltas from that snapshot to the current.

https://gafferongames.com/post/networke … l_reality/

Black Mamba · 2018-12-03 04:48:01

ziba128 wrote:

Black Mamba wrote:
Does anyone know what game.numDeltasPerBaseLine do and what the default value for it is? Seems to be a server-side command by the looks of it. It accepts uint as the argument (any integer bigger than 0) if that's of any help.
Probably this
First person shooters often implement delta compression by compressing the entire state of the world relative to a previous state. In this technique, a previous complete world state or ‘snapshot’ acts as the baseline, and a set of differences, or delta, between the baseline and the current snapshot is generated and sent down to the client.
This technique is (relatively) easy to implement because the state for all objects are included in each snapshot, thus all the server needs to do is track the most recent snapshot received by each client, and generate deltas from that snapshot to the current.
https://gafferongames.com/post/networke … l_reality/

Nice link, I read a bit of it and it said in one of the paragraphs that the number of deltas can be -1, +2 or +5. Will do some testing to see what happens.

Black Mamba · 2018-12-13 06:13:40

So I tested the game.numDeltasPerBaseLine command, and to my surprise setting different values to it server side actually makes a difference. It seems the most stable value is 2, with 1 causing slight lag. Setting the number to anything higher than 2 caused significant lag, and the most lag was caused by setting the command to a value of 8. Is 5 really the default value? I set it to that to test it out, and it was pretty laggy on my end. Not too sure what this command does.

SiMPLE | Forum

Announcement

#1 2018-10-17 06:28:53

Some useful (and not so useful) console commands I tested

#2 2018-10-17 21:07:46

Re: Some useful (and not so useful) console commands I tested

#3 2018-10-17 23:17:53

Re: Some useful (and not so useful) console commands I tested

#4 2018-10-17 23:27:26

Re: Some useful (and not so useful) console commands I tested

#5 2018-10-17 23:49:07

Re: Some useful (and not so useful) console commands I tested

#6 2018-10-18 00:37:46

Re: Some useful (and not so useful) console commands I tested

#7 2018-10-18 07:00:55

Re: Some useful (and not so useful) console commands I tested

#8 2018-10-18 18:30:28

Re: Some useful (and not so useful) console commands I tested

#9 2018-10-18 21:16:09

Re: Some useful (and not so useful) console commands I tested

#10 2018-10-18 23:36:12

Re: Some useful (and not so useful) console commands I tested

#11 2018-10-18 23:49:36

Re: Some useful (and not so useful) console commands I tested

#12 2018-10-19 19:48:27

Re: Some useful (and not so useful) console commands I tested

#13 2018-10-19 20:14:13

Re: Some useful (and not so useful) console commands I tested

#14 2018-10-20 11:25:02

Re: Some useful (and not so useful) console commands I tested

#15 2018-10-20 16:35:22

Re: Some useful (and not so useful) console commands I tested

#16 2018-10-20 17:03:26

Re: Some useful (and not so useful) console commands I tested

#17 2018-10-20 20:47:40

Re: Some useful (and not so useful) console commands I tested

#18 2018-10-20 20:54:38

Re: Some useful (and not so useful) console commands I tested

#19 2018-10-22 13:03:35

Re: Some useful (and not so useful) console commands I tested

#20 2018-11-06 01:03:27

Re: Some useful (and not so useful) console commands I tested

#21 2018-11-06 09:45:32

Re: Some useful (and not so useful) console commands I tested

#22 2018-11-06 09:52:09

Re: Some useful (and not so useful) console commands I tested

#23 2018-11-06 15:45:49

Re: Some useful (and not so useful) console commands I tested

#24 2018-11-09 19:00:24

Re: Some useful (and not so useful) console commands I tested

#25 2018-12-02 03:21:35

Re: Some useful (and not so useful) console commands I tested

#26 2018-12-02 11:52:51

Re: Some useful (and not so useful) console commands I tested

#27 2018-12-02 18:49:43

Re: Some useful (and not so useful) console commands I tested

#28 2018-12-02 21:37:16

Re: Some useful (and not so useful) console commands I tested

#29 2018-12-03 04:48:01

Re: Some useful (and not so useful) console commands I tested

#30 2018-12-13 06:13:40

Re: Some useful (and not so useful) console commands I tested

Board footer