Injector crash and other unrelated modding topics

[Frosferes2]

ExePath targets Gw2-64.exe with d3d9.dll 64 bit in the same directory. Launcher will log in but then crash when attempting to launch the game. The crash sometimes produces an "Install cannot be completed" error message but other times will crash with no message. I wasn't able to determine what causes the different outcomes. The ModelMod log doesn't report anything beyond the initialization message. ModelMod.Gw2-64.log Removing d3d9.dll from the game directory allows it to launch as normal again.

I tried using the 32bit dll as well but MM would not initialize at all when trying this.

[jmquigs]

d3d9.dll needs to be in the "bin64" subdirectory, not the directory containing gw2-64.exe

[Frosferes2]

MM doesn't initialize for me when d3d9.dll is in bin64. Is there an argument I'm missing?

[Frosferes2]

d3d9.dll needs to be in the "bin64" subdirectory, not the directory containing gw2-64.exe

MM is initializing properly now and it works great! I do have some questions regarding it's feature set however and I wonder if there's a more appropriate place to ask about them than here?

I would also like to thank you for this mod, it's opened up avenues I didn't think possible just a week ago. Keep up the good work!

[jmquigs]

You can go ahead and ask here. I'm not paying attention to any other possible question forum 😄 I used to have some explanatory videos but I deleted them. That was a mistake I guess. There is some other info in the wiki here but that is a bit out of date.

[Frosferes2]

You can go ahead and ask here. I'm not paying attention to any other possible question forum 😄

I've been thinking about doing a remesh/retexture of some of the races in GW2, in a similar vein to the sort of stuff on offer for FF14 on Nexus Mods, since a lot of the character models in GW2 can look very dated by today's standards. I was wondering if such a thing could be achieved using MM, but I'm not sure if it's feasible given the injection method that MM uses doesn't seem to give lower level access to the mesh and overlay texture files used to construct player proportions and skin patterns. Am I correct about this?

On that note, MM has not been able to snapshot any normal or scatter maps from GW2. I'm wondering if this is simply because the game doesn't use them, or if I'm not snapshotting them correctly.

I've figured out how to make the mod mesh use mod weight mode, which is my preferred method to rig a mesh given my experience in 3D design. However, for some reason, some of the polygons like to distort through the model like shown below. This is more common with modified geometry, but not all new verts are like this. Strangely, this only happens in-game and not on the character select screen, where the new model appears to work correctly. I have double checked that the geometry is all assigned to vertex groups, is triangulated, is normalised and is limited to 4 bones per vertex.

Also seen in the screenshot is the lack of lighting effects on the modified body compared to the head, which I'm led to believe is because the mmobj exporter does not export tangent/normal spaces. Is this correct? And if so, is it possible to fix somehow?

Thanks for taking the time to read this 😁

[jmquigs]

You can go ahead and ask here. I'm not paying attention to any other possible question forum 😄

I've been thinking about doing a remesh/retexture of some of the races in GW2, in a similar vein to the sort of stuff on offer for FF14 on Nexus Mods, since a lot of the character models in GW2 can look very dated by today's standards. I was wondering if such a thing could be achieved using MM, but I'm not sure if it's feasible given the injection method that MM uses doesn't seem to give lower level access to the mesh and overlay texture files used to construct player proportions and skin patterns. Am I correct about this?

Yes that is right. MM doesn't actual touch the game's memory at all, it just swaps stuff out just at render time. So the "prototype" for character skins, etc, isn't available/editable by MM. So really you what it is editing is just pieces of the character.
In theory you might be able to take, like, a naked character and create a bunch of custom models that use that as the base. But that would be a lot of work and of course for actual gameplay your dude wouldn't be wearing any armor so that would be an issue. Its possible to do something like this with some of the outfits which snapshot to (largely) a single mesh. However some outfits snapshot to a zillion tiny pieces (usually because of material changes) and so aren't easy to work with.

In theory a program could actually scan game memory and find/edit, say, the base character models the game uses, but that would require a lot of reverse engineering of the game's internal memory structures and probably the dev wouldn't be happy about it.

On that note, MM has not been able to snapshot any normal or scatter maps from GW2. I'm wondering if this is simply because the game doesn't use them, or if I'm not snapshotting them correctly.

