ManehattanProject

Checked through it all (even did a brand new scan with Malwarebytes) and no luck there. Hell, I've even cut out half of my services to see about isolating the issue. Nothing.

That is exactly what I was hoping for. Sounds like it's time for a UI mod. Thank you kindly!

So I'm throwing this out as a concept. As one of my upcoming projects, I'd like to be able to introduce limited magic-like abilities, mainly ideas like "force push/pull" and "levitation," as well as a healing spell. While I know there would easily be some ways to fake healing spells and potentially use the "Alien Artifact" ability as a quasi-force push, I'm wondering how far you could stretch the game engine. How possible is this idea?

No dice. It's actually slower. Additional note: New rig is running 16GB DDR4 2400 RAM (just in case it matters) I went through the following iterations, changing compatibility mode on the actual GECK Power Up Shortcut, the GECK.exe and the nvse_loader.exe files. (Just to be extra thorough, though I'm fairly sure the only one required was the GECK itself. Fastest: Compatibility mode disabled (about 1 minute to load FalloutNV.esm) Tried Windows 8, Windows 7, Windows Vista SP2, Vista SP1, Vista and even XP. On another unit, which is a boot-camped iMac (Late 2012, Model 13,2) where GECK is actually on a USB 3.0 external hard drive (i7-3770 3.4GHz Quad/8 Thread, 16GB DDR3-1600 RAM, GTX 680MX) the same process took 20 seconds. Even the initial load time of the GECK is slower. On the iMac, it's nearly instant (1 second or less). On the new rig, it takes a minimum of 4 seconds for the GECK splash screen to go away. I also tested both machines with FalloutNV.esm running only GECK.exe (without the PowerUp) iMac: 21 seconds New Rig: 1 minute, 5 seconds. The iMac has no special compatibility settings. In fact, since it's loading from an external USB HDD instead of an internal SSD, it should be running a heck of a lot slower. This thing is killing my productivity.

I know this sounds like a silly one, but bear with me. I recently built a new rig running a i7-6700K (4.4 OC), a GTX 970, 16GB Memory, Windows 10 and a 500GB SSD (among other things). Yet despite this, the FO:NV GECK runs actually worse on the new unit than my previous unit, which had an i7-2600K (3.4), GTX 960, 16GB RAM, Windows 10, and a 7200RPM HDD. On the new machine, I get FPS stutters loading large cells, especially with lighting active. The load time of the .ESM/.ESPs is at least triple from what it used to be. For pete's sake, it even hangs for about 10-20 seconds when loading up an Object Palette! Both processors are 8-core processors (well, 4 cores, 8 threads). The 2600K hasn't been modified or tweaked in any way. Now I have the 4GB hack and the GECK Power Up 1.4 already set up on both units and both units are running off the local C: drive. What's even worse is that I tried firing up the Fallout 4 GECK and it's just as slow and clunky as FO:NV's GECK. Now, I suspect that mainly to be because of the size of the data Fallout 4 has, but still. Any recommendations? How have you been able to effectively run on the GECK on a modern system. (I built this thing last month).

I could be wrong, but I think this was primarily caused by Obsidian introducing a new music system into the game replacing/bypassing the base one in FO3, so I think it's specific to FONV.

I tried the radio trick by placing a bunch of "AutoOn" radios just outside the walls and it just failed miserably. Definitely didn't work out...though now the players have the choice to listen to the score through their PipBoy Radio, which is something I got a few requests for. I'm guessing this is going to be the same for worldspaces, huh? Or is that easier to control? I've got an amazing musician on the team that's putting out Triple-A quality scores and I just want to have folks be able to enjoy them! Worst-case scenario...we could always replace the existing scores with our new ones. Jim, did you try saving the MP3 in different formats? (For example, I know that radio song .WAVs need to be in mono). Just something that came to me, you probably tried it a dozen times over.

