Mage ArenaMAVR

Last Updated

First Uploaded

Downloads

Likes

Size

674KB

Dependency string

J_axon-MAVR-1.0.0

Dependants

0 other mods

Mods

Download

Details Required (1)Wiki Changelog Versions Analysis

MA VR

Version 1.0.0 — Beta Made by J_axon

Full virtual reality support for Mage Arena. Room-scale head and hand tracking, a real body you can look down at, motion controls, look-based aiming, and networking that lets VR and flatscreen players see each other move properly.

Client-side only. Your friends do not need it, and a lobby with one VR player and five flatscreen players works fine.

Runs on OpenVR — SteamVR must be running before you launch the game. Not OpenXR. See Why OpenVR and not OpenXR if you want the reasoning. Any headset SteamVR supports will work.

Requirements
Installing
Why OpenVR and not OpenXR
Choosing VR or Flatscreen
Controls
Look-based actions
The VR settings panel
Your body
Menus and the laser pointer
Multiplayer and player tags
Spell effects and the pipe smoke
Why the lighting looks the way it does
Why it may look softer than you expect
Configuration
Reporting a problem
Known limitations
Roadmap
Troubleshooting
Disclaimer

Requirements

Mage Arena on PC
BepInEx 5.4.2305 (x64, Mono) — this exact pack. The mod uses a preloader patcher as well as a plugin, and BepInEx 6 is a different architecture that will not load it.
SteamVR — required, and it must already be running when you launch the game. This is not optional or a convenience: the mod renders through the OpenVR runtime, and the OpenVR compositor is SteamVR. Without it there is nothing to hand frames to, and the mod will load, log the failure, and leave you on the desktop.
A PC VR headset. Developed and tested on a Meta Quest 3 over Virtual Desktop. Anything SteamVR drives should work — Quest over Link, Air Link, Steam Link or Virtual Desktop, Index, Vive, Pico, and WMR headsets through SteamVR.

Installing

Mod manager

Install through your mod manager. The BepInEx dependency is handled for you, and the OpenVR runtime is put in place automatically the first time you launch. Nothing else to do.

Manual

If you are not using a mod manager:

Install BepInEx 5.4.2305 x64 Mono into your Mage Arena folder, then launch the game once and close it so BepInEx generates its folders.
Copy the BepInEx folder from this package into your Mage Arena folder, merging with the one already there. You should end up with:

Mage Arena/
└─ BepInEx/
   ├─ plugins/MageArenaVR/MageArenaVR.dll
   └─ patchers/MageArenaVR/
      ├─ MageArenaVR.Preload.dll
      └─ openvr_api.dll

Start SteamVR.
Launch the game.

You do not need to place openvr_api.dll anywhere yourself. It ships next to the patcher, and the patcher installs it into the game's native plugin folder at startup — before anything tries to use it. If it cannot write there (a Program Files install without permission, for example) it loads the file straight from the mod folder instead, so either way it works.

Why OpenVR and not OpenXR

Short version: Mage Arena is not built with VR support, and OpenVR is the only runtime that can be added to a game like that from the outside without fighting the engine.

OpenXR is the newer standard and would normally be the right choice. But in Unity it is not just a library you call — it is an XR plugin, and Unity wires those in at engine startup, before any mod code runs. Adding one to a shipped non-VR game means:

writing a UnitySubsystemsManifest.json into the game's data folder,
deploying UnityOpenXR.dll and openxr_loader.dll beside the engine's own natives,
and persuading Unity to register and initialise a display subsystem the build was never compiled to expect.

This mod did work that way early on, and it was fragile in exactly the way you would expect from injecting files into someone else's engine startup. When the display subsystem did initialise, it took over the render loop on its own terms; when it did not, the failure came from inside the engine with nothing useful to report.

OpenVR needs none of that. openvr_api.dll is an ordinary native library. The mod calls it from a normal plugin, renders each eye itself into a render texture, and hands the result to the SteamVR compositor with Submit(). No manifest, no loader DLLs, no engine XR registration — nothing touches Unity's startup path at all. Everything the mod does to the game is done from managed code, at runtime, where it can be inspected and undone.

That control is what makes the rest of this mod possible: rendering each eye by hand is what lets it fix per-eye lighting, give each eye its own camera, and hand every override back to the game when you leave a match.

The trade is the one stated above — SteamVR has to be running. Given SteamVR drives essentially every PC headset, including Quest through Link, Steam Link or Virtual Desktop, that costs almost nothing in practice.

