It seems to be able to happen with any ref, persistant or not. I've seen it affect everything up to and including modder added collision planes.

One fix that usually works is to tell the player to load from the main menu, but players often don't bother to listen to advice or even RTFM, so you get 30 posts on the Nexus calling you a noob and telling you your mod is poo from people who can't read...

So, hmm...I guess until we can fix the problem itself, maybe a function to trap pressing the quickload key and disable it and pop up a message that says 'hey Einstein, you were told not to quickload...use the menu' hehe.

Thank you, thank you, thank you! :wub:
I wasn't expecting the above commands anytime soon...
Now I can really get going on my inventory/container mod for FO3. :brokencomputer:

With serialization implemented in the Plugin API, I can port the log functions as well Would you guys be prioritizing string and array vars for a 1.2 release, or will that be released in a later build ?

Just in case you didn't know, there's already a http://geck.gamesas.com/index.php/Log function available. I don't know how fast it is though.

Cipscis

You had me going there I was talking about http://cs.elderscrolls.com/constwiki/index.php/Category:ConScribe, not the math function.

Oh, that log! I really should have thought of that, lol.

Cipscis

Nice, I had no idea this existed!

For some reason, FOOK2 [DIK] DLC Improvement Kit.ESM (internal v1.1) won't load in the GECK if I open it with 1.2b's loader. I thought I'd FOOK'd something up, but it opens fine with previous versions or without using my FOSE GECK shortcut. I tried stripping all compiled scripts from a plugin, then loading it to recompile and it still crashes. Any ideas?

Note: Everything else seems to load w/o issue.

Uh oh, this is sounding familiar in an unsettling way. Within the last 24 hours I've had the sudden onset of a bug in my ongoing game where I can no longer save my progress in a new save without crashing.

Fallout 3 loads, and I can select a saved game to play via choosing 'Continue' or 'Load' from the main menu, and the game starts fine. I can then play for as long as I like but will have a crash upon attempting to save the game again. I get as far as actually choosing to make a new save through the menu and it crashes a moment after attempting.

The familiar part from above is that I found I could get around this crashing problem by loading up the game, choosing to 'continue' or 'load' a specific saved game, and then after the game started if I immediately hit ESC to the menu and loaded the same or different save I would be able to save the game again. Is this possible because of these shortcuts and such you mentioned in the quote above?

The last change I've made to my game was upgrading to the latest FOSE beta so that I could try the Fallout Stutter Remover. Is it at all possible that one or both of these updates could have caused this strange saving bug to appear? It was days and 20 or so hours of gameplay that my next most recent update of adding the large Zeta Mothership Crew mod happened. I'm not sure why the save bug wouldn't have appeared in the hundreds of saves during all of that gameplay though.

As far as I know, the "crash on save" bug occurs when Fallout 3 tries to write some form of corrupted data to a save file. This tends to happen occasionally on saves that have had a lot of time put into them, and the only way to fix it is usually to load a previous save. When you load your save from the in-game menu, Fallout 3 doesn't load all of the data that is in the file, so when you save after that some of the same data isn't present. In your case, you're lucky enough that some of that data was what was causing your crash on save, although it's also likely that there is other data missing from your save.

Cipscis

Okay, interesting. I removed FOSE 1.2 beta 1 and Fallout Stutter Remover beta and went back to FOSE 1.1 beta9 went back through my saved games to the last one before I upgraded and the saving bug appears to be gone.

EDIT: Argh, so then I upgraded back to FOSE 1.2 beta 1 with that previous save and the save bug is still gone. So then I added back Fallout Stutter Remover as well, and the save crash bug is again still gone.

I'm completely mystified. If I try and load up any of the saves from the period following the initial upgrade of FOSE and addition of FSR, the crashes on saving still happen. So what happened in that two hours of gameplay from the last working save to all these other unusable saves?

I'm fairly oblivious to how things actually happen in the game with scripts firing off and what not. Is it possible that a script from a mod could lay dormant for an extended period of time and then cause this bug to ruin any save following visiting a specific place or doing a specific thing?

Hmm, so this may just be something I need to pay attention to moving forward or I guess finally face that I need to start a new game from Vault 101 or move on from FO3? I'm still playing on the same character/save progression (currently at 464 hours according to the last working save) from when I first got the game after launch, so I can only imagine how much through the ringer my ongoing 'saved game' has been after each one of the patches, each version of MMM, and numerous other mod additions and deletions over that time. It's got to be a mess.

The corruption that causes the "crash on save" bug seems to be pretty random. To be honest, I think it's probably just a coincidence that this problem cropped up for you at the same time as you updated FOSE and installed Fallout Stutter Remover.

Unless you notice any odd bugs that can't be explained by something else, there shouldn't be any need to start a new game. After all, so long as you're enjoying playing it you're doing nothing wrong.

Cipscis

Thanks so much for your response Cipscis! I really appreciate your feedback and guidance. I'm going to stick with my current game and ride that story as long as I can. I've always assumed I'd eventually hit a wall where it would just stop working. The file sizes of the saves have steadily gotten bigger (up to 30.2 megabytes each now) as the gameplay hours have gone up. Not sure if that is expected or something else?

