v0.8.5-alpha: the one-frame black screen (exclusive fullscreen fix)

The black screen after exactly one frame was our bug, and my own install guide caused it. v0.8.5 fixes it and takes the decision away from you.

Thanks to the tester who sent a full log bundle on v0.8.4. It answered this in one read.

What was happening

The mod forces the game to render internally at 3840x2160 so the picture in the headset is sharp even from a 1080p desktop. That is fine in a window. It is not fine in exclusive fullscreen, where the buffer size is not just a buffer, it is a real display mode.

So on a 1920x1080 monitor, the mod was effectively asking the display for a 4K mode it does not have. The tester's log:

factory: ResizeBuffers 1920x1080 UPSIZED -> 3840x2160
windowed : NO (exclusive fullscreen)
hb 24  frames=1  (+0 in the last second)

One frame reached the headset, and then nothing, forever. In one of his sessions it also took the NVIDIA display driver down with it, an access violation inside nvwgf2umx.dll with no mod code anywhere on the stack.

And the reason he was in exclusive fullscreen at all is that my own INSTALL.txt told him to be. It said to use fullscreen, while the mod's own code was logging "VR needs WINDOWED" into a file nobody reads. He followed the instructions exactly and the instructions were wrong.

What v0.8.5 does

It declines exclusive fullscreen and keeps the game windowed by itself. You no longer have to know any of the above, or pick a window mode, or get it right.

This is not a compromise. Staying windowed avoids the display mode change and keeps the sharp 4K internal render at any desktop resolution. It is better on both counts. The desktop window is only a mirror of what you are already seeing in the headset.

If the game insists on fullscreen anyway, past eight attempts the mod gives up and lets it, and says so in the log. It will not sit there fighting the game.

There is a second, quieter fix behind it: the mod also refuses to resize the buffer to 4K while in exclusive fullscreen, which covers you if you turn the first fix off.

If you want the old behaviour

Set force_windowed = 0 in GRWVR\grwxr.cfg. If you do that and the headset goes black after one frame, also set upsize_width = 0 and upsize_height = 0.

Also worth knowing, and not our bug

Ubisoft posted on 7 August that they are aware of a CPU E-core issue and an issue affecting weapon attachments in the current game version, and that they have a workaround for the attachments. If your weapon behaves oddly, that is a candidate before you suspect this mod. The E-core part only affects Intel CPUs that have efficiency cores.

Being straight with you

I do not have a headset on the machine I build on, so v0.8.5 has not been confirmed in VR by me. The diagnosis came entirely from a tester's logs. v0.8.4's two fixes, by contrast, are now confirmed working on the machine that had been hanging, which is why this release is worth taking.

Reporting a problem

Double-click GRWVR\Collect-Logs.bat and attach the zip it makes. If you would rather do it by hand, please include:

1. GRWVR\grwxr.log, GRWVR\grwxr-prev.log, and every GRWVR\grwxr-<number>.log beside them. The game starts more than one process and the interesting one is often not the first.
2. Whether the game was running normally on your monitor, frozen, or gone from Task Manager.
3. Your headset and runtime (SteamVR, Virtual Desktop, Steam Link, Quest Link).

v0.8.4-alpha: startup fixes (mod switching itself off, and a frozen black screen)

Two testers, two different startup failures, both in the same 30 lines of code. v0.8.4 fixes both.

Neither of these was the motion-controlled weapon, the compiler, the runtime, or your PC. Both were bugs in how the mod attaches itself to the game's renderer at startup, and one of them has been in every release since v0.1.0. It only ever showed up on machines that reach that code in a slightly different order than mine does.

What was actually happening

To hook the game's renderer, the mod creates a tiny throwaway Direct3D swapchain, reads one function pointer out of it, and throws it away. Two things were wrong with that.

1. It built that throwaway on a window it does not own. Windows is allowed to refuse this, and on one tester's PC (Ubisoft Connect + SteamVR + Valve Index) it did, with E_ACCESSDENIED. The mod then correctly stood down and left the game completely alone, which is why his report was "nothing happens, I hear sound in the headset". The game was running perfectly. The mod had switched itself off. His log said so:

