[MOD] l3lessed Enchanted Compass

[l3lessed]

Thanks for the explanation on textures. I'll compile them into the mod, and I will just provide documentation on how to name and structure the files in streaming assets for overriding the mods.

Material and Shader issue isn't really an issue. I found that out a long time ago, and I have been using prefabs with the material assigned to it and compile that into the mod. I forgot I had already encountered and fixed that issue long ago.

So, for now, I've removed all the offending code causing the key mismatch error. I'll deal with it after I just drop a stable, optimized version. Still befuddled by why I'm getting a key mismatch all of a sudden, but I can at least get out a working version with only dot markers for npcs.

However, this has led me to another weird bug. It doesn't break the mod, but it does cause a odd texture rendering bug.

When I'm in an exterior location, my standard unity unlit/particle shader works fine with transparent textures. The texture shows, and the alpha layer is render transparent as it should. However, when I walk into an interior, I get this odd issue.



I know some lighting changes were made for improving the look and feel of the game, and I'm wondering if this could be causing this issue. I've tried changing the render type to all the differing types (Cut out/transparent/Opaque), but it still persists and only in interiors.

One other odd note, it appears fine in the editor scene, but not in the game render itself.

[l3lessed]

Fixed it. Flipping it to a soft edge unlit legacy shader took care of this issue; probably better anyways, as the shader itself isn't as demanding as the particle shader. Still curious what in the particle shader is causing the alpha issue.

[BadLuckBurt]

Nice! I have been out of the loop a little after my family got hit with a nasty flu, we went down one after the other so I never got back to this.

But I think this means you got everything sorted now?

[l3lessed]

Close, but I'm still having a shader lighting issue. I fixed the alpha layer showing by changing the shader itself.

However, I'm still having a lighting issue. The shader isn't picking up interior lighting, and so it is showing up black. I know the color is working, as I can change the colors alpha value and make the texture completely clear. But, because the shader isn't processing the lighting properly, it shows up black no matter the actual color I am picking.

I'll mess with the shader some more today and maybe try a built in DFU shader and see if I can make it work for my purpose.

Any ideas though what would be causing the lighting issue with my current shader? I'm using the unlit soft edge legacy shader that comes with Unity.

[l3lessed]

I've debugged a few smaller things: removed some left over game objects and assets from the icon generation process. However, still having issues with the new shaders in interiors

I know everything is working as should on the texture/color side. Texture shows up, debug log shows proper color RBGA values. So, it is clearly an issue of the texture being darkened by one of the new graphical shader changes, even though I am using unlit shaders. It also only happens when running the stand alone it seems, which seems odd too.

Could the new colorboost post processing shader be causing my marker textures to not properly render their lighting now? Is there anyway to get my npc marker material or minimap render camera to just ignore the new colorboost post process shader?

[l3lessed]

One more question about this:

Yeah, the texture replacement system checks for texture files in this order if I'm not mistaken: It first looks in StreamingAssets/Textures to see if there are any loose files. If there are it loads those. If there are no loose files, it starts to check the .dfmods that have been loaded in a reverse order (so mods that are loaded last get queried first - last mod to load wins). If no other mods offer replacement files, it will eventually query your mod as it moves up the list and just load the files from there.

So I would bundle them and load the textures using the proper import method provided in the mod system:

Code: Select all

Texture2D tex;
if (!TextureReplacement.TryImportTextureFromLooseFiles(Path.Combine("ModName", "Example"), mipMaps, encodeAsNormalMap, readOnly, out tex))
    tex = mod.GetAsset<Texture2D>("Example");

My question is, how does it check the streaming assets folder? Does it use a sub-folder name to find the mod it is tied to, then find the texture name within that subfolder? As an example, if a user put a texture replacement in for my mod, they would put within their streamingassets/Texture folder, "Minimap Mod/Texturename.png". Guess I'm asking, what is the proper folder setup to ensure it pulls correctly from the streamingassets/Texture when using the TextureReplacement call?

[Jarlyjarljarl]

I ran into a problem when running this mod where it messed with the way my game's mouse output. It made the mouse smoothing setting result in significantly less smoothing. Sometimes it'd revert to normal but when making the compass visible again it'd mess up again.

[l3lessed]

Odd, this shouldn't affect mouse smoothness in anyway. I have only one thing touch mouse input, and it isn't even messing with the setting. It is merely grabbing the mouse movement input and then using it to allow you to drag and drop the compass around on your screen. I'll look into this as I try to resolve this last shader bug before new drop.

[l3lessed]

Man, I can't figure this out. The quad applied texture is still not processing the shader properly, leading to a black texture. You can see it in this screenshot; the enemy circle is almost completely block when the shader material color is red and the base texture is applied to the quad.


One thing I noticed, I'm using my work computer, and it doesn't have any real GPU. As a result, the rendering camera for the minimap reverts to a vertix lit rendering path. Could the older, simpler camera rendering path be causing this issue? I'll check on my home computer.

[l3lessed]

Okay, I'm a scrub. I found the issue, and it was a bad loose texture file. The dot texture was colored black instead of white. Of course, color won't change on a black texture.

It slowed me down anyways and forced me to setup a proper logic ladder for marker generation and then mesh combining. Now the generation is tied directly to code execution through proper ienumerator and bool trigger use. This should fix any possible bugs arising from a frame skip or any other small cpu cycle glitch from throwing off the code execution and causing a null error.

I need to fix a few bugs that have to do with loading old saves and it not resetting/grabbing the new amulet data. This is causing null crashes when loading between saves and wearing an amulet in them. These are the last bugs to smooth out before a new drop.

I also still need to figure out that dang token mismatch error with grabbing npc billboard textures for the markers, but that will not stop a new drop.