Jump to content

Severe synchronization/input issues on macOS(Sequoia 15.4 Beta 24E5206s) causing persistent rubber-banding and inability to interact with objects


Royce233
  • Fixed

[DST] Severe synchronization/input issues on macOS causing persistent rubber-banding and inability to interact with objects

Platform: macOS (latest version) Game Version: Latest Steam version of Don't Starve Together Issue:

When playing Don't Starve Together (DST) on macOS, my character experiences severe synchronization issues. Specifically:

  • Upon starting or joining a world, my character constantly "rubber-bands" back to the spawn point. Any attempt to move causes immediate teleportation back to the original spot.
  • Interaction with objects (items, resources, structures) does not function. Clicking items only triggers the animation briefly but never completes the interaction.
  • When enabling Lag Compensation, pressing a directional key once causes the character to run indefinitely in that direction, unable to stop unless pressing the spacebar. Interaction still remains impossible.
  • The issue persists even in Offline Mode (hosting local games), ruling out network or server-side latency.

Steps Taken (with no effect):

  • Verified integrity of game files via Steam.
  • Completely removed mods and tested on fresh worlds.
  • Deleted entire DST directory at ~/Documents/Klei/DoNotStarveTogether to reset configurations.
  • Fully reinstalled DST via Steam after manually deleting local files.
  • Tested using both built-in MacBook trackpad and external mouse/keyboard.
  • Disabled Steam overlay.
  • Checked macOS firewall, input monitoring, and accessibility permissions.

Additional Info:

  • No unusual logs appear obviously, but I can provide logs if directed.
  • Issue renders the game entirely unplayable on my Mac.

Thank you for your assistance.


Steps to Reproduce

[DST] Severe synchronization/input issues on macOS causing persistent rubber-banding and inability to interact with objects

Platform: macOS (latest version) Game Version: Latest Steam version of Don't Starve Together Issue:

When playing Don't Starve Together (DST) on macOS, my character experiences severe synchronization issues. Specifically:

  • Upon starting or joining a world, my character constantly "rubber-bands" back to the spawn point. Any attempt to move causes immediate teleportation back to the original spot.
  • Interaction with objects (items, resources, structures) does not function. Clicking items only triggers the animation briefly but never completes the interaction.
  • When enabling Lag Compensation, pressing a directional key once causes the character to run indefinitely in that direction, unable to stop unless pressing the spacebar. Interaction still remains impossible.
  • The issue persists even in Offline Mode (hosting local games), ruling out network or server-side latency.

Steps Taken (with no effect):

  • Verified integrity of game files via Steam.
  • Completely removed mods and tested on fresh worlds.
  • Deleted entire DST directory at ~/Documents/Klei/DoNotStarveTogether to reset configurations.
  • Fully reinstalled DST via Steam after manually deleting local files.
  • Tested using both built-in MacBook trackpad and external mouse/keyboard.
  • Disabled Steam overlay.
  • Checked macOS firewall, input monitoring, and accessibility permissions.

Additional Info:

  • No unusual logs appear obviously, but I can provide logs if directed.
  • Issue renders the game entirely unplayable on my Mac.

Thank you for your assistance.

  • Like 2
  • Sad 3
  • Sanity 2



User Feedback




A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.

I am having the exact same issue, please let me know if you find a solution!

I'm not sure if this is relevant, but my partner plays DST with me on an identical laptop to mine (13 Inch M1 Macbook 2020) and has no issues. As far as I can tell, the only difference between her computer and mine is that I am on the Mac OS Developer Beta (like Royce233, I am on 15.4 Beta (24E5206s)).

Also I think that my movement behavior is reversed from yours: when I have predictive lag compensation turned on, my character rubber bands every time it gets a certain distance away from the portal. But, with lag compensation turned off, my character keeps moving in a direction even after I release the key. For example, if I tap w and release it, the character continues to move in that direction. I also noticed that if you rotate the camera the character moves in the same world-direction (i.e., tapping w and then rotating the camera once causes the character to be running diagonally).

