Roblox Device Simulator and Network Simulator (October 2026): Presets, Ranges, Custom Profiles, and the 8 ms Trap

Fri Oct 23, 2026 8:31 am

Quick Summary

Studio's Device Simulator and Network Simulator are out of beta as of October 16, 2026, and both sit in one toolbar above the 3D viewport
The Network Simulator shapes playtest traffic with 5 built-in presets, from Ideal Fiber (8 ms each way) to Bad Connection 3G (150 to 180 ms), with separate inbound and outbound values
Latency, jitter, and packet loss each run 0 to 1000 ms, or 0.00 to 0.50 percent for loss, and you can save custom presets that survive across places and Studio sessions
Ideal Fiber is not the same as turning simulation off, because it still adds 8 ms in each direction
Device Simulator is not a hardware benchmark, and neither tool changes your published game

What Changed on October 16

Roblox confirmed on the Developer Forum that the new Device Simulator is out of beta and available to everyone. You no longer enable it in File > Beta Features. The note landed alongside the October 12 to 18 weekly recap, which also covered in-experience makeup creation, the one-question publishing flow, custom per-game Quick Words, and a beta Quality mode for texture generation.

The beta itself shipped on September 9 and ran for a little over a month. It rebuilt the Device Simulator around a toolbar at the top of the viewport and bolted the Network Simulator onto the same bar. That pairing matters: one tool changes what your game thinks it is running on, and the other changes what the connection feels like while you playtest.

Two tools share this toolbar, and they answer different questions:

Device Simulator changes the screen size, pixel density, on-screen keyboard, and platform your experience reports. It is a layout and input tool.
Network Simulator adds latency, jitter, and packet loss between the playtest client and server. It is a resilience tool.
Controller Emulator is the third piece in the same family. It changes what is plugged in, not what the screen looks like, and it follows the device you select in Device Simulator.

The Device Simulator Toolbar

The toolbar stays available in both edit and play mode, so you can swap the simulated device mid-playtest without stopping, switching, and restarting. The left side holds one button per device category plus a chip naming the active device:

Phone covers phones and tablets, including touch input and the on-screen keyboard
Desktop covers desktop and laptop resolutions
Console covers console output resolutions and gamepad-first input
Headset covers VR headsets

Clicking a category jumps to that category's default device. A category is greyed out when nothing in it is available to simulate. The phone group splits further into Flagship, Mid-range, and Entry level, which is the fastest way to walk a layout down the performance ladder. Desktop, Console, and Headset each have one built-in group, and then there is Custom for devices you built yourself and Current device, which turns simulation off entirely.

Open Studio and load your place
The toolbar appears above the 3D viewport whenever a place is open
Click a category button to switch, then click the device chip to open the full device menu
Use Rotate for phones and tablets, or the mock Android back button for Android devices
Open Touch controls to see the keyboard and mouse shortcuts that stand in for multi-touch
Use Display scaling to choose how the simulated screen maps onto your monitor
Select Manage devices at the bottom of the menu to build or hide devices

Display Scaling and Why Physical Size Needs Calibration

A 1080-pixel-tall phone screen and a 1080-pixel-tall monitor have identical pixel counts and very different physical sizes. The Display scaling menu decides which property the viewport preserves:

Physical size matches the simulated screen's real-world size, so on-screen elements look about as large as they would in a player's hand
Actual resolution maps one simulated pixel to one of your monitor's pixels
Fit to window stretches the simulated screen to fill the available viewport

Physical size only holds if Studio knows how big your own monitor is, and it cannot read that number directly. Two menu items supply it. Auto-detect scaling reads the pixel density and scaling factor your operating system reports for your display, and turning it off falls back to your saved manual calibration. Calibrate physical scaling asks you to drag a slider until the image on screen matches the width of a student ID or library card, and calibrating turns auto-detect off and switches you to Physical size. Both values persist across sessions, so calibrating once is enough.

Custom Devices and What You Can Set

Manage devices opens the Device Manager with one tab per category, and it opens on the tab matching whatever you are simulating. The Standard list holds Roblox's built-in devices. Use Add devices to choose which of them show up in the toolbar's device menu and hide the rest, which keeps the list down to the devices you actually test against. Hiding a device does not delete it. Custom devices always stay visible, and so does the device you are currently simulating.

