Nexus integration v1

[OlivierFortier]

Add initial Nexus addon loader & manager support

This pull request introduces Nexus addon loader integration to the project, updates documentation. The main changes are the addition of Nexus support via a nexus_addon module, new GitHub workflow files for CI/CD to enable automatic updates of the nexus version of the addon, and updates to the documentation to guide users through both traditional and Nexus-based installation and troubleshooting.

Nexus Integration and Build System Updates

• Added Nexus integration as an optional feature, including new dependencies (nexus, rfd) and feature flags in Cargo.toml. The library name and version were updated, and authors/repository metadata were added. This is needed for documenting nexus addons in the library of addons.
• Updated .cargo/config.toml to use the x86_64-pc-windows-msvc target. For some reason, the gnu target works on windows, but the addon is not detected by Nexus. Using the msvc target fixes this.

CI/CD and automatic update management for Nexus version of the addon
These actions only run when manually triggered. These changes are necessary for enabling automatic updates of the nexus version of the addon.

• Added .github/workflows/build.yml for building the Nexus-enabled DLL and uploading it as an artifact.
• Added .github/workflows/check.yml for CI checks: build, test, clippy linting, and rustfmt formatting.

Documentation and User Guide Enhancements

• Expanded README.md with detailed instructions for compiling, Nexus integration, and comparison between Nexus and traditional methods.
• Updated Simple-User-Guide.md to describe both regular and Nexus installation methods, including step-by-step guides and feature comparison tables.
• Improved Troubleshooting-Guide.md with Nexus-specific troubleshooting steps, clarifying the components involved in each method and providing targeted advice for common issues.

[SorryQuick]

Couple things.

1. I don't like the idea of having a separate release for the nexus version. It should probably be with the main version, the zip could include a "-nexus dll", and it can also be provided separately as part of the same release if this is needed for the update part.

2. How does this autoupdate take care of the blish exe? Because the forked blish exe (and sometimes folder) needs to be updated at the same time as the dll, otherwise things will break.

3. Couple of places you mention the traditonal method uses "manual dll injection", while it isn't any different from the way nexus loads their DLLs. The user themselves does not inject it, it gets done fot them, I feel it's a bit misleading to say Nexus is somehow superior despite effectively doing the same thing. Perhaps reword it to mention it allows re/unloading instead.

4. Weird formatting in lib.rs

5. #[cfg(feature = "nexus")] everywhere in init.rs, just put it on the module only

6. This also would require detatch() to be properly done if reloading is to be a feature, there will likely be memory leaks as of right now.

7. That's a lot of code for a very specific use-case. I'd rather you make that a sub-crate than a module. You would also keep everything nexus-related in that crate, including the documentation, which you could link to from the user and troubleshooting guide.

I personally don't have any intention to maintain a nexus integration, so you'd have to be the one maintaining it.

[OlivierFortier]

First of all, thank you for taking the time to look at this in detail and to comment on specific and actionnable things to improve.

I will try to answer each question to the best of my knowledge and abilities, if something remains unclear just ask again.

Couple things.

1. I don't like the idea of having a separate release for the nexus version. It should probably be with the main version, the zip could include a "-nexus dll", and it can also be provided separately as part of the same release if this is needed for the update part.

That's a good idea, I thought about it at first but then I didn't want to intrude too much. There is also a part of this that has to do with your second question.

I also tried to make it dynamic to have only a single DLL that can loaded both ways instead of doing conditionnal compilation, but couldn't make it work due to my lack of experience and knowledge.

2. How does this autoupdate take care of the blish exe? Because the forked blish exe (and sometimes folder) needs to be updated at the same time as the dll, otherwise things will break.

The autoupdate only takes care of the DLL as far as I know. I would have to check if it even works when a zip file or multiple files are involved. This was one of the reasons why I made the action to release the nexus build separately, but you're right concerning the Blish executable, I hadn't thought of that. I will need to check it out. This is/will be probably the biggest issue of this nexus integration. Although nexus also allows update providers other than the github one, the worst that could happen is that automatic updates will be disabled.

3. Couple of places you mention the traditonal method uses "manual dll injection", while it isn't any different from the way nexus loads their DLLs. The user themselves does not inject it, it gets done fot them, I feel it's a bit misleading to say Nexus is somehow superior despite effectively doing the same thing. Perhaps reword it to mention it allows re/unloading instead.

Completely fair, I'll remove and reword, my intention was not to make nexus seem superior.