I tried many of the same things as Royce233 (I deleted my Dont Starve Together directory under Documents/Klei. I also tried disabling all of my mods, both client and server side, and starting new world, without any luck.

Edited by NarcolepticFrog

Share this comment


Link to comment
Share on other sites

11 hours ago, NarcolepticFrog said:

I am having the exact same issue, please let me know if you find a solution!

I'm not sure if this is relevant, but my partner plays DST with me on an identical laptop to mine (13 Inch M1 Macbook 2020) and has no issues. As far as I can tell, the only difference between her computer and mine is that I am on the Mac OS Developer Beta (like Royce233, I am on 15.4 Beta (24E5206s)).

Also I think that my movement behavior is reversed from yours: when I have predictive lag compensation turned on, my character rubber bands every time it gets a certain distance away from the portal. But, with lag compensation turned off, my character keeps moving in a direction even after I release the key. For example, if I tap w and release it, the character continues to move in that direction. I also noticed that if you rotate the camera the character moves in the same world-direction (i.e., tapping w and then rotating the camera once causes the character to be running diagonally).

I tried many of the same things as Royce233 (I deleted my Dont Starve Together directory under Documents/Klei. I also tried disabling all of my mods, both client and server side, and starting new world, without any luck.

That’s right! I have experienced the exact same situation as you when predictive lag compensation turned on or turned off.

Share this comment


Link to comment
Share on other sites

11 hours ago, NarcolepticFrog said:

I am having the exact same issue, please let me know if you find a solution!

I'm not sure if this is relevant, but my partner plays DST with me on an identical laptop to mine (13 Inch M1 Macbook 2020) and has no issues. As far as I can tell, the only difference between her computer and mine is that I am on the Mac OS Developer Beta (like Royce233, I am on 15.4 Beta (24E5206s)).

Also I think that my movement behavior is reversed from yours: when I have predictive lag compensation turned on, my character rubber bands every time it gets a certain distance away from the portal. But, with lag compensation turned off, my character keeps moving in a direction even after I release the key. For example, if I tap w and release it, the character continues to move in that direction. I also noticed that if you rotate the camera the character moves in the same world-direction (i.e., tapping w and then rotating the camera once causes the character to be running diagonally).

I tried many of the same things as Royce233 (I deleted my Dont Starve Together directory under Documents/Klei. I also tried disabling all of my mods, both client and server side, and starting new world, without any luck.

Thank you for helping me clarify the issue I encountered

Share this comment


Link to comment
Share on other sites

Yes, I can confirm that I encounter the same bug. The problem persists in macOS 15.4 Beta 2 (24E5222f).

Share this comment


Link to comment
Share on other sites

I was troubled by a similar bug, but it seems that turning off game mode fixed it. It’s not a fundamental solution, and I haven’t fully confirmed it yet.

Share this comment


Link to comment
Share on other sites

Similar problem occurs today on macOC Sequoia 15.4. Cannot interact with anything. Keep moving in one direction.

Share this comment


Link to comment
Share on other sites

Was going through this same issue even on macOS 15.5 beta, and I created a new world without caves. For some reason, I have no trouble playing in this world. But worlds with caves cause rubber banding and inability to interact. 

  • Like 1

Share this comment


Link to comment
Share on other sites

I'll confirm this as well. I might have some details to add. Today on Sunday I played with my friend, I had this issue, my friend did not. I recently upgraded to Sequoia 15.4. (My friend I'm not sure what MacOS version they are but might be pre-Sequoia).

I use a dedicated Linux server as the host, and RPCs are failing, e.g. at join of myself I see:

[00:07:34]: Invalid SetMovementPredictionEnabled RPC from (XXX) Noeda
[00:07:34]: Invalid SetSkillActivatedState arguments RPC from (XXX) Noeda
[00:07:36]: Invalid MakeRecipeAtPoint RPC from (XXX) Noeda
[00:07:41]: Invalid PutAllOfActiveItemInSlot RPC from (XXX) Noeda
[00:07:41]: Invalid PutAllOfActiveItemInSlot RPC from (XXX) Noeda
[00:07:41]: Invalid PutAllOfActiveItemInSlot RPC from (XXX) Noeda
[00:07:41]: Invalid PutAllOfActiveItemInSlot RPC from (XXX) Noeda
[00:07:41]: Invalid PutAllOfActiveItemInSlot RPC from (XXX) Noeda

(I censored the ID thingy with XXX but I'm not sure if that's even sensitive but whatever).

The PutAllOfActiveItemInSlot seems to be about if I try to wear or move items. The first three seem related to joining the server.

I worked around it by playing on Windows (which is unlikely to be a viable workaround for many; I just happen to have multiple computers).

It is bizarre to me that OS itself would cause the issue. I've thought of checking traffic between the server and the game or even dropping the executable to Ghidra (decompiler/reverse engineer tool) to decipher how do RPCs work internally; what's actually in them, and why would an OS change make them fail (one idea is that there's some checksum or a component in the protocol that somehow involves something from OS, like OS identifier or something, but that's purely a hunch).

I'm a developer, and briefly looked at Lua side of code which is readable, but I think the RPC implementation is perhaps in the non-Lua game engine (need to check more, only did a cursory look so far). If anyone finds a workaround, great!

I don't want to promise anything for others but: if Klei doesn't come with a fix soonish, I might put in my developer chops to try reverse engineer why is it failing and is there a workaround. I play every Sunday and this is an actually important friend-time routine with me going for years, so I'm quite invested that this gets fixed (or workarounded). My friend for example won't upgrade their MacOS now until we figure this out.

I'll also confirm @NarcolepticFrog here:

On 3/1/2025 at 6:07 AM, NarcolepticFrog said:

Also I think that my movement behavior is reversed from yours: when I have predictive lag compensation turned on, my character rubber bands every time it gets a certain distance away from the portal. But, with lag compensation turned off, my character keeps moving in a direction even after I release the key. For example, if I tap w and release it, the character continues to move in that direction.

This is 100% precisely what I observed. I didn't think to check camera thing but this is so on point I'm convinced we are all talking about the same issue. I also tried many of the methods listed before I stumbled on this thread here by Google.

I find it interesting that this was reported February 27 but I only noticed it this Sunday (last Sunday worked fine). What I did was upgrade to latest Sequoia 15.4.

Quoting
@NarcolepticFrog again: "As far as I can tell, the only difference between her computer and mine is that I am on the Mac OS Developer Beta (like Royce233, I am on 15.4 Beta (24E5206s))." I guess that is likely the point of brokenness; now that 15.4 landed for everyone as Stable, every Mac user gets this bug.

  • Potato Cup 1

Share this comment


Link to comment
Share on other sites

I had a bit of time just now to check deeper, and looked in the Lua part specifically because that doesn't involve decompiling. Posting a bit of progress just in case some other invested code nerd who has experience with the game's inner workings is also looking around this. I'm writing this hastily to braindump so apologies if anything is hard to read or understand.

This is specifically on client side. My server is on Linux, and only Mac clients fail. Possibly things might fail even more if the server was also on a Mac but I have not tested that.

There's this piece of code (this is inside scripts.zip, and the file is called networkclientrpc.lua, around line 855)

     SetMovementPredictionEnabled = function(player, enabled)
         if not (checkbool(enabled)) then
             printinvalid("SetMovementPredictionEnabled", player)
             return
         end
         ...

I tracked down that the first error message I get is from printinvalid() here, that calls standard Lua print. I hacked it in this way to learn more:

     SetMovementPredictionEnabled = function(player, enabled)
         if not (checkbool(enabled)) then
             print('The enabled flag is: ', enabled)
             print('The enabled type(flag) is: ', type(enabled))
             printinvalid("SetMovementPredictionEnabled", player)
             return
         end
         ...

I got "The enabled flag is: 0" and "The enabled type(flag) is: number". In Lua, 0 is considered 'true'. The flag is almost certainly supposed to be "true" or "false" and "boolean" as a type instead of "0" and "number".

The RPC handling on Lua side is getting a number instead of a boolean, and the code has been written to check for that, and fails. In the game menu, when you turn on predictive lag thingy, on or off, the server RPC error still says it is the number 0. (I thought maybe it would be 0 for "off" and 1 for "on" but I now think it's 0 because it's buggy).

Movement is not RPC maybe; I don't see errors for that but I think it's possible that the code simply doesn't have print() calls to report on it when movement RPCs fail.

I dumped some traffic-related syscalls with `strace` on server side and compared traffic from MacOS client and Windows client (i.e. bad case and good case), and it isn't different enough to be able to eyeball that one is obviously wrong. Although I did learn apparently DST does not use any encryption in the traffic? The server password and all chat messages were in cleartext over the protocol, at least on the syscall level.

The RPC codepath inside Ghidra, looking at decompiled code, I didn't see any OS-provided functions being used other than memcpy() so far. This is a pretty far-fetched idea IMO but possibly game engine might be relying that memcpy() with overlapping memory areas behaves in a certain way, and OS upgrade changed the behavior (it is an incorrect use of memcpy to use it on overlapping memory areas; doesn't mean people don't do it). I feel this is pretty outlandish and not likely to be true because if that was the case, I think my Googling would have found issues in other projects too because memcpy is a very common function to use. (I was also surprised it wasn't inlined in apparently in the code, or maybe I just saw the ones that didn't get inlined in decompilation).

I'll likely be back with some more digging unless the bug gets fixed meanwhile :) or I learn about a workaround that's not "don't use Mac". Likely deciphering how the protocol works in more detail, all I can say so far it looks like there's counters inside the payload for each package, but I didn't write down notes what the actual structure of a payload really is.

Share this comment


Link to comment
Share on other sites

The official macOS Version 15.4 (24E248) has now been released. After updating, I encountered exactly the same issue again.

Share this comment


Link to comment
Share on other sites

I found the problem. A large portion RPC codes inside the game have shifted by one, and it looks a lot like some operating system string comparison function likely stopped caring about case sensitivity. There is an RPC call called "exitgym" that normally is code 74 (last one). It instead switched to position 29, and by doing that, it also shifted up about 2/3 of all the other RPC call codes, making the game very confused when it tries to communicate with a server. I think the RPC code logic is used even in a totally local game, so it makes sense the OP here had issues with local game as well.

"exitgym" alphabetically is in the "correct" place now in Sequoia, but all other editions of the game don't use alphabetical sorting, but rather sorting by byte, in which case lower-case starting RPC calls should be sorted to the last place. (and there is only one of them, "exitgym").

I had the game dump internal codes for RPC handlers and compared what I got on Linux vs Mac. These are long pastes but it might be easier to understand, look for "exitgym" in the pastes below and what their RPC number is.

MacOS (the bad listing of codes)

MacOS Sequoia 15.4

[00:00:02]: RPC 1 = ActionButton
[00:00:02]: RPC 2 = AddAllOfActiveItemToSlot
[00:00:02]: RPC 3 = AddOneOfActiveItemToSlot
[00:00:02]: RPC 4 = AddSkillXP
[00:00:02]: RPC 5 = AOECharging
[00:00:02]: RPC 6 = AttackButton
[00:00:02]: RPC 7 = BufferBuild
[00:00:02]: RPC 8 = CannotBuild
[00:00:02]: RPC 9 = CastSpellBookFromInv
[00:00:02]: RPC 10 = ClearActionHold
[00:00:02]: RPC 11 = ClosePopup
[00:00:02]: RPC 12 = ControllerActionButton
[00:00:02]: RPC 13 = ControllerActionButtonDeploy
[00:00:02]: RPC 14 = ControllerActionButtonPoint
[00:00:02]: RPC 15 = ControllerAltActionButton
[00:00:02]: RPC 16 = ControllerAltActionButtonPoint
[00:00:02]: RPC 17 = ControllerAttackButton
[00:00:02]: RPC 18 = ControllerUseItemOnItemFromInvTile
[00:00:02]: RPC 19 = ControllerUseItemOnSceneFromInvTile
[00:00:02]: RPC 20 = ControllerUseItemOnSelfFromInvTile
[00:00:02]: RPC 21 = DirectWalking
[00:00:02]: RPC 22 = DoActionOnMap
[00:00:02]: RPC 23 = DoubleTapAction
[00:00:02]: RPC 24 = DoWidgetButtonAction
[00:00:02]: RPC 25 = DragWalking
[00:00:02]: RPC 26 = DropItemFromInvTile
[00:00:02]: RPC 27 = EquipActionItem
[00:00:02]: RPC 28 = EquipActiveItem
[00:00:02]: RPC 29 = exitgym
[00:00:02]: RPC 30 = GetChatHistory
[00:00:02]: RPC 31 = InspectButton
[00:00:02]: RPC 32 = InspectItemFromInvTile
[00:00:02]: RPC 33 = InteractionTarget
[00:00:02]: RPC 34 = LeftClick
[00:00:02]: RPC 35 = MakeRecipeAtPoint
[00:00:02]: RPC 36 = MakeRecipeFromMenu
[00:00:02]: RPC 37 = MoveInvItemFromAllOfSlot
[00:00:02]: RPC 38 = MoveInvItemFromCountOfSlot
[00:00:02]: RPC 39 = MoveInvItemFromHalfOfSlot
[00:00:02]: RPC 40 = MoveItemFromAllOfSlot
[00:00:02]: RPC 41 = MoveItemFromCountOfSlot
[00:00:02]: RPC 42 = MoveItemFromHalfOfSlot
[00:00:02]: RPC 43 = OnScrapbookDataTaught
[00:00:02]: RPC 44 = OpenGift
[00:00:02]: RPC 45 = PostActivateHandshake
[00:00:02]: RPC 46 = PredictOverrideLocomote
[00:00:02]: RPC 47 = PredictWalking
[00:00:02]: RPC 48 = PutAllOfActiveItemInSlot
[00:00:02]: RPC 49 = PutOneOfActiveItemInSlot
[00:00:02]: RPC 50 = RepeatHeldAction
[00:00:02]: RPC 51 = ResurrectButton
[00:00:02]: RPC 52 = ReturnActiveItem
[00:00:02]: RPC 53 = RightClick
[00:00:02]: RPC 54 = SetClientAuthoritativeSetting
[00:00:02]: RPC 55 = SetMovementPredictionEnabled
[00:00:02]: RPC 56 = SetSkillActivatedState
[00:00:02]: RPC 57 = SetWriteableText
[00:00:02]: RPC 58 = StartHop
[00:00:02]: RPC 59 = SteerBoat
[00:00:02]: RPC 60 = StopAllControls
[00:00:02]: RPC 61 = StopControl
[00:00:02]: RPC 62 = StopWalking
[00:00:02]: RPC 63 = StrafeFacing
[00:00:02]: RPC 64 = SwapActiveItemWithSlot
[00:00:02]: RPC 65 = SwapEquipWithActiveItem
[00:00:02]: RPC 66 = SwapOneOfActiveItemWithSlot
[00:00:02]: RPC 67 = TakeActiveItemFromAllOfSlot
[00:00:02]: RPC 68 = TakeActiveItemFromCountOfSlot
[00:00:02]: RPC 69 = TakeActiveItemFromEquipSlot
[00:00:02]: RPC 70 = TakeActiveItemFromHalfOfSlot
[00:00:02]: RPC 71 = ToggleController
[00:00:02]: RPC 72 = UseItemFromInvTile
[00:00:02]: RPC 73 = WakeUp
[00:00:02]: RPC 74 = WobyCommand

Linux (how the codes are supposed to be)

Linux

[00:00:06]: RPC 1 = AOECharging
[00:00:06]: RPC 2 = ActionButton
[00:00:06]: RPC 3 = AddAllOfActiveItemToSlot
[00:00:06]: RPC 4 = AddOneOfActiveItemToSlot
[00:00:06]: RPC 5 = AddSkillXP
[00:00:06]: RPC 6 = AttackButton
[00:00:06]: RPC 7 = BufferBuild
[00:00:06]: RPC 8 = CannotBuild
[00:00:06]: RPC 9 = CastSpellBookFromInv
[00:00:06]: RPC 10 = ClearActionHold
[00:00:06]: RPC 11 = ClosePopup
[00:00:06]: RPC 12 = ControllerActionButton
[00:00:06]: RPC 13 = ControllerActionButtonDeploy
[00:00:06]: RPC 14 = ControllerActionButtonPoint
[00:00:06]: RPC 15 = ControllerAltActionButton
[00:00:06]: RPC 16 = ControllerAltActionButtonPoint
[00:00:06]: RPC 17 = ControllerAttackButton
[00:00:06]: RPC 18 = ControllerUseItemOnItemFromInvTile
[00:00:06]: RPC 19 = ControllerUseItemOnSceneFromInvTile
[00:00:06]: RPC 20 = ControllerUseItemOnSelfFromInvTile
[00:00:06]: RPC 21 = DirectWalking
[00:00:06]: RPC 22 = DoActionOnMap
[00:00:06]: RPC 23 = DoWidgetButtonAction
[00:00:06]: RPC 24 = DoubleTapAction
[00:00:06]: RPC 25 = DragWalking
[00:00:06]: RPC 26 = DropItemFromInvTile
[00:00:06]: RPC 27 = EquipActionItem
[00:00:06]: RPC 28 = EquipActiveItem
[00:00:06]: RPC 29 = GetChatHistory
[00:00:06]: RPC 30 = InspectButton
[00:00:06]: RPC 31 = InspectItemFromInvTile
[00:00:06]: RPC 32 = InteractionTarget
[00:00:06]: RPC 33 = LeftClick
[00:00:06]: RPC 34 = MakeRecipeAtPoint
[00:00:06]: RPC 35 = MakeRecipeFromMenu
[00:00:06]: RPC 36 = MoveInvItemFromAllOfSlot
[00:00:06]: RPC 37 = MoveInvItemFromCountOfSlot
[00:00:06]: RPC 38 = MoveInvItemFromHalfOfSlot
[00:00:06]: RPC 39 = MoveItemFromAllOfSlot
[00:00:06]: RPC 40 = MoveItemFromCountOfSlot
[00:00:06]: RPC 41 = MoveItemFromHalfOfSlot
[00:00:06]: RPC 42 = OnScrapbookDataTaught
[00:00:06]: RPC 43 = OpenGift
[00:00:06]: RPC 44 = PostActivateHandshake
[00:00:06]: RPC 45 = PredictOverrideLocomote
[00:00:06]: RPC 46 = PredictWalking
[00:00:06]: RPC 47 = PutAllOfActiveItemInSlot
[00:00:06]: RPC 48 = PutOneOfActiveItemInSlot
[00:00:06]: RPC 49 = RepeatHeldAction
[00:00:06]: RPC 50 = ResurrectButton
[00:00:06]: RPC 51 = ReturnActiveItem
[00:00:06]: RPC 52 = RightClick
[00:00:06]: RPC 53 = SetClientAuthoritativeSetting
[00:00:06]: RPC 54 = SetMovementPredictionEnabled
[00:00:06]: RPC 55 = SetSkillActivatedState
[00:00:06]: RPC 56 = SetWriteableText
[00:00:06]: RPC 57 = StartHop
[00:00:06]: RPC 58 = SteerBoat
[00:00:06]: RPC 59 = StopAllControls
[00:00:06]: RPC 60 = StopControl
[00:00:06]: RPC 61 = StopWalking
[00:00:06]: RPC 62 = StrafeFacing
[00:00:06]: RPC 63 = SwapActiveItemWithSlot
[00:00:06]: RPC 64 = SwapEquipWithActiveItem
[00:00:06]: RPC 65 = SwapOneOfActiveItemWithSlot
[00:00:06]: RPC 66 = TakeActiveItemFromAllOfSlot
[00:00:06]: RPC 67 = TakeActiveItemFromCountOfSlot
[00:00:06]: RPC 68 = TakeActiveItemFromEquipSlot
[00:00:06]: RPC 69 = TakeActiveItemFromHalfOfSlot
[00:00:06]: RPC 70 = ToggleController
[00:00:06]: RPC 71 = UseItemFromInvTile
[00:00:06]: RPC 72 = WakeUp
[00:00:06]: RPC 73 = WobyCommand
[00:00:06]: RPC 74 = exitgym

The game gets confused about codes; my earlier post where I saw 0 is because the server misinterpreted what RPC command was sent to it.

I used this hack to fix it in `util.lua` (look for __genOrderedIndex). I slapped a custom comparison to table.sort there:

function __genOrderedIndex( t )
    local orderedIndex = {}
    for key in pairs(t) do
        table.insert( orderedIndex, key )
    end
    -- This used to be just:
    -- table.sort( orderedIndex )
    -- I hacked a comparison function to force "exitgym" to be last in the list.
    table.sort( orderedIndex, function(a, b)
        -- "exitgym" must be last, so always treat it as "bigger"
        if a == "exitgym" then
            return false
        end
        return a < b
    end)
    return orderedIndex
end

This is a very unclean way to fix it, but if someone wants to make this into a mod before waiting for Klei fix, go ahead. I am hoping that by next Sunday there's some fix in place from Klei. But if you really really really want to fix it right now using that horrible hack above: Go to your game files, go inside your "dontstarve_steam.app" (right click, "Show Contents"), find scripts.zip in databundles/, unzip it, find util.lua, find the piece of code above with __genOrderedIndex, replace it with that code above. Zip it back to scripts.zip and launch the game. The game will show a scary warning that "it may be broken" (it detects the scripts.zip has changed). If you have Steam verify the files, it'll change the scripts.zip back.

If you have DST from some other source (not sure there are other sources besides Steam for Mac), I'd assume there's an .app of some kind where you can do all that.

I don't know exactly which C or C++ function in Sequoia 15.4 broke (guessing something from POSIX/standard C library, there's a whole bunch of string comparison functions and I rarely use them in my work so less familiar) but it seems very plausible some commonly used comparison function changed behavior, maybe unintentionally from Apple's part. I stopped looking deeper now that I found a workaround.

I have absolutely no idea what is "exitgym". Are there gyms in the game? Game only allows you to exit one. Not enter one. At least based on this little investigation ;)

