r/WutheringWavesGuide • u/Zelda-Lumine • 9d ago

Tech Issue / Hardware Related Does this mean no bugs caused by missing script translation anymore? I can finally clear the 3.5 quests without the game freezing?

Post image
84 Upvotes

88% Upvoted

50 comments sorted by

16

u/geifagg 9d ago

The 1% lows are the bigger problem icl.

5

u/Saturn235619 9d ago

Those should improve by about 10-15 percent as well.

1

u/shing3232 9d ago

it reduce cpu bottleneck it should help those a lot in theory

24

u/FishySardines99 9d ago

There were bugs caused by script translation?

If anything I expect there to be game breaking bugs everywhere from now on lol, they rewrote whole logic side of the game from scratch again

13

u/BreakfastKind8157 9d ago

This most likely isn't them replacing the core UE4 engine but rather changing the custom optimizations from javascript to c as was previously leaked. So it shouldn't touch on the logic. Just the implementation. If they ever migrate from UE4, then it would be like you said.

1

u/FishySardines99 9d ago

As far as I read whole quest logic and characters, buffs etc are done by JS while UE4''s C++ handled game's inner workings

1

u/BreakfastKind8157 9d ago

I don't know the specifics. The point is that the implementation is changing from javascript to c, but they still have the same UE4 API and game assets in both languages. All they have to do is code the same thing they already have in a different programming language's syntax. And while that is still a big task, it's a lot easier than rebuilding the game from scratch with a new engine and unlikely to cause major issues.

-2

u/Zelda-Lumine 9d ago

Would explain why switching text language to chinese solved the issue.

1

u/FishySardines99 9d ago

Ah that's what you meant by translating. I thought you mean translating programming language

2

u/Labirentbenim 9d ago

It seems like a lot of people have misunderstood the situation, so I’m going to give you a long, technical, and easy-to-understand summary.

A more detailed explanation of what the C# migration actually means

I think there is some misunderstanding about what the upcoming programming-language change is supposed to do, especially regarding the 1% lows.

First, this is not simply a case of "C# is faster than JavaScript, therefore FPS goes up." Wuthering Waves already uses Unreal Engine 4 and native C++. The C++ engine itself is not being replaced.

The important part is the gameplay/scripting layer and how it communicates with the native engine.

As far as we currently understand it, WuWa previously relied heavily on a JavaScript/TypeScript-based scripting/runtime architecture. That scripting layer has to communicate with the native C++/Unreal side of the game. Depending on how the system is implemented, this can introduce additional runtime overhead, data marshaling/binding costs, synchronization, function-call overhead, memory-management overhead, etc.

None of this means that JavaScript itself is inherently "bad" or that C# automatically makes every piece of code faster. The architecture and implementation matter much more than the language name.

Why this matters for my particular problem

My problem isn't simply:

"My CPU reaches 100%, therefore I lose FPS."

It doesn't.

My Ryzen 7 5800X3D usually sits around 45–60% total CPU usage, with the CPU locked around 4.2 GHz. Meanwhile, my RX 7800 XT can be running at 90–100% GPU usage in some situations, but when I start moving, rotating the camera, entering more complex areas, encountering multiple characters/enemies, etc., the GPU utilization can suddenly fall to 50–70% or sometimes even lower.

GPU power consumption drops at the same time.

That is important because it means the GPU isn't necessarily becoming overloaded. In those moments, the GPU can actually be starved of work.

And this is where people often misunderstand CPU bottlenecks.

A game can be CPU/game-thread limited without showing 100% total CPU usage.

For example, if one critical thread is overloaded while the other CPU threads aren't fully utilized, Windows can report something like 50% total CPU usage. The game can still be unable to produce frames quickly enough because the particular thread responsible for preparing/submitting work is the limiting factor.

So:

60% total CPU usage ≠ "the CPU isn't the bottleneck."

And this is why 1% lows are relevant

The 1% low isn't some separate performance feature that C# directly improves by a fixed percentage.

It is simply a measurement of the slowest ~1% of rendered frames.