If you are curious what this looks like in the log, the mod reports the runtime it loaded on startup:

[MageArenaVR.Preload] OpenVR runtime loaded from '...\MageArena_Data\Plugins\x86_64\openvr_api.dll'.

Old OpenXR files from pre-1.0 installs are deleted automatically, so a leftover UnityOpenXR.dll cannot register a display the mod does not use.

Choosing VR or Flatscreen

When the game starts, a Windows dialog asks how you want to play:

Yes — Virtual Reality. Full VR. Requires a headset with SteamVR running.
No — Flatscreen. Normal keyboard and mouse.

The dialog appears before the game draws anything and before the headset is touched, so it is a real choice rather than a restart.

Flatscreen is not just "the mod off." It runs a companion mode that changes nothing about how you play — no VR, no rendering changes, no input changes — but adds the two things a flatscreen player wants when their friends are in VR:

You see VR players move for real. Their head and hands are driven by their actual tracking instead of the game's walk-cycle animations.
You are tagged as a flatscreen player, so VR players can tell at a glance who is on a monitor.

To skip the dialog, set ForcedMode in the config to VR or Flat. Ask is the default.

Controls

Input	Action
Left stick	Move
Left stick click	Sprint (hold)
Right stick, left/right	Turn — snap or smooth, your choice
Right stick click	Crouch (toggle)
Right trigger	Use item / attack
Left trigger	Secondary / aim
A	Jump
B	Interact
X	Cycle inventory, one slot per press
Y	Pause / Escape
Left grip	Map (hold)
Right grip + right trigger	Drop the item you are holding
Right grip + right stick left/right	Flip spell book pages
Both grips, hold ~0.4s	Recall
F1, or both thumbstick clicks	Open the VR settings panel
F8	Re-calibrate your height and arm reach

A few of the combinations exist to stop inputs colliding:

Right trigger is suppressed while the right grip is held, so gripping to drop never also swings what you are holding.
Holding both grips suppresses map and drop, so recall cannot fire them by accident.
Turning is suppressed while the right grip is held, because that combination is page-flipping.

Everything that maps to a game action targets whatever key is currently bound in the game's own settings, so if you rebind jump or interact in-game, VR follows.

Calibration

The mod measures your height and arm reach automatically about 15 seconds after you enter a game. F8 re-runs it — stand naturally with your arms out and let it settle. Do this if your arms feel too short or your body sits at the wrong height.

Look-based actions

Several things in this game are aimed by where you are looking rather than where you are pointing, and getting that right in VR takes more than reading the camera.

The game does not aim from your headset. It rebuilds its camera's rotation from look values it is fed, and that rebuild clamps pitch and discards roll. Read the camera and your aim drifts from where you are actually looking — worse the further you tilt your head. So anything aim-critical reads the real headset pose instead.

Spell aiming is driven from the headset. You aim by looking, the same as the base game, but the direction comes from your actual head orientation.

Dark Blast gets special handling. Its damage is a long box that passes through walls, and the game builds that box from its camera's forward direction. The mod points the camera at your true headset direction for the instant of the cast and hands it straight back, so the damage lines up with your aim, not just the visible beam. Because the spell's only visible body is volumetric fog — which VR cannot afford — a beam is drawn down the exact axis and length the damage box uses. What you see is genuinely what hits, walls included, because the damage goes through walls too.

Interaction uses the same real headset pose. Ray length is configurable, and anything you are looking at that can be interacted with gets a coloured outline so you know before you press B. The outline is a shell drawn around the object with its colour, thickness and brightness all adjustable — it is emissive, so it stays a clean solid colour instead of being washed out by daylight. Skinned meshes that cannot take a shell get a tint instead.

The VR settings panel

Press F1, or click both thumbsticks at once.

The panel floats in front of you and faces you, following gently as you look around. It works anywhere — main menu, lobby, or mid-match — and does not depend on any game menu being open. Point at it with the laser and click a row to cycle it. Changes apply immediately; nothing needs a restart.

It uses the game's own menu typeface rather than a generic font, so it should not look bolted on.

Every setting here is also in the config file, and the panel and the file are the same values — change one and the other follows.

Turning — Snap / Smooth

Snap rotates you in one instant step per flick of the stick. Because your view never moves through the rotation, your inner ear is never told you turned, which is the single most effective thing for people who get uncomfortable in VR. It is the default for that reason.

