jimnms

I sent a bug report on the mod's page. It seems that the X-42 Giant Robo-scorpion not attacking is a known bug according to the Fallout Wiki. Perhaps YUP was trying to fix that. I'm going to take a closer look at that script and see if something in it might be causing it to not engage in combat.

Ok, it turns out YUP breaking the Giant Robo-scorpion. I didn't expect that. I disable YUP first just to rule it out since it was the only mod that changed the giant robo-scorpion and then it was working as "normal" (more on that below). I poked around more in FNVEdit and discovered the cause. YUP changes the NVDLC03RoboscorpionGiantUseWeapon package to an object type of Weapons: Ranged instead of the ObjectID: NVDLC03LaserStinger. This basically removed it's weapon, effects and sounds, and replaces it with some magical ranged weapon that hits through any object and fires at an extremely fast rate. I reverted this one value in a test.esp and it fixes it. What is odd to me is that this package is added to the scorpion in a script which is supposed to give the player 10 seconds to find cover before enabling the combat package. There is still something wrong though. The Giant Robo-scorpion seems to have a very limited view distance. I can literally stand in the door with my pip-boy light on, jumping up and down and it doesn't see me or fire at me. If I shoot at it, it sometimes fires back then goes back to idle as if it can't see me anymore, but most of the time it aggros for a second and then goes back to idle without returning fire. If I go down on the floor and slowly walk up to it until it sees me, then back up a step, it loses sight and goes back idle. I remember this being a pretty tough encounter, but now it's too easy since the Giant Robo-scorpion just sits there ignoring me. Using FNVEdit, I've combed through every bit of OWB to see what is modifying what, and the only mods that directly change anything with OWB are YUP, Interior Lighting Overhaul, FNV Realistic Wasteland Lighting, and EVE. I tried disabling everything I can think of that might cause it to be practically blind, but I couldn't find the cause of that.

I'm not using the MMUE bugfix patch, just the Mission Mojave x93 terrain and object fix only version. It's just mesh files, the description on the download page says: "for use when not installing MMUE itself. Does not require DLCs. Also compatible with pretty much everything." I do have a merge patch, it took me days to comb through everything in FNVEdit and sort out conflicts. I fired up FNVEdit briefly to see if anything was making changes to the Giant Robo-scorpion or the Stealth suit. YUP is the only thing that makes a change to either of them. It does mody the Stealth Suit's script, but I looked through the changes and don't see any reason would not be working. The only changes it makes to the X-42 Giant Robo-scorpion is add a couple of actor effect flags to make it immune to radiation and poison. I only stuck with the Stealth suit through the X-13 tests, and the last two of the X-8 tests. I got nearly killed during one, down to ~20% health and my right arm crippled and the suit didn't inject me with Stimpaks or Med-X. I'll try it without the auto-purge script and see if that fixes it. This has been a long game, nearly 400 hours, but I've had very few crashes. Due to the massive amount of texture packs installed, it does tend to slow down over time forcing me to restart because my frame rate will begin to tank.

Are there any mods that are known to cause problems with the Giant Robo-scorpion battle at the end of Old World Bues? I'm playing with a lot of mods installed, but I haven't run into any major problems until now. I'm near the end of OWB, but when I enter the Forbidden Zone where the X42 Giant Robo-scorpion is, I die almost immediately. At first I thought this was because I was was not wearing the Stealth Suit Mk II. I didn't use the suit after getting it and running it through the tests. I was curious if it was required to be worn for the final battle, so I assumed this was why I was dying. I got the Stealth Suit, equipped it and went back in, but I still die. I turned god mode on just to be 100% sure I wasn't dying because of some other reason. It looks like I'm dying because the giant robo-scorpion immediately fires at me when I enter, and it's firing at an extremely fast rate and kills me near instantly. It's been a long time since I last played OWB, but I thought the robo-scorpion didn't fire at you until Dr. Mobius finished his speech and the lights come on, and I don't remember it shooting so fast. The scorpion doesn't seem to have any visual or sounds effects when it fires either. I only hear a squish sound when it fires and hear the splat as whatever it is firing hits my body, and there is no explosion sound either. It even seems to be hitting me when I move behind a wall or other objects. Then after a few seconds, it spontaneously blows up without me doing anything to it. It has to be one or more mods causing the problems. This is my mod list exported from Mod Organizer. I probably won't have time to play again until Friday night, so hopefully someone might know what's causing this and save me a lot of time troubleshooting mods. I'm suspecting EVE or Project Nevada. The settings I'm using for PN ramp up the damage, especially from explosives, so maybe it's doing so much damage that it's killing itself, and EVE is the only mod that would be effecting its visuals. I don't know why either of those would be causing it to fire immediately instead of waiting for Mobius to finish his speech and turn on the lights though. One other thing I noticed. For the short time I wore the Stealth Suit Mk II, it didn't auto inject stimpaks or Med-X when I got injured or crippled limbs.

