Help: “Drift / auto-walk” bug when many users (~60+) — jump stops responding

Help!
, , ,
1

Translation: ChatGPT

Summary
In an 80-capacity world, when around 60 users gather, many or all players occasionally enter a “drift” or auto-walk state — jumping stops working, and avatars keep walking in the last input direction.
This doesn’t seem to depend on rendering or CPU/GPU load — it simply correlates with high player count, not general performance issues. The symptom started about two months ago, and we haven’t identified any clear cause.

Observed behavior

  • When the world has many users (≈60), some or all players suddenly can’t jump.

  • The avatar keeps moving in the last pressed direction, as if input became “stuck.”

  • iwasync voice continues normally.

  • It doesn’t look like collider push or lag — rather, input processing stops on the client side.

Reproduction conditions

  • Does not happen with small groups.

  • Appears randomly once population grows.

  • Sometimes triggered while repeatedly pressing jump, but can occur even without heavy action.

Console / logs (repeated since world join)

Error - [Yodo] Please assign a hapticSlider to HapticSliderPersistenceManager.
2025.09.05 21:19:49 Error - [TextureManagement] Over cache size but failed to find any textures to remove
2025.09.05 21:19:51 Error - [TextureManagement] Over cache size but failed to find any textures to remove

Aside from these, no obvious error appears at the moment the drift starts.

Movement-related mechanics in the world

  • A generic teleport gimmick (use to teleport).

  • A uGUI teleport by player name (teleports to a specified user).

Main world systems / gimmicks

  • PlayerSelecter – teleports selected player to me; cinemaCamera follows them.
    Modified to only list players within a collider range, refreshes locally.

  • YodoHapticSwitch (200+ instances): toggles objects (local/global).

    • OR-type (added OR logic)

    • Linked-type (linked buttons)

    • AudioLink-type (switches AudioLink target)

  • Yodo_HapticSlider (and modded variants): controls rotation or material values globally.

  • UdonToggleSwitch – only one visible object among choices (modded for multiple setups).

  • Modified ImagePad – can display in up to five locations simultaneously.

  • AudioReverbFilter – adds reverb to world audio.

  • VoiceGroupControl2 – for microphone and soundproof systems.

  • Fukuro Udon – ManualObjectSync and reset utilities.

  • FadeObject – teleport with fade effect.

Ask / Discussion
Has anyone encountered a mass “auto-walk” or input-lock issue that appears only when many users are in the instance?

  • Could this be related to input desync under high player counts, rather than performance load?

  • Any known engine-side or networking quirks affecting movement input when many UdonBehaviours are active?

  • Could the TextureManagement or HapticSliderPersistenceManager warnings be connected?

  • Any tips on client logs to capture, or world-side mitigations (input debounce, fewer toggles, etc.)?

Any insight or similar experiences would be extremely helpful. Thank you!

1 Like
2

This is a basic network performance error encountered in literally all online games since ultima back in like 1997: Your device sends an input, the network resends that input interpreted in a client, that network packet gets sent over the line to a server where the server interprets it and either sends back its own input as an output or waits for the next signal. When that signal gets stuck in a loop, in online games with multiple networked users the first disruption is at the client level, where it recieves the last network request then never updates: Receiving the same input indefinitely and manifesting as locked user movement.

This is truly nothing new, extremely well studied across hundreds of online games over decades, and it is 100% caused by your hardware limitations at the client-network level; Ie. Your PC, your LAN, and your Router/Gateway. Especially if it recovers, and manifests only for you and not other users in the instance: If Everyone* is experiencing it, it’s a server processing error of a similar nature.

The easiest fix is to remove all other network latency: hardwire if wireless, minimize interlan device communication, get a better router or tap to your isp through your gateway. Short of that, improve the hardware itself: Get better graphics drivers, higher bandwidth internet.

You could also use better servers if that’s an issue, something closer to your physical location: VRC has had a few outages over the past month or so, and some upstream provider issues causing regional problems that affect more users than others.

This is obviously a generalization overall, so I can find more info for you if you can’t pin down a specific cause within your own home network setup.

Anyone who’s ever played on a moderately sized java minecraft server should be familiar with this behavior.

3

Thank you for the detailed explanation.

However, this issue also occurs even when I host the instance on a Japan server.

It doesn’t just happen to me — every player in the same instance experiences the exact same problem simultaneously.

Each player keeps walking in the direction of their own input, but all players start moving at once when it happens.

Also, in another world I created that also supports 80 players, this issue has never occurred, even when the instance is full.

So it seems to be something specific to this particular world rather than a general network or hardware issue.

4

That’s still a desync issue, just on the side of the server usually if not the client.