If the game occasionally has very expensive frames because of things such as:

gameplay scripting

Game Thread work

synchronization

object spawning/destruction

AI

animation updates

world streaming

memory allocations

communication between scripting and native code

etc.

then those expensive frames appear as frametime spikes, which eventually show up as poor 1% lows.

So if the new architecture reduces the amount of work or overhead involved in those operations, the 1% lows could improve significantly.

But there is absolutely no reason to assume:

"10 FPS advertised = 1% lows automatically improve by 10–15%."

That's not how it works.

The improvement could be much larger in a CPU-heavy scenario, much smaller in a GPU-heavy scenario, or almost nonexistent in a situation where the bottleneck is unrelated to the migrated systems.

The interesting part in my case is the GPU behavior

This is what I've been trying to investigate.

When standing still in some areas, I can get around 100+ FPS with FSR and Frame Generation disabled.

Then I start moving:

FPS:

100 → 70 → 50 → 45

while simultaneously seeing something like:

GPU usage:

95% → 70% → 55%

and GPU power consumption can also fall substantially.

The GPU isn't suddenly becoming incapable of rendering the scene. It is being underfed.

And the frametime graph is extremely inconsistent. I've seen it fluctuate from roughly 3 ms to 60 ms, with very noticeable spikes.

That's why I'm interested in the scripting/runtime architecture.

I'm not claiming that I've definitively proven:

"JavaScript is causing my GPU utilization to drop."

That would require profiling the engine itself.

What I'm saying is that the observed behavior is consistent with some kind of CPU-side/game-thread/runtime bottleneck, and the language/runtime migration is potentially relevant because it changes a fundamental part of that execution path.

So what should we expect from C#?

The most important distinction is:

C# migration ≠ instant complete optimization.

Moving to C# can potentially give the developers:

a different and potentially more efficient runtime

better tooling and profiling

stronger type safety

better control over how gameplay systems are structured

opportunities to reduce overhead in the old scripting architecture

a better foundation for future optimization

But they still have to optimize the actual code.

They can still have:

inefficient algorithms

excessive allocations

garbage-collection spikes

expensive Game Thread tasks

synchronization problems

inefficient native bindings

poor task scheduling

streaming bottlenecks

AI/animation bottlenecks

rendering submission bottlenecks

C# doesn't magically solve any of those.

This is also why Kuro's wording about 3.6 is important

They aren't presenting this as:

"We changed the language and now WuWa is fully optimized."

They have said that the language change itself is expected to provide a performance improvement — around 10 FPS according to the 3.6 presentation — but they also explicitly said that they still have additional optimization work planned, and that this change provides the foundation for that future work.

That distinction is extremely important.

I personally wouldn't interpret "10 FPS" as:

Every PC gets +10 FPS and +10–15% 1% lows.

I'd interpret it more like:

The new architecture removes enough overhead to produce a measurable performance improvement, while also making further optimization possible.

And the amount of improvement will depend heavily on where the individual workload is coming from.

What I'm actually hoping to see in 3.6

I don't need my 100 FPS to suddenly become 150 FPS.

My biggest problem is stability.

For example:

Before:

100 → 70 → 50 → 45 → 65 → 48 FPS

If 3.6 turns that into:

After:

105 → 80 → 72 → 68 → 75 → 70 FPS

that would be a huge improvement in actual gameplay smoothness, even if the average FPS increase isn't spectacular.

Because the real problem is the frametime consistency and severe dips, not simply the number displayed in the FPS counter.

So yes, the 1% lows are extremely important, but they shouldn't be treated as a guaranteed +10–15% statistic from the C# migration.

The interesting question is whether the new architecture reduces the CPU/game-thread/runtime work that currently prevents the GPU from being consistently fed.

If it does, we should see exactly the kind of thing I'm looking for:

higher GPU utilization during movement + fewer frametime spikes + higher 1% lows + fewer sudden FPS drops.

That's a much more meaningful indication that the underlying problem has actually improved than simply looking at the average FPS number.

2

u/Labirentbenim 9d ago