It will snapshot any valid texture on the first 4 texture mapping units. My experience is that with GW2 it doesn't use any more than these. I don't think it uses normal maps. Rather, it may store some information in the alpha channel of the base texture. I believe I always snapshot those as DXTC1 which might be throwing away some of that the information in the dds files exported by a snapshot. However, a "mod" texture isn't normally used unless you explicitly specify it in the yaml file. So, if you just have a mod mesh it will use whatever textures the game loaded which should contain whatever alpha info it needs.

I've figured out how to make the mod mesh use mod weight mode, which is my preferred method to rig a mesh given my experience in 3D design. However, for some reason, some of the polygons like to distort through the model like shown below. This is more common with modified geometry, but not all new verts are like this. Strangely, this only happens in-game and not on the character select screen, where the new model appears to work correctly. I have double checked that the geometry is all assigned to vertex groups, is triangulated, is normalised and is limited to 4 bones per vertex.

That is a bit weird, especially if it works on the character screen. One thing that can happen is if you are accidentally intercepting a very common prim/vert count combo, like a square (2 prim, 4 verts), that can cause artifacts in game with other things that rendering use squares. But if this is an armor piece, those kinds of collisions tend to be pretty unusual. You could try moving the camera around or moving to another map to see if it is something in the scene that may be colliding. Unfortunately if it is, there isn't a way to prevent that right now. MM will warn about potentially problematic stuff it sees in a mesh on load and stick that in the log file, so its always worth checking that. However it doesn't warn about collisions because it doesn't know the context of a scene the mod will be rendered in.

Also seen in the screenshot is the lack of lighting effects on the modified body compared to the head, which I'm led to believe is because the mmobj exporter does not export tangent/normal spaces. Is this correct? And if so, is it possible to fix somehow?

Yeah there is an issue about this #10 . It's been there since the beginning, and is especially noticeable on High detail shaders. It's true that MMobj does not currently export those vector spaces, but in an experimental branch I actually had it recomputing those at load time and it didn't fix anything. So what it does now is "borrow" these vectors from the nearest ref mesh vert. But, something must be going wrong, because if you look at the mesh carefully what appears is that all the binormals/tangents almost seem to be pointing in the same direction. Its possible that I have the vector component order wrong, or I'm not reconstructing those vectors properly, or I didn't normalize them, or who knows. But it used to be WAY off and I did fix something to make it better - so it can't be totally wrong. Its been so long since I worked on this unfortunately.

In the meantime since I worked on it I learned that blender can compute those vectors for you. So I wonder if my experimental branch I just computed them wrong. They are somewhat tricky to compute and I don't know of a way to verify the results other than visual inspection. So followup work might involve trying to get the blender-computed vectors into the mmobj so that they can be loaded that way.

[Frosferes2]

Yes that is right. MM doesn't actual touch the game's memory at all, it just swaps stuff out just at render time. So the "prototype" for character skins, etc, isn't available/editable by MM.

I suspected as much. If it weren't for the fact that this is an MMO I wouldn't be averse to finding a way to unpack the game's .dat file and making some edits. But somehow I suspect that directly tampering with the game's data would be significantly more likely to result in a ban than simply swapping out assets at render time, like you say. According to Reddit, the reason FF14 players can get away with it is because Square Enix is Japanese, and Japan has a law explicitly forbidding companies from scanning the files on your computer. Perhaps I could try it on a dummy account anyway and see what happens?

In theory you might be able to take, like, a naked character and create a bunch of custom models that use that as the base. But that would be a lot of work and of course for actual gameplay your dude wouldn't be wearing any armor so that would be an issue. Its possible to do something like this with some of the outfits which snapshot to (largely) a single mesh. However some outfits snapshot to a zillion tiny pieces (usually because of material changes) and so aren't easy to work with.

I've considered making a naked base mesh and splitting it up into detachable parts for different armor pieces. I've got experience in modding Skyrim, so I know how that goes. However, unless there's a feature I'm not aware of, each mod can only affect one object in one specific snapshot. So not only do you have to make a separate body mod for each armor piece, but also every possible combination of different armor pieces that affect the snapshot, which is obviously infeasible. I have noticed that the snapshot for the body is not affected by changes to the head, helmet or weapons though.