Edit: also realized after posting I technically wrote the hacked Lua code incorrectly ("exitgym" could be presented through 'b' variable instead) but it seems to work anyway for me. You'd add an if block for b == "exitgym" and then unconditionally return true for that case. Might be working by accident.

Edited by Noeda
Mentioned my code has a bug but seems to work anyway. And also it is util.lua, not utils.lua.
  • Like 2
  • Thanks 1
  • Big Ups 1

Share this comment


Link to comment
Share on other sites

14 hours ago, Noeda said:

I found the problem. A large portion RPC codes inside the game have shifted by one, and it looks a lot like some operating system string comparison function likely stopped caring about case sensitivity. There is an RPC call called "exitgym" that normally is code 74 (last one). It instead switched to position 29, and by doing that, it also shifted up about 2/3 of all the other RPC call codes, making the game very confused when it tries to communicate with a server. I think the RPC code logic is used even in a totally local game, so it makes sense the OP here had issues with local game as well.

"exitgym" alphabetically is in the "correct" place now in Sequoia, but all other editions of the game don't use alphabetical sorting, but rather sorting by byte, in which case lower-case starting RPC calls should be sorted to the last place. (and there is only one of them, "exitgym").

I had the game dump internal codes for RPC handlers and compared what I got on Linux vs Mac. These are long pastes but it might be easier to understand, look for "exitgym" in the pastes below and what their RPC number is.