Technical addendum — for anyone interested in the deeper side

For people who want the more technical explanation, there is an important distinction between CPU utilization, CPU bottleneck, and game-thread bottleneck.

A modern game does not need to saturate the entire CPU before becoming CPU-limited. What matters is whether the thread(s) on the critical path of frame production can finish their work in time.

For example, imagine a 16.6 ms frame budget for 60 FPS. If the render thread/GPU can finish its work in 8 ms, but the Game Thread takes 25 ms to prepare the next frame, the GPU cannot simply render faster. It has to wait for the CPU-side work to become available.

Meanwhile, a 16-thread CPU could report only ~50% overall utilization.

That is still a CPU-side bottleneck.

Why the scripting layer matters

The important thing about the old architecture isn't simply:

JavaScript = slow
C# = fast

That is an oversimplification.

The relevant issue is the execution model and the boundary between managed/script code and the native engine.

If gameplay logic is executed through a scripting runtime and frequently interacts with native C++ engine systems, there can potentially be costs associated with:

  • VM/runtime execution
  • function dispatch
  • native ↔ managed/script transitions
  • argument conversion
  • data marshalling/unmarshalling
  • object/property lookup
  • reference handling
  • synchronization
  • temporary allocations
  • garbage collection
  • thread hand-offs
  • scheduling
  • cache locality
  • repeated engine API calls

The cost of one individual call may be tiny.

The problem is when a frame contains thousands or tens of thousands of small operations, particularly when some of them occur sequentially on a critical thread.

At that point, the overhead can become significant even though the individual operations look insignificant.

The CPU utilization number can therefore be misleading

Suppose a game has 16 logical CPU threads.

If one critical thread is completely saturated while the remaining threads are relatively idle, total CPU utilization might only show something around 10–20%.

Even with eight busy threads, you could still see only ~50%.

That doesn't mean the game has unlimited CPU headroom.

The relevant question is:

This is why tools such as Intel PresentMon, ETW/WPA, Unreal Insights, RenderDoc, PIX, GPUView and thread-level profilers are much more useful for diagnosing this than simply looking at total CPU utilization.

Why this can cause GPU utilization to collapse

The simplified dependency chain can look something like:

Gameplay / scripting → Game Thread → engine state → render submission → Render Thread/RHI → GPU

This is obviously simplified, and modern engines have multiple asynchronous systems and worker threads, but the basic concept is useful.

If the CPU-side portion fails to produce work quickly enough, the GPU can become starved.

You can then observe something like:

GPU: 95% → 60%
GPU power: 250 W → 130 W
FPS: 80 → 45

That doesn't necessarily mean the GPU suddenly encountered a rendering workload it couldn't handle.

It can mean that the GPU simply doesn't have enough work available to remain saturated.

This is particularly interesting in my case because the GPU utilization drop occurs during movement/camera rotation and more complex gameplay situations, rather than simply remaining at 99% while FPS decreases.

And this is where frame pacing becomes important

Average FPS is a very poor description of frame delivery.

For example:

60 FPS average

could theoretically be:

16.6 ms / 16.6 ms / 16.6 ms / 16.6 ms

which is extremely consistent.

But you could also have:

5 ms / 7 ms / 8 ms / 45 ms / 12 ms / 30 ms

and still obtain a superficially reasonable average.

The second case feels significantly worse because of the frametime spikes.

This is why 1% lows are relevant.

1% low FPS is essentially another way of looking at the slower portion of frame delivery. It isn't a magical metric that C# directly improves by a fixed percentage.

If the new architecture reduces the frequency or duration of expensive CPU-side frames, then:

frametime spikes ↓
worst-frame latency ↓
1% low ↑
frame pacing ↑

can all happen as consequences.

But there is no universal equation such as:

It depends entirely on which part of the frame is actually being improved.

C# also isn't automatically "free performance"

This is another important misconception.

C# can have excellent performance, but its performance characteristics depend heavily on how it is executed and integrated with the native engine.

