Well then that is misinformation that was foisted at me.

Where did I hear that???

I'm guessing on the CSE thread. There was a bug in OBSE (small thing with inter-plugin message passing) that caused some plugins to break when installed together. Since the problem tended to affect people with lots of OBSE plugins, there was speculation early-on about an upper limit on the number you could safely have. I believe this issue has long since been fixed.

Had similar experience as Walker, though mine is with a custom race which had permanent water breathing. Took out OSR, loaded a very early save that didn't have SDR beta saved, everything was fine. Save that and reloaded, still ok. Threw in OSR and loaded that save, water breathing was gone. Very odd.

I don't think it's that odd. If you read the description of OSR on the TES Nexus site, especially sections 7.3 and 7.4, the author admits that some folks experience instability with OSR using certain settings. Of particular note to me was the heap allocation and descriptions of "skipping" certain functions. You may get a smoother video experience, but you might be sacrificing playable features depending on what other mods or plugons are installed.

SDR requires two OBSE .dlls to function, and these .dlls create new game settings and actor values, amd it plays with the memory heap to do so.. RBP has it's own system of giving abilities to characters. Combine those three things with OSR, and perhaps that's enough to make it wonky.

I see. Don't suppose there's any way to work out the compatibility issues? At the moment I'd keep wondering what else is broken. It's totally ok if there's no way of course, not like I can give up the awesomeness of SDR.

I don't think this is a garden variety instability issue. There is something in the combination of OSR+SDR+AddActorValues that is preventing the correct loading of the player's base stats.

@Omletted and Walker - what are your OSR settings? Specifically, are you using any non-default values?

Like I said before, I changed only three settings:

bAllowSlowMotion = 0 (default 1)
MaximumFPS = 0 (default 30)
iHeapAlgorithm = 3 (default 5)

When I renamed my SDR.ini and let the game generate a new one, everything worked fine - even after changing the settings back, the bug didn't reoccur. I'm using iHeap 5 now, BTW.

Missed the part about regenerating OSR ini, yeah that did seem to do the trick, haven't set back all the changes I made though. Changed quite a few things from the default, have to do a diff to tell you guys what exactly. >_> Still wondering why that happened and what else might be broken or will break again.

Edit: Eh, found it. Seems simply enabling heap replacement triggers the issue, saebel hit the mark. Using "iHeapAlgorithm = 6", will have to experiment and see whether the other algorithms are the same.

Walker, you didn't mention setting bReplaceHeap = 1, probably why you didn't get the issue again.

Edit2: Seems only 1 (FastMM4) works fine for me, the rest all had the issue.

Back on topic a little, I've been seeing messages like these pop up in the console every now and then:

Nothing equipped in that slot.GetInvObj 0 >> SL - Ruined Elven Shield 43011bc4 (TESObjectARMO@@)GetEquippedObject 16 >> C - Dwemer Shortsword (00035dd3)

Doesn't always happen so I'm having difficulty tracking down where it's from, wondering if it's something from SDR.

Those don't look like any of my debug messages.

So to be clear on the OSR settings so that I cam document it and supply recommendations, if they choose heap replacement (1), they should only go with the first replacement option (1), and none of the others? Or they should just have heap replacement disabled (0)?

Thanks for helping to figure this out!

I don't know that you can do that. Heap replacement success seems to vary a lot from machine to machine. I use option 5 with OSR and haven't had any issues. I don't think you can recommend disabling heap replacement, because that's where the major benefit of using OSR kicks in. It's probably more a case of if you have issues, try another algorithm option.

BTW, for WalkerInShadows' issue, I suspect the problem was this line, assuming it's not a typo:
MaximumFPS = 0 (default 30)

I can see that causing strange behavior across the board, as it's trying to limit the frame rate to 0 fps. Add to that, you're not letting it put the game in slow motion and it may not be able to deal with those settings. Unexpected values tend to cause strange software issues, not always repeatable too.

Ok, thanks for the confirmation. Guess I'll have to binary it and hope I hit the culprit. o.o