However, a "mod" texture isn't normally used unless you explicitly specify it in the yaml file. So, if you just have a mod mesh it will use whatever textures the game loaded which should contain whatever alpha info it needs.

This specific mod is not using a mod texture, but I have used mod textures and i've not noticed any differences to the look of the character. The baked in 'normal' data you mention seems to be preserved. I think the strange lighting is probably more due to the lack of tangent spaces on the model than anything else.

Modifying textures for the purposes I want would probably be difficult too since I can only access the composite texture file and not the colour tint and pattern overlays that make it up.

That is a bit weird, especially if it works on the character screen. One thing that can happen is if you are accidentally intercepting a very common prim/vert count combo, like a square (2 prim, 4 verts), that can cause artifacts in game with other things that rendering use squares. But if this is an armor piece, those kinds of collisions tend to be pretty unusual. You could try moving the camera around or moving to another map to see if it is something in the scene that may be colliding. Unfortunately if it is, there isn't a way to prevent that right now. MM will warn about potentially problematic stuff it sees in a mesh on load and stick that in the log file, so its always worth checking that.

I don't think it's an interception since this effect doesn't happen when using reference model weights. I might end up having to use the reference instead, but that method isn't perfect and produces some anomalies. I did test in some different areas anyway and the result is the same. It's also unaffected by camera position. The strangest part is how it works correctly in character select. I'm not sure at this point if it's a fault on my end or with MM or its exporter. I can try a couple of things which might help if it's a mesh problem but I'm not convinced they will.

So followup work might involve trying to get the blender-computed vectors into the mmobj so that they can be loaded that way.

I hope you will continue work on this mod because it's honestly really cool 😀. I've been in modding for a while now so I'm used to bugs and things not working as intended. I wish I could offer help with the back end development but unfortunately my coding background is very limited. However, I might be learning some Python in Uni this year so I won't say never haha

[Frosferes2]

I've tried to use exclude vertex groups for weighing the model using a reference, but both the exclude group in the mod and the excluded group in the reference are not exporting. If I re-import the meshes I can see those groups are missing. Any clue why that might be? Also, are mod groups excluded proportionally based on their weighting to the vertex group, or is it just that any vertex that belongs to the group is entirely excluded?

[jmquigs]

I don't recall if mmobj will reimport the named exclude groups. It may not, since its not really expecting them to be there as part of a snapshot. If you want to send me a repro case (or attach it here) with the ref and mod mmobj files as well as the blend files you are using, I can take a look to see what is in there.

Exclusion will wholesale exclude those verts from being considered for the affected mod part. So then it will use the nearest non-excluded vert in the ref to find the animation weights. You can also use Include groups to include specific verts only from the ref. I forget what happens when you mix Inclusions and Exclusions but of course one of them must take priority. I usually don't do that because it gets too confusing.

Its important not to modify the ref in any way other than adding the groups. Specifically don't change the vertex or primitive count by adding/removing geometry. If you change the geometry in the ref, that will definitely mess stuff up.

[jmquigs]

Yes that is right. MM doesn't actual touch the game's memory at all, it just swaps stuff out just at render time. So the "prototype" for character skins, etc, isn't available/editable by MM.

I suspected as much. If it weren't for the fact that this is an MMO I wouldn't be averse to finding a way to unpack the game's .dat file and making some edits. But somehow I suspect that directly tampering with the game's data would be significantly more likely to result in a ban than simply swapping out assets at render time, like you say. According to Reddit, the reason FF14 players can get away with it is because Square Enix is Japanese, and Japan has a law explicitly forbidding companies from scanning the files on your computer. Perhaps I could try it on a dummy account anyway and see what happens?

I wouldn't recommend doing this. Developers justifiably get angsty when people start modifying game data in a persistent way. This is one reason why I went with a renderer-interception approach for MM even though I knew it would have limitations. That way there is no possibility of changing the game data even accidentally.

For example, if the dev allowed unauthed game file mods, someone could create a malicious "mod" that, when loaded into the game, causes a memory overflow and lets some remote actor mine bitcoin on the client's computer. Or ransomware it. Virtually all games are written in C/C++ and are thus wide open to this kind of memory exploit.

From a purely practical perspective its also a pain in the ass to modify on disk files. They are probably protected by various levels of checksums and maybe even HMACs (to guard against security issues like the above). There could also be third party DRM systems involved. Very unfun coding and possibly fruitless in the end.

