Jump to content

Finding the source of a bug


SirDanest

Recommended Posts

When I encounter a bug in new vegas, one that doesn't happen with no mods at all, I am left with the sinking feeling that it is going to mean I have to go through 150+ mods, one at a time, un-checking it, reloading new vegas and testing, quitting, un-checking another mod, reloading, etc. It is going to take FOREVER with a huge mod list. I really wish there was a faster way to find the source of a bug. This is hellish.

Link to comment
Share on other sites

Much depends upon the nature of the "bug". Some will generate log files, while others never get the chance. Those generated by Fallout itself tend to be pretty rudimentary and deal primarily with launching the game. Those added by mods will only generate entries up to the point the game crashes and seldom get the chance to write that they are failing fatally.

 

Anytime the game "Crashes to the Desktop" (CTD) it's typically going to generate an error message in the Windows Eventlog. Please see the "Windows Error Messages" section of the wiki "How to read most Bethesda game error logs" article.

Logs generated by the game itself (not Windows) are found in the game folder, where the "FalloutNV.EXE" file is located.

"NVAC - New Vegas AntiCrash" error log entries are described on the "Description" page. This an important log for "in-game" errors. Some are intended to assist mod authors; while others are there to help "you, the player" trying to resolve a problem. You are interested in the entries which are NOT automatically handled successfully by NVAC, and records which do NOT begin with "00" (which are in the vanilla game files and not typically going to be fixable by yourself). Key entries to look for are the following "letter codes":
* "e" entries are Exceptions handled specifically by NVAC's targeted code changes
* "h" entries are exceptions identified Heuristically by NVAC's "global" exception handler, sometimes handled unsuccessfully.
* "m" entries are "Middle of nowhere" exceptions, sometimes handled unsuccessfully.
* "ñ" entries are Null instruction exceptions, sometimes handled unsuccessfully.
* "n" entries are Null pointer call exceptions, sometimes handled unsuccessfully.
* "o" entries are stack Overflow exceptions, usually handled unsuccessfully.
* "q" entries are program self-termination information; these are effectively crashes.
* "u" entries are Unhandled exceptions reported from the Unhandled Exception Filter; these are crashes (and the NVAC author wants to hear about them).
* "v" entries are unhandled exceptions reported by NVAC's "global" exception handler; these are crashes.
* "w" entries are informative, relaying exception information as it passes through New Vegas's final exception handler.
* "x" entries are critical errors in Windows exception data; these entries should never occur.
* ":" entries are output from OutputDebugString calls.
* ";" entries are output from the game's own error checking.
Other codes may be of interest, but are not things the player is likely to be able to resolve, They are useful for informing the author of the mod to aid them in fixing their plugin. In particular, pass along the:
* "_" entries are informative, relaying that NVAC was loaded and the base address of various DLLs
* "!" entries are informative, relaying human-readable text for the user entries.
Any error codes found in the log but not listed on the mod "Description" page should be reported to the NVAC comments page.

'Expression Error: SYNTAX' is not uncommon, even in vanilla without any mods loaded. These are basically "typos". Such errors are reported by NVAC but ignored. Those lines of script code do not get executed, but also (when caught by NVAC) are not "fatal" to the game. They are the sort of thing mods like "Yukichigai Unofficial Patch - YUP", "JIP LN NVSE", "JohnnyGuitar NVSE", "lStewieAl's Tweaks" etc. are designed to fix or supplement if possible.

* If you have "NVSE logging" disabled (see the 'Checklist Item #4' entry in the wiki "Fallout NV Mod Conflict Troubleshooting" guide), try to enable it only as long as actually needed. (Reading from or writing to disk for any reason is the slowest thing the game does.)

 

If you do get forced to determine which plugin by disabling them, use the procedure described in 'Mod Conflict Isolation' section of the wiki "Fallout NV Mod Conflict Troubleshooting" article. It is much faster than just working through the list one-by-one.

 

-Dubious-

Link to comment
Share on other sites

Well, for one, the securitrons don't shoot; they punch. I don't have any weapons mods or AI mods. I know for sure I didn't download a "make securitrons punch" mod, or any kind of securitron mod or melee mod at all. So it's a mod conflict that shouldn't be there, something is modding securitrons or their AI/weapons that was not meant to be modding them. The question is, which mod is doing something to securitrons that shouldn't be touching them at all? Everyone else seems to shoot just fine.

Usually when something like this happens I eventually get an answer from someone online, but for once I want to just figure out how to solve these problems myself. Someone else almost always knows what's causing this or that glitch... how did they know? When I figure that out, I won't have to keep coming back to ask every time something unexplained happens. And when running 150+ mods, there's almost always something unexplained happening. It'll be good to figure out how to hunt these bugs myself. It's too tedious to disable a mod, reload, quit, disable another mod, reload, quit, on and on. There has to be another way.

Link to comment
Share on other sites

One way to narrow the list of potential suspects is to load everything into FNVEdit and see what mods make changes to whatever is bugged, to see what is making changes to the securitrons expand FalloutNV.esm, expand the "Creature" entry, click on the various securitrons in the list and on the right hand panel you'll what if any mods are making changes to them.

 

For example in the this shot Momod is making changes.

 

oY1M7Vj.png

Link to comment
Share on other sites

"Bug hunting" IS tedious work. Which is why so many still remain. People search online hoping to find someone else has already identified a particular conflict to avoid exactly the sort of tedium you describe. But if even if they do, typically the most that happens is they dump one of the conflicting mods instead of tracking down the exact cause of the conflict within the plugins. (Hopefully they report the issue to an author who will followup, but if they have moved on to other games or the mod is too old, that is unlikely. And if the problem is not described clearly enough to reproduce reliably (down to the conflicting plugins), most authors can't do anything anyway.)

 

First step is always determining which plugins are in conflict. Sometimes the nature of the conflict is obvious. Case in point: "securitrons are punching" means something is affecting securitrons. But that is still pretty broad a category; can we narrow it down a bit further because it is affecting the nature of their combat AI: are they punching because they have no "ranged weapons" available ("melee" is the default in that case), no ammo for those weapons; or because their combat script has been altered so they "prefer" unarmed/melee combat? Were they singled out specifically (e.g. a mod specific to securitrons) or were they an accidental side-effect of some other intentional change (e.g. a change to a "leveled list" of ammo types so their particular ammo is no longer available)?

 

With some idea as to possible causes you can narrow down the list of potential plugins that are known to make such changes, but you may be able to further narrow the list further by loading the entire "load order" into FNVEdit and seeing which plugins are affecting a record in common, such as which modify the "securitron" record. But you have to have some idea of which record is likely to be affected to tell which of multiple record types are of interest to your situation.

 

Knowledge of how mods work in general is necessary to be able to determine if any particular plugin is unlikely to be making a particular change in a specific instance. Not everything is obvious in a single record category. "Scripts" do a lot of the heavy lifting and you have to be able to examine and read them in the GECK to determine what is going on.

 

"Bug hunters" usually have programming experience and at least some familiarity with mod creation in the game in question. Most with that skill set are more interested in creating their own mods than in chasing after bugs in others. You have to be fairly heavily invested in a particular mod or problem to persevere through the tedium to resolve a bug.

 

-Dubious-

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...