projects:iedtimer

CSGO IED Bomb Timer

User gamestate integration file:

csgo\cfg\gamestate_integration_yourservicenamehere.cfg
"Console Sample v.1"
{
 "uri" "http://127.0.0.1:3000" //Game will be making POST requests to this uri. If the endpoint needs traffic to be encrypted in flight then it is recommended to specify a secure uri and use SSL on the service end. Steam client will automatically use SSL and validate endpoint certificate for https destinations.
 
 "timeout" "5.0" // 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. Note: 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.
 
 
 "buffer"  "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" // 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" // 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"
 {
   "token" "CCWJu64ZV3JHDT8hZc"
 }
 "data"
 {
   "provider"            "1"      // general info about client being listened to: game name, appid, client steamid, etc.
   "map"                 "1"      // map, gamemode, and current match phase ('warmup', 'intermission', 'gameover', 'live') and current score
   "round"               "1"      // round phase ('freezetime', 'over', 'live'), bomb state ('planted', 'exploded', 'defused'), and round winner (if any)
   "player_id"           "1"      // player name, clan tag, observer slot (ie key to press to observe this player) and team
   "player_state"        "1"      // player state for this current round such as health, armor, kills this round, etc.
   "player_weapons"      "1"      // output equipped weapons.
   "player_match_stats"  "1"      // player stats this match such as kill, assists, score, deaths and MVPs
 }
}

piggybacking OLED on ESP8266

https://blog.squix.org/2016/06/esp8266-hack-piggybacking-oled-display-on-wemos-d1-mini.html

Assuming that your display’s connectors are in the order GND, VCC, SCL and SDA just place the display on the bottom of your WeMos D1 Mini so that the two GND’s are connected with each other.
VCC connects to D4, SCL to D3 and SDA to D2. I’m aware that I am “cheating” the D4 connector into being the power source, but I couldn’t find any data about the max. current the display draws.
If you want to be 100% safe add a connection between VCC (on the display) and 3V3 instead.
If you are following my VCC-D4 hack from above make sure that you enable D4 for output and to set it to HIGH:
pinMode(D4, OUTPUT);
digitalWrite(D4, HIGH);
  • Last modified: 2019-12-20 14:21