theblackman

Discussion topic: High Res Local Maps by VishVadeva50 - WallSoGB Wiki Link Increases the resolution of local maps in the PipBoy from 128 to 512 and optionally 1024.

Discussion topic: Just Disarm It by palateswap Wiki Link Removes the dialogue box for disarming traps, enabling the player to make them safe with just the press of one button.

Discussion topic: Slightly Less Annoying Cazador Poison Sound and Audio Fix by TheHermit Wiki Link A replacer for the Cazador poison sound effect that includes a bug fix making it less audible over distance. I tested this today and it does make the sound effect less of an assault on the ear drums.

Discussion topic: Ultimate Edition ESM Fixes by RoyBatty - team blackout Wiki Link Optimizes and cleans the FalloutNV.esm, as well as fixes some hard errors in the landscape. Decompresses NPC and Landscape records in the main game and major dlcs to reduce stutter. Boosts performance on modern systems with SSDs. Gun Runner's Arsenal and the preorder packs are untouched.

Yes, I'm inclined to agree. It is hard to argue that some of the weapons added by CFWR qualify as a 'perceived oversight', even though they might be lore-friendly.

Discussion topic: Elijah Voice Audio Files Fix by Chloe Wiki Link Attempt to fix Elijah's voice loudness and clipping issues in Dead Money.

Discussion topic: New Vegas Mesh Improvement Mod - NVMIM by RoyBatty and SciRika Wiki Link Optimizations and fixes for a large selection of meshes in the base game and DLC.

Perhaps I'm missing something but the mod author (Rrezz) posted the following comment on the mod posts tab (11 July 2022): "At this point in time, is probably better to use Classic Fallout Weapons Remastered. Use that with Fallout 3 Weapons Restoration and you've got yourself a very nice assortment of lore friendly weapons to add to your arsenal. " So you could remove PN from the guide entirely, assuming Classic Fallout Weapons Remastered is suitable for inclusion.

Apologies - I clearly didn't read the OP carefully enough and thought Tech was the guide curator. The process is very straightforward and the aspect of the process which appears to have been the subject of most of the 'complaints', being the edit required to the .ini file, is now performed by the tool itself. It's arguably less complicated than the process described in the guide for NVTF. If you have a look at the comments section of the FCO Bugfixes mod, for example, (which you already have in your guide), it is filled with comments by people experiencing various issues. If you look at any reasonably popular mod on the Nexus, you will always find users making comments where often they failed to follow clear instructions, or discovered that the issue was caused by a different mod. Or have a look at the Vortex support forums where you'll find users who can't get xNVSE/SSE etc to work via Vortex even though Vortex automatically installs it. Hopefully you can see my point.... The term 'casual modder', to me at least, would seem to be more applicable to someone who would be more likely to install a collection rather than a fairly extensive modlist like STEP F:NV. Regardless it's not a discussion for this thread. My impression is that users who come to STEP are likely to want to push themselves a bit to learn more about how to better mod their game. My responses to #1 apply here as well, with the caveat that it's arguably simpler than the BSA decompression tool/process. You can perform the actions yourself to see; the Viva New Vegas guide has clear instructions on how to use both tools: https://vivanewvegas.github.io/utilities.html Will do. And the 4GB patcher and Heap Replacer don't....? Still, I guess it depends how you define 'game mechanics'. From the utility's mod description page: Simple tool to decompress the FNV BSA's and repack them without zlib to increase performance on modern systems. Additionally it transcodes all sound fx in .ogg format to .wav so they function in the game. It also extracts any mp3 files to loose files because they will not play when in a BSA.

Some questions: 1. Why are you not using the BSA decompression tool on the BSAs ( I assume the OGG Vorbis library solves part of the problem here)? https://www.nexusmods.com/newvegas/mods/65854?tab=description 2. Ultimate Edition ESM fixes? https://www.nexusmods.com/newvegas/mods/77170 3. Mesh Improvement Mod? I note you have a lot of mesh replacers so perhaps they are your preferred options: https://www.nexusmods.com/newvegas/mods/74295 4. Elijah Voice Audio Files Fix: https://www.nexusmods.com/newvegas/mods/73526 I will throw these up on the wiki if you like.

Re: PN (per the guide): As of 2021 Project Nevada is very outdated and should not be used as a standalone mod. However, it adds some lore-friendly weapons and armor that can be used with the help of Project Nevada-Equipment Standalone. And the instructions included are: disable all plugins. Re: FCO, there is a fix which is included in the guide. I'm not sure if it fixes all of FCO's deficiencies but I'm sure Tech will enlighten us.

