Would we be able to have access to the pedal effects/force ourselves?
There are tons of things I’d like to do. Write a launch script that gives me haptic feedback at certain rpms. Tap my foot with a bump of force when I cross the line or set a fast lap.
I know these are dumb examples but can we get in there? I assume the cat5 connection isn’t accessible over something cool like http or tcp sockets? Is there an sdk we can have?
Love these pedals so far and I’m glad you made them. Looking forward to tinkering.
There will be API; it is actually being worked on. It is going to be made available to game developers and commercial sim operators that have e.g. integrations to systems that do not run a “racing game” but some other real simulator.
We already have a RPM based vibration effect but I think you mean some RPM based vibration that trigger only when RPM reaches some value?
To start, what would be nice is to be able to swap the Simucube Tuner profile on the fly. So as an example, with a script or a button push. Hit a button and it switches from an aggressive pedal curve to make a softer one. That would be huge.
But past that, it would be nice if there was an SDK so that I could do things to the pedals based on telemetry or other stuff. Let’s be honest, stuff like SimHub is a powerful tool.
Here’s a really cool example I want to do. SimHub has a property that tells you when a different class car is approaching from behind. It beeps and gets progressively higher pitched as the car approaches. It’s really handy for endurance multi-class racing.
I want to take those properties and have them shake my pedals instead.
… Maybe have them vibrate my brake pedal when I’m a few meters away from the pit lane speed limit line? The possibilities are endless.
Ultimately. I want to do whatever I want. I feel like if you gave us an sdk to tinker, you could then focus on optimizing and improving the firmware and integrations which is what yall are clearly good at. Meanwhile, us nerds could go off and make the really bad ass scripts and macros and effects and stuff from the telemetry data
Indeed. We have a list of things that people would like to be able to do from the SDK, and this falls into that requirement list. But, we can’t rely on SimHub on any of our product features as we don’t own Simhub and if any other company buys Simhub, the Simhub developer gets bought out, or some other things happen, we would be left without support and that would hurt our product a lot.
Yes, that would be nice if Simhub could be avoided in the long term.
No no no. Simhub is just an example of a tool we use to trigger things. I’m not suggesting writing some custom integration with Simhub.
What I’m suggesting is the Tuner software or the pedal itself has some communications tool we can use to send effects and commands. Like an sdk. As an example say if I ran: active-pedal.exe -brake -vibrate 20
it would vibrate the brake 20%.
Then I can write my own scripts, automate different effects, use tools like simhub and Z1 to trigger my scripts, etc. So we can create our own triggers, the active pedal is just the action. It doesn’t know or care what triggered it.
These open sdk’s and cli tools we get from hardware manufacturers are a dream. And the potential in the active pedal for tinkering is huge.
Just curios if no integration with SimHub, how typical consumer will utilize such SDK, by running
active-pedal.exe -brake -vibrate 20
?
BTW, SimHub recently added integration with Simagic P1000/P2000 motors reactor.
SimHub: “The P1000 pedals reactor are now supported in Shakeit motors.
Make sure to update both simpro and simhub to use it
Huge thanks to the Simagic team which made it possible
by bringing the required firmware features.”
We will not do the integration to Simhub, and will not utilize Simhub scripting or whatever it makes possible in our marketing due to the risk that then our product features would somehow be dependent on Simhub. That is a horrible idea business wise.
But we expect that Simhub will want to utilize our SDK and implement it into Simhub.
The answer is that Simucube would make an example sdk/cli tool like I mentioned active-pedal.exe.
Then someone in the community would make a SimHub plugin that wraps up that tool.
Now Simhub would have an “integration” with the tool, yet Simucube doesn’t have to depend on or maintain anything. Simucube / Granite then has zero connection to Simhub and doesn’t have to know or care anything about it. All they focus on is maintaining their own cli tools. Like the exe I mentioned.
Same exact pattern as every other tool. I would bet Phillips has no idea that an app like Simhub exists. Yet Phillips makes cli tools to adjust their Hue lights, and people from the community have made scripts and plugins to connect it to simhub.
I understand how sdks work, Simucube will not integrate into SimHub, SimHub can using published SDK/API.
It’s just the original statement from Mika was a bit confusing as if they do not want any integration from SimHub at all and prefer using only own internal tools utilizing this SDK, which defeats the purpose of having open API in the first place.
But looks like the follow up post clarifies SC stance. All good now.