4. Weird formatting in lib.rs

Sorry about that, totally forgot to run fmt.

5. #[cfg(feature = "nexus")] everywhere in init.rs, just put it on the module only

Will do ! I probably made a lot more mistakes than this since this is like the 3rd time I dable in Rust.

6. This also would require detatch() to be properly done if reloading is to be a feature, there will likely be memory leaks as of right now.

Yeah I know. The hot-loading part works, but unloading to reload it doesn't because of this. I don't really have any experience in such "low" level game and graphics programming, will have to do some learning and research.

7. That's a lot of code for a very specific use-case. I'd rather you make that a sub-crate than a module. You would also keep everything nexus-related in that crate, including the documentation, which you could link to from the user and troubleshooting guide.

1. When you say sub-crate , do you mean in your repo using cargo workspaces ? Or do you mean a completely separate repo ?
2. My end goal was to make this addon easily discoverable and downloadable from the nexus library of community addons (like blish hud modules). It get it feels like a very specific use-case but I felt justified in doing this to bring more light to this great addon.

I personally don't have any intention to maintain a nexus integration, so you'd have to be the one maintaining it.

I have no problem with this. I can maintain it. Barring any major rewrite from scratch, I basically just call your attach and detach functions as they are. Most of the code is for the ui and shouldnt change at all.

Or if you prefer I can keep this nexus version completely separate in its own repo as a fork in order to not interfere at all.

[SorryQuick]

I'll take care of detatch().

I also tried to make it dynamic to have only a single DLL that can loaded both ways

I don't think it's needed, it just makes the DLL bigger for users that don't need the nexus integration. We can just have a script that compiles 2 versions instead, the user can use whichever they prefer.

When you say sub-crate , do you mean in your repo using cargo workspaces ? Or do you mean a completely separate repo ?

Basically a cargo workspace in the same project. Keeps things tidier, with all nexus related things in the same subcrate/workspace.

My end goal was to make this addon easily discoverable and downloadable from the nexus library of community addons (like blish hud modules). It get it feels like a very specific use-case but I felt justified in doing this to bring more light to this great addon.

That's fine, but I'm also trying to keep this repo somewhat generic, since almost all of this code is not gw2-specific and could work with any other overlay from any other game, assuming one wrote the other side (aka the one file in the blish fork). Eventually I plan to remove the gw2-specific parts and provide those as, for example, a config file. So for that reason, I think it would make sense to have the nexus integration be a subcrate with its own cargo.toml, compiled with its own feature (like you're already doing).

[herrfleischladen]

If I may hijack this pull request to make a suggestion, why not do it the other way around? Create a Nexus addon that integrates SorryQuick's package as a dependency. That way the amendments to the overlay code would be minimal and all the maintenance for the Nexus stuff could be outsourced.
I allowed myself to make a proof of concept here, with the upstream fork with the amendments here.
Here is a build that shows the core functionality, rendering Blish HUD, is there, which is what most users are looking for I guess. All the polishing could be done in due time.

[SorryQuick]

I have no issue with that, honestly it could be made into a rust library upstream as well without relying on the the cargo feature.
Same question as above, how do you plan on dealing with the blish fork? To be fair now that I think about it I could do the blish releases on github separately and have the dll check for updates to the latest. #40

[herrfleischladen]

For the time being I would just point users to the newest build of your Blish HUD fork. For now, the overlay_nexus.dll is imho just a way to use your overlay.dll with Nexus, nothing more, nothing less.

[SorryQuick]

The thing is it's pretty important that the blish fork and dll match. If Nexus updates the dll but the user did not update their blish, it will cause issues. If/when I make the dll take care of that it won't be an issue, but until then, that's something to think about.

[herrfleischladen]

The Nexus dll just uses your code and wraps it so to say, so there are no updates as long as there are no upstream updates. This update dilemma is not limited to a Nexus package, whatever it may look like, but is rooted in the fact that a forked Blish HUD build is needed for now. And this is the same for upstream or Nexus "wrapper". If someone would use a newer version of the upstream dll without using a updated Blish HUD fork, that user would run into the same issue without Nexus being in the equation.

[SorryQuick]

My mistake, I never used nexus much so I assumed adding it to nexus meant adding it to their list of addons. In that case, is there anything missing in upstream besides what's in your POC?

[herrfleischladen]

I don't think so. Everything else would be done in the "wrapper repository".