Smooth rotates continuously while you hold the stick, proportional to how far you push past a small deadzone. It feels far more natural and makes tracking a moving target much easier, but continuous rotation with a stationary head is the classic trigger for motion sickness. If you have VR legs, use it.

Snap gives a small haptic tick on each turn. Smooth deliberately does not — it delivers a tiny rotation every frame, so a pulse per step would be a constant buzz in your hand.

Snap angle — 15° / 30° / 45° / 60° / 90°

How far one snap turns you. 45° is the default and is the usual comfortable middle.

Smaller angles mean finer aim but more flicks to turn around, and each flick is a jump your brain has to reconcile — more small jumps can actually be less comfortable than fewer large ones. Larger angles turn you around faster with fewer interruptions, but 90° can leave you briefly disoriented because the entire view changes at once.

Only used in Snap mode.

Smooth speed — 60 / 90 / 120 / 180 / 240 °/s

Degrees per second at full stick deflection. 120 is the default — about three seconds for a full circle.

Lower is gentler and much easier on the stomach. Higher lets you spin to face someone behind you quickly, which matters in a fight, at the cost of comfort. Rotation eases in from the deadzone rather than starting abruptly, so small stick movements give fine control at any speed setting.

Only used in Smooth mode.

Shadow distance — 40 / 60 / 75 / 100 / 150 / 250 m

How far from you shadows are drawn. 250 m is the default.

This is a sharpness-versus-range trade, and the reason is worth knowing: a shadow map has a fixed number of pixels, spread across however much ground the distance covers. Halving the distance does not make shadows cheaper — it makes them sharper, because the same pixels now cover half the ground.

Low (40–75 m) — crisp, detailed shadows nearby. Anything beyond the limit has no shadow at all, which reads as objects in the distance sitting slightly flat.
High (150–250 m) — distant shadows exist, but everything is softer, and far-off shadows can look like vague blobs with the right outline and no detail.

Performance cost is roughly the same either way. This is about where you want the detail spent.

Desktop mirror — On / Off

Whether the monitor shows what you see in the headset. On by default.

Turning it off saves a small amount of performance for something you cannot see while wearing the headset. Worth it if you are chasing frames and nobody is watching the screen; leave it on for recording, streaming, or when someone is spectating.

The mirror shows the left eye only, and drawing it costs nothing beyond the copy itself.

Volumetric clouds — On / Off

Whether HDRP draws its volumetric clouds. On by default — they are a large part of how the sky looks in this game.

They are also the most expensive single effect still enabled, so turning them off is the second biggest performance win after the camera setting, and the two stack.

There is a visual catch worth knowing: with One camera in a match, clouds show a moving black grid. HDRP builds them from a history buffer that assumes one camera position per frame, and rendering the same camera twice breaks that assumption. Two cameras fixes it; One cannot. So if you are running One camera for frames, turning clouds off is usually the better-looking choice as well as the faster one.

Cameras in match — Two / One

Which rendering path is used during a match. This is the biggest performance lever in the mod, and a genuine trade rather than a quality slider.

Two (better visuals) — each eye gets its own camera. HDRP ties several things to the camera rather than to the frame: the volumetric cloud history, the colour buffer used for water refraction, and various screen-space effects. Giving each eye its own means those effects reproject against their own previous frame instead of the other eye's. Volumetric clouds render correctly instead of showing a moving black grid, and water resolves properly in both eyes.

One (faster) — the game's own camera is rendered twice, once per eye. This is the original path and it is meaningfully cheaper, because HDRP does roughly half the per-frame work. The cost is that both eyes share one set of buffers, so the cloud grid returns and water looks right in only one eye at a time.

The menu always uses one camera, whichever you pick. Per-eye cameras exist to fix clouds and water, and a menu has neither — while the HDRP state they accumulate during a match cannot be handed back on the way out, which used to leave the menu rendering wrong. Your choice is remembered and re-applied the instant you enter a match, so the setting means what it says: in match.

Switching is instant and safe in either direction. If you are struggling for frames, try this before anything else — it moves performance more than every other setting combined.

Your body

You have a real body — the game's own character, not a floating pair of hands. Look down and you see yourself.