ERROR dummy swapchain creation failed: 0x80070005
ERROR cannot read the vtable, so no hooks installed. Game unaffected.
WARN  phase 2 hook NOT installed. Game continues unmodified (rule 7).

v0.8.4 creates its own hidden window instead, and if that somehow fails it tries two more routes and writes down exactly which one Windows refused and why.

2. It threw the throwaway away at the wrong moment. The mod was arming its render hook first and cleaning up second. On my PC that cleanup takes about 130 milliseconds and nobody ever noticed. On a second tester's PC it never finished at all, because by then the game's render thread was already inside the freshly armed hook, and both threads were waiting on the same Direct3D lock. That is a deadlock: a black screen you cannot navigate and have to force-kill from Task Manager. Which is exactly what he reported.

v0.8.4 cleans up before it arms the hook. There is no longer a window in which the two can collide, so this is removed rather than made less likely.

There is a third, smaller change that change 2 requires: the mod now pins the Direct3D module in memory before releasing its last reference to it. On both testers' machines the mod itself was the first thing in the process to load Direct3D at all, which is the difference that made these bugs visible on their PCs and invisible on mine.

Motion controls are unchanged and still on

The weapon still follows your right controller in position and rotation. That code is byte-for-byte identical to the build where it was first confirmed working in a headset, and it stays armed by default (wgun = 3, wgun_pos = 1 in grwxr.cfg). Nothing about it was disabled, reverted, or gated. If you never saw it work, it is because your session never got as far as starting VR at all.

Also in this release

• Your previous log is no longer destroyed on relaunch. It is kept as GRWVR\grwxr-prev.log. If you crash and immediately relaunch to see whether it repeats, the evidence you actually needed survives.
• Collect-Logs.bat ships in the zip and is copied into your GRWVR folder. Double-click it and it packages everything I need into one zip to attach to an issue.

Being straight with you

I do not have a headset on the machine I built this on, so v0.8.4 has not been confirmed in a VR headset by me. What I can tell you is exactly what was wrong, that both diagnoses came out of your logs rather than guesswork, and that the fixes are small and targeted at those two failures specifically.

If it still fails, the log is far more useful than it used to be: every route the mod tries now records its own error code, and the cleanup step now announces itself before and after, so a log tells us which line stopped instead of leaving a silent gap.

If you are updating

Run install.bat. It keeps your existing grwxr.cfg and merges in any new keys. If you hand-copy files instead, the game will not start, because the installer also places openxr_loader.dll and a copy of your own Windows dxgi.dll, and the game cannot load without both.

Reporting a problem

Please include three things, because together they separate every cause I currently know how to tell apart:

1. Your GRWVR\grwxr.log and every GRWVR\grwxr-<number>.log beside it. The game starts more than one process and the interesting one is often not the first.
2. Whether the game was running normally on your monitor, frozen, or gone from Task Manager.
3. Which headset and which runtime (SteamVR, Virtual Desktop, Steam Link, Quest Link).

v0.8.3-alpha: GPU-mismatch startup-crash fix (two-GPU PCs)

The startup crash points to a two-GPU problem, and v0.8.3 both guards against it and proves it.

Tester logs narrowed it hard. The same v0.8.2 build ran flawlessly on Virtual Desktop for one tester (15,554 frames, 90 fps) and froze at frame 1 for another. Same build, same runtime, opposite result, so it was never the build or the compiler or Virtual Desktop. The difference is the PC, and the strong lead is a GPU mismatch. v0.8.3 adds the detection that confirms it in the log and stops the freeze.

What was actually happening

The crashing PC had two GPUs: a discrete graphics card plus the integrated graphics built into its CPU (common on AMD Ryzen 7000/9000 and many Intel chips). The headset runtime used the graphics card, but Windows was running the game on the CPU's built-in GPU. Frames cannot be shared across two different GPUs, so the VR view rendered exactly one frame and then hung. That is the black-screen-then-crash.

What v0.8.3 changes

• The mod now detects a GPU mismatch at startup. Instead of freezing the game, it keeps running on your flat monitor and writes a clear, step-by-step fix to the log. This protection is ON by default, including for people who UPDATE and keep their old config.
• If you were crashing, the log now tells you exactly what to do, and so does INSTALL.txt.

If you hit the black-screen crash, do ONE of these and relaunch

