XivAlexander: keeping weaving responsive across a long link to the game server

The problem: a weaving window that is wider than your latency budget

XivAlexander is described as latency mitigation and a bunch of modding tools mixed into one giant mishmash of a program, and the project's own summary is blunt about the mix. The repository description calls it double weave on high latency, and a mishmash of modding tools, especially for fonts and internationalization for Final Fantasy XIV.

The core feature is precise. This add-on will make double, or triple if your GCD is 2.50, weaving always possible. In Final Fantasy XIV, weaving is a crafting action whose window is measured in fractions of a second, and it has to be confirmed within that window or the craft fails. When the game client is several hundred milliseconds from the server, the window can close before the confirmation arrives, and the craft is lost through no fault of the player.

The illustration in the guide is a table of three connections with before and after images. Korea to NA DC over VPN only, Korea to NA DC with XivAlexander enabled, and Korea to Korean DC over a direct connection. The third row is the baseline, the uncorrupted case, and the second row is the case the tool is meant to match. So the goal is not to make the game faster overall, it is to make the client behave as though it were closer than it is, at least for this one interaction.

That framing matters for expectations. This is a targeted fix for a specific mechanic on a specific game, not a general network optimisation, and the tool is not going to make your latency go down. It is going to change how the client behaves relative to the clock.

The installation model: a loader DLL that masquerades as a system library

The quickstart is three steps, and step two is the interesting one.

Run XivAlexanderLoader64.exe and choose your game, or use Find game folder if it is not listed. Then choose how to use XivAlexander. The Use now option applies to a running game, or you can choose Start game and apply and log in through the official launcher, and without installation this lasts until you close the game. The Automatic loading option asks you to set it up once, after which you use your usual launcher, and to undo the installation you choose Turn off automatic loading.

So there are two modes and the distinction is about persistence. Use now is a temporary injection with no trace left in the game folder. Automatic loading writes something into the installation so that it is picked up every time, and the documentation is careful about the consequences: you need to restart a running game after installing, updating, or uninstalling.

Why would a tool need to write a file with a particular name into the game folder? The building section explains it. XivAlexanderLoader64.dll is what gets installed into the game folder as d3d11.dll, dxgi.dll or dinfo8.dll.

Those are the names of Windows graphics and input libraries. A DLL with one of those names, sitting in the application directory, is loaded by the game ahead of the system copy, and the game's own calls to Direct3D 11 or to raw input go to the proxy instead. That is the classic DLL search order technique, and it is why the loader needs to follow the launcher into the game rather than simply running alongside it. The loader is also described as running the loader window for XivAlexanderLoader64.exe and following launchers into the game, which is the part that makes it work with the official launcher rather than only with a direct executable.

If several games are running from the selected installation, you choose one in the running games list before applying, and the Advanced option shows technical details and alternative installation methods.

The build: static linking, vcpkg manifest mode and four output artefacts

The building section is short and specific, which is what you want from a project whose artefacts have to load into a live game process.

You clone with submodules, or run git submodule update --init --recursive after cloning, and there is a wrinkle worth knowing: FFXIV-FontChanger has a nested submodule. The font changer is one of the modding tools in the mishmash, and it brings its own dependencies with it.

Dependencies come through vcpkg in manifest mode through its MSBuild integration. The projects point vcpkg at the overlay triplets in a triplets directory, with x64-windows-static for 64-bit builds and x86-windows-static for 32-bit builds, and those triplets link everything statically with the v145 toolset, so no extra setup is needed for them.

That choice is the interesting one and it is not accidental. A DLL that gets injected into a running game cannot rely on the host process having particular shared libraries available, and it certainly cannot ask the user to install runtimes. Static linking of the whole dependency tree means the artefact that lands in the game folder carries everything it needs, which is exactly what a proxy DLL has to do.

The build output for the Release|x64 configuration is four things, and each has a distinct role. XivAlexander64.dll holds the features and is loaded only into the game. XivAlexanderLoader64.dll runs the loader window, follows launchers into the game, and is what gets installed into the game folder under one of the three proxy names. XivAlexanderLoader32.dll is loaded into 32-bit game launchers, which is a separate artefact because the 32-bit and 64-bit loader processes are different. And XivAlexanderLoader64.exe is the executable the user actually runs.

There is one more build step that is easy to miss: make Certificate.pfx and CertificatePassword.txt in the Build directory. The project needs a signing certificate, and the password is written to a file next to it.

The modding side: fonts, internationalisation and the FontChanger submodule

The font and internationalisation tooling is not an afterthought, it is a named part of the project and it has its own directory in the repository tree.

The repository top level shows the shape: FFXIV-FontChanger is a directory in its own right, alongside StaticData/, the XivAlexander/ and XivAlexanderLoader/ and XivAlexanderLoaderDll/ source directories, the Graphics/ folder holding the before and after images used in the guide, a scratch/ directory, the triplets/ overlay for vcpkg, and a CertificateGenerate.bat at the root for producing the signing certificate.

The FontChanger is described in the building section only in terms of its nested submodule, which tells you the build detail but not the feature. What the repository description does say is that the mishmash includes modding tools especially for fonts and internationalization for Final Fantasy XIV. So the same project that solves the weaving latency problem also lets you replace the game's typeface and adjust its localisation, and both of those are things that have to be done by hooking into the game the same way the latency fix does.

That shared mechanism is the reason the two halves live in one program rather than two. Both font replacement and the weaving fix need to be present inside the game process, and both need to intercept the game's own calls. Building them as separate proxy DLLs would mean two files competing for the same installation slot, with only one of them able to be d3d11.dll at a time.

StaticData/ is the third piece of that group, and the name suggests the data the tools operate on rather than configuration for the build. A repository with a scratch/ directory as well is a sign of someone who works on the problem rather than only releases artefacts.

Releases, licences and what to check before you install

The release history has an unusual shape. The most recent tag is v1.14.10.0-TESTING, published on 2026-10-14, and the version number carries a TESTING marker inside the release title. Before that came v1.14.9.3 from 2026-03-26 and v1.14.9.2 from 2026-02-05.

So the newest build is explicitly labelled as a test build, and the last stable-looking one is from seven months earlier, while the last push to the repository was on 2026-10-19. The project is clearly still being worked on, and the maintainer is being explicit about which artefacts are for testing. If you are deciding what to run, the tag suffix is the thing to read, not the version number.

The version numbering itself appears to track the game. The game version is 1.14, and the artefacts run 1.14.9.2, 1.14.9.3, 1.14.10.0, so a build targets a specific game version. That is the obvious design for a tool that hooks into a game's internals, and it is also the main reason the downloads are not interchangeable across patches.

The download instructions have one warning that is worth repeating. Use the Releases section on the sidebar, and do not download using the green Code button. That is advice aimed at people who expect a source repository to have a build attached, and for a project that needs a signed DLL and a specific triplet configuration, building from source is a different path entirely from installing.

The licence is Apache License 2.0, which is permissive and lets you redistribute modified versions with attribution and a notice of changes. For a tool that injects into a commercial game, that licence also says nothing about the game's own terms of service, and that is a decision to make for yourself rather than something the licence settles.

Editorial conclusion

Adopt XivAlexander if you play Final Fantasy XIV across a long distance to a game data centre and the weaving mechanic suffers for it, since that is the specific problem it exists to solve. Do not adopt it if your latency is already fine, because it works by injecting into the game process and the cost of that is not zero. Before you install it, read the wiki page on installing and loading once, and note that automatic loading writes files into the game folder, so you need to know how to undo that with the turn off automatic loading option and when a running game needs a restart.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. Soreepeong/XivAlexander on GitHub