So I know there's a couple different ways to handle music in FO:NV, but I'm really not sure what the most effective one is. Currently, Smuggler's Run is using an AudioMarker that's pointed to a Media Location Controller that ends up going to the Media Set. (This all seems very convoluted to me). However, when I'm in the level, the music doesn't loop properly. It'll restart the loop about halfway through the song. Anyone have any experience with custom music who can tell me the best way to do this for a seamless experience?

Ah well, you can't have everything, eh? Sounds like no matter what, they'll be some loose files, but at least I can finally clean up the textures and meshes (and don't need to worry about how much of a mess the file structure may or may not be >.>)

Thanks for the tip. What happened with the LOD? Damn. I forgot to check that. Nice catch.

Actually, I just realized that my custom music isn't playing when packed into the BSA. Any ideas?

Thank you that was exactly what I needed. I was just missing a single step. ^^

It appears as if the documentation site for BSAopt is down and the GitHub has no data on the usage of this program. Could anyone give me a quick rundown of how BSAopt operates? I'm just looking to package up Smuggler's Run in a cleaner way.

Rick, you're right. I forgot that they were separate things. As far as it looking terrible, it's a little of both. In the particular example I was seeing, I found that walking out over the platform that looks out on the Wasteland results in flashing textures, the same kind you get when you have overlapping objects. There's also the fact that the particular angle I'm using allows the user to look beyond terrain that is normally hidden from view, which isn't exactly bad, but is really dull looking. Otherwise, it's object LOD. I ended up having to make another "Metro Tunnel End" south of Nipton to avoid the fact at least five other people had already thought of using that damn door to hide things. I also have added several new things to the landscape for this particular level, all of which need LOD. I'll look into all of these. I didn't know about these particular ones, only the recent FNVLODGen addition that gives us stuff like curved rail tracks, boxcars and the like: http://www.nexusmods.com/newvegas/mods/61206/?

Okay, I know this is likely utter madness, but I need to ask anyway. I'm using the cliffs just beyond Spring Mt. Ranch State Park looking out toward the rest of the wasteland for one of the climatic battles of GoE (Serious boss fight with Veribird attacks. Yeah. It's going to be awesome.) But as I look out over the distance, I realize that the LOD for this area is really terrible. In addition, I'd like to add a few Satellite Dishes above the area. ...so how insane is the idea of regenerating the LOD of WastelandNV with various resources available now? Or has this already been done...and is there any way to regenerate a small section of the WastelandNV instead of the entire thing?

I wasn't sure if Pixelhates was an expression of how much you loathe the process or an actual thing. ^^;; Thanks much! :D

One more thing...is it possible to add another animation state easily to this? Basically just duplicate one of the states so there are three instead of just two? Or would I need to do that in Blender or another program?

Okay, that was a #$%#$ nightmare. Whoever designed the framework of color animation for .NIFs needs to get shot. Like in the leg or something, not killed. But definitely injured in some way. What totally threw me was the 0-1 RGB value scale. I had to use one website to convert the 0-1 RGB value into a normal 0-255 value, shift the hue to the purple part of the spectrum, export the 0-255 value, convert that back into the 0-1 value...and rinse and repeat for each animation state. (I wanted the same general brightness as the existing glow). Thankfully, there was only actually four colors between the 14 different states, so throwing them on some Macro Keys on my old G15 Keyboard and bam, it was pretty quick after that. Thank you so much for pointing me in the right direction. If this piece wasn't an integral part of a huge quest finale sequence I have planned, I would have never gone through with it...but I'm stubborn like that. Seriously though, thank you a billion times over. I never would have figured this out on my own. http://i.imgur.com/BnNsvNh.jpg

Thanks, this definitely helped for the Tesla arc (also helped that I changed a bunch of .dds file references I apparently missed the first time). However, the SatelliteTop01 doesn't seem to follow the same rules. When I check out the Vertex Colors, everything's white, gray, black or something in-between. I decided to try and do a "Set All" anyway using NifSkope 1.2, but all I got was a very dark midnight blue. The textures referenced are enclavebase03quad.dds, which only has rusted steel, so the blue isn't coming from there. I've done some more investigation. Could this have something to do with the NiMaterialColorController & the Target Color set to TC_SELF_ILLUM? This unit's particular two animation sets are flashing lights of the glowing areas.

