DanielCoffey

Hi folks - me again. I have been afflicted by the Pipboy Radio Stutter which is usually caused by Codec conflicts for the .mp3 files. I am referring to the "warbling" sound you get over the Pipboy music tracks. In-game radios are fine. The DJs are fine. it is only the music that is played after the news that is affected. According to the WIKI there are three fixes. One is an .ini edit which didn't work. The second is throwing new Codecs at it which worked in the days of WinXP and Vista (and using old 32-bit Codecs is contraindicated for Win7 onwards). The last is culling conflicting Codecs which may cause issues with applications other than FO3. I have cautiously applied the k-lite Codec pack since it has Win10 support in it and applied the "repair bad codecs" fix but to no avail (I used the Basic k-lite pack since it was the one with .mp3 cover in it and accepted the default installation options, applied the Detect and Repair tool and rebooted). Now the catch is that some music tracks will start to play fine and then go warbly after a minute. Others start bad and don't fix themselves. Some secret Enclave tech seems to make the majority of the Enclave Radio tracks work fine. Can I convert the affected tracks individually to a different format? Is there a known good codec for WIn10? Is there a known bad codec? I am using Win10 with MakeMKV and Reaper installed.

Ah, so it isn't just me then. Thanks for the confirmation.

Another question on the subject of LODs... are there supposed to be LODs for Big Town? Approaching from the direction of Megaton and Springvale I clearly see the Red Rocket station as I pass under the Raider highway but there is just a large blank ground square with LOD roadways marked where Big Town is supposed to be. As I approach some ruined trucks, the very edge of the Big Town boundary fence pops in from nothing. A few more steps and the rest of Big Town pops in from nothing. I would have expected shack LODs at least. I have pictures of the effect if needed.

Apologies - I meant the terminal hacking mini-game. It appears to be a known issue... and

I have spotted an oddity in the INI Tweaks section of the Guide on the separate INI Tweaks page. We are told to make the change in the [RenderedTerminal] section to use Darn_Sui_Generis_Otl_13.fnt for sFontFile_5 but this is a proportional width font. When you do this, the text in the Terminals is squashed up to the left. Is this a leftover form a removed mod called "Higher Resolution In-Game Rendered Terminal Text'' or something?

I have created some "thinner" textures for the FO3LODGEN trees folder and rebuilt the atlas. I can see the atlas pick up the new textures. The bare trees and stumps are fine - I just redid the DEAD leafy trees and they are a little better but I still have what appears to be a short draw distance for the detailed LODs. How far off do you think the TTW team is in creating low poly models for the trees?

Zilav - which texture is used when a tree in the distance is drawn? I mean the low detail "fat" ones? Is it FO3LODGEN's ../textures/landscape/trees/TreeDeadxxLod.dds or is the big ../textures/landscape/lod/wasteland/blocks/WastelandObjectsLOD.dds ? I assume that the WastelandObjectsLOD.dds is constructed by the script from all the other textures but I was planning to look at the mipmap and alpha mask and wondered if it was the single tree or the aggregated texture that was used.