You can build a custom device to model hardware Roblox does not ship a profile for, or to isolate a single property such as the same phone with half the memory. Duplicate copies a standard device as a starting point.

Name: the label shown in the device menu, required, unique, 200 characters or fewer
Platform: what the experience reports at runtime
Dimensions: screen width 1 to 7680 and height 1 to 4320
Pixel density: pixels per inch, 72 to 10,000, and the value that drives physical-size scaling
Keyboard height: how much of the screen the on-screen keyboard covers, per orientation, 0 to 4320

The Network Simulator and Its Presets

The Network Simulator lives in the same toolbar as a pill. It summarizes the staged or applied connection type and quality, and opening it shows the exact preset plus all six directional values.

It applies conditions independently in each direction. Inbound traffic travels server to client and covers replicated server state and server-to-client remote communication. Outbound traffic travels client to server and covers client requests and client-to-server remote communication. Latency is a minimum one-way delay added to each packet. Jitter is variation added on top of that minimum. Packet loss is the probability that an individual packet is dropped.

Ping is a round-trip measurement, so both directions count. Ten milliseconds of inbound plus ten milliseconds of outbound adds roughly 20 ms to the connection's existing round-trip time. The configured values are added on top of real conditions, which matters in a Team Test where geography and the public internet already contribute latency and loss.

Preset values are listed as latency / jitter / packet loss:

Ideal Fiber, pill LAN, inbound 8 ms / 0 ms / 0.00%, outbound 8 ms / 0 ms / 0.00%
Wired Broadband, pill LAN, inbound 25 ms / 3 ms / 0.00%, outbound 25 ms / 3 ms / 0.00%
Home Wi-Fi, pill Wifi, inbound 30 ms / 12 ms / 0.20%, outbound 30 ms / 15 ms / 0.30%
Standard Mobile (4G/LTE), pill 4G, inbound 45 ms / 20 ms / 0.40%, outbound 55 ms / 30 ms / 0.50%
Bad Connection (3G), pill 3G, inbound 150 ms / 70 ms / 0.50%, outbound 180 ms / 90 ms / 0.50%

Those presets are useful test conditions, not guarantees about every connection of that type. Real networks vary by device, location, provider, congestion, and time.

Ranges, Custom Profiles, and the 8 ms Trap

Latency runs 0 to 1000 ms, jitter runs 0 to 1000 ms, and packet loss runs 0.00 to 0.50 percent, each shown to 0.1 ms or 0.01 percent. A loss value of 0.50 percent means half of one percent, not half the packets.

Editing any number switches Preset to Custom. The edits stay staged until you press Apply, and dismissing the popover first discards them. After Apply, a running playtest picks up the new values immediately, with no restart. This is the detail worth remembering: Ideal Fiber is the default and least-impaired preset, but it is not the same as disabling simulation. It adds 8 ms in each direction. If you want a zero-added-delay baseline, set every value to 0 as a custom configuration and apply it.

Custom profiles are the part that saves real time. Edit one or more values, select Save, enter a unique name, then Save & Apply. The preset becomes available in the Preset menu across places and later Studio sessions. Naming an existing saved preset changes the button to Replace & Apply. Built-in preset names and Custom are reserved. When a saved preset is selected, Delete replaces Reset, and deleting it removes the preset and immediately applies Ideal Fiber.

One caveat: applied network values themselves are not preserved after a full Studio restart.

Driving the Simulator From a Script

Every Network Simulator control maps to a NetworkSettings property, so a plugin or an automated test can set the same conditions without the toolbar:

Inbound Latency maps to InboundNetworkMinDelayMs
Outbound Latency maps to OutboundNetworkMinDelayMs
Inbound Jitter maps to InboundNetworkJitterMs
Outbound Jitter maps to OutboundNetworkJitterMs
Inbound Packet Loss maps to InboundNetworkLossPercent
Outbound Packet Loss maps to OutboundNetworkLossPercent

Setting any of these directly keeps the toolbar and the pill in sync, because both read from the same underlying settings. The simulator also uses the same emulation settings as the Network tab of Studio Settings. If those settings change elsewhere while the simulator has staged edits, the external values win and the staged transaction is discarded.