Your head is anchored to your real head position, and the head mesh is hidden so it does not block your view from inside.
Your arms are solved to your controllers with two-bone IK, so shoulders and elbows bend properly rather than snapping.
Hands land on your controllers, measured to the knuckle rather than the wrist.
Held items ride your hand and are angled to sit naturally. The spell book is excluded from those offsets, because it needs its own pose.
The sticky tongue is repositioned so it works from a hidden head.
Health and stamina ride your left wrist. Look at your wrist to check them. Position, scale and rotation are all configurable.

Menus and the laser pointer

Game menus are converted to world-space panels you point at with a laser from your right hand. The laser appears only when there is something to point at, so it is not in your way while playing.

Menu input goes through a proper Unity input module rather than faked clicks, which means:

Sliders and scroll views work. You can press and drag them like a mouse.
Overlapping panels sort correctly.
Hover, press, drag and click follow Unity's own rules, so the game's own menus behave the way they were designed to.

The desktop mouse is fully blocked while in VR so it cannot fight the laser.

Multiplayer and player tags

The mod is client-side. Unmodded players are never sent any of its data, so a mixed lobby behaves exactly like vanilla for them.

Seeing other players move

VR players broadcast their real head and hand positions over the game's own networking, about 20 times a second. Poses are sent relative to each player's own body, so they rebuild correctly no matter where anyone is standing, how their playspace is rotated, or how their room is set up.

The server only relays that data to clients that announced they can read it. Anyone without the mod never receives a single byte of it.

You are...	You see a VR player as...
VR (this mod)	Their real head and arm movement
Flatscreen (this mod, flatscreen mode)	Their real head and arm movement
Unmodded	The game's normal animations — exactly as vanilla

Spell effects and the pipe smoke

Several of this game's effects are built entirely out of volumetric fog. That is a lovely way to make smoke and glow on a monitor, and it is unusable in VR — running HDRP's volumetric pass costs roughly 7 FPS per eye, which is not a trade worth making at any quality setting.

With volumetric fog off, those effects become invisible. Not dim — genuinely not there. A Dark Blast with no visible body is an invisible instant-kill lane, which is a fairness problem rather than a cosmetic one.

So the mod detects effects whose only visible body is volumetric fog and gives each a cheap stand-in that costs almost nothing:

Fireball — an emissive core attached to the projectile.
Magic missile — the same treatment, per missile.
Dark Blast — a beam down the exact axis and length of its damage box, drawn through geometry because the damage passes through geometry. It fades out shortly after the cast rather than hanging in the air.
Pipe smoke — a translucent ring.

The stand-ins are parented to the game's own objects, so the game moves them, spins them and destroys them, and they inherit all of that for free. A fireball's core rides the fireball. A smoke ring blows away because the game blows it away.

The smoke ring is the one place the mod animates something itself. The fog volume behind it barely changes size over its life, so mirroring it exactly gave a small ring that just sat there. Instead it starts small, drifts upward at a moderate pace, widens as it travels, thins out and disappears.

Anything room-sized is left alone — a large fog volume is atmosphere, not an effect, and faking it as a shape would look far worse than leaving it out.

Why the lighting looks the way it does

This is the part most likely to look "off" if you are comparing against flatscreen, so it is worth explaining rather than leaving you to wonder.

There is no automatic exposure. On a monitor, the game continuously adapts image brightness to the scene — walk into a cave and it brightens, step into sunlight and it settles down. That adaptation does not run in a manually rendered VR eye. Left alone, the game's real light values render badly: daylight blows the fog into a white wall, and night stays oddly bright.

So the mod pins exposure to a fixed value instead, with separate day and night settings and a smooth transition between them. The upshot:

Day and night are deliberately different, not inconsistent. They are two tuned values, not one compromise.
Some areas will look flatter than others. A scene lit for auto-exposure has places that were meant to be adapted into. Under a fixed exposure, an area authored much brighter or darker than average reads washed out or murky. Caves, deep shade and heavily fogged areas are where you will notice it.
Daytime fog is handled separately, because a brighter exposure makes fog read as thicker. Without that, sunny weather turned into a wall.

No volumetric fog, for the 7 FPS reason above. Fog is still there, just the cheap kind. Areas built around thick volumetric atmosphere will look clearer and plainer than intended — you are seeing the geometry without the haze it was designed with.

Torches are boosted. A torch lit to read as bright against an adapting image reads as weak against a fixed one, so its light is scaled up, day and night. Only torches — no other light in the game is touched.