MacOS (the bad listing of codes)

MacOS Sequoia 15.4

[00:00:02]: RPC 1 = ActionButton
[00:00:02]: RPC 2 = AddAllOfActiveItemToSlot
[00:00:02]: RPC 3 = AddOneOfActiveItemToSlot
[00:00:02]: RPC 4 = AddSkillXP
[00:00:02]: RPC 5 = AOECharging
[00:00:02]: RPC 6 = AttackButton
[00:00:02]: RPC 7 = BufferBuild
[00:00:02]: RPC 8 = CannotBuild
[00:00:02]: RPC 9 = CastSpellBookFromInv
[00:00:02]: RPC 10 = ClearActionHold
[00:00:02]: RPC 11 = ClosePopup
[00:00:02]: RPC 12 = ControllerActionButton
[00:00:02]: RPC 13 = ControllerActionButtonDeploy
[00:00:02]: RPC 14 = ControllerActionButtonPoint
[00:00:02]: RPC 15 = ControllerAltActionButton
[00:00:02]: RPC 16 = ControllerAltActionButtonPoint
[00:00:02]: RPC 17 = ControllerAttackButton
[00:00:02]: RPC 18 = ControllerUseItemOnItemFromInvTile
[00:00:02]: RPC 19 = ControllerUseItemOnSceneFromInvTile
[00:00:02]: RPC 20 = ControllerUseItemOnSelfFromInvTile
[00:00:02]: RPC 21 = DirectWalking
[00:00:02]: RPC 22 = DoActionOnMap
[00:00:02]: RPC 23 = DoubleTapAction
[00:00:02]: RPC 24 = DoWidgetButtonAction
[00:00:02]: RPC 25 = DragWalking
[00:00:02]: RPC 26 = DropItemFromInvTile
[00:00:02]: RPC 27 = EquipActionItem
[00:00:02]: RPC 28 = EquipActiveItem
[00:00:02]: RPC 29 = exitgym
[00:00:02]: RPC 30 = GetChatHistory
[00:00:02]: RPC 31 = InspectButton
[00:00:02]: RPC 32 = InspectItemFromInvTile
[00:00:02]: RPC 33 = InteractionTarget
[00:00:02]: RPC 34 = LeftClick
[00:00:02]: RPC 35 = MakeRecipeAtPoint
[00:00:02]: RPC 36 = MakeRecipeFromMenu
[00:00:02]: RPC 37 = MoveInvItemFromAllOfSlot
[00:00:02]: RPC 38 = MoveInvItemFromCountOfSlot
[00:00:02]: RPC 39 = MoveInvItemFromHalfOfSlot
[00:00:02]: RPC 40 = MoveItemFromAllOfSlot
[00:00:02]: RPC 41 = MoveItemFromCountOfSlot
[00:00:02]: RPC 42 = MoveItemFromHalfOfSlot
[00:00:02]: RPC 43 = OnScrapbookDataTaught
[00:00:02]: RPC 44 = OpenGift
[00:00:02]: RPC 45 = PostActivateHandshake
[00:00:02]: RPC 46 = PredictOverrideLocomote
[00:00:02]: RPC 47 = PredictWalking
[00:00:02]: RPC 48 = PutAllOfActiveItemInSlot
[00:00:02]: RPC 49 = PutOneOfActiveItemInSlot
[00:00:02]: RPC 50 = RepeatHeldAction
[00:00:02]: RPC 51 = ResurrectButton
[00:00:02]: RPC 52 = ReturnActiveItem
[00:00:02]: RPC 53 = RightClick
[00:00:02]: RPC 54 = SetClientAuthoritativeSetting
[00:00:02]: RPC 55 = SetMovementPredictionEnabled
[00:00:02]: RPC 56 = SetSkillActivatedState
[00:00:02]: RPC 57 = SetWriteableText
[00:00:02]: RPC 58 = StartHop
[00:00:02]: RPC 59 = SteerBoat
[00:00:02]: RPC 60 = StopAllControls
[00:00:02]: RPC 61 = StopControl
[00:00:02]: RPC 62 = StopWalking
[00:00:02]: RPC 63 = StrafeFacing
[00:00:02]: RPC 64 = SwapActiveItemWithSlot
[00:00:02]: RPC 65 = SwapEquipWithActiveItem
[00:00:02]: RPC 66 = SwapOneOfActiveItemWithSlot
[00:00:02]: RPC 67 = TakeActiveItemFromAllOfSlot
[00:00:02]: RPC 68 = TakeActiveItemFromCountOfSlot
[00:00:02]: RPC 69 = TakeActiveItemFromEquipSlot
[00:00:02]: RPC 70 = TakeActiveItemFromHalfOfSlot
[00:00:02]: RPC 71 = ToggleController
[00:00:02]: RPC 72 = UseItemFromInvTile
[00:00:02]: RPC 73 = WakeUp
[00:00:02]: RPC 74 = WobyCommand