Replacement option 1 worked for me, might not work for others. You could recommend people try that first if they're having issues. Performance of that algorithm is another matter... And yeah, as dreamed1 says OSR's major benefit is the heap replacement so probably shouldn't disable it.

Concur - After following the OSR threads for quite a while getting things perfect for both our desktop and laptop, settings for OSR are as varied as it has users - Even users with the same machine specifications would crash on one machine where the other had great success with the same heap replacement and settings. Suggesting change there for any particular users setup, may be a case of the user literally having to choose between having OSR installed or SDR.

Okay, well OSR is on my list of things to try out, so at least I know what to look for, and it's only in combination with RBP that the issue seems to arise as far as I can tell (and RPB is in my load order as well), so at least I can recommend some options for folks to try.

Sorry for bringing this up again, while it doesn't seem to affect anything it's bugging me. Did some more digging and found a reference in OBSE's Commands_Inventory.cpp which matched the messages I had:

There's also a section that had this exact message, "Nothing equipped in that slot." Only OBSE dll that I can think of that might be related is SDR. Any chance you can look into it, saebel?

What's 6? My version only has 1, 2, 3, and 5.

Actually, I never had it set to 1 in the first place. I just tried it, though, and nothing happened. I even tried iHeapAlgorithm with 3 and 5, and neither caused problems.

Personally, I'd say that if people run into the problem, just have them regenerate the ini - that seems to have worked for us.

The readme says: "Some people don't want their framerate limited at all. You can turn off FPS limiting by setting this to 0."

I used to have slow-mo, but then my combat sequences would look like something from The Matrix, so I stopped. Like I said, I've made huge upgrades since then, so I haven't felt the need to use it.

6 is ThreadHeap3, can't remember which version it was introduced. I'm using 4.1.24. You're saying your version doesn't have issues with heap replacement? Odd. o.o Regenerating only worked for me because it isn't enabled by default, turning it on would trigger the issue.

I'm using 4.1.0. I suppose I should upgrade.

Rolled back to the last stable version 3.1 and loaded a save game that was using that. Discovered my chameleon is acting weird, I get the chameleon effect even when I'd removed the Ring of Khajiit which is the only item I have that confers it. Uninstalled SDR but it's still broken though starting a new character works fine. Don't know if this is due to SDR. Is there any way to console the effect off?

Make sure you have no active Chameleon effects, then:

player.setav chameleon 0

That didn't work, don't know why. o.o Getav show it is 0, game somehow doesn't think it is. Guess I'll have to live with it or scrap the character.

It captured your character's alpha value as the base default, which left you as semi-transparent. With SDR disabled, and with all chameleon effects turned off, and not in sneak mode, go into console mode and type in the following:
player.setactoralpha 1

Then save the game, exit oblivion, reactivate SDR, and you should be fine.

hope that helps.

Note to self: make sure to set player's alpha value to 1 when token is first initialized.

p.s., I haven't had time to check on the object code issues you mentioned earlier. I lost my internet connection for awhile and just got it restored yesterday, so I'm a wee bit behind. The commands.cpp is a default OBSE feature that could be incorporated into any given OBSE plug-in, so it may not be just SDR. But I'll double check it regardless.

I looked, and none of my scripts use "GetInvObj". I have only two scripts that use "GetEquippedObject", the first only calls it if the object is already there (a torch), and the second (checking for a weapon) returns out early if there is a null reference (no weapon equipped). Neither of them call on debug messages from the OBSE commands. I really don't think it's my mod.

Sorry.

That worked, thanks!

As for the console message thing, don't worry about it and thanks for looking. It doesn't seem to affect anything, was just bugging me where it came from and whether I could turn it off or not. I don't have any other mods that would need to check through inventory like that so it's odd.

Hey all,

I'm on the verge of releasing 4.0.0. I'm just double checking the documentation and scripts. Any requests or issues before I make it public?

Yes, you join gamesas and remind them how to program a PC version of their games , after experiencing Skyrim I get the feeling there has been an element or two of skill fade over the years. (Not to put you off trying it, it is really good but as usual quite a few bugs, keymapping and mouse control in particular needs some attention before its playable)

Anyway going off topic here ... Very much looking forward to this update.