Designed to scale
Haptics should not need to be rebuilt every time the game changes.
Different simulators expose different data. Different hardware expresses sensation differently. The physical meaning in between does not need to start from zero every time.
MCP4SH is built as a semantic telemetry to haptics layer. It stays specialised where the source or hardware requires it and stays consistent where the physics means the same thing. The current product is delivered through SimHub. The interpretation and orchestration logic is deliberately separated from one renderer or one device class.
01 · The architecture
Different sims. Same physical world.
One simulator may expose a useful signal directly. Another may describe the same vehicle state through a different set of telemetry. MCP4SH does not require those sources to look identical.
The goal is to understand each source at the input, translate it into a consistent description of what the vehicle is doing, coordinate that information, then express it through the available hardware.
02 · Fidelity without fragmentation
Specialise at the edges. Standardise the meaning.
A simulator specific input path can remain as specialised as necessary. That does not mean every downstream effect and every output device must also become simulator specific.
Native signals, related signals and graceful fallbacks can all contribute without pretending they have identical fidelity.
When wheel level or directional information exists, it can remain spatial rather than being flattened into one chassis value.
When a title exposes less, MCP4SH should communicate less precision rather than inventing detail that is not there.
Concrete software example · braking and grip state
Different sources · preserved meaning03 · Orchestration
The vehicle is one system. The haptics should behave like one too.
Braking changes load. Load changes available grip. Suspension movement affects chassis behaviour. Engine, drivetrain, road, impact and tyre information all coexist. Making every lane louder at once does not necessarily communicate more.
MCP4SH treats effects as parts of one tactile scene. Interpretation determines what the signals mean. Orchestration decides how useful information should coexist when several things happen at the same time.
Concrete driving example · one Spa lap contains a whole tactile sequence
State changes over timeBrake feel, forward load, tyre state and exit traction all overlap.
Heave and chassis load become the dominant information.
Long-duration chassis and tyre state matter more than impacts.
Several useful cues arrive together and need space rather than simple stacking.
Work out what the available telemetry says about the current physical state.
Keep useful transient or state information from being buried by continuous activity.
Render the resulting meaning through the capabilities of the target hardware.
04 · Setup and tuning
Tune the rig. Not every game.
Transducers, mounting, useful frequency range, amplifiers, placement and personal preference still matter. No software removes the physical differences between rigs.
What MCP4SH is designed to remove is unnecessary repetition. Once hardware is mapped and calibrated, changing simulator should not mean rebuilding tyre, brake, suspension, drivetrain, road and load behaviour from zero.
What should remain user specific
What the system should solve first
Concrete setup example · calibrate the rig, then keep the baseline
One hardware pass · many titlesAssign the physical transducers and channels once.
Find the useful tactile range of the actual rig.
Choose gain, comfort and personal emphasis.
The hardware setup remains stable when the title changes.
05 · Latency
Fast matters. Latency is not the whole haptic system.
Lower transport latency is desirable. Discrete events such as impacts, kerbs and sudden interventions benefit directly from the fastest practical path.
Useful tactile response also depends on what was detected, when the underlying state became meaningful, how it was interpreted, what else was happening at the same time and whether the output communicates the correct thing.
This does not make transport latency irrelevant. MCP4SH does not claim to predict information that the simulator has not exposed. It means an evolving physical state can carry useful information before a later event threshold is crossed.
06 · Scalability
Same meaning. Different edges.
A simulator and a haptic device do not need to understand each other directly. The simulator needs an input path that can describe useful physical state. The output device needs a projection path that can express that state. The shared meaning sits between them.
Scaling problem · bespoke links grow in both directions
N inputs × M outputsReal integrations still have unique capabilities and constraints. The goal is to keep those differences at the edges instead of multiplying bespoke interpretation throughout the whole stack.
07 · Mixed hardware
Different devices can carry different parts of the same vehicle state.
A mixed rig does not need every device to reproduce every effect. Each output can concentrate on the information it is physically suited to express.
Concrete rig example · divide the sensory work
Different carriers · one interpreted vehicle state| Semantic cue | Pedal plate | Seat / chassis | Backrest / pad | Pedal motor |
|---|---|---|---|---|
| Brake state | ||||
| ABS / lock | ||||
| Road / impacts | ||||
| Rear traction | ||||
| Drivetrain | ||||
| Chassis load / direction |
08 · Built for integration
The current SimHub plugin is an implementation. It is not the intended boundary.
Today SimHub provides the public host for telemetry access, configuration and tactile output. MCP4SH.Core already separates most haptic interpretation and stateful effect logic from the host specific plugin layer.
That boundary is deliberate. The longer term direction is to let the same semantic and orchestration logic feed different hosts, SDKs and physical outputs without rewriting the interpretation model around each target.
Concrete OEM example · a new active pedal
Focus engineering on the device09 · Output paths already exercised
The architecture is already reaching beyond one shaker topology.
MCP4SH is primarily developed and validated through tactile hardware driven by SimHub. Real user testing has also exercised other output classes. Compatibility and first class Setup Assistant integration are not the same thing, so the status is shown plainly below.
Current output-path evidence
Compatibility is not the same as first-class setup support| Output class | Example | Status | Setup Assistant |
|---|---|---|---|
| Bass transducer | Dayton BST-1 / TT25 class | Reference path | First-class |
| Haptic pad | Next Level Racing HF8 / HF8 Pro | Public user report | Via SimHub |
| Haptic pad | SRS U-Shake | Reported compatible | Via SimHub |
| Motor haptics | Pedal motors / ShakeIt Motors | Documented route | Manual mapping |
| Multichannel audio | Creative X4 8-channel | User validated | Supported |
A device being reachable through SimHub does not automatically mean every MCP4SH Setup Assistant feature supports it directly. The distinction matters because architectural compatibility can arrive before guided setup and profile generation.
10 · Proof, not promises
Measure the experience. Do not rely on the number of effects.
The architecture should be testable. MCP4SH is preparing measurements that can show where time is spent, how consistently the system behaves and how much repeated setup is actually required.
Future published results should distinguish telemetry cadence, MCP4SH processing time, output path delay and physical response where the measurement setup allows it. The method should travel with the number.
11 · Domain portability
A useful abstraction should survive beyond the first domain it was built around.
MCP4SH began with automotive simulation. The v1.2 development track is testing how much of the same architecture can carry into flight. Shared physical ideas such as powerplant behaviour, body load and transients can remain reusable where they genuinely overlap. Airframe specific meaning can be added where the domain is different.
The goal is not to rename automotive effects as aircraft effects. The goal is to reuse physical meaning where it transfers and introduce new domain semantics where it does not.
load · acceleration · vibration · transients · powerplant behaviour
Design principle
Specialise at the edges. Standardise the meaning.
Different simulators deserve access to their unique telemetry. Different hardware deserves to use its unique capabilities. Neither requires rebuilding the whole interpretation stack between them.
That is the problem MCP4SH is designed to solve.