Integration in CS:GO

Theoretically, this step isn't important. We can use the Gamestate Integration which are already installed if it's not used with your Hardware. However, we need the IP and Port of the integration and our Gamestate Integration has some "tuning". Just open the folder where Counter Strike: Global Offensive is installed:

...\steamapps\common\Counter-Strike Global Offensive\csgo\cfg

If you press 'G', you will jump to the first file starts with the letter 'G'. Search for files which stars with gamestate_integration_.

Now, copy your file gamestate_integration_obs.cfg into this folder and open it with Notepad or similar.

---

IP Address

We need to set the URI of this Computer which means, setting the Internal IP-Address and Port. Just open a new console (cmd) and type: ipconfig. The next step look different for everybody. Look for something which says IPv4-Address......192.168.XXX.XXX and copy it into the file. E.g. your address is 192.168.178.2, inside of the file it should be now "uri" "http://192.168.178.2:XXXXX" (Personal, I had problems writing localhost in it, so I don't recommended it. 127.0.0.1 can work, aswell if you didn't change something at hosts settings well hidden inside Windows.).

*localhost and 127.0.0.1 are the same IP, but I had problems with my script inside Node.js to get proper information.

---

Port

Next step, set the port. Feel free to use almost every port above 20000 except of other Gamestate Integration. For me 65000 was free so try it. After this step, it looks like this now: "uri" "http://192.168.178.2:65000"

Filename	URI	Port
gamestate_integration_logitech	http://127.0.0.1	5000
gamestate_integration_overwolf	http://localhost	59873
gamestate_integration_overwolf2	http://localhost	59873
gamestate_integration_steelseries	http://127.0.0.1	49791

---

Setting

At this point you are ready but there is one more thing...

Here is our "tuning" like I mention before.

Setting	Old Value	New Value	Description
timeout	5.0	2.5	Game expects an HTTP 2XX response code from its HTTP POST request, and game will not attempt submitting the next HTTP POST request while a previous request is still in flight. The game will consider the request as timed out if a response is not received within so many seconds, and will re-heartbeat next time with full state omitting any delta-computation. If the setting is not specified then default short timeout of 1.1 sec will be used. ❗ If your endpoint is never receiving JSON payload blocks named "previously" or "added" then this may be an indication that the game client is never getting HTTP 2XX response and always considers the request as failed. (Well, I try to fix this)
buffer	0.1	0.1	Because multiple game events tend to occur one after another very quickly, it is recommended to specify a non-zero buffer. When buffering is enabled, the game will collect events for so many seconds to report a bigger delta. For localhost service integration this is less of an issue and can be tuned to match the needs of the service or set to 0.0 to disable buffering completely. If the setting is not specified then default buffer of 0.1 sec will be used.
throttle	0.5	0.1	For high-traffic endpoints this setting will make the game client not send another request for at least this many seconds after receiving previous HTTP 2XX response to avoid notifying the service when game state changes too frequently. If the setting is not specified then default throttle of 1.0 sec will be used.
heartbeat	60.0	1.0	Even if no game state change occurs, this setting instructs the game to send a request so many seconds after receiving previous HTTP 2XX response. The service can be configured to consider game as offline or disconnected if it didn't get a notification for a significant period of time exceeding the heartbeat interval.
auth		StreamOBS	Both sample cfg files provided in this document contain an optional "auth" configuration section. In most localhost or even LAN integration scenarios this section can be completely omitted, but when it is present, fields in this section will be transmitted as JSON string fields to the endpoint to authenticate the payload. It is recommended for the endpoint to also use SSL to protect the in flight payload containing an authentication block.

As you can see, there are some option you can set/unset:

Setting	Description
map	map, gamemode, and current match phase ('warmup', 'intermission', 'gameover', 'live') and current score
round	round phase ('freezetime', 'over', 'live'), bomb state ('planted', 'exploded', 'defused'), and round winner (if any)
player_id	player name, clan tag, observer slot (ie key to press to observe this player) and team
player_state	player state for this current round such as health, armor, kills this round, etc.
player_match_stats	player stats this match such as kill, assists, score, deaths and MVPs
provider	general info about client being listened to: game name, appid, client steamid, etc.

You can set/unset this information by adding // in front of each line but it's not necessary.

*I need a bit time, to find every value of each setting. Very often, it transmits changes and not all information per setting. (E.g. It transmits the value of equipped value when buying things but in the same JSON, there are other information, too, which are more frequently refreshed). Asynchrony Parsing

---

And again, this one is ready, aswell.