New Vegas Engine Bug List

[RoyBatterian]

Posting this here, so people can see what bugs are still in the engine and which ones have been fixed. I started this google doc in June of 2017 and keep it up to date as I find more.

 

Also as a log so there isn't dispute about who knows about what bug and when it gets fixed on the engine level they can't piss and moan about it like some people have in the past.

 

If you make a mod that fixes it via script or whatever, don't get upset when it's fixed at the engine level.

 

https://docs.google.com/document/d/1kK9WmQ2WFPJbDTDSn5vInpy-icRGkufa1Y69E3UrAHA/edit?usp=sharing

[dubiousintent]

Thanks a lot, Roy. You don't mind if I add this link to the wiki "Getting started creating mods using GECK" article, do you?

 

-Dubious- (BTW: Pink's the one they also call "Bouncé", no?)

[madmongo]

Excellent list. It's not as long as I expected it to be. :laugh:

 

There is a plugin limit that seems to be a signed/unsigned bug. It's not a memory or a handle bug. If you have more than 127 plugins, at some point the game starts going goofy. It's not a memory limit, as you can combine existing mods using the same amount of memory resources and once you get below 128 mods it will work. It doesn't affect all mods, and I have no idea exactly what it does and doesn't affect, so it is easily possible to have more than 127 mods and still have the game work. But at some point it usually breaks for people. I personally have had the game go squirrelly at 132 mods in one configuration and around 160 in a different configuration. The fact that the game starts to go squirrelly at some number over 127 strongly indicates that this is a signed vs unsigned char bug somewhere in the game engine code.

 

The game leaks memory. This is usually the main problem responsible for the game getting slower and slower and often finally crashing if you play it for an extended period of time. I can't confirm it, but I read somewhere that it is actually the game engine's texture caching system that is primarily responsible for the leaks. This is consistent with the fact that setting the graphics to a lower quality will dramatically reduce the memory leakage.

 

The game's physics engine has some definite bugs in it. Dead creatures will often bounce and fly all over the place or will get stretched to crazy sizes instead of properly ragdolling. Kicked objects can also bounce or fly in extremely unrealistic ways.

 

GameDaysPassed doesn't count properly. I believe there is a mod that fixes this.

 

This is probably more of a GECK bug than an engine bug, but the GECK will not prevent you from making a mod that is larger than 16 MB and will not give you any indication that anything is wrong if any object, actor, reference, etc. is above the 16 MB limit. The game engine will also happily load this mod but will crash as soon as it finds this entry above the 16 MB limit (which is why this is also a game engine bug). The GECK will also crash if you try to load the mod in the GECK to fix it. Landscapes, landscape texturing, navmeshes and dialog are not affected and can be placed above the 16 MB boundary without issues. If you are creating a large mod (one with multiple worldspaces, for example) you need to run the GECK in networked developer mode instead of the single user mode that most people run it in. Then, when you check in files, the GECK will order the things that are added so that all objects/actors/references/etc are well below the 16 MB boundary. This bug results from the fact that the game engine uses the upper 8 bits of each ID or reference to indicate which mod the reference comes from and the lower 24 bits to specify the offset into the file. 16 MB is the largest value that you can specify with 24 bits, so once you get past 16 MB the reference offset rolls over and breaks. The game's 255 mod limit comes from the upper 8 bits rolling over once you get past 255. There is no bounds checking in either the GECK or the game engine for the 16 MB offset bug.

[RoyBatterian]

Plugin limit is complex and varies depending on machine/load order, it's not a simple signed/unsigned bug or it would be fixed by now. Fallout 3 has it too btw, I've been able to trigger it.

 

The memory leak is the audio system primarily, this is fixed if you use the vorbis libraries that Kane Wright posted, they are included with TTW to fix the issue. It is a known issue with the version of the libraries that Bethesda used.

 

Havok problems are due to scaling, and that Havok uses metric and bethesda used imperial and they didn't account for it. This issue exists in the engine to this day (creation).

 

I don't know what you mean by 16MB limit, TTW, Frontier and DLC are beyond 16MB. They are ESMs as they should be, ESPs are not intended for production, and never were. ESPs could also be the cause of the plugin limit bug, I have not tested this yet, but it's possible its a memory leak as all records are treated differently and there is no ONAM in ESPs (creation engine changed this).

 

@Dubious

 

You may link anything and everything I do without asking permission.

 

That's a reference to Have a Cigar by Pink Floyd :)

[madmongo]

I'm a software engineer. The game mod limit breaks on a power of 2. You never have a problem below 128 mods. It's obviously not a problem every place where they use the mod number since problems don't always show up immediately, but I'm a software engineer and you are going to have a very difficult time convincing me that this isn't a signed/unsigned char bug. I know the bug is in Fallout 3. It might be in Oblivion. I don't remember. I think they finally fixed it in Skyrim.

 

There may very well be a leak in the audio system as well, but claiming that this is the primary cause of it does not match up with the symptoms where changing the graphics detail, and nothing else, will make the problem go away, or at least be very significantly reduced. If the leak was only in the audio, changing graphics detail wouldn't have any effect on it whatsoever.

 

I don't have any hard evidence one way or the other, but I personally find it a bit hard to believe that the numerous problems with the game's physics engine are only due to the issue of scaling. I can't prove it, but I strongly suspect that there are quite a few more bugs than that involved.

 

Your phrase "ESPs are not intended for production, and never were" doesn't match up with how the GECK is packaged for modders, how 99.9 percent of modders set it up, and how the instructions say to set it up. Instructions on how to set it up in developer mode (networked) so that you can properly create an ESM are sparse and what little documentation exists for it is incorrect, at least for FNV.

 

Here is a very simple way to recreate the 16 MB bug. Follow all of the instructions online for how to set up your GECK. It's bascially going to tell you to create an ESP (nowhere do the instructions say that ESPs aren't to be used for mods). Create a worldspace. Create a heightmap for that worldspace. Your mod will now be about 13 MB or so. Now go into the region editor and create an object region. Copy one of the tree regions so that you'll make a bunch of trees. Add in a bunch of trees. As soon as you add in enough trees that you cross the 16 MB boundary, you have forever broken your mod. The GECK can't reload it to fix it (it crashes). The game will crash if the mod is active.

 

