All rafts increase sensitivit while on them

[Inazuma]

Kinda funny

[wildguy]

Weird, been around the island twice with the small raft and never noticed any change to the game, but i have seen this mentioned a few times. maybe it was happening and i never noticed it :)

[Ozzys_Dad]

Originally posted by wildguy:

Weird, been around the island twice with the small raft and never noticed any change to the game, but i have seen this mentioned a few times. maybe it was happening and i never noticed it :)

I didn't see any sensitivity issues on my trip around the island in my small raft. Maybe it's mouse hardware/driver specific. I use Razer peripherals.

[Ryzilynt]

If you are playing on Windows there should be a setting in "mouse properties" in the control panel under "pointer options"

"Enhance pointer precision" (try unchecking this box)

This setting was giving me problems in a similar but unrelated problem.

Or it's probably just something that needs to be patched out in a future update.

[Inazuma]

Originally posted by Ryzilynt:

If you are playing on Windows there should be a setting in "mouse properties" in the control panel under "pointer options"

"Enhance pointer precision" (try unchecking this box)

This setting was giving me problems in a similar but unrelated problem.

Or it's probably just something that needs to be patched out in a future update.

That's already disabled.

So fare the 6 people I am playing with also have the same issue, so I may have jumped the gun and assumed it was a global bug

[Ryzilynt]

Originally posted by Inazuma:

Originally posted by Ryzilynt:

If you are playing on Windows there should be a setting in "mouse properties" in the control panel under "pointer options"

"Enhance pointer precision" (try unchecking this box)

This setting was giving me problems in a similar but unrelated problem.

Or it's probably just something that needs to be patched out in a future update.

That's already disabled.

So fare the 6 people I am playing with also have the same issue, so I may have jumped the gun and assumed it was a global bug

There was a similar mouse sensitivity issue when inside the backpack a long time ago. They ultimately fixed it.

[Reddington Beartholomew]

Originally posted by Inazuma:

Originally posted by Ryzilynt:

If you are playing on Windows there should be a setting in "mouse properties" in the control panel under "pointer options"

"Enhance pointer precision" (try unchecking this box)

This setting was giving me problems in a similar but unrelated problem.

Or it's probably just something that needs to be patched out in a future update.

That's already disabled.

So fare the 6 people I am playing with also have the same issue, so I may have jumped the gun and assumed it was a global bug

You're not alone, both me and my co-op partner were having the same issue and even when disabling it there was still a slight increase in sensitivity. (Edit: Using Logitech Mouse)

[Ozzys_Dad]

Originally posted by Reddington Beartholomew:

Originally posted by Inazuma:

That's already disabled.

So fare the 6 people I am playing with also have the same issue, so I may have jumped the gun and assumed it was a global bug

You're not alone, both me and my co-op partner were having the same issue and even when disabling it there was still a slight increase in sensitivity. (Edit: Using Logitech Mouse)

Maybe it's a multiplayer issue as I play solo.

[Sylar]

Could be isolated to Logitech mice... meece... mouses... mooses... Who is experiencing this but doesn't use a Logitech mouse? Edit: Or adjustable DPI mice?

[Sylar]

I see some controllers have a similar issue.

[Sylar]

Found the problem... Is it a polling rate issue? Yes and no.

Debugging Report:

When steering with the oar, the sensitivity is back to normal again.

Which is important to observe.

The physics engine is calculating raft movement—when not steering, but standing on the raft—out of sync with mouse/controller input causing a boost in the sensitivity.

I used "cheatsticks" and typed "showraftdebug on" and looked for "Player Collider Overlaps" which scales from "1" to "2" when on the raft.

Next, typed "oceancolliderdebug on."