Shadows are pinned to a fixed resolution. HDRP normally sizes each shadow map by how large the light looks on screen, and since your two eyes stand about 65 mm apart they can pick different sizes for the same light — which makes shadows look sharper in one eye than the other. Pinning removes that decision. The game's own shadow flicker is vanilla behaviour and is not something this mod causes or removes.

Each eye renders with a slightly wider view than it shows you, then crops back. You never see the extra margin. It exists because lights near the edge of view were being dropped from one eye's lighting calculations, and widening the rendered view is the only thing that keeps them in.

Why it may look softer than you expect

If the image looks less sharp than the same game on a monitor, this is why — and it is a deliberate default, not something broken.

The mod renders at 85% by default

EyeResolutionScale ships at 0.85. Your headset asks for a specific per-eye resolution; the mod renders at 85% of it and lets the compositor scale up. On a Quest 3 that is roughly 2013×2196 instead of 2368×2584 per eye.

The reason is cost. Rendering is not linear — 85% in each direction is about 72% of the pixels, so it saves nearly a third of the GPU work. And this mod renders the scene twice per frame, once per eye, so every pixel is paid for twice. A game that never expected to run in VR is already asking a lot of your GPU; that 28% is often the difference between comfortable and not.

If you have headroom, turn it up. Set EyeResolutionScale = 1.0 in the config for exactly what your headset asks for. It is a noticeable step up in clarity, especially on text and distant detail. There is no downside beyond frames.

It is not in the VR panel because changing it means tearing down and rebuilding both eye render textures mid-session, which is a good way to get a black screen. Config only, applies on launch.

Why VR is harsher on resolution than a monitor

Two things make the same number of pixels look worse in a headset:

The image fills your vision. A monitor sits in a small part of your view; a headset covers all of it, so the same pixel count is spread across a far wider angle.
Lenses magnify it. You are looking at a small panel through magnifying optics, which enlarges the pixels along with everything else.

A resolution that looks fine on a 1080p monitor can look soft in a headset for exactly these reasons, before any mod is involved.

Other things that soften the picture

Shadow maps are pinned to 1024 per eye so both eyes get the same one and the atlas can hold both. Larger looks sharper but makes one eye blobby — see the shadow distance setting for the trade.
No anti-aliasing. The eye textures have no MSAA, and post-process AA costs frames we would rather spend on resolution. High-contrast edges will shimmer a little.
Volumetric fog is off entirely. Areas built around thick atmosphere read clearer and plainer than intended — that is covered in the lighting section above.

If sharpness matters more to you than frames, the order to try is: EyeResolutionScale to 1.0, then turn volumetric clouds off to pay for it, then drop to One camera if you need more.

Configuration

BepInEx/config/com.jaxon.magearenavr.cfg, generated on first launch. Every setting is documented in the file itself, with an explanation of what it does and what it trades away.

The ones most worth knowing:

Setting	Default	What it does
`ForcedMode`	`Ask`	`Ask`, `VR` or `Flat` — skip the startup dialog
`EyeResolutionScale`	`0.85`	Render resolution per eye. Set to 1.0 for full sharpness if you have the frames — see above
`SnapAngle` / `SmoothTurnSpeed`	`45` / `120`	Also settable in the VR panel
`PlayerHeightOffset`	`1.2`	Raise or lower your viewpoint
`InteractRange`	`6`	How far you can interact
`InteractOutlineColor`	`cyan`	Name or hex code
`TorchLightMultiplier`	`2`	Torch brightness
`ExposureValueDay` / `ExposureValueNight`	`16` / `17`	Lower is brighter
`WristHUDScale`	`2`	Size of the wrist health display

After updating, delete your config. BepInEx never overwrites an existing config file, so values saved by an older version silently override the new defaults — which has caused more confusion than any actual bug. Delete com.jaxon.magearenavr.cfg and relaunch; a fresh one is written immediately.

Reporting a problem

BepInEx/LogOutput.log is still the most useful thing you can attach to a report.

The release build is deliberately quiet. It logs the version it started at, which mode you chose, where it found and loaded the OpenVR runtime, and then nothing further unless something actually goes wrong — at which point it says so with a warning naming the system and the reason. A healthy session is a handful of lines.

That means if you hit a problem, the log tends to contain the answer rather than being buried in it. Attach the whole file; it is small.

Known limitations

Honest list. These are trade-offs and unfinished areas, not things pretending to be fine.