You and I both know from experience that you have to set the GECK up in networked developer mode and create an ESM for any large-scale mod. That is not common knowledge, and the fact that you need to do this or you will run into the 16 MB bug is, as far as I can tell, not documented anywhere.

 

It's not just creating an ESM. If you create an ESM using the GECK in normal user mode (not networked) using the GECK power-up so that you can edit an esm and you go through the same steps as outlined above, you'll end up hitting the 16 MB bug and you'll brick your mod. You need to check in files in developer mode. When the GECK checks things in to the master, it re-orders records as necessary to keep IDs and references well below the 16 MB boundary. That check-in is the key to avoiding the 16 MB bug.

[RoyBatterian]

Im a programmer too, and it gets weird with more than 90, and will work anywhere between there and 142 on my machine (it varies) I can load 255 if the mods have very little in them. So no, that's not correct. The bug is not in Oblivion. From debugging it appears that the memory allocator for the plugins doesn't function correctly.

 

ESP are for working with Version Control and merged into master, the game treats ESPs differently, this is known and has been reverse engineered on several of the engines now by experts reverse engineers/programmers. They are not intended for production, Bethesda does not ship ESPs, they use more memory and all references are treated as persistent which wastes memory.

 

Version control has little to do with it. The tool is crippled anyways, this is what we have been trying to address.

 

Cannot reproduce 16MB bug with ESM, didn't test with ESP. I have no such issues, we have created very large mods with GECK now with no such limit, the Frontier is larger than NV is, and our upcoming DLC for TTW is also > 16MB with 0 issues. Then again we don't create stuff with the heightmap editor as it is limited to 64x64 and that is too small.

[PlayerI3]

Roy, since you try to document all engine bugs,

I noticed that the more ammo I have in my inventory , the more game lags and the lower my framerate is.

The difference is the most noticeable with uncapped framerate, when I add all ammo types from a pre-made .txt file using "bat" console command.

For example:

0 rounds and 0 items - 97 FPS

1000 rounds of each ammo type - 57 FPS

2000 rounds of each ammo type - 42 FPS

3000 rounds of each ammo type - 32 FPS

4000 rounds of each ammo type - 27 FPS

5000 rounds of each ammo type - 23 FPS

and so on...

Here is the link to .txt file, you can test it yourself if you want. Just put it inside New Vegas folder and type "bat AllAmmo" in console.

Edited June 11, 2019 by youngyone01

[PlayerI3]

Player's falling speed (maybe moving speed as well) is not being remembered / restored when saving / loading the game.

So it doesn't matter from what height player is falling down, in order to survive they can save right before landing and immediately load that save. Done. Player will still be alive without taking any damage.

[c6dev]

https://www.nexusmods.com/newvegas/mods/67167

Fixed the Disintegrations bug, hopefully jazz will merge it

[axonis]

Item weight & value at the HUD is not shown for certain types of items (eg. skill books or ammo) even though the values are passed at the UI.

 

It's possible to patch this by scripting, but it requires registering an event by OnCrosshairOn which can fail to fire up when targeting such items on certain circumstances.

 

Ideally the engine can be patch to remove whatever block is there for any item that has a weight or a value.