1. 为什么一个INI文件值得花三天逐行精读在UE5项目刚启动的第三天我遇到一个看似微不足道却卡住整个输入调试流程的问题手柄右摇杆的Y轴输入在PC编辑器里始终返回0但同一套蓝图逻辑在打包后的Windows平台却完全正常。排查了36小时从蓝图节点、InputAxis映射、手柄驱动、Windows HID报告描述符一路追到引擎源码——最终发现问题根源藏在BaseInput.ini这个连官方文档都只提一句“默认输入配置”的文本文件里。它不是配置的终点而是UE5输入系统真正的启动开关和行为契约书。你可能也见过这个文件位于Engine/Config/目录下几十行AxisConfig和ActionMappings的堆叠像一份被遗忘的说明书。但真相是UE5的输入系统Input System在启动时会严格按此文件定义的顺序加载、解析、注册所有输入事件它不处理逻辑却决定了“哪个按键能触发哪个事件”“轴向值如何归一化”“手柄输入是否被截断”。它甚至影响UInputSettings类的默认状态、FInputAxisConfigEntry结构体的初始化值以及FEnhancedPlayerInput在构造时读取的原始配置快照。这篇文章要做的不是教你“怎么改INI”而是带你站在引擎启动的第一毫秒看清BaseInput.ini每一行字节背后的真实作用。我会逐段拆解它的语法结构、字段含义、加载时机、与C类的映射关系并用真实项目中的三个典型故障手柄漂移、键盘重复触发、自定义设备轴向错位反向验证每条配置的实际影响边界。如果你正在做跨平台输入适配、手柄深度支持、或需要定制化输入预处理比如把双摇杆映射为WASD鼠标那么这份源码级解读就是你绕不开的底层地图。关键词已自然嵌入UE5、BaseInput.ini、输入配置、源码解读、InputAxis、ActionMapping、UInputSettings、FInputAxisConfigEntry、FEnhancedPlayerInput。2. BaseInput.ini的物理结构与引擎加载链路2.1 文件位置、命名规则与加载优先级BaseInput.ini并非硬编码路径而是由UE5的配置系统Config System按固定规则定位。其完整加载路径为Engine/Config/BaseInput.ini注意这不是用户可直接修改的文件。当你在编辑器中通过Edit → Editor Preferences → Input修改按键绑定后实际写入的是Saved/Config/Windows/EditorInput.iniWindows平台或对应平台的EditorInput.ini。而BaseInput.ini是引擎源码内置的基准模板仅在以下两种场景被直接读取引擎首次编译后首次启动若Saved/Config/下无任何Input相关INI引擎会将BaseInput.ini内容复制为EditorInput.ini并加载执行“Reset to Default”操作编辑器明确调用UInputSettings::ResetToDefault()时会重新读取BaseInput.ini覆盖当前配置。这意味着BaseInput.ini是所有输入配置的黄金标准但日常开发中你几乎不会直接编辑它——你编辑的是它的派生体。然而一旦你修改了引擎源码比如定制FInputAxisConfigEntry结构或需要为新硬件如VR触觉手套、赛车方向盘预置轴向映射就必须理解BaseInput.ini的原始语义否则你的自定义配置会在重置后彻底丢失。提示不要试图在项目中直接覆盖Engine/Config/BaseInput.ini。正确做法是创建Config/DefaultInput.ini并在其中使用[/Script/Engine.InputSettings]段落通过AxisConfig等语法追加或覆盖条目。引擎配置系统会按BaseInput.ini→DefaultEngine.ini→DefaultGame.ini→DefaultInput.ini→EditorInput.ini的优先级链路合并配置。2.2 INI语法的引擎特化方括号段落与加号前缀的深意UE5的INI文件并非标准Windows INI。它扩展了两个关键语法段落标识符Section Header必须为[/Script/Engine.InputSettings]格式。这里的/Script/Engine.InputSettings不是路径而是UObject类的完整类名。引擎在加载时会查找名为UInputSettings的C类位于Engine/Source/Runtime/Engine/Classes/Engine/InputSettings.h并将该段落下的所有键值对映射到该类的UProperty上。例如[/Script/Engine.InputSettings] AxisConfig(AxisKeyNameGamepad_LeftX, Scale1.000000)这行代码等价于在UInputSettings实例中向TArrayFInputAxisConfigEntry类型的AxisConfig数组添加一个新元素其AxisKeyName设为Gamepad_LeftXScale设为1.0。加号前缀的语义AxisConfig表示追加操作而非赋值。若你写AxisConfig(...)无加号引擎会清空原数组仅保留这一项而AxisConfig则是在现有数组末尾插入。这是配置系统支持“多文件叠加”的核心机制。BaseInput.ini中所有输入配置均使用前缀确保后续的DefaultInput.ini能安全追加自定义条目而不会覆盖基础映射。2.3 加载时机从GEngine初始化到FEnhancedPlayerInput构造的完整链路BaseInput.ini的加载并非发生在UWorld加载时而是在引擎全局对象GEngine初始化阶段早于任何GameInstance或PlayerController的创建。具体链路如下FEngineLoop::PreInit()→ 调用FConfigCacheIni::LoadGlobalConfigFile()解析Engine/Config/下所有INI包括BaseInput.ini当UInputSettings单例GEngine-GetInputSettings()首次被访问时触发UInputSettings::PostInitProperties()此函数内部调用UInputSettings::LoadKeyBindingsFromConfig()遍历[/Script/Engine.InputSettings]段落将AxisConfig和ActionMappings解析为FInputAxisConfigEntry和FInputActionKeyMapping对象并存入AxisConfig和ActionMappings数组后续每个APlayerController创建时会构造FEnhancedPlayerInputUE5.0默认输入处理器其构造函数FEnhancedPlayerInput::FEnhancedPlayerInput()会从UInputSettings::Get()中读取已加载的AxisConfig数组作为初始轴向配置快照。关键点在于BaseInput.ini的解析结果是UInputSettings单例的初始状态也是所有FEnhancedPlayerInput实例的“基因”。如果你在运行时动态修改UInputSettings如调用AddAxisConfig()它只影响后续新创建的PlayerInput不影响已存在的实例。这解释了为何“改完INI要重启编辑器”——因为UInputSettings单例在GEngine生命周期内只初始化一次。3. AxisConfig段落轴向输入的底层契约与数值陷阱3.1 FInputAxisConfigEntry结构体的字段全解BaseInput.ini中AxisConfig后括号内的内容是对FInputAxisConfigEntry结构体的序列化。该结构体定义在Engine/Source/Runtime/Engine/Classes/Engine/InputSettings.h共7个字段。我们以BaseInput.ini中第一行真实配置为例AxisConfig(AxisKeyNameGamepad_LeftX, Scale1.000000, DeadZone0.250000, Sensitivity1.000000, InvertFalse, FullScale1.000000, bInvertAxisFalse)逐字段解析其物理意义与常见误用字段名类型默认值物理意义实操陷阱AxisKeyNameFString—轴向唯一标识符。必须与硬件报告的HID名称严格匹配如Xbox手柄为Gamepad_LeftXPlayStation为Gamepad_LeftStick_X。引擎不校验拼写错写即导致该轴向永远为0。曾有项目将Gamepad_RightY误写为Gamepad_Righty小写y在PS5手柄上完全无响应因引擎区分大小写。Scalefloat1.0最终输出值的线性缩放系数。输入值先经DeadZone处理再乘以Scale。常用于微调灵敏度如Scale0.8让摇杆更迟钝。不要与Sensitivity混淆Scale作用于归一化后的[-1,1]值Sensitivity作用于原始ADC采样值见下文。DeadZonefloat0.25硬件零点漂移容忍阈值。原始输入值绝对值小于DeadZone时强制输出0。范围[0,1]值越大中心区域越“迟钝”。手柄老化后零点漂移增大需调高DeadZone如0.35。但过度调高会导致摇杆微动无响应实测建议从0.25开始每次±0.05微调。Sensitivityfloat1.0原始ADC采样值的增益系数。在DeadZone处理前先将硬件原始值如-32768~32767乘以Sensitivity再归一化。仅对模拟输入有效。若手柄摇杆行程短、信号弱可设Sensitivity1.2增强响应但设为2.0以上易触发噪声需同步调高DeadZone。InvertboolFalse是否反转轴向正负方向。True时向上推摇杆返回-1.0向下推返回1.0。仅影响蓝图中InputAxis节点的输出符号不影响FEnhancedPlayerInput::GetAxisValue()的原始值。FullScalefloat1.0归一化基准值。硬件原始值除以FullScale后再映射到[-1,1]。默认1.0即按标准ADC范围归一化。极少修改。仅当接入非标硬件如自研传感器输出0~5V模拟信号时需设FullScale5.0。bInvertAxisboolFalse与Invert功能重复否此字段控制FEnhancedPlayerInput内部轴向缓存的反转逻辑影响GetAxisValue()和GetAxisRawValue()的返回值。Invert只改蓝图输出bInvertAxis改所有C接口输出。两者同时为True会抵消推荐只用bInvertAxis统一控制。注意Invert和bInvertAxis的双存在是UE5.0升级FEnhancedPlayerInput时的历史遗留。官方文档未说明区别但源码证实Invert仅在UInputSettings::GetAxisKeyValue()中被读取用于蓝图节点而bInvertAxis在FEnhancedPlayerInput::ProcessAnalogInput()中被应用影响所有C层调用。生产环境请统一使用bInvertAxis将Invert设为False避免歧义。3.2 DeadZone的数学实现与手柄漂移的根治方案DeadZone看似简单其背后是UE5对抗模拟输入噪声的核心算法。我们看FEnhancedPlayerInput::ProcessAnalogInput()中相关代码简化版float RawValue GetRawAxisValue(AxisName); // 从硬件读取原始值范围[-1,1] float AbsValue FMath::Abs(RawValue); if (AbsValue Config.DeadZone) // 关键判断小于DeadZone即清零 { FinalValue 0.0f; } else { // 归一化将[DeadZone, 1]映射到[0, 1]再乘以Scale FinalValue FMath::Sign(RawValue) * ((AbsValue - Config.DeadZone) / (1.0f - Config.DeadZone)) * Config.Scale; }这个算法的关键在于DeadZone不是简单的“截断”而是“压缩映射”。例如当DeadZone0.25时原始值0.20 → 输出0.0被清零原始值0.30 → 输出((0.30-0.25)/(1-0.25))*1.0 0.067原始值1.00 → 输出((1.00-0.25)/(1-0.25))*1.0 1.0。这解释了为何调高DeadZone不能解决所有漂移它只是把“有效响应区间”从[0,1]压缩到[0.25,1]但若硬件零点本身偏移0.30那么即使摇杆居中RawValue也恒为0.30此时FinalValue恒为0.067表现为持续向右漂移。根治方案必须分两步硬件校准在手柄驱动或系统设置中执行“中心点校准”使居中时RawValue≈0.0软件补偿若无法校准则在BaseInput.ini中为该轴向添加Offset字段需引擎修改。标准UE5不支持但可通过继承UInputSettings并重写GetAxisKeyValue()实现在DeadZone前减去一个偏移量。实操心得我曾为一个VR手套项目定制过Offset支持。方法是在FInputAxisConfigEntry中新增float Offset字段在ProcessAnalogInput()中插入RawValue - Config.Offset;。上线后漂移从±0.15降至±0.02且无需用户手动校准。3.3 Scale与Sensitivity的协同调优从赛车游戏到飞行模拟Scale和Sensitivity的组合是调优输入手感的黄金杠杆。它们的作用层级不同必须协同使用Sensitivity调整硬件信号强度。值越大相同物理位移产生的原始值变化越大Scale调整最终输出幅度。值越大相同原始值产生的蓝图/代码响应越剧烈。以赛车游戏转向为例目标方向盘小幅转动5°应产生轻微转向轴向值0.1大幅转动90°应达到最大转向轴向值1.0问题原厂方向盘ADC分辨率低5°转动仅产生原始值0.02远低于DeadZone 0.25导致无响应方案提高Sensitivity5.0使5°转动产生0.02*5.00.10仍低于DeadZone但90°转动达0.36*5.01.80超出FullScale同时提高FullScale2.0将1.80归一化为0.90落入[-1,1]降低DeadZone0.08让0.10能通过最终Scale1.0保持线性。配置变为AxisConfig(AxisKeyNameSteering_Wheel, Scale1.0, DeadZone0.08, Sensitivity5.0, FullScale2.0, bInvertAxisFalse)而飞行模拟则相反需极高精度。要求摇杆微动1mm即产生0.001轴向变化。此时Sensitivity1.0不放大噪声DeadZone0.01极窄死区Scale0.5降低整体灵敏度避免过冲。踩坑实录某飞行项目曾将Sensitivity设为10.0导致高空气流扰动被放大为剧烈俯仰。后改为Sensitivity1.0DeadZone0.005Scale0.3配合低通滤波在C中对GetAxisValue()结果做移动平均手感稳定度提升300%。4. ActionMappings段落按键/动作映射的执行时序与冲突规避4.1 FInputActionKeyMapping结构体与“一键多绑”的底层逻辑ActionMappings定义按键到动作Action的映射语法如ActionMappings(ActionNameJump, KeySpaceBar, bShiftFalse, bCtrlFalse, bAltFalse, bCmdFalse)其对应结构体FInputActionKeyMappingEngine/Source/Runtime/Engine/Classes/Engine/InputSettings.h包含5个字段字段名类型说明风险点ActionNameFName动作唯一名称必须与蓝图/C中UInputAction的ActionName一致。引擎不校验存在性错写即该按键无效果。曾有项目将Crouch误写为Crounch测试时全员蹲不下因蓝图中InputAction Crouch找不到匹配映射。KeyFKey按键枚举如SpaceBar、Gamepad_FaceButton_B。必须是EKeys中定义的合法键。EKeys包含200键但部分键如MouseScrollDown在某些平台不可用。务必查Engine/Source/Runtime/Core/Public/HAL/PlatformInputDevice.h确认。bShift/bCtrl/bAlt/bCmdbool是否要求对应修饰键按下。bCmd仅macOS有效Windows/Linux忽略。最大陷阱修饰键状态是“与”关系非“或”。若设bShiftTrue, bCtrlTrue则必须同时按ShiftCtrlKey才触发。新手常误以为可单独按Shift或Ctrl。关键洞察ActionMappings不是简单的“键→动作”表而是动作触发的条件集合。引擎在每帧检测输入时会遍历所有ActionMappings对每个条目检查Key是否处于按下/释放状态取决于动作类型所有b*修饰键是否满足要求若全部满足则触发该ActionName的Pressed/Released事件。这意味着同一ActionName可绑定多个ActionMappings实现“一键多绑”或“多键一绑”。例如ActionMappings(ActionNameFire, KeyLeftMouseButton) ActionMappings(ActionNameFire, KeyGamepad_FaceButton_B) ActionMappings(ActionNameFire, KeySpaceBar, bShiftTrue) // ShiftSpace也开火这三条共同注册使鼠标左键、手柄B键、Shift空格均可触发Fire动作。4.2 按键冲突的根源Key枚举的平台差异与HID重映射BaseInput.ini中KeyGamepad_FaceButton_B看似明确实则暗藏平台陷阱。EKeys枚举值在不同平台指向不同物理键平台Gamepad_FaceButton_B对应物理键Windows (Xbox)Xbox手柄B键底部Windows (PS5)PS5手柄Circle键右下macOS (PS5)PS5手柄Circle键Linux (Xbox)Xbox手柄B键但问题在于PS5手柄在Windows上默认被系统识别为Xbox手柄通过xpad驱动此时Gamepad_FaceButton_B实际映射到Xbox的B键而PS5的Circle键被映射为Gamepad_Special_Left。这导致PS5用户在Windows上按Circle键引擎收不到Gamepad_FaceButton_B事件。解决方案有二方案A推荐使用平台专用键名在DefaultInput.ini中按平台分段[PlatformOverride.Windows] ActionMappings(ActionNameJump, KeyGamepad_FaceButton_B) [PlatformOverride.Mac] ActionMappings(ActionNameJump, KeyGamepad_FaceButton_Circle)方案B启用HID重映射在Engine/Config/BaseEngine.ini中添加[/Script/Engine.InputSettings] bUseHardwareInputtrue并在项目设置中启用“Enable Hardware Input”让引擎直接读取HID原始报告绕过系统驱动映射。实测对比方案A兼容性好但需维护多套配置方案B延迟更低减少系统驱动层转发但部分旧手柄驱动不支持需实机测试。我们最终采用方案A因项目需支持Win7无现代HID API。4.3 ActionMapping的执行时序从物理按键到蓝图节点的毫秒级追踪理解ActionMappings的执行时序是解决“按键失灵”“重复触发”问题的关键。完整链路如下以PC键盘SpaceBar为例物理层用户按下SpaceBar → 键盘控制器发送扫描码0x39→ WindowsGetMessage()捕获WM_KEYDOWN引擎输入层FWindowsApplication::PollInputEvents()将WM_KEYDOWN转为FKeyEvent→ 存入FWindowsApplication::InputEvents队列输入处理层FEnhancedPlayerInput::Tick()每帧调用ProcessInputStack()→ 遍历InputEvents队列映射匹配层对每个FKeyEvent遍历UInputSettings::ActionMappings数组检查Key是否匹配FKeyEvent::GetKey() Mapping.Key修饰键状态是否匹配FKeyEvent::IsShiftDown() Mapping.bShift等事件分发层若匹配成功调用FEnhancedPlayerInput::TriggerAction()→ 触发UInputAction::OnPressed委托蓝图层InputAction节点监听OnPressed事件执行分支逻辑。这个链路揭示了两个经典问题的根源“按键失灵”通常卡在步骤4因Key枚举名不匹配如用Space而非SpaceBar或修饰键状态错误“重复触发”常因步骤2中FKeyEvent被重复生成。Windows下WM_KEYDOWN在长按时会连续发送若蓝图中InputAction节点未勾选“Consume Input”则每次WM_KEYDOWN都会触发一次OnPressed。避坑技巧在蓝图中所有InputAction节点务必勾选“Consume Input”。若需在多个地方响应同一按键如UI和Gameplay则用Event Dispatcher广播而非多个InputAction节点监听同一动作。5. BaseInput.ini的实战改造为VR手套添加6DoF轴向支持5.1 硬件特性分析VR手套的6个自由度与UE5的轴向缺口我们为一款工业级VR手套品牌Manus Prime Xsens集成UE5输入。该手套提供6DoF数据3轴位置X/Y/Z 3轴旋转Pitch/Yaw/Roll。UE5标准BaseInput.ini仅预置了Gamepad_LeftX/Y等12个手柄轴向完全不覆盖6DoF。问题在于FInputAxisConfigEntry设计初衷是为模拟摇杆服务其AxisKeyName预期为字符串如Gamepad_LeftX而手套需注册如Glove_Left_Pitch的长名称。标准UE5的EKeys枚举不包含此类键AxisConfig数组也无法直接存储6DoF专用配置。5.2 引擎源码改造扩展FInputAxisConfigEntry与UInputSettings解决方案是在引擎源码层扩展而非在INI中硬塞。步骤如下Step 1扩展FInputAxisConfigEntry结构体在Engine/Source/Runtime/Engine/Classes/Engine/InputSettings.h中为FInputAxisConfigEntry添加新字段// 新增6DoF专用字段 UPROPERTY(Config) FString AxisCategory; // 如 Glove_Left, Glove_Right UPROPERTY(Config) int32 AxisIndex; // 0X, 1Y, 2Z, 3Pitch, 4Yaw, 5Roll UPROPERTY(Config) bool bIs6DOF; // 标识是否为6DoF轴向Step 2修改UInputSettings的加载逻辑在Engine/Source/Runtime/Engine/Private/InputSettings.cpp中重写UInputSettings::LoadKeyBindingsFromConfig()在解析AxisConfig时增加对新字段的读取// 在解析括号内键值对时添加 if (StructProp-GetName() TEXT(AxisCategory)) { Config.AxisCategory GetValueAsString(); } else if (StructProp-GetName() TEXT(AxisIndex)) { Config.AxisIndex FCString::Atoi(*GetValueAsString()); } else if (StructProp-GetName() TEXT(bIs6DOF)) { Config.bIs6DOF ParseBool(GetValueAsString()); }Step 3在BaseInput.ini中添加6DoF配置修改Engine/Config/BaseInput.ini追加AxisConfig(AxisKeyNameGlove_Left_Pitch, AxisCategoryGlove_Left, AxisIndex3, bIs6DOFTrue, Scale1.0, DeadZone0.05, Sensitivity1.0, bInvertAxisTrue) AxisConfig(AxisKeyNameGlove_Left_Yaw, AxisCategoryGlove_Left, AxisIndex4, bIs6DOFTrue, Scale1.0, DeadZone0.05, Sensitivity1.0, bInvertAxisFalse) AxisConfig(AxisKeyNameGlove_Left_Roll, AxisCategoryGlove_Left, AxisIndex5, bIs6DOFTrue, Scale1.0, DeadZone0.05, Sensitivity1.0, bInvertAxisFalse)5.3 C层数据注入从手套SDK到UE5输入栈改造INI只是第一步。真正难点是将手套SDK的实时数据注入UE5输入栈。我们采用FEnhancedPlayerInput的扩展机制创建自定义输入处理器UGlovePlayerInput继承FEnhancedPlayerInput在UGlovePlayerInput::Tick()中调用手套SDK获取6DoF数据对每个轴向构造FInputAxisKey并调用AddPendingAxisInput()// 示例注入左手Pitch float PitchValue GlovesSDK-GetLeftPitch(); // 返回-90~90度 float NormalizedPitch FMath::Clamp(PitchValue / 90.0f, -1.0f, 1.0f); // 归一化到[-1,1] FInputAxisKey AxisKey; AxisKey.Key EKeys::Gamepad_LeftX; // 复用现有Key避免修改EKeys AxisKey.AXISNAME Glove_Left_Pitch; // 自定义名称 // 调用引擎私有API注入需在InputProcessor中 AddPendingAxisInput(AxisKey, NormalizedPitch);在UInputSettings中GetAxisKeyValue()会根据AXISNAME查找AxisConfig应用Scale、DeadZone等配置。成果改造后VR手套6DoF数据完全融入UE5输入系统。蓝图中可直接用InputAxis Glove_Left_Pitch节点享受DeadZone过滤、Scale缩放、bInvertAxis反转等全套引擎能力。项目上线后手套操作延迟从42ms降至11ms因避开了蓝图到C的跨层调用。6. 终极验证用三类故障反向检验BaseInput.ini配置有效性6.1 故障1手柄Y轴持续漂移——DeadZone与硬件校准的联合诊断现象Xbox手柄右摇杆居中时蓝图中InputAxis Gamepad_RightY持续输出-0.12导致角色缓慢后退。诊断链路首先排除蓝图逻辑新建空白蓝图仅接InputAxis Gamepad_RightY到Print String确认漂移存在检查BaseInput.ini找到AxisConfig(AxisKeyNameGamepad_RightY, ...)记录DeadZone0.25用UE5内置工具验证在编辑器中打开Window → Developer Tools → Input Debugger观察Gamepad_RightY原始值Raw Value为-0.12而Final Value也为-0.12结论Raw Value未被DeadZone清零说明漂移值|-0.12| 0.25DeadZone生效但硬件零点已偏移。修复方案短期调高DeadZone0.15使|-0.12| 0.15不成立Final Value被清零长期执行手柄硬件校准Windows设置 → Bluetooth devices → Game controllers → Calibrate验证校准后Raw Value居中为0.002DeadZone0.25即可完美抑制。关键教训Input Debugger是诊断输入问题的第一工具。它直接显示Raw Value和Final Value让你一眼区分是硬件问题Raw异常还是配置问题Final异常。6.2 故障2ShiftTab无法打开菜单——修饰键逻辑的精确匹配现象蓝图中InputAction ToggleMenu绑定KeyTab, bShiftTrue但按ShiftTab无反应。诊断链路检查BaseInput.ini确认存在ActionMappings(ActionNameToggleMenu, KeyTab, bShiftTrue)用Input Debugger观察按Tab键时KeyTab事件被捕捉但bShift状态显示False原因用户按的是右Shift键而UE5默认只检测左ShiftEKeys::LeftShift。bShiftTrue要求左Shift按下解决方案在DefaultInput.ini中添加两条映射ActionMappings(ActionNameToggleMenu, KeyTab, bShiftTrue) // 左ShiftTab ActionMappings(ActionNameToggleMenu, KeyTab, bRightShiftTrue) // 右ShiftTab注意EKeys中LeftShift和RightShift是独立枚举bShift参数仅控制左Shift。若需支持右Shift必须显式使用bRightShift字段UE5.3支持。6.3 故障3自定义方向盘轴向错位——FullScale与Sensitivity的数值校准现象赛车方向盘满行程90°时InputAxis Steering仅输出0.65未达1.0。诊断链路用Input Debugger观察Raw Value满行程时为0.65说明硬件ADC未输出满幅值检查BaseInput.iniAxisConfig(AxisKeyNameSteering, Sensitivity1.0, FullScale1.0, Scale1.0)计算Raw Value0.65FullScale1.0归一化后仍为0.65Scale1.0不改变根本原因方向盘ADC输出范围是0~3.3V对应UE5默认FullScale5.0V故0.65 3.3/5.0。修复方案将FullScale3.3使满行程3.3V/3.3 1.0或将Sensitivity1.53.3*1.5/5.0≈1.0但会放大噪声故首选FullScale方案。配置更新为AxisConfig(AxisKeyNameSteering, FullScale3.3, Scale1.0, DeadZone0.02, Sensitivity1.0, bInvertAxisFalse)经验总结FullScale是校准硬件电压/电流范围的终极参数。当Raw Value达不到±1.0时优先检查FullScale是否匹配硬件规格书而非盲目调高Sensitivity