Controller Emulator and Touch Shortcuts

The Controller Emulator is a widget that shows a picture of the device you pick, sends real input events when you click it or press a mapped key, and lights up its controls as input arrives. Emulating input is separate from simulating a device: Device Simulator changes the screen, platform, and hardware your experience believes it is running on, and Controller Emulator changes what is plugged into it.

Available devices cover a Generic Gamepad, PS4, PS5, Xbox, Generic Handheld, TV Remote, and Quest2 / Quest3. Your experience sees the corresponding gamepad type, so code that branches on Enum.GamepadType behaves as it would with the real controller attached. Triggers and thumbsticks report analog values, not just pressed and released, which is what lets you find where your dead zones and activation thresholds actually fire.

VR is different because there is no single control to click. Headset, Left Controller, and Right Controller each have a toggle, and enabled parts respond to keyboard and mouse while disabled parts hold still. Move is Shift plus W, A, S, D, fly up and down is Shift plus E or Q, rotate is mouse move, tilt is right click plus mouse move, switch controllers is Shift plus Left or Right, toggle cursor lock is Alt plus 1, and toggle mouse emulation is Alt plus Esc. Reset Positions returns the head and both hands to their default pose mid-playtest, which is the fastest way out of a pose you cannot recover from by hand.

On the touch side, a mouse has one contact point, so two-finger gestures map onto modifier keys. Pinch plus rotate is Alt plus drag, and two-finger pan is Alt plus Shift plus drag.

How to Actually Use This

Pick one player journey that crosses the client-server boundary, such as a server-authoritative ability, an inventory update, or replicated movement
Write down what success looks like: response time, visible feedback, timeout behavior, corrections, duplicate requests, recovery
Apply Ideal Fiber or a zero-delay custom preset and run the journey as a baseline
Apply Home Wi-Fi or Standard Mobile (4G/LTE) and repeat the same actions
Apply Bad Connection (3G) as a resilience test and confirm the game stays understandable when updates arrive unevenly
Change only inbound or only outbound values to isolate which direction exposes the problem
After a fix, repeat the same runs and compare

The questions worth asking on each run: does the player get immediate local feedback while waiting for server confirmation, can repeated input submit the same action twice, do loading states tell slow work from a failure, do timeouts offer a safe retry, does replicated movement stay readable under jitter, and does the experience recover when the connection improves. For large comparisons, apply the condition before starting the interaction, because big latency changes during a running test can disturb congestion control.

Developer Console shows average ping and logs, which confirms the connection actually changed and surfaces errors in retry or timeout code. A MicroProfiler network capture shows sent and received engine traffic by frame, which separates replication from physics and other data. Keep the scenario, the playtest mode, and the capture method identical between runs.

FAQ

Does the Network Simulator affect players in my published game?
No. It only shapes traffic in your local Studio playtest session. Players connecting to your live experience are untouched.

Does simulating a phone tell me my game will run on that phone?
Not yet. Device Simulator simulates screen size, scaling, and input, not device hardware performance. Roblox says validating memory and rendering quality against real hardware profiles is something it is working on, and that the previous memory figure shown in the old emulator was a placeholder that never actually affected the emulator.

Do the network presets match real 3G or 4G?
They are approximations built from typical latency, jitter, and loss ranges for each connection type. Use them to find bugs that only appear under bad conditions, not as a precise model of any one carrier.

How do I get a true zero-latency baseline?
Ideal Fiber adds 8 ms in each direction. Set latency, jitter, and packet loss to 0 in both directions as a custom configuration, then Apply.

Do custom network presets persist?
Saved presets persist across places and Studio sessions. Applied values do not survive a full Studio restart, and deleting a saved preset immediately applies Ideal Fiber.

Why did my Studio feel slower after I closed the simulator?
The network values are Studio-level settings under Studio Settings > Network, not tied to the Device Simulator panel, so they do not reset when you close the toolbar. Set the inbound and outbound delay and jitter back to 0 to clear them. A creator reported this during the beta, and Roblox staff confirmed that is the intended behavior.

Does this replace testing on a real device?
No. It catches a large class of layout and network problems early, but testing on real hardware is still the most accurate way to see how your experience behaves.

Sources