Linux (how the codes are supposed to be)

Linux

[00:00:06]: RPC 1 = AOECharging
[00:00:06]: RPC 2 = ActionButton
[00:00:06]: RPC 3 = AddAllOfActiveItemToSlot
[00:00:06]: RPC 4 = AddOneOfActiveItemToSlot
[00:00:06]: RPC 5 = AddSkillXP
[00:00:06]: RPC 6 = AttackButton
[00:00:06]: RPC 7 = BufferBuild
[00:00:06]: RPC 8 = CannotBuild
[00:00:06]: RPC 9 = CastSpellBookFromInv
[00:00:06]: RPC 10 = ClearActionHold
[00:00:06]: RPC 11 = ClosePopup
[00:00:06]: RPC 12 = ControllerActionButton
[00:00:06]: RPC 13 = ControllerActionButtonDeploy
[00:00:06]: RPC 14 = ControllerActionButtonPoint
[00:00:06]: RPC 15 = ControllerAltActionButton
[00:00:06]: RPC 16 = ControllerAltActionButtonPoint
[00:00:06]: RPC 17 = ControllerAttackButton
[00:00:06]: RPC 18 = ControllerUseItemOnItemFromInvTile
[00:00:06]: RPC 19 = ControllerUseItemOnSceneFromInvTile
[00:00:06]: RPC 20 = ControllerUseItemOnSelfFromInvTile
[00:00:06]: RPC 21 = DirectWalking
[00:00:06]: RPC 22 = DoActionOnMap
[00:00:06]: RPC 23 = DoWidgetButtonAction
[00:00:06]: RPC 24 = DoubleTapAction
[00:00:06]: RPC 25 = DragWalking
[00:00:06]: RPC 26 = DropItemFromInvTile
[00:00:06]: RPC 27 = EquipActionItem
[00:00:06]: RPC 28 = EquipActiveItem
[00:00:06]: RPC 29 = GetChatHistory
[00:00:06]: RPC 30 = InspectButton
[00:00:06]: RPC 31 = InspectItemFromInvTile
[00:00:06]: RPC 32 = InteractionTarget
[00:00:06]: RPC 33 = LeftClick
[00:00:06]: RPC 34 = MakeRecipeAtPoint
[00:00:06]: RPC 35 = MakeRecipeFromMenu
[00:00:06]: RPC 36 = MoveInvItemFromAllOfSlot
[00:00:06]: RPC 37 = MoveInvItemFromCountOfSlot
[00:00:06]: RPC 38 = MoveInvItemFromHalfOfSlot
[00:00:06]: RPC 39 = MoveItemFromAllOfSlot
[00:00:06]: RPC 40 = MoveItemFromCountOfSlot
[00:00:06]: RPC 41 = MoveItemFromHalfOfSlot
[00:00:06]: RPC 42 = OnScrapbookDataTaught
[00:00:06]: RPC 43 = OpenGift
[00:00:06]: RPC 44 = PostActivateHandshake
[00:00:06]: RPC 45 = PredictOverrideLocomote
[00:00:06]: RPC 46 = PredictWalking
[00:00:06]: RPC 47 = PutAllOfActiveItemInSlot
[00:00:06]: RPC 48 = PutOneOfActiveItemInSlot
[00:00:06]: RPC 49 = RepeatHeldAction
[00:00:06]: RPC 50 = ResurrectButton
[00:00:06]: RPC 51 = ReturnActiveItem
[00:00:06]: RPC 52 = RightClick
[00:00:06]: RPC 53 = SetClientAuthoritativeSetting
[00:00:06]: RPC 54 = SetMovementPredictionEnabled
[00:00:06]: RPC 55 = SetSkillActivatedState
[00:00:06]: RPC 56 = SetWriteableText
[00:00:06]: RPC 57 = StartHop
[00:00:06]: RPC 58 = SteerBoat
[00:00:06]: RPC 59 = StopAllControls
[00:00:06]: RPC 60 = StopControl
[00:00:06]: RPC 61 = StopWalking
[00:00:06]: RPC 62 = StrafeFacing
[00:00:06]: RPC 63 = SwapActiveItemWithSlot
[00:00:06]: RPC 64 = SwapEquipWithActiveItem
[00:00:06]: RPC 65 = SwapOneOfActiveItemWithSlot
[00:00:06]: RPC 66 = TakeActiveItemFromAllOfSlot
[00:00:06]: RPC 67 = TakeActiveItemFromCountOfSlot
[00:00:06]: RPC 68 = TakeActiveItemFromEquipSlot
[00:00:06]: RPC 69 = TakeActiveItemFromHalfOfSlot
[00:00:06]: RPC 70 = ToggleController
[00:00:06]: RPC 71 = UseItemFromInvTile
[00:00:06]: RPC 72 = WakeUp
[00:00:06]: RPC 73 = WobyCommand
[00:00:06]: RPC 74 = exitgym