Thanks dubiousintent, I'll take a look at that. My temporary fix is working for me and I was too busy playing the game to work on a permanent fix. As Red Green said, "this is only temporary, unless it works."

Where were you when you did your test? When I did my initial testing, I just used the console and wrote down the values reported from there. I did the tests where I was in the game at the time, which was at the radio station northeast of Bitter Springs (Bravo I think). When I was making the script to fix it, I used NVSE's PrintF function to output to a log so I could keep an eye on what was going on and make sure nothing was messing up. I made a few changes to its output format, then I did some more tests last night and things got weirder. I started by setting GameDaysPassed to 20, let it run for a minute then incremented it by 10 up to 100. I'm currently in the Lucky 38 suite, so that's where I ran my test. The GameDaysPassed variable accumulated correctly (well slightly fast) until somewhere between 60 and 70 where it drastically slowed down. It was still accumulating, even at 100, so I just bumped it to 150 and there it completely stopped. That was totally different than what I got from my previous test, but like I said, I was outside when I did that test. I went outside and ran it again. I got about the same results as my initial test It was accumulating about 1.25x faster than it should until it slowed way down at 40 and stopping completely at 70. I dumped the logs to Google Spreadsheets. Here is the indoor test and here is the outdoor test.

In my current game, my hardcore needs stopped updating in real time. I did some searching and found a couple of mods that claimed to fix them, but they didn't work. I then found this post where the last post by Waren_AlKar mentions that the GameDaysPassed variable stops working when it reaches a value of 64, and that is indeed part of the problem. The hardcore needs increase based on this variable. I did some testing and found that there is more to it than it just stopping at 64. The game starts off with this variable set at 5, so I set GameDaysPassed to 5, then waited 10 game minutes and checked the GameDaysPassed variable again. I did this several times and I found that GameDaysPassed is increasing about 1.5x the actual game time. After each 10 game minute wait, the GameDaysPassed variable increased by 15 minutes. The hardcore needs also began updating since GameDaysPassed was now increasing in real-time, and they were increasing faster than they should because of this. That's not the worst part though. I tested GameDaysPassed at other values, and as the value increases, it accumulates at a slower rate until it stops around 64. By the time it reaches a value of 60, it is only accumulating at 8 seconds per game minute. This causes the hardcore needs to increase slower the the longer the game lasts until they stop when GameDaysPassed reaches ~64. Somewhere the game is still keeping track of things because although it doesn't update in real time anymore past a value of 64, it still increases when you sleep, rest or fast travel, which causes the hardcore needs to increase as well when you perform either of those actions. It is also being saved with the game, so when you load a save the GameDaysPassed variable is updated, which is why you might notice your needs have increased from what they were when you made the save. When looking at the variable on the console or what is returned when being read by scripts calling the variable, it only returns a value out to 4 decimal places. My guess is that due to rounding the value up and down to 4 decimal places, as the value increases, it's causing it to increase more slowly the higher it goes until it reaches a certain value where it doesn't round up or takes a very long time to pass before it rounds up by that fraction. My game has already passed 64 GameDaysPassed, so i threw together a quick fix, but I'm trying to think of a more permanent fix. I have briefly explored the GECK looking for what controls the needs to see if it can be separated from the GameDaysPassed variable, but I can't find it. Right now my only idea is to set GameDaysPassed to a high number (64 or higher) at the start of the game and use a script to increase it. This seems like it would be very inefficient though and there has to be a better way. Does anyone know what controls the hardcore needs and is it something that can be edited in the GECK or is it hard coded? I'm looking for ideas on a way to make a fix that will work from the start of the game rather than waiting for it to break.