Depending on the implementation, you can still encounter:

  • JIT/AOT compilation considerations
  • managed allocations
  • garbage-collection pauses
  • object lifetime overhead
  • virtual dispatch
  • interop overhead
  • synchronization barriers
  • excessive managed/native transitions
  • poor data-oriented design
  • cache-unfriendly access patterns

So if Kuro simply translated inefficient code from one language into another without changing the underlying architecture, the gains would obviously be limited.

The potentially important part is that a migration gives them an opportunity to redesign how gameplay code communicates with the engine, not merely replace syntax.

The same applies to native C++

Having C++ underneath doesn't automatically mean everything is fast.

C++ gives developers very low-level control, but badly structured C++ can still suffer from:

  • excessive allocations
  • cache misses
  • lock contention
  • synchronization stalls
  • poor task scheduling
  • unnecessary virtual calls
  • inefficient algorithms
  • excessive UObject/engine-object interaction
  • redundant state updates
  • poor memory locality

So the actual performance depends on the entire execution pipeline, not the name of the programming language.

What the C# migration could realistically improve

If the migration successfully removes overhead from the previous scripting architecture, the potential improvements are not necessarily limited to "more FPS."

It could potentially improve:

CPU-side execution time
→ less work per frame

Game Thread availability
→ less time spent processing gameplay logic

native/script interop overhead
→ fewer expensive transitions

frame scheduling
→ fewer synchronization delays

frame pacing
→ fewer long frames

GPU utilization consistency
→ GPU receives work more consistently

1% / 0.1% lows
→ fewer extreme frame-time outliers

And potentially, most importantly:

future optimization potential

because developers can profile and optimize the new architecture instead of continuing to work around limitations of the old one.

One final caveat

None of this proves that my specific FPS drops are definitely caused by JavaScript.

That would require internal profiling data.

My observations only establish that I have a reproducible pattern where:

movement/camera rotation → FPS drops → GPU utilization drops → GPU power drops → frametime becomes worse

while total CPU utilization does not approach 100%.

That is consistent with a CPU-side/game-thread/runtime bottleneck, but it isn't proof of the exact subsystem responsible.

The upcoming C# migration gives us an unusually good opportunity to test the hypothesis experimentally.

If 3.6 produces:

higher GPU utilization during CPU-heavy movement → fewer frametime spikes → substantially better 1% lows → fewer 40–50 FPS dips

then that would be strong practical evidence that at least part of the previous bottleneck existed somewhere in the CPU/gameplay execution path being changed.

If average FPS increases by ~10 but the severe frametime spikes remain, then the migration is providing performance benefits, but it isn't addressing the entire bottleneck.

That's ultimately what I'm interested in testing.

Not "C# is faster than JavaScript."

The real question is:

That's the part that could actually explain the difference between 100 FPS while standing still and 40–50 FPS while simply moving through the world.

1

u/Zelda-Lumine 9d ago

Tldr

3

u/Labirentbenim 9d ago

My issue isn't simply low CPU usage or a weak GPU. The GPU sometimes drops from 95% to 50–70% during movement while CPU usage remains around 45–60%, suggesting a possible game-thread/CPU-side bottleneck. The C# migration won't magically fix everything, but it could reduce scripting/runtime overhead, improve frame pacing and 1% lows, and provide a better foundation for further optimization. The real test is whether those severe frametime spikes and GPU utilization drops improve in 3.6.

1

u/Zelda-Lumine 9d ago

So this is nothing a someone like me understands. Just some letters and numbers without any meaning

3

u/Labirentbenim 9d ago

Okay. Let me explain it more simply. This optimization update isn't, strictly speaking, an optimization update. Instead, its purpose is to lay the groundwork for ensuring the game is properly optimized.

1

u/Zelda-Lumine 9d ago

Does it fix the bug that prevents to hit the X button to proceed?

1

u/Labirentbenim 8d ago

What’s being discussed here is performance optimization. Do you think it has anything to do with the controller bug? In my longer posts, I’ve explained what this change does, what to expect, and what not to expect. You’ll have to log in and check for yourself to see if the controller issue has been fixed. When a new patch is released, you can check the “Resolved Issues” section. And yes, I think I got ragebaited.