I'm going to go back and try and retrace my steps of those two hours of gameplay since the last working save to see if I can recreate the 'crash on save' bug to see if it was just bad luck or maybe a specific modded area of the game that caused the trouble.

Added to the req list, need to find where that data is stored on the TESObjectWEAP.


If you can set up a 100% repro case with an empty mod list (other than the mod used to repro the bug) I can try to fix it.


I'm not a big fan of being that invasive.


That first needs to be finalized on the OBSE side, then it'll get ported over and show up in 2.0.


Interesting. Can you send me a PM with a link to the esm/dependencies?

edit: screwed up quote tags

If you really want to have something that does this, once we have the ability to detect when disabled keys are pressed it shouldn't be at all difficult. I can't see people downloading something that just reminds them not to quickload though. In my opinion the best solution, until we can fix the problem in some way, is to make it common knowledge that saves should only be loaded from the main menu.

Cipscis

Thanks for deducing what was going on and linking me to the http://www.gamesas.com/bgsforums/index.php?s=&showtopic=1069833&view=findpost&p=15551113 which I had ashamedly missed. Everything loads fine now with 1.2b.

*runs off to play with shiny new functions*

Thanks Ian. My next request

SetNPCUsesAmmo (Or something similair.)

This would help make a non-intrusive more realistic ammo mod.

Harmy52

Just a quick question, do we have an equivalent of MessageBoxEX at the moment? SetUIString doesn't seem to take variables.

^^^I don't think that's done on an actor basis. You can just scan nearby NPCs every 10-20 seconds and set all their weapons to have NPCs Use Ammo checked.

Two requests:

GetPassword/SetPassword (GetOpenKey/SetOpenKey doesn't work on terminals)
TransferItem or MoveItem (Where you could move one item from a container/NPC/Creature to another and have that item keep it's current condition)

This would be marvellous, but I'm not sure it's possible. I guess the FOSE guys will let us know if it is actually do-able...
There's no such function in OBSE as far as I know, unless it was introduced in recent versions.

You can achieve the same thing in a round-about sort of way, and this is the core of my Oblivion mod Speedy Deposit...
http://geck.gamesas.com/index.php/RemoveAllItems will move anything that's not flagged as a quest item, and retain all properties of the items it moves, so...
Flag everything except what you want to move as a quest item (using the http://www.gamesas.com/bgsforums/index.php?s=&showtopic=1044512&view=findpost&p=15548121 function),
then ".removeAllItems 1" to the target container/NPC/Creature will move the rest as you want, retaining properties and ownership
Then flag the non-quest items that are left behind back to normal...
Of course, first you have to take note of what was originally a quest item, so you leave those alone and not unflag them as quest items after the move.

Phew! It's clunky, but it works.

If there was a MoveItem function, the above would be completely unnecessary, so I'll definitely add my vote for such a function if possible...


[edit: just had a look through the latest OBSE docs - there's no function like this, so since it's essentially the same engine, it looks like it's not possible.
I know various people including me asked for some sort of function like this in OBSE from time to time.]

Is there a function to get the level of light you're in? I figured it might be possible to use the data that the engine uses during sneak calculations when seeing how dark or bright the ground is as a workaround instead of trying to actually see how much light is really on the player. Anyways, keep up the amazing work guys!

The best way to do this would be to use a script to individually set each of the game's base weapon objects to "NPCs Use Ammo". Because if you open up a gun or grenade weapon in the GECK you'll see on the upper left area of the window that there is a flag for "NPCs Use Ammo" instead of trying to apply that to individual NPCs, which would be a lot more cumbersome, methinks.

As to providing a mod/save that illustrates the bug problem "100% repeatable", I don't think thats possible as the amount and type of data skipped by an F9 reload seems to vary. One session one type of thing will show up, the next session another type.

If you want to take the time to play with it a bit, however, grab a copy of the beta for Path of the Gunslinger that is currently up on the Nexus and get the COC codes with the GECK then COC yourself to the Triton Facility and the caverns next to it.

I can't give you the CoC codes right now as our website is in transition and I had ALL my misc info stored over there while I reformated my computer...and the database is currently still offline for the website

If you look in the GECK, the caverns should be easy to find. I'll try to post later with the COC codes once I get the GECK running again (have to reinstall it as well...keep forgetting heh).

What you are, ideally looking for in the caverns is a ghost that appears as you come down the first sloped tunnel inside. The path to the left leads to a room with three coffins, which he should lead you to, the path to the right leads to an open area with glowing mutants.

The save issue in this instance shows up most often as the ghost disappearing, or not walking his paths, the mutants vanishing (at least some of them), and the traps in the vicinity mysteriously becoming sprung or vanishing altogether.

-------
EDIT: I wonder if it would be possible to make a script that modders could invoke on session startup that remaps the F9 key to open the LOAD menu directly when pressed, instead of doing its normal 'quickload' ?

The game must maintain which items are in a container and their condition, so the data is there somewhere. Also note, that it is possible - in the ui - to move a particular item. Thus, it is possible. The problem here is how difficult it is, particularly compared to the gain from having such a function.


Last I checked, FOSE does not support key-pressed detection of disabled keys or controls. So, disabling the quickload key would not be the correct approach.