The game gets confused about codes; my earlier post where I saw 0 is because the server misinterpreted what RPC command was sent to it.

I used this hack to fix it in `util.lua` (look for __genOrderedIndex). I slapped a custom comparison to table.sort there:

function __genOrderedIndex( t )
    local orderedIndex = {}
    for key in pairs(t) do
        table.insert( orderedIndex, key )
    end
    -- This used to be just:
    -- table.sort( orderedIndex )
    -- I hacked a comparison function to force "exitgym" to be last in the list.
    table.sort( orderedIndex, function(a, b)
        -- "exitgym" must be last, so always treat it as "bigger"
        if a == "exitgym" then
            return false
        end
        return a < b
    end)
    return orderedIndex
end

This is a very unclean way to fix it, but if someone wants to make this into a mod before waiting for Klei fix, go ahead. I am hoping that by next Sunday there's some fix in place from Klei. But if you really really really want to fix it right now using that horrible hack above: Go to your game files, go inside your "dontstarve_steam.app" (right click, "Show Contents"), find scripts.zip in databundles/, unzip it, find util.lua, find the piece of code above with __genOrderedIndex, replace it with that code above. Zip it back to scripts.zip and launch the game. The game will show a scary warning that "it may be broken" (it detects the scripts.zip has changed). If you have Steam verify the files, it'll change the scripts.zip back.