No volumetric fog. Costs ~7 FPS per eye. Affected effects use stand-ins.
Controller models are not rendered. You see your in-game hands, not your controllers.
Water renders slightly differently between the eyes. Its shader samples a buffer that belongs to the camera, and refraction cannot be made per-eye from a mod without removing the distortion entirely — which looked worse.
Some menu text can clip at the edges at certain angles.
The FP- and VR name prefixes need a modded host. The lobby rank tags do not.
Areas built around heavy atmosphere look plainer than on flatscreen. See the lighting section.
This is a beta. It is stable and playable, not finished.

Roadmap

What is planned next, roughly in order.

HUD customisability

The wrist HUD is currently health and stamina at a fixed spot on your left wrist. The goal is to let you choose what appears, where it sits, and whether it rides your wrist, floats in the world, or hides until you look for it. Different people want very different amounts of information in their eyeline.

Physical hand interactions

Right now you interact by looking and pressing a button. The aim is to interact by reaching — touch a door to open it, push it with your hand, grab things because your hand is on them rather than because a ray is pointed at them. This is the single biggest step toward the game feeling native to VR instead of adapted for it.

Physical item use

Following from that: items that respond to how you actually move them. Swing rather than press. Hold a torch out to light a corner. Aim by pointing your hand instead of your head. Some of this depends on how the game validates actions on the server, so it will arrive piece by piece rather than all at once.

Flag painting

Painting your team's flag is one of the few things in this game you do with your hands rather than your voice, which makes it the most obviously VR-shaped feature it has — and right now it is driven by a mouse cursor mapped onto a flat canvas, which in a headset means aiming a laser at a painting.

The goal is to paint by moving your hand across the flag: bring a brush to the cloth, drag it, and have the stroke follow your hand rather than a pointer. Depth matters here too — pressing in for a heavier mark, pulling back to lift off.

It sits ahead of the other hand work in one sense and behind it in another: the interaction is simpler than picking up and using arbitrary items, but it needs the painting surface mapped into world space and strokes fed to the game in a form its own networking already understands, so other players see what you painted. That last part is what decides how it gets built.

More item optimisation

Item placement in your hands is good but not perfect — offsets are shared across items that would be better tuned individually, and a few objects sit slightly off. This is per-item polish work, and it is exactly the kind of thing that benefits from people reporting the specific item that looks wrong.

Troubleshooting

The game launches but nothing appears in the headset. SteamVR must already be running before you launch the game — the mod renders through OpenVR, and the OpenVR compositor is SteamVR. If it was running, check BepInEx/LogOutput.log for a line from MageArenaVR.Preload — it reports where it found and loaded the OpenVR runtime, or why it could not.

Everything is black. Set CheapFrameSettings = false in the config.

Wrong mode at launch. Set ForcedMode to VR or Flat, or leave it on Ask for the dialog.

A menu will not respond to the laser. Set LaserInputMode = Legacy and report it with your log.

Arms are too short, or the body sits wrong. Press F8 and stand naturally with your arms out.

Settings changes do nothing. Your config is probably stale after an update. Delete BepInEx/config/com.jaxon.magearenavr.cfg and relaunch.

Frame rate is poor. Switch Cameras in match to One first — that is the biggest single lever. Then turn volumetric clouds off. Then lower EyeResolutionScale below 0.85 if you still need more.

Licence

MA VR redistributes openvr_api.dll, © Valve Corporation, and includes Valve's auto-generated C# bindings in its source. Both are covered by the BSD 3-Clause licence, included with this package as LICENSE.txt.

MA VR is not affiliated with, endorsed by, or supported by Valve Corporation. References to SteamVR and OpenVR describe what the mod needs in order to run, nothing more.

BepInEx and HarmonyX are required to run the mod but are not redistributed here — your mod manager installs them.

Credits

Made by J_axon.

Built on groundwork from my earlier VR mod, MuckVR — the approach of driving OpenVR from a plain BepInEx plugin, without Unity's XR stack, carries over directly.

Thanks to everyone who tested and reported.

Testers:

Wakeyiscool
MinusNeptune94
MagicHead333
Abyxus
supersaiyanslyr

Disclaimer

AI was used during the development of this project, mainly for revisions, inquiries, and things I just did not know. This does not mean the mod was fully AI-made, but rather that AI was used as part of the development process. I wanted to disclose this for people who may have a problem with AI being involved and may not want anything to do with it. Even though I disagree with your view on AI, I still respect your opinion on the subject.

Details

Categories