I’ve released Wheeler, an Open Broadcaster overlay.
Wheeler is designed to replace pedal cams (sock cams) in racing games for streamers. It displays configurable racing wheel, pedal, shift and handbrake input and plays nicely with multiple input devices.
Wheeler is priced at pay-what-you-want, but all support is appreciated.
After some trial and error (and error, and error, and error), I’ve managed to get DiRT Rally telemetry data to
display on a TM1638 display module, and have released both the arduino sketch I’m using and the python script used for communication here: https://github.com/Billiam/pygauge
The python script is also available as an all-in-one exe. You can download gauge.ziphere.
Here it is in use:
I started with X-Sim and this guide, but ran into a few problems. X-sim required Dirt’s extradata option to be set to 1, and didn’t seem to be aware of each cars rev limit. In the linked guide, the rev limit has been hardcoded to 9,500, which is pretty far off of some of DiRT Rally’s cars. The Use automatic maximum adjustment setting partially resolves this, but it won’t know what the maximum rpm until you reach it at least once.
X-Sim is extremely flexible and powerful, but is very configuration-heavy and felt like overkill for this project. If you’re already using X-Sim to drive your sim rig/gauges, I’d recommend sticking with it.
Additionally, if you’re interested in using this LED module for other games, including Assetto Corsa, iRacing, Project Cars and rFactor, check out http://batrako.blogspot.com/ instead.
Verify that you can upload sketches by uploading the blinky light Arduino example (see guide link).
You will need to connect arduino pins to the LED module. One for ground, one for power, and 3 to control it. If you plan to daisy chain multiple modules, you’ll be using additional pins.
Both the Arduino and the LED module pins are labeled on the PCB. Connect the Arduino 5v to the VCC input pin on the Arduino, connect ground to ground. I’ve wired Strobe 0, Clock and data to D3, D4 and D5 respectively.
If the TM1638 library was installed correctly, you should have a TM1638 menu in the Arduino app under File > Examples. Upload the tm1638_one_module_example sketch to verify that you can communicate with the led module. You may need to update the data, clock and strobe pins used, depending on how you wired them together.
In your DiRT hardware configuration, <Documents>\My Games\DiRT Rally\hardwaresettings\hardware_settings_config.xml, set the motion_platform udp enabled attribute to true and extradata to 3
Ran into an issue this weekend with httparty, and an API (mapquest) that was sensitive to query parameter order. Specifically, when batch geocoding locations, mapquest expects a query string like: ?location=foo&location=bar&location=baz, and will return geocode results in the order received.
I noticed the issue when an api call for a US city returned a result in Ireland.
Httparty has two methods of encoding query parameters. The default, rails-friendly, way converts
This can be disabled by calling disable_rails_query_string_format, which replaces the default query string normalizer with this proc
Different version of ruby (even different 1.8.7 versions) will sort the result of
differently. A sort was added at the end of the normalizer proc to ensure that the query string is consistent across versions, likely for testing. This works, but has the side effect of also shuffling the order of array value elements.
Presort query parameters to avoid surprises,
use an alternate proc for query normalization (I just removed the sort entirely in my app),