Story Manager Settings

[cooltrickle]

I was just tweaking the shadow settings in the SkyrimPrefs.ini, when I came across these two entries:

 

iStoryManagerLoggingEvent=-1

bEnableStoryManagerLogging=0

 

I assume it's referring to this:

 

“The story manager is looking at everything you do and then making things happen. So if you set a chicken on fire, or you drop an item, or pickpocket somebody or if you kill a dragon in town and absorb its soul, how people react all goes through the story manager.” explained Bethesda's Todd Howard in an interview with 'The Edge' magazine.

 

“We track how ever [sic] person and faction feels about you, and their own limit for how many illegal things they will do. You can get followers and command them, and they may like you enough that no matter who’s attacking you they will join in, even if it’s the guards.”

 

So, why is it switched off? Can anyone else check the .ini files just to confirm this? Maybe it's just me for some reason. I suppose changing both values to 1 will enable Story Manager, right? I'm not really sure what Logging Event means.

[marxismoney]

I've been wondering about these two buggers since I noticed them, too. Glad someone asked about them cuz now I have a chance to share my insights (i.e., my guesses).

 

It's not just you, everyone's INIs are preset that way.

 

I imagine your guess is correct - this is likely a debug info-dumping tool the developers used (and will use, read on) to analyze/debug the "Radiant Story" system that you quoted Howard describing. I'm guessing you meant that "1" will enable the Story Manager's logging functions and just left out the "logging," but just to be clear, these can't possibly turn on and off the Story Manager itself - the game wouldn't work without it since it's responsible for updating and advancement through quests and probably a whole lot more we don't have details about. However, that doesn't make these lines any less interesting. If we could get them working and churning out Story Manager debug logs, modders could probably learn a good deal about how the Story Manager works.

 

Most serious debugging tools are permanently disabled or removed from the hard-code of the game's executable prior to launch, unless they pose no threat of screwing up a game (such as functions that simply display information, or in this case, log it somewhere), in which case why waste precious near-launch time or resources rebuilding code and binaries just to remove something harmless? However, if it is indeed some kind of Radiant Story-tracking debug info tool, there may have been a reason to leave it in rather than just no reason to take it out - that's my bet, considering it seems prepared to be activated, unlike the slew of other debug info-tracking functions which refuse to activate or even acknowledge their own existence (try plugging "help debug 0" into the console, PageUp to the commands, then try some out and be amazed as they feign nonexistence).

 

I'm going to hazard a deduction that suggests a more important & revealing raison d'etre than not wasting compiling time: That the reason these commands got their very own toggles in the INIs is because INIs can be updated much more easily than hard-coded EXEs and the devs knew they were going to need to switch on (and perhaps off, and on again, etc) these functions in future updates. Specifically, I bet they'll want access to the streamlined plot-tracking information it likely provides when it comes time to integrate the expansions/DLCs & their characters/story-lines into each individual player's unique Radiant Story circumstances. Because Radiant Story - assuming Bethesda's portrayal of it isn't exaggerated - must allow for an incredible amount of diversity in situations & outcomes between copies of the game (from a coding standpoint, i mean, i'm not gushing, i swear - think of the variables!), the integration of new storylines that are affected by existing ones or the continuation of existing storylines will be no simple feat, and the game itself would need to be prepared at launch for this task; each copy of the game will need to address, on its own, the contingencies for the myriad "what ifs" unique to its own player's choices & actions relating to the new content's integration. So it makes perfect sense, in that regard, to proactively leave this debugger at the ready to be enabled when the expansions are released, so that the resulting inevitable bugs and glitches (which we know and love) can be easily presented to tech support for quicker patching. Given the uniqueness of each game as I just elaborated on, Bethesda must know it will be hard to catch everything in the expansions' alpha/beta/QA phase, especially if they're going to release the first one so soon, so having a logger like this pre-loaded was probably seen as a necessity.

 

I'm fairly confident about that prediction, but now I'm gonna move into sheer speculation, because I would like to figure out what the different settings for these functions do. The second one seems pretty straightforward, we know it's a boolean (starts with a 'b'), so it must be Story Manager Logging on (1) or off (0). The other command, iStoryManagerLoggingEvent, is the puzzle. Most of the time (judging by Bethesda's INI formatting), variables that start with i have a limited set of options, each represented by a number, that control how something functions. It defaults to -1, which usually means something like 'not applicable' or 'ignore' as far as I can gather from browsing the INIs. If this function controls the triggers or filters - as is my best guess - which "events" get printed to the log, then it makes sense that it should be 'ignored' since the other command has the logging set to disabled. So, then, if it is like other "pick an option" i-variables, then there will be a setting of 0, a setting of 1, and an indefinate number of further settings after that, though usually not more than 10. The options might be filters like "record all events" or "errors only" or "NPC relationships" or "NPC deaths" or "critical dialogue choices" etc. etc. etc., who knows how many there might be since we barely even understand how the Story Manager works, much less know its intricacies.

 

I'll definitely try turning everything on, so to speak, and I'll try numbers in sequence for the 'Event' control, and I suppose it will just be a matter of locating the log. It would be nice if it just appears in the preferences folder, where the saves and the INIs are. But it's also possible that this was a feature designed to upload log data/files directly to "big brother" over in Valve-land, and copies of the information were never intended for the user, and so no log files will be put on our hard drives no matter how many settings we change.

 

But here's hoping! Let me know how your experiment goes. And even if we can't find any logs, I'd still like to hear other people's guesses on these two mystery settings.

[cooltrickle]

It's probably a debug tool as you say. I found some log files in the path: My Games\Skyrim\Logs\StoryManager, named StoryManagerLog.x.log, where x is the number of the log.

 

I've tried values 1 and 2 for the event logging but it hasn't logged anything interesting yet, just stuff like this:

 

[11/25/2011 - 09:48:58AM] StoryManager log opened (PC)

[11/25/2011 - 09:48:58AM] Started processing event 00002679: Assualt Actor Event - Victim: ,Attacker: ,Location: NULL,Crime: 0

[11/25/2011 - 09:48:58AM] -Node 'Assualt Actor Event' passed

[11/25/2011 - 09:48:58AM] --Node '' failed conditions

[11/25/2011 - 09:48:58AM] --Node '' passed

[11/25/2011 - 09:48:58AM] ---Quest 'WIAssaultRemember' failed to fill aliases

[11/25/2011 - 09:48:58AM] --Node '' passed

[11/25/2011 - 09:48:58AM] ---Node '' passed

[11/25/2011 - 09:48:58AM] ----Quest 'WIAssault02' failed conditions

[11/25/2011 - 09:48:58AM] ----Quest 'WIAssault01' failed conditions

[11/25/2011 - 09:48:58AM] Finished process event.

[11/25/2011 - 09:54:40AM] Log closed

 

Thanks for the tips. I'll make another post if anything interesting shows up in the log.