I'm trying to create a custom version of NVDLC03SatelliteTop01.nif. For this mesh, I simply want to change the color (from blue to purple) while keeping the animation states the same. However, unlike most other NVDLC03 assets, when I selected the colored "glow" textures and changed the emissive color, this caused no change to the mesh itself. In fact, only the "Wires" has an emissive option which shows as the correct color: blue. The outlines and small boxes along the base have a black emissive color. I have no idea where the colors on this model are coming from. Could someone please tell me where the colors are being pulled from? In addition, I've tried to manipulate some FX models such as dlc03fxteslaarc01, arc02 and side.nif. I've made colored versions of the .dds files (same as I done dozens of times before), and save custom models pointing at the new textures, but the colors are still blue in-game. I feel like there's some sort of color setting in NifSkope that I'm completely missing. (And yes, auto-sanitize is now off permanently). Any suggestions would be extremely welcome.

I'll see about getting a copy of the bottom level of GoERFS3Labs where I identified my problem and maybe of my other level that still has it. It'll likely be a bit though. I desperately want to finish this series of levels. ^^;;

One other detail I found: If I added new elements to the game (textures/models), this issue would suddenly reappear until I turned off and on Archive Invalidation in FOMM. After reactivation, the problem would resolve itself. However, if this is happening in a NavMeshed cell, I found that make sure that cover was not going through the door was the best fix. It seemed to resolve all the problems with a cell where I had done the NavMesh. Now if only someone would explain why NavMesh, which is supposed to control the NPC actions, is screwing with a player's ability to walk through doors, they'll get five thousand invisible and useless bits.

I had to double check all my cover for the levels and make sure I didn't have cover going through any of the Utility Doors. After that, I had to turn off/on Archive Invalidation. Then it worked...at least for me. Mine's a bit different since the particular place I'm having the issue I just nuked the NavMesh for later, but I remember adjusting the cover helped a lot, making sure it was properly set up around the edges of every door in another cell I was working on.

Oh yes. Roy especially has been of tremendous help with insane levels of patience for dozens of my random questions in the past. I'm always grateful for the insight of the best. Without their help, this would have never happened. At all. I've always been huge on iteration. My real skill set is an author and I started doing that years and years ago because saves can be unpredictable. Occasionally I'll want something that I wrote previously and I want to have that always available. Our build numbers are also somewhat misleading. When we make a massive change or cleanup, we'll usually up it to the next tier (400, 500, etc.). I also do have some professional experience as did our former Technical Director, who set us up early on with the idea of iteration as a key component of design. I also formerly did both hardware/software tech support and have some experience building network infrastructure from the ground up. Those kinds of systems demand an extremely thorough iteration system. And then there's the whole OCD thing. :D I've learned this doubly so in GECK which is bloody unpredictable (especially when NavMeshing - thank God for autosaves). Thankfully, it was iteration that saved us. I ended up loading each one until I found the one that didn't have the problem and compared it to the one immediately afterwards. I didn't want to restart from there because an ENORMOUS amount of work had been done already, stuff I really didn't want to duplicate, so instead I searched for the culprit and found it. :) Thank you though! I'm just happy the nightmare is over (even if it took 12 hours of QA :P)

I'm going to post this for anyone else who comes across this issue. I finally nailed down what was causing my issue. One of my levels had an unfinished NavMesh. It was the level directly before the location with the problems. As soon as I removed it, the issue resolved itself. I remembered afterwards that I had a similar problem after NavMeshing another level. I suspect it has something to do with the cover system, but that's just a theory. Thankfully, I had iterations and using the Compare filter in FNVEdit helped clue me in after going through each version of the mod to find what had been changed.