Brilliant idea. Looking forward to seeing this develop. Did you learn Python/JSON as part of developing this or did you already know those languages?

Why did you upload it to the Alchemy category? Looks good though! :)

I actually preferred the previous version of the message; it was clear and concise. As it is now, you have to click through two links to see the boilerplate and at first I wasn't sure if that was to be used in the wiki only or the forum post too.

I thought that might be the case, but then I wondered why you would want a DB full of rejected mods. But OK, makes sense, thanks.

When posting a mod suggestion for inclusion into STEP, the 'warning' text states to consider creating a modpage on the wiki for the mod, but no reason is given as to why it might be preferable to do this. Perhaps the reason(s) could be included - it would be more persuasive, at least. Thanks.

Actually I'm not sure the 'norm' was ever the quite the 'norm' we assumed it was. This is the thread (2017) that prompted me to investigate this issue more closely, specifically DoctorKaizeld's comment: "kinda a well-known thing that you don't clean master files". Note that they are specifically referring to LE, not SE, but that doesn't really matter in this context. GrantSP (2018) reaches a similar conclusion here after discussion with other mod authors although he admits "there may be some small benefit for Skyrim to do so". Then there's the anecdotal reports, some linked below: One Two Three The AFKMods discussion was bemusing to me when I first read it when I was researching this as I read Arthmoor's most recent comment to not clean the masters before I read that thread where he is passionately disagreeing with Mator and recommending they be cleaned. Anyway, as we now know that cleaning can cause issues and since we appear to not have any cases of issues caused by using uncleaned masters (assuming correct use of patches), I would say that's fairly conclusive.

IIRC it was in Arthmoor's Reddit post, which I now can't find, but it was the reason I emailed him. He also confirmed it via email to me but as it is personal correspondence I can't cite it. As to why if only using USSEP, no specific reasons were given, just Arthmoor recommending cleaning for 'patchophobes'.

Elminster's amusing summary from one of those GitHub links about Skyrim's DLC:

I can't find any documented instances of users experiencing problems from not cleaning them; perhaps I'm not looking in the right places. But Arthmoor in his Reddit post (which I now can't find but it was about a year old) specifically mentions bug reports to Github as a result of cleaning the masters, and he confirmed this via email. And there's other anecdotal content on various forums matching this. Mator is one of the contributors to xEdit and his view has always been fairly consistent - it's a waste of time, assuming one is using USSEP. There's definitely a clear pattern towards not cleaning them, again assuming USSEP is being used. If it isn't being used then cleaning is recommended. Given all this, perhaps the status quo needs to be taken with a 'grain of salt'. What references do you want, btw?

That's probably a good idea. I looked at the xEdit documentation. There's nothing in there about cleaning the masters other than a clarification point about manually cleaning Dawnguard.esm. There is a link to a 3-year old discussion on afkmods about pros/cons, mostly between Arthmoor (for) and Mator (against). Of course, Arthmoor now agrees with Mator. I've communicated with Arthmoor directly on this in the last few days. He said his view had changed in the last year or so.

Discussion topic: No Grass in Objects by meh321, DwemerEngineer, and alandtse Wiki Link UPDATED to support the latest SkyrimSE runtime (and SkyrimVR support forthcoming). Not only is this mod necessary for generating LO-specific grass LOD, but it's also beneficial to performance without grass LOD if properly configured. Prevents grass clipping through most objects. Mod performs a raycast in-game from each position where grass is located and if it detects a collision with another object then it doesn't place grass at that point. Needs .Net framework but that's already a requirement for MO2. OCD sufferers rejoice!

Don't worry, I wouldn't post something this consequential unless I had done my homework first. :) A while ago I saw a post on the Nexus by a technically-savvy modder telling a user to not clean the masters. I was quite surprised by this so I started reading around and saw more evidence of mod authors recommending to not clean the masters (including one on this forum) and anecdotes from other users about experiencing problems from cleaning the masters. Arthmoor is also on record (Reddit IIRC) as saying that he has documented cases of people experiencing issues as a result of cleaning the masters and that he doesn't do it anymore. I can't remember when I last saw a post on the Nexus recommending that the masters be cleaned and certainly not one objecting to a post where someone said to not clean the masters. Totally conclusive? No. But definitely persuasive; hence my post.