This specific mod is not using a mod texture, but I have used mod textures and i've not noticed any differences to the look of the character. The baked in 'normal' data you mention seems to be preserved. I think the strange lighting is probably more due to the lack of tangent spaces on the model than anything else.

Yeah the tangent space is jacked. I just peeked at that code and it looks like I left it in a pretty rough state. I doubt the calculation there is even remotely close to accurate: https://github.com/jmquigs/ModelMod/blob/master/MMManaged/ModDBInterop.fs#L445 My experimental branch that tried to fix that is still around, it looks like I was loading them the mmobj themselves. I don't recall how I generated them, maybe I managed to get blender to do it: https://github.com/jmquigs/ModelMod/commits/fix-lighting-export

I hope you will continue work on this mod because it's honestly really cool 😀. I've been in modding for a while now so I'm used to bugs and things not working as intended. I wish I could offer help with the back end development but unfortunately my coding background is very limited. However, I might be learning some Python in Uni this year so I won't say never haha

I'm not working on it that much anymore but I do plan to add DX11 support if GW2 drops DX9. I should probably find a new maintainer but TBH until recently no one was very interested in it. I should probably updating the Contributing guide to make it easier to get into. Its actually a bit easier now that I junked all the old c++ code which was a real can of worms.

Python wouldn't be a bad thing to learn, I hate that language, but the mmobj importer/exporter are written in it, because they have to be. Those were originally based on blender's own obj scripts which I basically cut/pasted and hacked to make mmobj. But now blender totally changed their API for blender 2.8+ so MM is stuck on 2.79 until someone ports those scripts over to the new api. Which I don't want to do because...I hate python.

[Frosferes2]

For example, if the dev allowed unauthed game file mods, someone could create a malicious "mod" that, when loaded into the game, causes a memory overflow and lets some remote actor mine bitcoin on the client's computer. Or ransomware it. Virtually all games are written in C/C++ and are thus wide open to this kind of memory exploit.

Yeah you're right that it's likely not even worth trying to modify the game data. However, I might still look into how to rip it because that would provide the base assets I could use to build a resource repository for a sort of 'build your own' MM mod. Obviously, such a resource would not be as accessible or flexible as more traditional mods that directly modify game data, but that's a limitation that we have to accept given GW2 is a multiplayer game.

I also just think it would be fun to dig around in the game's assets and see how it all ticks.

My experimental branch that tried to fix that is still around, it looks like I was loading them the mmobj themselves. I don't recall how I generated them, maybe I managed to get blender to do it:

Does the branch not work as intended? I use an addon for importing and exporting NIF files for Bethesda games and I'm fairly sure that one exports tangent spaces directly from Blender unless I'm mistaken: https://github.com/BadDogSkyrim/PyNifly

I'm not working on it that much anymore but I do plan to add DX11 support if GW2 drops DX9. I should probably find a new maintainer but TBH until recently no one was very interested in it. I should probably updating the Contributing guide to make it easier to get into.

I was surpriesd to see so little activity when it came to modding GW2. I guess the barrier to entry is pretty high, and I'm used to something like Elder Scrolls, where mods are the literal life-blood of the games. I do know at least a couple of people personally who might be interested in MM. And at least one of those people has more coding experience than myself. I'm trying to spread the word a bit.

If you want to send me a repro case (or attach it here) with the ref and mod mmobj files as well as the blend files you are using, I can take a look to see what is in there.

CharrBody.zip

Here's a quick remesh I did for the Charr body. I haven't spent much time on it so it's pretty janky. I just wanted to test how it would look in-game. Automatic weighing doesn't really work very well here so I want to be able to use mod weighting for the improved control it offers. As far as I can tell, the bone groups are set up correctly, but when I load it in game I get the same problem as before: It looks fine on character select but goes balistic in game. I can't think of why this might be happening except for maybe it's running up against some kind of invisible tri/vert limit in MM? Either that or verts added on top of the imported ones have some sort of hidden property that MM doesn't like. I'm honestly not sure. This body is about 11K tris which is pretty modest for modern video game characters, but it's still much higher than the vanilla 2.5K.