By “This problems happens to all players at once” I do NOT mean that you simply *SEE* it happening to everyone: Other people need to actively be experiencing the same issue, usually at the same time; that’s what I meant. YOU may be seeing everyone sending stuck inputs, but for others the server may be working just fine, and you’re just seeing all the clients catching up afterward. Unless people are actively complaining about how laggy the lobby is while you’re in it: It’s probably just you. That’s just how this problem manifests, YOU’RE the one with the network latency so YOUR client is the one that needs to catch up to the server sync.

If this were a world specific issue, it could be caused by a number of things, most notably resource exhaustion: If the lobby is trying to use more assets or processing data at one time than the pipeline can handle, at literally any point it may crash and recover in strange ways. That’s anything from network calls to poor resource allocation to an abundance of poorly optimized avatars being processed to client-server sync issues.

What is the world in question? If this were the case, this would need to be tested on an individual level and then probably discussed with the world maker, as VRC really can’t do anything except remove unoptimized worlds.

Personally, I’ve experienced this issue with as few as two people in the lobby at the same time.

___

If you’re on quest v79 or v81, it’s extremely easy to test this type of behavior in nearly all games that use Unity multiplay (ie. practically every multiplayer game on the quest store) by joining a multiplayer lobby with any number of players and rapidly switching between passthrough and vr modes.

Everyone else in the lobby will see you sending stuck inputs, they will lag, and then the moment you rejoin vr mode the client replaces everyone on your side to resync with the server, represented by avatars floating in every which direction until they come to a stop where their player actually is. No one else in the lobby actually desyncs, it just tanks their frames while your avatar sits stationary, unmoving, and only partially affected by physics and world interactions.

___

Same issue: New coat of paint.

5

Other players in the instance are also saying things like “I can’t jump” or “I’m sliding.”
So this is definitely not just happening to me.

Even when all 80 participants join using “Excellent”-rated lightweight avatars,
the same issue still occurs.

The affected world is this one:
https://vrchat.com/home/world/wrld_ccc409d2-537f-4aaa-8d11-fd03876a732c/info
I am the creator of this world, which is why I am trying to identify the cause myself.

Also, when the instance has only about 10 players or fewer,
the issue does not appear, even if those avatars are high-performance-cost ones.

If your experience or knowledge could help me investigate this further,
I would truly appreciate your guidance.

6

i get something like this but when using OSC script to control daisy chained instances. they amble around aimlessly and the camera rotation is uncontrollable

7

Unfortunately I’m on quest only or I would help you test your world more directly. Since this is your world, we actually CAN pinpoint the cause and fix it, unlike where my last responses assumed it was someone else’s world. You’ll need an experienced world maker to help you with this, I’d recommend.

If you stated initially it was your world, I apologize if I read past that without seeing it. Once again if EVERYONE is seeing it that’s actually a good thing because it means it’s more fixable, that difference matters.

With all those world systems you have implemented, it’s very likely there is collision happening somewhere in the pipeline causing the desync issue I elucidated prior. Especially with multiple teleport / player tracking systems, it’s possible they use overlapping means of achieving a similar result, which again: If the rendering pipeline gets stuck basically anywhere, it manifests as this lag-drift thing you’ve described. You’d need someone more familliar with each of the specific systems you listed as well as any other tools that might be interfering to get down to the bottom of this.

This is all assuming that this isn’t just a known issue with one of those tools, something others have reported on regarding that specific tool which others would only know about through direct searching.

My recommendation is to make a new thread with a more robust description and explanation of the issue, and point to the fact that it’s your world systems rather than input. One thing is almost certainly true: This has nothing to do with your keyboard or controllers in any way, which is what most people think when they mention similar-sounding issues.

In your logs, rather than errors you should look for multiple different subsystems trying to do the same thing, or making similar syscalls. Admittedly I don’t know anything about unity logging but the idea should be cross-modal and applicable to most systems: Too many things trying to work at the same time, with no handler to resolve conflicts.

I wish you luck. Hopefully someone else can chime in with their reports for you soon and get this solved.

All else fails, remove all custom systems then add them back one at a time until the bug starts happening again, and you can isolate it to a single source install. Then test just with that code by itself, see if it happens with nothing else added, and if it does you have your answer. This is the most tedious and time consuming way to bug test though.

8

Yes, I plan to gradually remove about half of the gimmicks at a time to identify which one is causing the issue.
However, reproducing the problem requires more than 60 players, and gathering that many people is extremely difficult.

That’s why I came to this forum — I’m hoping for the knowledge and cooperation of experienced world creators to help investigate this.

Thank you very much.
I’ll wait and see if someone else can lend me a hand.

9

Thank you for your reply.
I’m not quite sure what you mean by “daisy chained instances,”
but there’s nothing in my world that’s being controlled by any kind of external device or OSC-based system.

Now that you mention it, there are quite a few differences between this world (where the issue occurs) and the other one where it doesn’t.
One of the main differences is that this world uses a Cinemachine camera.
Could that possibly be related?

It’s not really that the avatars “wander around,”
but rather that during the issue, they keep walking in the first direction that was input when the problem began.