If you have DST from some other source (not sure there are other sources besides Steam for Mac), I'd assume there's an .app of some kind where you can do all that.

I don't know exactly which C or C++ function in Sequoia 15.4 broke (guessing something from POSIX/standard C library, there's a whole bunch of string comparison functions and I rarely use them in my work so less familiar) but it seems very plausible some commonly used comparison function changed behavior, maybe unintentionally from Apple's part. I stopped looking deeper now that I found a workaround.

I have absolutely no idea what is "exitgym". Are there gyms in the game? Game only allows you to exit one. Not enter one. At least based on this little investigation ;)

Edit: also realized after posting I technically wrote the hacked Lua code incorrectly ("exitgym" could be presented through 'b' variable instead) but it seems to work anyway for me. You'd add an if block for b == "exitgym" and then unconditionally return true for that case. Might be working by accident.

Big respect for that, the solution worked and saved our game session. One note though - we were still unable to use space to pick up items, needed to do it by clicking. Playing with Wendy, it was also impossible to use Abigail's flower. Other than that, the functionality was restored, thanks a mil <3 

Share this comment


Link to comment
Share on other sites

3 hours ago, Roystone said:

Big respect for that, the solution worked and saved our game session. One note though - we were still unable to use space to pick up items, needed to do it by clicking. Playing with Wendy, it was also impossible to use Abigail's flower. Other than that, the functionality was restored, thanks a mil <3 