Since the 'accepted wisdom' of cleaning the Skyrim SE DLC .esms + Update.esm has moved back to not cleaning them, should the guide be updated to reflect this? I had a look for any previous discussion about this but I couldn't find anything. At the moment, most modding guides still recommend cleaning them although very few state why. By contrast many mod authors either don't see any benefit in cleaning them or recommend not cleaning them, including those at the pointier end of providing support. This isn't a thread for discussing the technical issues of cleaning the .esms, rather to address the following: 1. Whether STEP should still recommend cleaning the .esms 2. Whether it should be discretionary 3. If certain components of the guide rely on the .esms being cleaned then of course that answers both questions above. But if that is the case, and we agree that cleaning them is unnecessary, then perhaps future versions of the guide could be reconfigured based on this. I've cleaned the esms both times I've done a STEP install and I never experienced a problem. However, I didn't have a lot of mods installed on top of STEP. Some people do experience problems as a result of cleaning them. Related note, just FYI: the 'accepted wisdom' also applies to the other Bethesda games' DLC, with the exception of TES IV: Oblivion as those are .esps

Thanks for taking the time to give such a comprehensive reply. I know you have another project you are passionate about and would most probably rather be doing that. I acknowledge and appreciate your apology. No hard feelings. From my perspective, automation is one of those domains about which people allow their personal feelings, prejudices and innate cognitive biases to influence their opinions. That makes discussing it difficult because people say "I think X" but provide no evidentiary or logical reason for thinking that. We're not talking about ice cream flavours here where personal preference is what matters. What you think is less interesting than why you think it, particularly if you have sound evidence or logical reasons for thinking it. To address the points made: 1. Both you and Mercury71 have overlooked the fact that you are already using automation in the STEP guide. Two examples are any mod manager and BethINI. These are both forms of automation. Given that, you drawing the line at Wabbajack seems rather arbitrary and illogical. 2. Following on from #1, your points about automation 'dumbing down' the user base also logically apply to automation tools like mod managers and BethINI. Yet you both seem to again arbitrarily draw the line at Wabbajack. This seems inconsistent to me. 3. Your thesis that automation causes the 'dumbing down' of the user base has no evidentiary support. It might be persuasive to you, but it isn't to me. Maybe you're suffering from a phenomenon that we all suffer from at times: confirmation bias (that's not a personal attack but a well-known human failing). Further, and again going back to the points above, if your thesis had merit, we would be able to tell if there has been a 'dumbing down' due to the effects of other automation tools like BethINI and mod managers. I've seen no evidence that users are 'dumber' now than in 2006. Further, some things in life are counter-intuitive. This could be one of those things. Use of automation tools might actually contribute to users becoming smarter mod users. One person's experience isn't enough to conclude either way, unfortunately. 4. As I stated before, but this point was ignored, virtually all of the points made by you and Mercury71 about automation can also be made about curated modlists. How do I know this? Because other people have made them to me over the years. 5. I don't agree with your statement that automation contributes to information being lost. In my experience (which in this domain is considerable) automation improves people's productivity because they can focus on doing more important, higher-value tasks. Information isn't lost, merely the experience of performing the repetitive, low-value tasks. 6. Even if I agree with you that information is lost, you've ignored the fact that time is gained. This may not be an acceptable trade-off to you, but it is to many people. If I might paraphrase your earlier comment: this is time that could be better spent with families, making mods etc. What would you rather be doing: resolving mod conflicts, or making mods for the game? 7. Neither you nor Mercury71 have defined how much knowledge one needs about modding in order to avoid suffering from 'dumbing down' when using automation tools. Given there are so many variables to consider here, and your statements are very 'general' in nature, I would think that this question alone is fatal to your statements about automation with regards modding, especially given you are already recommending automation tools in STEP. 8. This seems to contradict your earlier statement that automation creates more support than it prevents. It could be that one reason the support requirement is quite low is due to the effects of using automation tools. I don't expect my responses to convert you into automation disciples but I think your views would benefit from exposure to a fresher perspective, which I have tried to provide. **** No he isn't. The sentence terminates at the period, not at the first bracket. Ironically, he's misrepresenting his own comment. See here, underlined: You missed the 'should' part. Where I've given my opinion, I've provided a 'why'. In other words, I don't expect people to believe my opinion just because I said so. That's not actually the point I was making - I was highlighting your value judgement in contrast to DoubleYou's comment. However, you've since clarified so it's irrelevant now. This is not uncommon in software development. People who highlight all the problems as justification to not do something rather than being aspirational and looking for solutions. This is how cool tech is made. Nobody said that Tech and z92669 had to also maintain a Wabbajack guide. New/existing team and community members may like to step up. I'm happy to contribute however I can.