Leaderboard

Yes, testing is completed for the current build so mods completed as part of these requests won't be tested for implementation until the next build iteration, which will probably begin testing work sometime around November of this year. So 10 months roughly before I am going to be pulling new testing material.

I am incredibly enthusiastic about this project--it's something I know I have been hoping for for quite some time, as others have said, and I'm thrilled that you're personally looking over every output for quality checking. It's more than I'd ever hoped to see, and I'm eagerly awaiting it. With that said, however, I do want to sound a potential word of caution since this is intended to be a 4x package. I have a great deal of experience troubleshooting setups with an overabundance of texture data, whether that be from upscale mods or just a ton of handmade textures, and I can say definitively that the larger the file load, the quicker both games' native memory leaks are exacerbated, leading to save corruption if the game isn't restarted frequently. Indeed, for some of the existing 4x textures on the Nexus, the problem is so bad that they can cause save corruption just by a user trying to save the game in a particularly heavily-affected module, even if the game was only just restarted. In the worst-case, modules with too much texture data can be impossible to load in; I'm not sure of the precise reason behind this, but I suspect there's some sort of backend texture throughput budget which, if breached, causes the save load to fail. Now, most of the problems that lead to these behaviors are rooted in using only .tga textures, and lighter-weight .tpc textures can greatly reduce the strain--but still, there are limits to how much reduction can be expected, and any amount of texture load per-module which is in excess of 50mb, I would say, is likely to at least slightly reduce the amount of time it takes to begin experiencing memory overflow. With that in mind, it might not be a bad idea to make different texture sizes, if at all feasible: 4x for users who are willing to restart their game a little more frequently or who have access to large address aware packages that can allow the executable to use more RAM (and thus ameliorate the memory overflow), and a 2x package for other users (such as those who have the game on Steam, where the encrypted executable leads 4GB patches to fail on the original game's .exe). I think having options for both would be very helpful, as long as it wouldn't require you to redo every texture from scratch.

I was hoping to get some feedback on a model tweak I am working on and figured I may as well start a WIP thread. (At the very least I am a work-in-progress as a modder😁) First up (and so far only) my take on the female mandalorian. Let me just preface this by saying I have no idea what I am doing. This is the first time I am trying anything like this. In my first attempt I narrowed the shoulders of the model which caused weapons to float alongside the hands, and really mangled the offhand when trying to hold a melee weapon. Since I have no idea how to fix this I ended up just keeping the shoulders the same width and tried to create the illusion of narrower shoulders. Any tips, suggestions or critiques would be appreciated. Thanks.

As shocking as it is for me to believe this myself, I just put up by my count north of 115 mod requests. Blame Obsidian for making a flawed masterpiece--emphasis on the flawed.

Upload the TPCs in the enduser mod (one for K1, one for TSL). Create a separate modder's resource with the source assets. Optionally you could have a single modder's resource or split it per game, since the site has per-game modder's resource sections. Its use will likely be pretty minimal, since most downloads will just be the actual mods, so just go with what you think is best. Have a look at how JC split his cloaked robes mods for how it could work.