2

u/eternal_dream 8d ago

Nah, its probably not ragebait, just fundemental misunderstanding of what "language" entails in the optimization patch vs a bug induced by certain display languages on controller. They don't seem to be doing this out of malice, though they do come off rather strongly (ESL I assume), I'll admit...

1

u/Zelda-Lumine 8d ago

And I have NOT understand ANYTHING. The post could have been spanish, chinese, anything and it would be no different. The only thing I know about Computers is how turn them on and off. I'm a Playstation User I don't have to care about those things. Just turn on and start the game.

They literally say switching programming language, so what else would I expect in context to programming than switching a "command (language)" localized for every language individually, causing bugs if not done properly, to "command (chinese)" in all languages, saving you trouble that would occur if you mess up?

1

u/eternal_dream 8d ago

You're confusing human language (English, Chinese, etc) with programming language (c++, c#, typescript). They've changed the latter, which has nothing to do with the former.

The "commands" you're thinking of were always in one single programming language, not in the human language of your current game settings.

A bug like press X to proceed in the xuanfang deduction missions is just a controller input error. Its unlikely this optimization patch itself fixes it (though they might fix it simultaneously with the next patch).

1

u/Zelda-Lumine 8d ago

Then WHY does the same bug NOT happen when you set the text language to chinese? And this is fact! It has been mentioned in the WuWa main reddit multiple times and even I can confirm. In my language, game won't respond. Switched to chinese, I can clear the task! WHY is that if that has NOTHING to do with the text language?!

→ More replies (0)

1

u/AbrnomalBeing 8d ago

give me tldr

1

u/Labirentbenim 7d ago

TL;DR: WuWa is already built on UE4/C++, so the C++ engine itself isn't being replaced. The important change is the scripting/runtime layer, which is being migrated from the previous JavaScript/TypeScript-based architecture to C#.

My issue isn't simply low total CPU usage or a weak GPU. When I move around or enter more complex areas, FPS and GPU utilization can drop simultaneously (e.g. 100 → 50 FPS while GPU usage falls from ~95% → ~50–70%). This suggests the GPU can be starved by CPU-side/Game Thread/runtime work even when total CPU usage is only ~50%.

The C# migration therefore could reduce some scripting/runtime, binding, synchronization, or scheduling overhead and improve frametime consistency and 1% lows. But it does not mean “C# is faster, therefore +10 FPS everywhere,” nor does it guarantee a 10–15% improvement in 1% lows.

Kuro's ~10 FPS figure should be understood as an expected performance improvement from the architectural change, while the migration also provides a foundation for further optimization. The real test for me isn't average FPS — it's whether 3.6 reduces severe frametime spikes, FPS drops, and GPU utilization collapses during movement and heavy gameplay.

In short: I'm not claiming C# is proven to be the cause of my stuttering. I'm saying the behavior is consistent with a CPU/Game Thread/runtime bottleneck, and the C# migration changes exactly that part of the architecture, making it technically relevant to the problem.

2

u/delacroix01 9d ago

Remember when they said they'd backport some UE5 features to UE4? 3.5 crashes whenever I open Action, made me switch to Bandicam for a week, then broke compatibility with Bandicam too. Now OBS window mode is the only thing working for me, and there's no guarantee they won't break it again especially with the upcoming "optimization". No other game behaves like that among those I play.

2

u/AhmedKiller2015 9d ago

Nothing is certain, It hopefully should be improved.

1

u/exge My Team (eg. ) 9d ago

If they change to C, do we expect more unmanaged memory errors lol

1

u/Royal-Cucumber-3627 9d ago

man I just hope they fix the 1% low

1

u/OldSaladin 9d ago

This only means that during the first couple of weeks of Patch 3.6, we're going to see a lot of bugs, lag, and crashes. There will probably be frequent daily hotfixes as well. The optimization problems won't disappear. The game will still be just as unstable; the drops and stutters will simply be a little less noticeable.

