Palworld Config: Engine.ini, and Where the Stutter Comes From

Of the games on this site, Palworld is the one where a config file has the most room to work. It is Unreal Engine 5 with no anti-cheat blocking the engine overrides, and its main complaint is not a low frame rate but stutter — which is exactly the kind of problem these settings address.

Last updated 1 August 2026 · Palworld, Unreal Engine 5

Where Engine.ini goes

Under your local app data, in a folder named Pal rather than Palworld:

%LOCALAPPDATA%\Pal\Saved\Config\Windows

Paste that into the Explorer address bar — %LOCALAPPDATA% expands itself, so your username does not matter. The internal name is Pal because that was the project name during development, and it is the reason searching your drive for "Palworld" does not find this folder.

The file often does not exist yet, in which case you create an empty text file and name it Engine.ini yourself. That is normal: Unreal only writes the file when it has something to put in it.

You should see GameUserSettings.ini in the same folder. That is the menu's own settings file and it holds your resolution and quality preset. Engine.ini is the one that reaches past the menu, which is why it is the interesting one.

Set it read-only, or lose it

Unreal rewrites the file when the game exits, which is normal engine behaviour rather than a Palworld quirk. Set the file to read-only after you save it and the game keeps your values.

Right-click Engine.ini → Properties → tick Read-only → OK. The engine tries to write, is refused, and carries on with what it read at startup.

This is the opposite of the advice on our VALORANT page, and the difference is worth understanding rather than memorising. There, the file is the game's own settings store, so locking it breaks the menu. Here, Engine.ini is an override file the menu does not use — your resolution and preset live in GameUserSettings.ini, which stays writable. Locking one costs you nothing; locking the other costs you the settings screen.

The two stutters, and what fixes each

Treat it as two separate problems, because it is. Texture streaming causes the hitching while you move, and shader compilation causes the freeze the first time you see something new.

Streaming stutter: the pool size

Palworld's world is loaded in pieces as you move through it. The streaming pool is the amount of video memory reserved for holding those textures. Set too small — and the default is conservative, because it has to work on an 8 GB card and a 24 GB one — the game evicts textures it is about to need again, then fetches them back. Each fetch is a hitch.

[SystemSettings]
r.Streaming.PoolSize=3072
r.Streaming.LimitPoolSizeToVRAM=1
r.TextureStreaming=1

The number is in megabytes and this is the setting to get right, because it is the one that depends entirely on your card. A useful shape: comfortably below your total VRAM, leaving room for everything else the frame needs. Too high is worse than too low — when you exceed what the card has, Windows starts spilling to system memory and you trade a hitch for sustained slowness.

LimitPoolSizeToVRAM=1 is the safety net that keeps the engine from asking for more than the card physically has, and it is why this line belongs next to the pool size rather than in a list of extras.

Shader stutter: the pipeline cache

The other freeze — a hard pause the first time a new effect or creature appears — is UE5 compiling a shader at the moment it needs it. It happens once per shader, which is why your second hour is smoother than your first.

r.ShaderPipelineCache.Enabled=1
r.ShaderPipelineCache.PreOptimizeEnabled=1
r.CreateShadersOnLoad=1

These move that work earlier: compile during loading, when you are already waiting, rather than mid-fight. Expect slightly longer loads in exchange, which is a trade worth making every time.

Loading threads

One more pair worth having, in the same spirit — letting the engine load in the background rather than blocking the frame:

s.AsyncLoadingThreadEnabled=1
s.AsyncLoadingTimeLimit=2.0

The time limit caps how many milliseconds per frame the engine may spend on loading work. Low keeps frames even and content arrives later; high loads faster and hitches more.

Lumen and Nanite: the two expensive things in UE5

These are what makes Palworld cost more than a game of its art style should, and they are the biggest lever in the file for a mid-range card.

Lumen is UE5's real-time global illumination — light bouncing off surfaces, computed continuously. It looks genuinely better and it is expensive:

r.Lumen.DiffuseIndirect.Allow=0
r.Lumen.Reflections.Allow=0

Turning it off is the single largest frame gain available here, and it is also the most visible change in the file. Interiors and shadowed areas go flatter. On a card that is struggling this is the trade to make first; on one that is comfortable, leave it on — you would be giving up the thing you paid the card for.

Nanite is the geometry system, and it is not something to disable. It has a quality dial instead:

r.Nanite.MaxPixelsPerEdge=1.0   ; higher = coarser geometry, cheaper

Raising it toward 2.0 lets distant geometry be simplified more aggressively. Modest gain, modest cost, and far safer than the "disable Nanite" advice you will find — the engine expects it and turning it off can make things slower rather than faster.

Two more that cost nothing to lose, since they are post-processing effects that mostly get in the way:

r.MotionBlurQuality=0
r.DepthOfFieldQuality=0
r.LensFlareQuality=0

What a config cannot fix in Palworld

Two limits that no amount of [SystemSettings] will move, and it is better to know than to keep tuning.

Base and simulation load. A large base with many Pals working in it slows the game down because of the simulation, not the rendering. Every Pal has tasks, pathing and state to update, and that runs on your CPU regardless of how the world is drawn. If your frame rate is fine in the wild and poor at home, that is what you are looking at — and the fix is fewer working Pals or a less dense base, not a graphics setting.

Dedicated server tick. On multiplayer, how often the server updates is set by the server, not by you. Rubber-banding and delayed hits on someone else's world are not a client problem.

Beyond those, which side of your machine limits you decides which half of this page matters. Our bottleneck calculator is free, needs no account and takes about fifteen seconds. GPU-bound is where Lumen and the pool size do the work; CPU-bound is where the loading threads matter and where turning shadows down changes nothing.

Is editing Engine.ini safe?

Yes. Palworld has no kernel anti-cheat, and this is a documented Unreal Engine mechanism. Engine.ini exists so that engine variables can be set without code changes; no game file is patched, nothing is injected, and no external program runs. Every value is one the engine already supports.

Worth being clear about the multiplayer case, since it is the reasonable worry: these are client rendering variables. They change how your machine draws the world, not what the world is or what you can do in it. A server has no way to be affected by your shadow resolution.

The reversibility test: untick read-only, delete the file, launch, and you are back to stock. Nothing is written anywhere else.

Writing your own, in four steps

1. Close Palworld completely, then open the folder from the first section.
2. Create or open Engine.ini in Notepad. Keep the [SystemSettings] header on its own line at the top of the block — a variable outside a section header is ignored.
3. Save, then set the file read-only.
4. Launch the game and open the console with the tilde key, then type one of your variables with no value — it prints the current one. If it matches what you wrote, the file applied.

Where the numbers come from

The variables above are the general case. The two that depend on your specific machine are the ones that decide whether this works: r.Streaming.PoolSize has to fit your VRAM with room to spare, and whether Lumen is worth keeping depends on how much GPU headroom you have at your resolution.

That is the part a guide cannot do for you, and it is what our generator does — you enter your CPU, GPU, RAM, resolution and refresh rate, and it writes the full [SystemSettings] block with those numbers filled in, plus a report explaining each line and which profile it used.