This is weird - I created new versions of the FO3LODGEN tree textures with no mipmaps to see if I could work out what was happening and they were still fat and blocky in the distance. As I approached, they moved up the mipmap chain (even though I had not provided mipmaps, getting better in appearance until they switched at the LOD point for the actual models when they looked perfect. There must be some part of this I don't understand. EDIT : I see you are still in discussion about LODs in the TTW LODGEN thread. I'll put this on one side for now and concentrate on my other problem... does my draw distance and grass fade match what you would expect?

The closeup trees in the FO3LODGEN file are nicely done and correspond exactly to the trees in the foreground. Redoing their mipmaps in Photoshop had no discernible effect on the foreground trees. If I look at the background "fat" trees then they don't match any of the textures in FO3LODGEN itself. They seem to originate from the Generated Textures that the script makes. There is a file called ../textures/landscape/lod/wasteland/blocks/WastelandObjectsLOD.dds (and the _n.dds) and it seems to be this file that is used to draw the "fat" trees. I think the second and third levels of mipmap are the culprits and are fairly fuzzy. Where is that texture assembled from and how are its mipmaps generated? It seems to be assembled by the FO3LODGEN script out of components in the main FO3LODGEN mod? EDIT : Scratch that - I created a version of that file without any mipmaps and they were still fat and blocky. It has to be something else.

I am getting some oddities with my draw distance and tree billboards and I wonder if I could just get an eyeball on these screenshots to check if what I am seeing is what you would expect for the Ultra settings. The first shot is taken from the bridge at Arefu looking in the general direction of Megaton. There is a clear grid of detailed LOD and grass nearby and then an abrupt boundary where the grass stops and the LOD is low detail. All buildings outside this block are low detail shapes with simple textures. As I walk towards them, the grass extends then they pop in to full detail. You can see the LOD edge just past the Brahmin pens and just as far as the boat on the jetty. I have resized the image down from 2460x1440 to 1280x720 for convenience. Next I will show you the issue with the tree billboards I am seeing with the output from FO3LODGEN. I am using the DEAD version of the Flora Overhaul. First is the Vanilla LODs and billboards with both the FO3LODGEN ESP and LODs disabled in ModOrganizer and then I have turned the tree billboards back on... Look at the "fat" trees in FO3LODGEN. Have I created them correctly? Here are the Fallout.ini and FalloutPrefs.ini files in Spoiler tags. Fallout.ini FalloutPrefs.ini

There are two weapons in 20th Century Weapons -Plus- Reborn Cut Weapons.esp that need removing from that plugin as they are duplicates of weapons that already exist in 20th Century Weapons. Their stats are slightly different and if you get one of each you can't use them to repair each other. VEPR-12 Molot Drum VEPR-12 Molot Mag In the Cut Weapons ESP they need deleting from the list of weapons, the Repair list, the Condition and Ammo list, the supermutant levelled list and the AutoShotgun levelled list. This is more an FYI to those who are trying to maintain their own Compatibility Patch rather than a change to the guide. === EDIT : It appears that the Cut Weapons mod restores some 20th Century Weapons that were modified, renamed and re-calibred by the 20th Century Weapons -plus- Reborn FWE-WMK-Calibr14_V1_70RC_18668.esp There are some duplicates such as the VEPR-12 but it looks like the original 20th Century Weapons omitted the originals from levelled lists like the SuperMutantWeapons list so the Cut Weapons does add functionality. The Cut Weapons mod may need some scrutinising as there are quite a lot of tangled edits between the 20th Century Weapons and the Reborn patch.

Kelmych - I would advise keeping the Guide as it is with the ENBoost included but make the change to the enblocal.ini such that ReduceSystemMemoryUsage=false. Perhaps also make a comment on RH_Ironsights along the lines of "If you see the model of the weapon not aligning with the expected aiming point and being drawn too high or too low, consider limiting the FPS to 54 instead of 60. This can be set in the Stutter Remover ini. Do not confuse this issue with the skill-based hand shake or drift which can be adjusted in the Gun Oil menu." ==== Testing... (Since I play at 1440p, I am used to 16xAF, 0xAA) 1. StutterRemover capped to 54fps. ENBoost installed, ReduceSystemMemoryUsage=TRUE. ENBoost handling AF/AA GPU : 25% VRAM : 1.2Gb used FPS : 54.0 when still, Stutter : very heavy 2. Stutter Remover capped to 54fps. ENBoost uninstalled. Fallout3 handling AFx16, AAx0 GPU : 12% VRAM 1.2Gb used FPS : Less than 54.0 Stutter : none, slightly choppy but steady 3. Stutter Remover capped to 54fps. ENBoost enabled, ReduceSystemMemoryUsage=FALSE. ENBoost handling AF/AA GPU : 25% VRAM : 1.2Gb used FPS : 54.0 Stutter : none, smooth By changing the ReduceSystemMemoryUsage to FALSE, the GPU is now doing more work but the stutter when turning is completely gone. Textures take a little while to cache but once done, the framerate is steady. It appears that when ENBoost was handling the memory, the GPU was idle more often because the stutter was reducing its workload significantly. I then tried enabling the default UseEffect setting in ENBoost to turn on the rudimentary default ENB and noted that the FPS dropped to the 40s, VRAM went up to 1.5Gb, the GPU was running at 90% but everything was still smooth when turning. === EDIT : Repeated test 2, Stutter remover only. GPU was underutilised and often stepping down its clock. The frame rate was a little ragged and felt as though it was in the 40-s. When I put ENBoost back on with the ReduceSystemMemoryUsage set to false, the GPU was working a little harder but the frame rate was very smooth. There is certainly merit in having ENBoost in the mix providing you can edit the .ini to avoid the choppiness. I have no idea how much work the ENBoost dll is doing but it is appreciable.

Hishutup - you were right! Look at this reddit... https://www.reddit.com/r/FalloutMods/comments/3agal0/fallout_3_enb_fps_drop_when_turning_help/ And from the horse's mouth on the FO3 ENBoost page itself... I will have a test later.

I wonder if StutterRemover/NVAC and ENBoost are working at cross purposes then? I think tomorrow (it is late here) I will try StutterRemover/NVAC alone and then just ENBoost. EDIT : Oh, NVAC is needed for other things too.

Even ENBoost without effects enabled? (UseEffect=false in enbseries.ini)

VRAM seems to sit at about 1.5Gb used, even with all the LODs added. Fortunately I had PLFewerItems.esp hidden already. I did think about ditching IMPACT at least but it is referenced in some of TWPC patches so will need unpicking carefully. I get the hitching right at the very beginning of the game too - exiting the FWE Alternate Start hut and after waiting for all the scripted items to finish still demonstrates the hitching. It is not apparently tied to any one direction - just swinging the camera round. The mods are all on an SSD so should not be causing pop-in to slow down drawing. In fact, texture/mesh/LOD-only gives a very smooth game which was why I wanted to identify the heavy script mods.

As I have mentioned in a few posts, I am having severe and disruptive "hitching" when turning the camera around in my C&PD install. It occurs both outdoors and indoors, on a fresh character, both in and out of combat, immediately on launching as well as after considerable play and it is highly irritating. I have the large majority of the C&PD mods installed, even the Optional ones because I figured that an overclocked 4770K and 780ti could handle them. I should point out that I am running on Windows 10 since I have no other versions of Windows available. The game is very stable with no CTDs and only one lockup in several hours of play when zoning to an indoor location in Minefield. I would like to ask how to identify the "heavy" mods that might be causing this. Rather than just disabling chunks of mods till the situation eases, I wondered if there was a more scientific way of locating the culprit. It may just be something being taken over a threshold by the sheer number of mods or it may be a single mod with a script gone bad. I would like to find out. I set up several MO profiles to test this by using the FWE Alternate Start - Vault Dweller. One was FWE/MMM/RH_Ironsights and the UI mods plus all the "texture and mesh" mods and it was as smooth as anything. Rock solid 60fps at all times. The ENBoost profiling tab showed absolutely no change in frame rate as the draw calls fluctuated from c. 1500 to c. 3500 as I turned around in Springvale near the roaming Eye Bot. As soon as I re-added all the "content and gameplay mods" such as 20th Century, WMK and the Locations, the choppiness was back. The frame rate was largely 60 when stationery but hitched unevenly down to the 20s as I turned. It was not a smooth decrease - it was as if there was something hard in my way and the camera froze then jumped to the new position. I would consider FWE, MMM and RH_Ironsights as my core mods but unless I can be given a few pointers, I am afraid a large chunk of the rest of the guide will have to go since I do not find it playable in this state.

Not yet - the mod seemed to be used to make the first person shoot-from-hip model follow the pointer tightly rather than being anything to do with RH_Ironsights. I will set the fps clamp back to 60 tomorrow and try this though. I am still trying to track down my hitching issue. It is not graphics related as I found when I set up a new profile in MO. I got perfectly smooth turning and movement with ALL model and texture mods enabled but all gameplay, location and so on mods disabled. I am wondering since it occurs indoors and out when swinging the camera if it is a script going mental under certain circumstances and the main thread being too busy to cater for it. No idea how to track it down since it is not dependably reproducible.

Have a look at FO3LODGEN (a script that runs inside xEDIT) - it is in the guide.

You will see a few weapon issues too - the MP5A4 SMG family and a few ironsights that were missed (VEPR-12 Molot Drum for one). Check the MP5 plugins plus anything that Impact is missing for starters.

If you look in xEDIT you will probably find the Bashed Patch has not picked up the FWE changes to drinks. You will need to make a Conflict Resolution patch that forwards the FWE Effects changes to the foods and drinks that are not correct.

I am not talking about the gun shake caused by low skill - it is the ironsights becoming uncentred from the sights themselves. After a while of playing, the model of the gun gets drawn in the wrong position for you to see down the barrel. According to THIS reddit, it is an interaction between RH_Ironsights and the Stutter Remover. HERE and HERE is the Stutter Remover's comments on the issue. EDIT : A quick check for 20 mins clamped at 54fps seems to have done the trick for the drifting of the gun models. I still have very heavy stuttering and hitching so I will look at reducing LOD and similar next although it does it indoors too which would normally eliminate LOD workload.

If your system spec is up to date, you might experience it if your FPS is frequently 60. It is common enough to still be talked about on reddit last year (google "fallout 3 ironsights drift" and ignore the gun oil hand shake chatter). I am trying to let the Stutter Remover manage fps again but have capped to 54fps for a while to test. I am getting very frequent and heavy hitching that is not GPU-related. My GPU is about 25% utilised and only 1.5Gb VRAM used and is running very cool. I am thinking it is to do with either scripting or LOD pop in and may be because the FO3 main thread is too overloaded. I should probably look for the script-heavy mods and try an alternative MO profile while I look for culprits. The ironsights drift may be related in that if the game is too busy doing something else, it can't keep track of stuff like that.

I am having the issue of Iron Sights drifting from true over time as I play (not the hand sway that you can adjust in Gun Oil) and I wondered if there was a definitive way of dealing with it? The issue is that over time, the aiming point of a weapon when sighted drifts away from the true aiming point, often to the point where it obstructs what you are shooting at. Rarely the gun model drifts down but more often it drifts up. The short term solution appears to be to un-equip and re-equip the weapon in the PipBoy then the sighting issue is resolved for a little while longer. Anecdotal evidence suggested it was something to do with the framerate lock in the Stutter Remover. I have seen folks say to either disable Stutter Remover or lower its framerate lock to 54fps (which seems an unusual and somewhat arbitrary number to choose). Since I knew that ENBoost also had a FPS lock, I disabled the FPS Manager of the Stutter Remover completely (bManageFPS = 0) in the hope this would resolve the issue but it did not. I still had a solid 60.0fps from ENBoost but still had the drift. Any ideas? Is this mysterious 54fps backed up by something solid?

I am looking at a couple of the DAM values in-game of some weapons which seem a little overpowered and I am trying to understand the factors which contribute to that DAM rating. Example 1 : Combat Shotgun DAM 55 Example 2 : VEPR-12 Molot Drum - DAM 681 Both are 12-gauge. Is it something to do with the fire rate? In xEDIT, the combat shotgun has damage 72, projectiles 12, fire rate 1, clip 12 and the VEPR-12 has damage 25, projectiles 8, fire rate 10, clip 30 and supports full auto. Both the weapons above are somewhat low in condition if that makes a large difference.