Run v0.8.3 first: your GRWVR\grwxr-<pid>.log will now say plainly whether the game and headset are on different GPUs. If it reports a mismatch, force the game onto your graphics card. In order of what actually works:

1. Plug your monitor into your graphics card's ports, not the motherboard's HDMI/DisplayPort. This is the most reliable fix by far.
2. Disable the CPU's built-in graphics in Device Manager (or BIOS).
3. NVIDIA Control Panel / AMD Software: set GRW.exe's preferred GPU to your graphics card.
4. Windows Settings > System > Display > Graphics: GRW.exe = High performance. (Note: this one often does NOT move the game off the built-in GPU on its own; if it doesn't, use 1 or 2.)

Single-GPU PC and still crashing? Please open a GitHub issue with your GRWVR\grwxr-<pid>.log.

Everything else

Same as v0.8.2: the weapon follows your right controller, bullets follow your gaze (aim down sights to shoot accurately), full stereo at 72 Hz, true first person, head aim, Touch as an emulated gamepad. Note that the research draw-probes stay off by default.

Solo campaign only. Never co-op, PvP, or matchmaking (the game ships Easy Anti-Cheat). Offline mode recommended. Your antivirus may flag dxgi.dll; INSTALL.txt explains why.

---

Optional, never required: a donation page exists at buymeacoffee.com/firejumper93 for anyone who has asked. The mod is free and stays free.

v0.8.2-alpha: startup-crash fix (draw hooks off by default)

Startup-crash fix: the mod no longer touches the game's draw calls.

Tester logs on v0.8.0/v0.8.1 pinned this down. Some people crash on startup (black screen for a couple of seconds, then the game closes), on both Virtual Desktop and Steam Link. This release removes the most likely cause.

What the logs told us (thank you, testers)

• It is NOT the motion-controlled weapon. A tester ran with the weapon feature turned off (safe_mode = 1) and it still crashed the same way, at the same point. So the weapon hooks are ruled out.
• The one thing still touching the game every frame was the draw-call rerouting. For research (a texture/skinning probe and a weapon-draw census) the mod was detouring the game's own D3D11 draw calls. The VR view never needed that, its cost was never measured, and it was the only hook left on the render path when the crash happened.

What changed in v0.8.2

• The draw-call rerouting is OFF by default (draw_probes = 0 in GRWVR\grwxr.cfg). The mod no longer patches the game's draw functions unless you explicitly turn the research probes on. This is the fix attempt, and it is the right default regardless: the shipping mod should not be doing unmeasured work on the render path.
• Carried over from v0.8.1: the blocky placeholder gun is gone, and safe_mode still exists as a switch (now known not to be the cause, kept for diagnostics).

If v0.8.2 works

Everything from v0.8.0 is intact: the weapon follows your right controller in position and rotation, bullets still follow your gaze (aim down sights to shoot accurately), full stereo at 72 Hz, true first person, head aim, Touch as an emulated gamepad.

If v0.8.2 STILL crashes on startup

Then the cause is in the core VR path or the build itself, and we will need a differently-compiled version. Please report it on the GitHub issue with your GRWVR\grwxr-<pid>.log. In the meantime, v0.7.0 from the Releases page should just work (it is the last release built the old way, known good on Virtual Desktop and Steam Link).

Honest status

This build, like v0.8.0/v0.8.1, was compiled on a different PC than earlier releases and has not been headset-tested here, so it is a targeted fix based on your logs rather than a confirmed one. Your result on v0.8.2 tells us whether we are done or whether the next step is a rebuild on the original machine.

Install

Unzip anywhere, run install.bat, read INSTALL.txt. ASW off, fullscreen window mode, SMAA or no AA (never TAA), motion blur off, FSR off, 72 fps limit. Your antivirus may flag dxgi.dll; INSTALL.txt explains why, and the full source is public if you would rather build it yourself.

Solo campaign only. Never co-op, PvP, or matchmaking (the game ships Easy Anti-Cheat). Offline mode recommended.

---

A few people have asked whether they could donate. There is now a page for that: buymeacoffee.com/firejumper93. Entirely optional, never required, nothing is gated behind it; the mod is free and stays free. It just helps with tools and late nights, and it is appreciated.

v0.8.1-alpha: startup-crash fix attempt (Virtual Desktop + Steam Link)

A startup-crash fix attempt, and the placeholder gun is gone.

Some people are hitting a crash on startup with v0.8.0: a black screen for a couple of seconds, then the game closes. It has been reported on both Virtual Desktop and Steam Link, and both worked in earlier releases, so this is a regression. This release removes one likely cause, adds a switch to rule out another, and, if neither helps, points you at exactly what to tell us.

Being upfront: v0.8.0 was the first build produced on a different PC with a different compiler than every earlier release, and it went out without a headset test. That makes the build itself a real suspect, not just the mod's new code. This release is built the same way (it is the only option available right now), so it may not fix the crash on its own. The steps below are how we find out, and v0.7.0 is a known-good fallback in the meantime.

What changed

• Removed the blocky placeholder gun (the old overlay_gun preview) entirely, along with its config keys. It was a rough visual-only stand-in, and removing it also drops one of the things v0.8.0 newly did at launch.
• New safe_mode config option (GRWVR\grwxr.cfg, default off). safe_mode = 1 turns off this release's new motion-controlled-weapon engine hooks, making the startup path behave like v0.7.0. One edit to get running, and a clear signal to us about where the problem is.

If the game crashes on startup, walk this ladder (please report which step works)

1. Just run v0.8.1. The placeholder gun removal may be enough.
2. Still crashing? Set safe_mode = 1 in GRWVR\grwxr.cfg, save, relaunch. You lose the motion-controlled weapon this release, nothing else.
3. Still crashing with safe_mode = 1? Then it is not the mod's new code, it is the build itself, and we need a version compiled on the original PC. Please say so on the GitHub issue (with your GRWVR\grwxr-<pid>.log), and in the meantime:
4. Fallback that should just work: v0.7.0 from the Releases page. It is the last release built the old way and is known good on Virtual Desktop and Steam Link.

Quest Link users: you should not need any of this. Leave safe_mode = 0.

Everything else is v0.8.0

The weapon follows your right controller in position and rotation; bullets still follow your gaze (aim down sights to shoot accurately); full stereo at 72 Hz; true first person; head aim; Touch as an emulated gamepad.

Install

Unzip anywhere, run install.bat, read INSTALL.txt. ASW off, fullscreen window mode, SMAA or no AA (never TAA), motion blur off, FSR off, 72 fps limit. Your antivirus may flag dxgi.dll; INSTALL.txt explains why, and the full source is public if you would rather build it yourself.

Solo campaign only. Never co-op, PvP, or matchmaking (the game ships Easy Anti-Cheat). Offline mode recommended.

---

A few people have asked whether they could donate. There is now a page for that: buymeacoffee.com/firejumper93. Entirely optional, never required, nothing is gated behind it; the mod is free and stays free. It just helps with tools and late nights, and it is appreciated.

v0.8.0-alpha: The Weapon In Your Hand (the gun follows your controller)

The weapon follows your hand now.

This release adds the first real motion control to Wildlands VR: the game's own weapon follows your right controller, in position and rotation, one to one. Point your hand and the gun points there. It is not an overlay or a fake viewmodel; the mod writes the bone the engine mounts the weapon on, at the exact moment the engine reads it, so the model, the muzzle flash and the collision all move together.

As far as we can tell, no game on this engine family has had a motion-controlled weapon before. This is the first pass at it, and it ships with its rough edges named below rather than hidden.

What you get in this build

• Motion-controlled weapon (new): the held weapon tracks your right controller 1:1. On by default; wgun = 0 in GRWVR\grwxr.cfg turns it off and gives you exactly the v0.7.0 behaviour back, live, no restart.
• A safety rail on the feature: however wrong a tracking sample ever is, the gun cannot end up more than 60 cm from where the game itself put it, and its rotation rate is capped. Both are tunable in the config.
• Everything from v0.7.0: full stereo on the current game version at 72 Hz, true first person, head aim (Numpad Decimal), Touch controllers as a full emulated gamepad, hand markers, 4K internal rendering, hot-reloading config plus the cfg_gui.exe slider editor.
• A hardening fix: a config-supplied research value could previously crash the game if edited out of range by hand. Config values are now bounds-checked before use. A number in a text file should never be able to kill the process, and now it cannot.

The honest limits, read before judging

• Bullets still follow your gaze, not the gun. You can point the weapon at one thing and hit another. Aiming down sights remains the accurate way to shoot. This is the last major piece, it is close (three candidate mechanisms were tested and ruled out with evidence, one identified candidate remains), and it is what the next release is about.
• Your character's arms do not follow the weapon yet, so the gun can look detached from the body. IK arms are a later phase.
• The gun sits where the engine mounts it, near the receiver, which may not be exactly in your fist. A grip offset is coming.
• Head hiding in first person is still out on the current game version (see the v0.7.0 notes); you will see hair or helmet from inside until the engine function is re-derived.

Release engineering, honestly

The motion-controlled weapon was confirmed in the headset on 2026-08-09/10 ("it is tracking the controller", position and rotation both, clean counters over 7 million hook calls). This exact binary was then built from that source plus the bounds-check fix above, on a different machine, and has not itself been through a headset run yet. Nothing in the fix touches the weapon path; it is labeled here anyway, because that is the deal: you get told what was tested, not what should work.

Settings and install

Unchanged from v0.7.0: unzip anywhere, run install.bat, read INSTALL.txt. ASW off, fullscreen window mode, SMAA or no AA (never TAA), motion blur off, FSR off, 72 fps limit. If your game is under Program Files, right-click install.bat and run as administrator. Your antivirus will probably flag dxgi.dll; INSTALL.txt explains why in full, and the complete source is public if you would rather build it yourself.

The usual rules

Solo campaign only. Never co-op, PvP, or matchmaking (the game ships Easy Anti-Cheat). Offline mode recommended.

---

A few people have asked whether they could donate. There is now a page for that: buymeacoffee.com/firejumper93. Entirely optional, never required, nothing is gated behind it; the mod is free and stays free. It just helps with tools and late nights, and it is appreciated.

Crash-fix TEST: v0.7.0 code on the new compiler (NOT a feature update)

This is NOT a feature update. It is a crash-fix TEST build.

If you are running fine on v0.8.2, you do not need this. This exists only for the people hitting the startup crash (black screen for a couple of seconds, then the game closes) on Virtual Desktop and Steam Link.

What it is

The exact code of v0.7.0 (the last version known to work on Virtual Desktop and Steam Link), recompiled with the current compiler (VS 2022, the same one used for v0.8.0/v0.8.1/v0.8.2).

It deliberately does not include the v0.8.x features (no motion-controlled weapon, etc.). That is the point: it isolates one single variable. Tester logs have already ruled out every code change between v0.7.0 and v0.8.2 as the cause of the crash, which leaves only the compiler. This build pairs v0.7.0's known-good code with the new compiler to find out.

Please test it if you were crashing (swap is quick)

You already have v0.8.2 installed, so:

1. Open your Wildlands game folder.
2. Rename the existing dxgi.dll to dxgi.bak.
3. Copy the dxgi.dll from this zip into the game folder.
4. Launch and see if it still crashes on startup.

Or just run install.bat from this zip over your existing install.

What your result tells us (please report it on issue #2 with your GRWVR\grwxr-<number>.log)

• If it STILL crashes: the compiler is the cause. The fix is to build the mod with the original toolchain; no code change would have helped, and we will sort out the build environment.
• If it WORKS: the compiler is innocent, and the crash is a code change made after v0.7.0. That is fixable, and it tells us exactly where to look. You would also have a working (if older) build to play on in the meantime.

Everything else

Same rules as always: solo campaign only, never co-op/PvP/matchmaking. Your antivirus may flag dxgi.dll; INSTALL.txt explains why. If you are not affected by the crash, stay on v0.8.2 for the newer features.

---

Optional, never required: a donation page exists at buymeacoffee.com/firejumper93 for anyone who has asked. The mod is free and stays free.

v0.7.0-alpha: The Update Update (full stereo on the August 2026 game patch)

The game updated and broke the mod. This release is the mod catching up.

Ubisoft's ~31 GB "Last Rites" update (August 2026) replaced GRW.exe. This mod refuses to touch an executable it does not recognize, so on the updated game older releases simply ran flat: no crash, no risk, just no VR. That refusal is by design, and this release is the other half of the design: every engine address re-derived and re-verified against the new executable.

Verified in the headset on the updated game (2026-08-08): full stereoscopic 3D, head tracking, the fullscreen view, 4K internal rendering, head aim, Touch-as-gamepad, and the no-blur patch. All 11 camera hooks confirmed live in the log.

Bonus from the update: Steam and Ubisoft Connect now ship the byte-identical executable, so one verified address table covers both stores. (The two pre-update executables remain supported by their own tables, so nobody is left behind.)

What you currently get in this build

• Full stereo VR on the current game version, paced at 72 Hz, alternate-eye rendering with compositor reprojection
• True first person anchored to your character's head bone, with the close-range body blur removed
• Head aim (bullets follow your gaze, 1:1), toggle on Numpad Decimal
• Touch controllers as a full emulated gamepad plus tracked hand markers
• Scoped aiming that stays true (the mod steps aside while you are scoped)
• Hot-reloading config (GRWVR\grwxr.cfg) plus the cfg_gui.exe slider editor

What the update broke, honestly

• Head hiding in first person is temporarily NOT working (confirmed in the headset). The update recompiled the engine function behind it, its signature no longer matches, and this mod never guesses addresses: the feature disables itself rather than risk your game. You will see hair or helmet from inside until it is re-derived by hand. Top restoration priority for the next release.
• Two developer-only research instruments are disarmed on the new build for the same reason. They shipped off by default; you will not notice.

Not sure it is broken yet, but flagged for re-verification

These worked before the update and are expected to work, but the update changed weapon handling (authentic reloads, two-primary loadout) and the internal structures they read have not been re-confirmed in the headset yet:

• The head-bone first-person anchor (eye height following stand, crouch, prone)
• The weapon-identification research readings (wp_markers, wskel, off by default)

If either misbehaves for you, that is why. Please report it with your GRWVR\grwxr-<pid>.log.

The installer now finds your game by itself

No more pasting paths. install.bat locates the game in this order and tells you which method found it: the folder you unzipped into, then every Steam library on every drive (read from Steam's own library list, so unusual install locations work as long as Steam knows about them), then Ubisoft Connect's per-game install records, then the classic default paths. Only if all of that fails does it ask, and you can drag the game folder onto the window instead of typing. uninstall.bat detects the same way, removes exactly what the installer placed, and asks before touching your config and logs.

Settings for the new game version

• The update added FSR upscaling: keep it OFF with the mod (it sits inside the render path the mod manages, untested there).
• The update's new native immersion toggles (reduced highlight glow, throwable sightline preview off, hidden-UI sounds) work fine and are recommended in VR.
• Everything else unchanged: ASW off, fullscreen window mode, SMAA or no AA (never TAA), motion blur off, 72 fps limit. INSTALL.txt has the full baseline.

The usual honesty

• Solo campaign only. Never co-op, PvP, or matchmaking (the game ships Easy Anti-Cheat). Offline mode recommended.
• There are still no real motion controls: Touch is an emulated gamepad, and the motion-tracked layers are head aim and hand markers. Read "Controller support, honestly" in the README before forming an opinion.
• Your antivirus will probably flag dxgi.dll (Program:Win32/Wacapew.A!ml or similar). That is a machine-learning shape match on the hooking technique, not a signature match. INSTALL.txt explains it in full, and the complete source is public if you would rather build it yourself.

Install: unzip anywhere, run install.bat, read INSTALL.txt. If your game is under Program Files, right-click install.bat and run as administrator.

v0.6.1-alpha: the camera contract

v0.6.1-alpha: the camera contract

If you tried an earlier alpha and the view flipped over when you looked up, or your
character always drifted left no matter how often you recentred, both of those are
fixed here. Both were real bugs, not tuning problems.

Fixed, all confirmed in the headset

• The view no longer inverts when you look up or down. The right stick's vertical
  axis was pitching the engine camera underneath the pitch coming from your head;
  past vertical the two summed and flipped the world over. Stick pitch is now removed,
  so your head is the only thing that pitches the view. New config key stick_pitch
  if you want it back for aircraft.
• Recentring now actually fixes the drift. The mod tracks how much aim it has fed
  the engine, and that total used to survive a recentre, leaving your view facing one
  way and your character aiming another by exactly the accumulated angle (140 degrees
  in one recorded session). That is the whole explanation for "it runs slightly left and
  recentring never helps". Every recentre now resynchronises, and view and body agree
  immediately.
• Aim keeps following your head while you stand still. The aim path used to wait on
  the engine's own updates, which stop when you are idle, so aim seemed to work only
  while moving or shooting.

Heads-up: your antivirus will probably flag dxgi.dll

Windows Defender reports it as Program:Win32/Wacapew.A!ml. We hit this ourselves while
packaging this release. The !ml suffix means a machine-learning model flagged it by
shape rather than matching any known malware. A VR mod has to load inside the game,
intercept graphics calls and rewrite running code, which is structurally identical to
injection, and the file is unsigned. INSTALL.txt explains it in full, including how to
add an exclusion, and the complete source is public if you would rather compile it
yourself than trust a binary from us.

Still honest about the controls

There are still no real motion controls. The Touch controllers act as an emulated
gamepad, plus hand markers and head-driven aim. Making the weapon follow your controller
is the work in progress, and this release contains research toward it that is switched
off by default and does not affect how the mod plays.

Known issue: pressing Numpad 8 (first-person toggle) in the pre-game lobby can crash
the game. Only use it during on-foot gameplay.

Also fixed: the most common installation failure now names itself

If you copy the mod's files into the game folder by hand instead of running
install.bat, the game crashes a few seconds after launch with nothing useful in
the log. The installer is what creates dxgi_real.dll (a copy of your own Windows
dxgi.dll), and every function in the mod forwards to that file, so without it the
first graphics call dies inside Windows itself.

Until now the mod reported that as normal. It now detects the missing file and says
so in capitals at the top of the log, with the fix. INSTALL.txt also spells it out,
including that a game installed under Program Files needs install.bat run as
administrator or Windows silently refuses the copy.

Thanks to the tester who hit this and sent a log; it cost him hours of chasing
overlays and anti-cheat that were never the problem.

v0.6.0-alpha: experimental Epic/Ubisoft Connect support, Touch startup fix, hand markers

The headline: Epic and Ubisoft Connect builds are now supported, experimentally. The store version of Wildlands ships a different GRW.exe than Steam; this release carries a full, machine-verified address table for both known builds and identifies which one it is running inside from the executable's own headers. Every address is re-verified in place before anything is patched, and an unrecognized executable (for example a future game patch) is named in the log and left completely untouched. Honest status: the store table was derived and machine-verified offline against a real store executable, but no store-build user had confirmed it in a headset at release time. If you play the Epic or Ubisoft Connect version, please try it and report your GRWVR\grwxr-<pid>.log either way (look for the build pin: line near the top).

Also in this release:

• Fixed: Touch controllers dead unless a gamepad was plugged in, or when the headset came up after the game. The game probes for a gamepad once at startup and never polls again if nothing answers; the mod now answers as a connected (neutral) pad from the first poll and hands over to the Touch controllers when they arrive. This was the most reported tester issue.
• Hand markers (verified in the headset): blue and orange dots drawn where your controllers actually are, with real stereo depth. hand_markers in the config, default on.
• Head aim is now the default (aim_source = 0). Controller-driven aim is retired as a default: in this engine the gameplay aim direction is the camera, so steering aim from the controller turns your view and fights head-look. Your head aims and looks (which is truly 1:1), the controller is a full emulated gamepad plus hand markers, and the sight picture stays true under ADS. The gun following your hand is being pursued through the engine's object-placement system instead; see the roadmap.
• Weapon-handle identification instrument (research aid, default off): wp_markers = 1 draws colored dots on the engine objects placed nearest the camera with a color-to-handle legend in the log. If you want to help get the visible gun onto your controller, the CHANGELOG explains the two-minute test.
• Numpad 8 (first person) now also recenters, so a stale head reference cannot skew a session.

Install: unzip into the game folder next to GRW.exe (or run install.bat), and read INSTALL.txt, particularly the baseline graphics settings (never TAA) and the ASW-off requirement. Solo campaign only, always.

Full details in the CHANGELOG and the reworked README sections "Controller support, honestly", "Which version of the game do I need?" and "Roadmap".