I managed to accomplish what I need by using the GetSecondsPassed and adjusting it to the time scale. This worked out better since it doesn't have to run faster for people that use the default timescale of 30, and it's more accurate since the script is not always processed exactly every 5 seconds (the default process time). To help debug the script, I set some stuff to output things to the console and noticed the script processing time would vary by up to 0.1 seconds, which isn't much, but over time would add up to a significant error. The only down side is that more in-game time will pass for people with higher timescales before things update. I can't find the page on the GECK Wiki where it gave an example using fQuestDelayTime, but the link it gave for help on the fQuestDelayTime pointed to the Elder Scrolls Construction Set Wiki, which says: It appears this is no longer used in the GECK and is replaced by the SetQuestDelay instead.

I need to make a script run every in-game minute, which will differ if users change their timescale. To find out how long one in-game minute is, you just divide 60 by the timescale, so I do "set fQuestDelayTime to ( 60 / timescale )". My current timescale is 12, so one game minute is 5 seconds, which is also the default time for repeating scripts. The script works, but when I tested it using a different timescale, it still runs every 5 seconds. I've even explicitly set the fQuestDelayTime to a faster interval, but it always runs at the default 5 seconds. Does this just not work in New Vegas?

I'm playing a heavily modded game that adds a lot of new quests, and it has been and is going to be a very long game. I just finished Honest Hearts and my food, hunger and sleep meters do not increase in real time anymore. Sleeping, waiting or fast traveling will advance them, but after that they immediately stick again. I don't remember having this problem in previous play throughs, but I just may not have noticed it or I got lucky. It appears to be a common problem based on what I found when searching for a solution, and it's documented on the Fallout wikis. This is bothering me, so I've spent the past two days trying to find and a fix for it. I found two mods that claimed to fix it, but they don't work (one just kills me on the spot). Those two mods fix the "bug" when starting DLC and finishing DLC where your sleep gets set to -10000 and causes them to get stuck, but they gave me an idea to poke around at the values. I knew about the actorvalue (getav), but I did not know there was a different permanentactorvalue variable. I checked the values and they were off, so I manually zeroed all of them (which is pretty much what those mods do). This still didn't fix the problem, the meters remained stuck, only increasing after sleeping, waiting or fast traveling. Then I remembered another post I found while searching (that I can't seem to find again) where someone said there was a bug in the GetDaysPassed variable that cropped up after it went higher than 64. I checked my GameDaysPassed variable and it's 83.XXXX. After checking the GameDaysPassed variable, I let the game sit for a few minutes, then checked again and it had not advanced, so it's stuck like the needs values are stuck. I set the GameDaysPassed variable to 1, saved and restarted, and now the needs meters are increasing as they should and checking the GameDaysPassed variable every few minutes, it also is increases in real time. I reloaded the save where the GameDaysPassed is 83.XXXX and stuck, then added 0.1 to the variable and the needs meters increased with it, so the needs variables do increase with GameDaysPassed variable. TL;DR Since GameDaysPassed is what is getting stuck, fixing that will take care of the needs meters. Setting GameDaysPassed to 1 will fix the needs meters, but this will probably break quests and scripts that read and stored this variable at some point. Although the value is not increasing in real time, the game is still tracking it, but it doesn't apply the time passed to it until you do something like sleep, wait, fast travel or load a save, then it increases it. Are there any commands that will force the game to update the GameDaysPassed variable? If so, then a simple fix would be to make a script that runs every few minutes to kick the game and force GameDaysPassed to update. EDIT: I managed to create a stupid simple script that fixes it. It takes a snapshot of the GameDaysPassed variable, then compares it to the current GameDaysPassed variable on the next run. If the snapshot is equal to the current GameDaysPassed, it increases GameDaysPassed using the GetSecondsPassed variable (after adjusting it to the TimeScale and then converting it to days), then takes a new snapshot and repeats. If for some reason GameDaysPassed increases on its own, it just takes a new snapshot and waits. I'm not a scripting expert, so this is probably a crude and inefficient solution. There is probably a better way to do it, but no one (to my knowledge) has done it yet. I tested it quite a bit today and I'm confident it works, so I'm going to go ahead and throw it up on NexusMods.

Did you (or anyone) figure the problem (yes I know I'm replying to an old post)? To the best of my Google-fu ability, this was the only search result I found mentioning this. I did not have this problem in my previous game, which I only ran a bug fix mod and some gameplay tweaks. I'm now running a heavily modded game and I'm having this problem now. It makes it impossible to give companions junk weapons to carry because they equip the weapon with the highest DPS in their inventory, which now is the lowest quality weapon. I attempted to figure out which mod was responsible a while ago. I was suspecting Project Nevada, because it's the only mod I use that changes weapon damages, but I couldn't start the game with PN disabled. I finally had enough and was able to figure out how to disable PN and get the game to start, however, after going to all that trouble, it isn't Project Nevada doing it. I was about to go through and try disabling one mod at a time, which would take a while with ~120 mods loading. Thanks to the OP's list, I can cut the list down to what we have in common.

I'm going resurrect this thread since it's the most recent one I've found on this issue. Something is not right with achievements and the NVSE 4GB exe. I recently starting playing FNV again after having quit a long time ago before completing the game despite Steam saying I have 280+ hours (long story involving bugs, patches breaking things, corrupt save etc). I'm using the fnv4gb.exe downloaded from nvse.silverlock.org. I have the nvse files as well as the fnv4gb.exe and fnv4gb_helper.dll in the main FNV directory. I seem to be getting achievements for quests, but not other things. I do not have the Jury Rigger (Repair 30 items), Crafty (Craft 20 items) or No Tumbler Fumbler (Pick 25 locks) achievements even though the PipBoy's stats page shows I've repaired hundreds of items, crafted hundreds of things and picked well over 25 locks. I also don't have achievements like Lead Dealer (Cause 10,000 damage with Guns) which I should have by now at level 27 and having used only conventional guns the entire time.

I haven't been able to access newvegasnexus.com for days, but newvegas.nexusmods.com works. It's a bit of a pain because a lot of links still point to newvegasnexus.com and it's giving 404 errors instead of re-directing like it used to.

Are there different mirrors for files that may not have updated, because I don't think it was a browser cache problem. It did it when I used a completely different computer. I'm not behind a proxy, and my router doesn't cache. I did use the same file name each time, but it didn't work until I changed the version number on the upload page. On the upload page it says to leave the version number blank to ignore, which I did on the original upload. On the description page you have to put a version number, so I just put "1" in the box. When I finally got it to take the new file, all I did was change the "1" to a "1.0" and put "1.0" as the version on the upload page. The file name is still the same, but it is now the correct file with the correct contents. All that matters is that the correct file is there now, I just hope the people that downloaded the wrong one will come back and get the correct file.

I uploaded a small bug fix mod several days ago. I downloaded the file and checked that it worked, and it did. Later decided to add a Readme.txt. I created a new archive since I'd already deleted the old one. I re-uploaded it and everything was ok, or so I thought. Today someone told me my fix wasn't working, so I downloaded my file and noticed I stuck the wrong .esp file in the archive by accident. I've corrected it and re-uploaded, but when I go to the files page and download it, it's the old file still. At first I thought it was my browser cache, so I deleted the file from the nexus again, re-uploaded it, cleared the cache and downloaded it. I even tried from a different computer, but I sill got the old file. I finally managed to get it to take the new file by changing the version number on the upload page. Why couldn't I just upload the new file? And now what do I do about all of those people who downloaded the wrong thing?