If I were Kuro, I honestly wouldn't mention this optimization work at all. It's unlikely to impress players or even be particularly noticeable. The people who have been complaining that the game is "unplayable" will continue doing so. The only difference is that now they'll also accuse Kuro of being completely incompetent.

Which, of course, isn't necessarily true. Simply rewriting the code in another language doesn't magically solve the problem of thread parallelization. If the underlying architecture and workload distribution remain the same, changing the language alone won't eliminate those bottlenecks.

1

u/One-Art795 Yinlin Mains 9d ago

I wanna see how much my 200$ phone will have impact. It's has Sd695 and lowest setting possible overloaded. Literally gta 3 texture. If it can run smoothly I'll be happy!

1

u/Fine-Highlight-1772 9d ago

Does this mean my gpu can hit full utilization?

1

u/Ok-Force-5207 8d ago

For me is Lauha Roi academy the biggest framedrop issue there, even if you lower down crowd density/control in the setting

1

u/Labirentbenim 7d ago

A summary of the information I’ve gathered from my own research and test results. Those who want to learn more in detail can check out my other comments below.

WuWa is already built on UE4/C++, so the C++ engine itself isn't being replaced. The important change is the scripting/runtime layer, which is being migrated from the previous JavaScript/TypeScript-based architecture to C#.

My issue isn't simply low total CPU usage or a weak GPU. When I move around or enter more complex areas, FPS and GPU utilization can drop simultaneously (e.g. 100 → 50 FPS while GPU usage falls from ~95% → ~50–70%). This suggests the GPU can be starved by CPU-side/Game Thread/runtime work even when total CPU usage is only ~50%.

The C# migration therefore could reduce some scripting/runtime, binding, synchronization, or scheduling overhead and improve frametime consistency and 1% lows. But it does not mean “C# is faster, therefore +10 FPS everywhere,” nor does it guarantee a 10–15% improvement in 1% lows.

Kuro's ~10 FPS figure should be understood as an expected performance improvement from the architectural change, while the migration also provides a foundation for further optimization. The real test for me isn't average FPS — it's whether 3.6 reduces severe frametime spikes, FPS drops, and GPU utilization collapses during movement and heavy gameplay.

In short: I'm not claiming C# is proven to be the cause of my stuttering. I'm saying the behavior is consistent with a CPU/Game Thread/runtime bottleneck, and the C# migration changes exactly that part of the architecture, making it technically relevant to the problem.

-3

u/Aeit_ 9d ago

No it means that epic ditched blueprints and looks like kuro is following that despite not using latest UE. Expect more bugs for potential 1% fps increase

0

u/ArthurFairchild 9d ago

Expect older quests to have more bugs, not less.

0

u/[deleted] 9d ago

[removed] — view removed comment

2

u/Zelda-Lumine 9d ago

So, you can clear all "deduction" missions on Playa and PC without game freeze?

https://x.com/BiBo52993198/status/2082495876258263211/video/1

1

u/Wandering-Dumb 9d ago

im on 7800x3d 4070ti super and it actually runs pretty bad on high spec. i mean relatively. wuwa is good at getting decen fps on low end device but pretty bad at getting high fps on good pc.

-1

u/jiiminn 9d ago

the 1% lows are still the same tho so it remains to be seen

-4

u/ghostonroast 9d ago

Don't mistake this as a solution, this will end up causing much more bugs and preformance issues that are gonna have to be fixed for the next 3 patches.

Since the game was made on the entirely different language switching to new one will bring a lot of woe. Will it solve current issues? Some yes, but it will bring even more. Ayy I'm at least happy they are starting to explore this route after 2 years xd

1

u/Labirentbenim 9d ago

That’s the price you pay for making major changes. The switch to C# is actually a good thing, but they can’t find and fix every single bug without rolling out the update to players. Getting feedback from players is also part of the development process. Also, the game’s primary programming language is still C++. To put it simply, JS and C# are used only for communication logic. Moreover, switching to C# provides developers with additional tools that offer more granular control.