It's probably worth noting that I don't do mesh work in 2.7. I just use it for import/export and copy the objects between it and current Blender for editing. That Blend file is only the objects to be exported copied from my 2.9 workspace to a new Blender 2.7 scene. The triangulate modifier also needs to be applied before exporting.

[DaelinDwin]

I made a new mod utilising your mesh and it seems to work fine, with minor errors around the neck and armpit due to differing body sizing.

I exported the mesh with Apply Modifiers checked, as well as manually applying the modifier before exporting, with no difference between them. I also replaced the new Ref model with the one from your file, with no visible difference.

Perhaps your mod itself is setup wrong? That's the only thing I can think may be causing the errors, as the mesh itself appears fine.

[Frosferes2]

I made a new mod utilising your mesh and it seems to work fine, with minor errors around the neck and armpit due to differing body sizing.

Were you using reference or mod weighing? By default the reference is used for weighing which produces some funky results on the new body, so I wanted to use mod weight mode to set the weights manually. The mesh explosion only happens when using this mode.

[DaelinDwin]

I used Reference weighting. In the Blender file, assuming the "Thighs" vertex group is for the mod weighting, the modded model doesn't have an "Include.Thighs" group referencing it. I would guess the issue is both thighs being in the same weight group. Separate them to ThighL and ThighR and see if that fixes it.

Unless you are handling mod weighting via modifying the Ref's "index" weight groups, which I don't think is how weight modding is intended to be handled.

[Frosferes2]

I used Reference weighting. In the Blender file, assuming the "Thighs" vertex group is for the mod weighting

It isn't. That's just a leftover from when I was trying to use exclusion groups. I stopped using it when i found out that vertex exclusion is binary and is not affected by group weights, and so is not very useful for precise weighing.

Unless you are handling mod weighting via modifying the Ref's "index" weight groups, which I don't think is how weight modding is intended to be handled.

The index groups represent the detected bone influence regions used for vertex deformation. I assume the indicies are numbered based on order of detection. When using reference weighting the index groups in the mod object are discarded and then projected from the reference group. Using mod weight mode, the index groups in the mod object are used for weighing, which is why you have to be careful that the regions of influence are numbered the same in the mod and reference when using that mode, or it may result in mismatched bones when the model is injected back into the game. I'm fairly sure my index groups are set up correctly, since the mod weighted mesh appears correctly on the character selection screen. But for some reason in-game a high number of verticies stretch off along some axis above and below the characer model. This behaviour doesn't seem like bad weighing to me, but I can't think of why it is happening beyond some glitch with MM.

[drakumus]

d3d9.dll needs to be in the "bin64" subdirectory, not the directory containing gw2-64.exe

MM is initializing properly now and it works great! I do have some questions regarding it's feature set however and I wonder if there's a more appropriate place to ask about them than here?

I would also like to thank you for this mod, it's opened up avenues I didn't think possible just a week ago. Keep up the good work!

What steps did you take to get MM to initialize properly? I'm running into the same issue where the logs appear to show injection working but no ingame UI appears.

[Frosferes2]

What steps did you take to get MM to initialize properly? I'm running into the same issue where the logs appear to show injection working but no ingame UI appears.

Putting d3d9.dll into the bin64 folder in the Guild Wars 2 directory did end up working for me, I think I might have just missed the UI the first time around as it's not always obvious it's doing anything until you cycle through a few highlighted objects. Also make sure that the dx11 rendering beta is disabled in your graphics settings or the plugin won't work at all.

[arsipsik]

Hey! Can you guys give a brief explanation on how to use mod weighting? The user guide is sparse in how to set this up and I can't seem to figure what I need to do to enable mod weighting.

Everything else on my mods work but the new pieces on my modded mesh are a little wonky in game and it appears that's because it's using reference weighting.

[arsipsik]

Sorted it out! For those wondering, you need to add the following line in your mod.yaml file.

WeightMode: mod

Of course, as mentioned in the User guide, you have to properly line up weights and indexes. And to further expand on that, what i did for my mod was take the new mesh piece and renamed the indexes to line up approximately with the existing mesh.

For example, on the existing mesh the right shoulder was weighted on Index.25. I looked at the new mesh, found the Index where the right shoulder was weighted and renamed that index to Index.25. I did that for all the appropriate Indexes on the new mesh and then joined it to the existing mesh.

Its not perfect but its way better than what it was!