Np! I'm glad that I was able to find and share the problem even if I had never looked deeper into this code. I think I just realized that there is at least one other action RPC wrong, which is the very first one "AOECharging" and "ActionButton". Same issue: it's sorting alphabetically but now it's the second letter "O" vs "c". I am guessing "ActionButton" = space. It just happened that "exitgym" apparently was much easier for my eyeballs to notice. But also respect for Klei for marking this as "Fixed", so I'd be expecting a proper fix into the game whenever they get around to releasing a new version. :)

I play as Wendy main, I think almost all of my playtime of 600+ hours have been just Wendy, and when I was testing the fix, it just happened that I did not think to try to use the flower at all so I did not notice anything was wrong.

Share this comment


Link to comment
Share on other sites

It seems like a macOS bug related to strcoll and LC_COLLATE

Add an extra environment `LC_COLLATE="C"` can bypass this bug.

Recent update 663947 tried to use `stringidsorter` in `table.sort` which utilizes `strcmp`. However it seems there is some other bugs in stringidsorter..

print(stringidsorter("AO", "Ao")) -- false
print(stringidsorter("Ao", "AO")) -- false

 

Share this comment


Link to comment
Share on other sites

We've just patched the game (664019). Please let us know if the problem still occurs.

  • Thanks 1

Share this comment


Link to comment
Share on other sites




Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...