After fooling around with this, I noticed the debug shows "IsOnRaft" as true, even when the collider overlap is reading as 1—for example when I stand on top of a filled up firewood holder on the raft—(indicating you're not touching the raft).

Even so, "IsOnRaft" doesn't change, which is interesting.

It seems you are "on the raft" even outside of a collider overlap.

This further points to an issue where the game’s logic for "on-raft" state is decoupled from the actual physical collision state (the collider overlap).

I enabled "superjump" and it seems that "IsOnRaft" remains "true" only about 3 or 4 units (Ty) above the raft. Once above that level, mouse sensitivity normalizes again while the player is in the air.

Which means the problem can be narrowed down...

The issue persists as long as the "IsOnRaft" flag remains true, unless the Oar is in use. When the Oar shows "InUse: True," the sensitivity bug disappears. When the Oar shows "InUse: False," the sensitivity bug resurfaces again.

Which means the Developers are likely using input scaling to ensure smooth, free-looking motion for the camera, as opposed to having the camera move with the raft's swaying and rocking motions in the water.

...

Here's my recommended debugging solution: Instead of modifying the scaling multiplier, you temporarily halve the mouse sensitivity (mouseXSensitivity and mouseYSensitivity) only when the player is on the raft but not steering. Since we know sensitivity is doubling (due to a redundancy), the most hassle-free solution is to halve the sensitivity, as per the settings, whenever "IsOnRaft" is "True" and "OarInUse" is "False" during gameplay.

That way you avoid touching any multiplier logic and giving yourself a migraine. Here's an example (C#) and I'm skipping var declarations. Let's just use common sense to assume these are locally scoped floats:

void Update() {
    // Determine current sensitivities
    float currentXSensitivity = mouseXSensitivity;
    float currentYSensitivity = mouseYSensitivity;

    if (isOnRaft) {
        if (OarInUse) {
            // Steering: Use normal sensitivity
            currentXSensitivity = mouseXSensitivity;
            currentYSensitivity = mouseYSensitivity;
        } else {
            // On raft but not steering: Halve the sensitivity
            currentXSensitivity = mouseXSensitivity / 2.0f;
            currentYSensitivity = mouseYSensitivity / 2.0f;
        }
    }

    // Debugging: Output the current state and sensitivity values
    Debug.Log($"X: {currentXSensitivity}, Y: {currentYSensitivity}, IsOnRaft: {isOnRaft}, OarInUse: {OarInUse}");

    // Apply mouse input
    float mouseX = Input.GetAxis("Mouse X") * currentXSensitivity;
    float mouseY = Input.GetAxis("Mouse Y") * currentYSensitivity;

    // Apply camera rotation
    transform.Rotate(Vector3.up * mouseX);  // Horizontal rotation
    transform.Rotate(Vector3.left * mouseY);  // Vertical rotation
}

// Update oar (steering) state
public void SetOarInUse(bool inUse) {
    OarInUse = inUse;
}

// Update raft state
public void SetIsOnRaft(bool onRaft) {
    isOnRaft = onRaft;
}

Just do the same thing for controllers as well. Then the problem should be solved.

[Inazuma]

Originally posted by Sylar:

Found the problem... Is it a polling rate issue? Yes and no.

Debugging Report:

When steering with the oar, the sensitivity is back to normal again.

Which is important to observe.

The physics engine is calculating raft movement—when not steering, but standing on the raft—out of sync with mouse/controller input causing a boost in the sensitivity.

I used "cheatsticks" and typed "showraftdebug on" and looked for "Player Collider Overlaps" which scales from "1" to "2" when on the raft.

Next, typed "oceancolliderdebug on."

After fooling around with this, I noticed the debug shows "IsOnRaft" as true, even when the collider overlap is reading as 1—for example when I stand on top of a filled up firewood holder on the raft—(indicating you're not touching the raft).

Even so, "IsOnRaft" doesn't change, which is interesting.

It seems you are "on the raft" even outside of a collider overlap.

This further points to an issue where the game’s logic for "on-raft" state is decoupled from the actual physical collision state (the collider overlap).

I enabled "superjump" and it seems that "IsOnRaft" remains "true" only about 3 or 4 units (Ty) above the raft. Once above that level, mouse sensitivity normalizes again while the player is in the air.

Which means the problem can be narrowed down...

The issue persists as long as the "IsOnRaft" flag remains true, unless the Oar is in use. When the Oar shows "InUse: True," the sensitivity bug disappears. When the Oar shows "InUse: False," the sensitivity bug resurfaces again.

Which means the Developers are likely using input scaling to ensure smooth, free-looking motion for the camera, as opposed to having the camera move with the raft's swaying and rocking motions in the water.

...

Here's my recommended debugging solution: Instead of modifying the scaling multiplier, you temporarily halve the mouse sensitivity (mouseXSensitivity and mouseYSensitivity) only when the player is on the raft but not steering. Since we know sensitivity is doubling (due to a redundancy), the most hassle-free solution is to halve the sensitivity, as per the settings, whenever "IsOnRaft" is "True" and "OarInUse" is "False" during gameplay.

That way you avoid touching any multiplier logic and giving yourself a migraine. Here's an example (C#) and I'm skipping var declarations. Let's just use common sense to assume these are locally scoped floats:

void Update() {
    // Determine current sensitivities
    float currentXSensitivity = mouseXSensitivity;
    float currentYSensitivity = mouseYSensitivity;

    if (isOnRaft) {
        if (OarInUse) {
            // Steering: Use normal sensitivity
            currentXSensitivity = mouseXSensitivity;
            currentYSensitivity = mouseYSensitivity;
        } else {
            // On raft but not steering: Halve the sensitivity
            currentXSensitivity = mouseXSensitivity / 2.0f;
            currentYSensitivity = mouseYSensitivity / 2.0f;
        }
    }

    // Debugging: Output the current state and sensitivity values
    Debug.Log($"X: {currentXSensitivity}, Y: {currentYSensitivity}, IsOnRaft: {isOnRaft}, OarInUse: {OarInUse}");

    // Apply mouse input
    float mouseX = Input.GetAxis("Mouse X") * currentXSensitivity;
    float mouseY = Input.GetAxis("Mouse Y") * currentYSensitivity;

    // Apply camera rotation
    transform.Rotate(Vector3.up * mouseX);  // Horizontal rotation
    transform.Rotate(Vector3.left * mouseY);  // Vertical rotation
}

// Update oar (steering) state
public void SetOarInUse(bool inUse) {
    OarInUse = inUse;
}

// Update raft state
public void SetIsOnRaft(bool onRaft) {
    isOnRaft = onRaft;
}

Just do the same thing for controllers as well. Then the problem should be solved.

Would this go in the console perhaps or in a form of .ini file?

[Sylar]

Originally posted by Inazuma:

Would this go in the console perhaps or in a form of .ini file?

No, no. This is for the Dev team—it belongs in the codebase. It's written in C#, so it's not just key-value pairs or bind commands; it needs to execute actual logic. The developers can easily integrate it into the relevant game script. The issue with trying to mod via .ini files is that this bug is context-dependent, not a simple settings tweak.

However, modders can still use this approach to inject code into the game's logic through frameworks like BepInEx, which supports IL2CPP.

For a proper mod, you'd need to hook into the player movement script and modify mouse sensitivity based on state transitions related to the raft. The mod would then be compiled into a .dll, placed in the plugin directory, and the problem would be resolved.



But these Devs are ♥♥♥♥♥♥♥ lazy in my honest opinion, and Farket shares my sentiments. Because most of the bugs that have been plaguing this game can be resolved in a couple of weeks. Most of the content added after waiting 6 months, like the rafts and holders, 3 day's work, maximum. I'm not even kidding...

So, something doesn't quite add up. But don't dare complain, or you're just another something, something.

[Inazuma]

Originally posted by Sylar:

Originally posted by Inazuma:

Would this go in the console perhaps or in a form of .ini file?

No, no. This is for the Dev team—it belongs in the codebase. It's written in C#, so it's not just key-value pairs or bind commands; it needs to execute actual logic. The developers can easily integrate it into the relevant game script. The issue with trying to mod via .ini files is that this bug is context-dependent, not a simple settings tweak.

However, modders can still use this approach to inject code into the game's logic through frameworks like BepInEx, which supports IL2CPP.

For a proper mod, you'd need to hook into the player movement script and modify mouse sensitivity based on state transitions related to the raft. The mod would then be compiled into a .dll, placed in the plugin directory, and the problem would be resolved.



But these Devs are ♥♥♥♥♥♥♥ lazy in my honest opinion, and Farket shares my sentiments. Because most of the bugs that have been plaguing this game can be resolved in a couple of weeks. Most of the content added after waiting 6 months, like the rafts and holders, 3 day's work, maximum. I'm not even kidding...

So, something doesn't quite add up. But don't dare complain, or you're just another something, something.

Ohhhhh, my bad. That makes much more sense :P