Your movement options are excellent but they conflict with Realistic Fatigue, which I'm pretty much tied to. I set iSDRsMovementRevamped to 0 but it looks like running fatigue is still in effect (as in too tired to run). Shouldn't iSDRsMovementRevamped 0 also disable the running fatigue option without needing to set iSDRsRunFatigueOption to 0? In other words, shouldn't iSDRsRunFatigueOption be a subset of iSDRsMovementRevamped?

FWIW, RH doesn't just limit your movement when you're fatigued - you actually collapse, or at least risk collapsing. I think your method makes way more sense.

EDIT: Actually, it doesn't look like there's any way to disable the running fatigue option. Even with iSDRsRunFatigueOption set to 0, forced walk still happens.

Well, the fatigue options are a subset of movement revamped. So it shouldn't be doing that. Perhaps something else is happening?
Here's the chunk of code:

; 	movement revamped	if GetGS iSDRsMovementRevamped; 		updates movement rates		SetNumericGameSetting fMoveCharWalkMin sdrQ.fSDRsMoveCharWalkMin		SetNumericGameSetting fMoveCharWalkMax sdrQ.fSDRsMoveCharWalkMax		SetNumericGameSetting fMoveRunMult sdrQ.fSDRsRunMoveMult		SetNumericGameSetting fMoveRunAthleticsMult sdrQ.fSDRsRunMoveMultAthletics		SetNumericGameSetting fMoveSneakMult sdrQ.fSDRsMoveSneakMult		if GetGS iSDRsRunFatigueOption			SetNumericGameSetting fFatigueReturnBase sdrQ.fSDRsFatigueReturnBase			SetNumericGameSetting fFatigueReturnMult sdrQ.fSDRsFatigueReturnMult			SetNumericGameSetting fFatigueRunBase sdrQ.fSDRsFatigueRunBase			SetNumericGameSetting fFatigueRunMult sdrQ.fSDRsFatigueRunMult			SetNumericGameSetting fPerkAthleticsNoviceFatigueMult sdrQ.fSDRsPerkAthleticsNoviceFatigueMult			SetNumericGameSetting fPerkAthleticsApprenticeFatigueMult sdrQ.fSDRsPerkAthleticsApprenticeFatigueMult			SetNumericGameSetting fPerkAthleticsJourneymanFatigueMult sdrQ.fSDRsPerkAthleticsJourneymanFatigueMult			SetNumericGameSetting fPerkAthleticsixpertFatigueMult sdrQ.fSDRsPerkAthleticsixpertFatigueMult			SetNumericGameSetting fPerkAthleticsMasterFatigueMult sdrQ.fSDRsPerkAthleticsMasterFatigueMult		endif;		double checks combat effectiveness settings and makes sure these values do not go above 1 or below 0.		if (GetGS fSDRsSprintMultEffectiveArmorHeavy) < 0			SetNumericGameSetting fSDRsSprintMultEffectiveArmorHeavy 0		elseif (GetGS fSDRsSprintMultEffectiveArmorHeavy) > 1			SetNumericGameSetting fSDRsSprintMultEffectiveArmorHeavy 1		endif		if (GetGS fSDRsSprintMultEffectiveArmorLight) < 0			SetNumericGameSetting fSDRsSprintMultEffectiveArmorLight 0		elseif (GetGS fSDRsSprintMultEffectiveArmorLight) > 1			SetNumericGameSetting fSDRsSprintMultEffectiveArmorLight 1		endif		if (GetGS fSDRsSprintMultEffectiveBlock) < 0			SetNumericGameSetting fSDRsSprintMultEffectiveBlock 0		elseif (GetGS fSDRsSprintMultEffectiveBlock) > 1			SetNumericGameSetting fSDRsSprintMultEffectiveBlock 1		endif	else		SetNumericGameSetting iSDRsSprintOption 0		SetNumericGameSetting fSDRsRunBackwardsMult 0	endif

Here's a weird Detect Life question.

Let's say you close your eyes. Would you still see the detect life feedback? I mean, if you get feedback through walls, why not the eyelids?

If so, how would that impact someone who is sleeping but has an active detect life effect (like with a ring or something).

You could say that their brain just filters it out. Or you could argue that sleeping has no negative affect on detect life detection bonus. Or you could split the middle and say that the sleeping penalty normally applied to sight (with eyelids closed) is different than how it would impact detect life. That would mean another game setting.

I like the idea of it having a partial effect, but of the other two options I think I'd prefer zero effect.

By the logic of it applying in sleep, then actors can also use telekinesis in their sleep... I dunno, maybe they can. Cyrodiil's an odd place.

I think asleep is asleep, ring or not. Unless you have a ring of 'WakeMeUpWhenDeathApproaches'.

Well, I think the word "Detect life" doesn't necessary means a sight bonus.

You could detect life in many ways, but I like to think it allows you to sense the life force (and this explains why you can't detect undeads or vampires), something not restricted to sight, sound or sneak skill, but a combination of all 3, with sneak skill as primary factor. Also, a good Mysticism skill could help too.

Closing the eyes won't block the detect life perception (but still it will be slightly less accurate), while draining the sneak or mysticism skill could heavily reduce it.

Sleeping is a different problem. When you sleep your senses are barely working, and you can only awake because of a sudden bright light or a loud sound (or with some luck, if your dreams ends while there's a thief). Detect life is not different. At best, it could give a tiny tiny boost to the "awakening chances", but it would be barely noticeable.

Setting iSDRsRunFatigueOption to 0 does nothing, but setting both fSDRsRunFatigueLower and fSDRsRunFatigueUpper to 0 works fine. Maybe just a note in the docs for users of Realistic Fatigue.

Well, Detect life is a passive effect, while telekinesis is an active effect. I don't think you can have a telekinesis ring or anything, so using it in your sleep would be pretty difficult.

I think a game setting simplifies things. Then people can do whatever they want. I'll just go with that.

that's weird, because by the power of scripting logic, that should not be happening at all. game settings are not stored with the save game and have to be reset every single time you start a new game session. The script code you saw only kicks in when a game is restarted. I don't see why any of the sub-steps in the script kick in.

Maybe, unlike variables, as long as there is some value in the game setting it will return true, even if the value is 0! I didn't think of that before, because that sort of thing is not supposed to be happening to my knowledge. I'll tweak the script so that it specifically looks for == 1 or > 0 and see if that helps.

Tricky. I'm thinking in terms of translating what you as a character perceive when detect life is active. You can only sense a life if it is within your field of view. And the way blindness currently works if you are 100% blind, you wouldn't be able to see anything. Currently (I've been working on the formula) detect life is calculated separately from the light level calcs. The base sight adjustment is this:
SInt32 vBaseSightAdj = (((iLightingBump + dAIbehaviorAdj) * fSleepingMult) + (dDetectLifeAdj * fSleepingMultDetectLife)) * fDistanceFactor;
By separating out light from detect life, you can still see someone that is invisible.

One option is to move the detect life bonus / calculations into the miscellaneous category. However, it would almost be like recreating the entire sight formula all over again because so many elements are the same. I'm not opposed to doing it that way, but the end result would still be the exact same bonus. Although, as I think about it, it *might* actually be more efficient to do it that way, programming wise, because if there is no detect life in play, that entire portion of the calculation would be ignored, boosting performance. As it is, the sight calculation is forced to go through the various checks for it.

I agree that sleeping significantly reduces chances of detecting. The default visual sleeping mult is .1, mainly because you aren't going to notice much of anything with your eyes close other than major shifts of light. But if detect life can get through the eyelids, it deserves a different multiplier. Your senses are reduced because your are asleep, but the eyelids won't be as much of a negating factor. It's no different than seeing through walls. I've randomly chosen .3 as the default DL Sleep multiplier.

Speaking from my own experiences, I've woken up from a dead sleep due to noises and changes in light, so I think some sort of sleep factor is justifiable. The effect will just be significantly reduced.

It must be something like that because with both iSDRsMovementRevamped and iSDRsRunFatigueOption set to 0, fSDRsRunFatigueLower and fSDRsRunFatigueUpper shouldn't even be read. And yet your code is exactly how I would have written it. I've been leaving '> 0' off of virtually everything.

Here's a thought. I set up the script to only run when the game is restarted (as in exit and restart Oblivion). I'm knee deep in programming, so I can't test this. Can you check what the fatigue options are after you immediately start oblivion and load a game? If the settings are as you would expect them to be, then try saving and reloading the game you saved and double check the settings again.

According to the docs I've been reading, game setting changes are supposed to be good for the entire game session, even if you are loading saved games. But now I am wondering if that is incorrect and they have to be reloaded with every game load, not just when Oblivion starts.

All four fatigue options (iSDRsMovementRevamped, iSDRsRunFatigueOption, fSDRsRunFatigueLower, and fSDRsRunFatigueUpper) exactly match my SDR Tweaks.ini in all scenarios - new save, restored resave, new game, and new game saved.

They are 0, 0, .10, and .20 unless I change the lower and upper values to 0. (ConScribe is a great tool!)

Somehow those upper and lower values are being read and applied despite all logic.

Just to clarify, those upper lower values don't actually reduce fatigue. They force you to walk when your fatigue reaches those levels. They are used in the Player Token Script. I looked at the script, and I can confirm that it does NOT check to see if the revamped movement feature is turned on first before checking all the sub-sections. So I imagine that's the issue. I forgot to put the whole thing inside a giant if / endif.

In general, all the fatigue settings with an SDR tag are passed on to the Oblivion equivalents during start up if Revamped is flagged on. But that doesn't alter the defaults.

As soon as I can get the CSE to work again (it's crashing on me for some reason) I will fix it.

Thanks - I knew what you were doing with those upper and lower values and I'm glad you found the culprit!

EDIT: I can confirm that in sdrPlayerTS, enclosing lines 305 - 381 in a "if getGS iSDRsMovementRevamped" block fixes the problem. And >0 isn't needed, thankfully.

Excellent. I'll be sure to incorporate that fix.

In other news, after a great deal of thought, I have decided to go with Forli's suggestion and move the Detect Life aspect out of the visual factor. There is a fourth detection category which has been loosely called "Miscellaneous" for lack of a better term. It covered health and fatigue effects on the detector as well as the effects of 3rd party mods. I'm renaming the category "Meta" and moving the detect life features into that section. I think that will resolve a number of issues, both programming/performance wise and also logic-wise.

The core detection formula is:
base + visual adj + audio adj + skill adj + meta adj

Also, previously the detect life features only kicked in for the advanced formula. I am going to add an option so that the user can decide at which formula level it should kick in. Advanced will be the default. It's less complicated to program.

Thanks for the changes!

Are you using SMAA dll from SMAA injector? If so, each time before you start CSE, rename or remove temporarly d3d9.dll, or use such batch file:

@echo offecho DON'T CLOSE THIS WINDOWS - CLOSE THE CONSTRUCTION SET TO EXITecho Renaming Directx library...ren d3d9.dll d3d9.dll.1echo Starting Construction Set Extended...start obse_loader.exe -editorecho Waiting for exit...:LOOPtimeout /t 1 /nobreak > nultasklist /fi "IMAGENAME eq TESConstructionSet.exe" | find /i "TESConstructionSet.exe" > nulif errorlevel 1 goto ENDif errorlevel 0 goto LOOP:ENDren d3d9.dll.1 d3d9.dll

It was made for Alenet's SMAA - details here: http://www.nexusmods.com/oblivion/mods/44618/?

The issue is with my sdr.dll. I'be programmed something wrong and it is crashing CSE when it loads.

Update:

Fixed .dll and have updated .esm (mostly).

I'm holding off on releasing because there were tons of changes on the back end. I want to make sure that all the game settings referred to in the .esm are actually in the .dll. Plus, I still need to update all the documentation with the changes.

It's going to be awhile, so please be patient.

Update 2:

Bugger it all. Now my actor tokens are causing a huge performance hit (44%). Overall, SDR is causing about a -30 fps (about 66%), even with minimal actors in town. I ran around Cheydinhal for a bit. With SDR, 15-25 fps. Without it was 30-50 fps. (sigh)

Update 3:

My attempt and shorting load up times isn't working for some reason. So I will unfortunately still have to load up a chunk of defaults every time a save game is loaded. It only means a 30 ms delay each time you load a save game, but considering how dragging it's become, every ms counts.

Managed to optimize the Actor Token script a little bit more. But it doesn't seem to have made much difference. Overall, assuming my script profiling anolysis is correct, SDR is eating up 63% of the total amount of time spent on scripts - not including the detection formula calculations. And of that 63%, the NPC token eats up 36%. The next highest performance impacting script is only 3%.

Been running a "loop" test in Cheydinhal. I start at an inn and run around the city in a big circle. What makes this test interesting is that there aren't very many actors around. So there aren't a huge number of detection calls. And yet the performance hit is 15 FPS with SDR active.

Average FPS

SDR: 29.16

no SDR: 44.05

In addition, every time I get to a certain spot in the loop, Oblivion crashes. This does not happen with SDR inactive.

I dunno what to think or do about it. I have to go deal with RL for awhile. So I will have to come back to this later.

Not happy.

Edit: All I know is that the crash has something to do with the actor token or one of the sub-scripts that it is calling. I'm also going to do some soul searching about the detection formula itself. As cool as it would be to have everything that is in it, I think the best direction to go would be to figure which elements can be simplified.

Good luck with it

Edit: is Oblivion magic extender 'stable'?

Is the performance hit happening only with some very recent changes?

I'm not the best person to ask. Other than the SDR OBME Additions mod, I don't use anything else that uses it.


Not really. It's better than it used to be - but still not good enough as far as I'm concerned.

I have basically come to accept the fact that SDR was too complex for the Oblivion Game Engine to handle. I don't want people having to weigh which mods they want to add just because they want to keep SDR. Especially myself. Considering the formula is called 100s of times per second, and all the calculations and updates the Actor tokens perform, every bit and byte will help.

I'm working on an experimental streamlined version that keeps all the meaty stuff, but dumps all the bits that I think are probably unnecessary or aren't working quite as I thought. The other benefit is that it will significantly reduce the overwhelming complexity of choices that users currently wade through.

Speaking of which... I have taken a cursory glance and the SDR OBME addon must NOT be used with the newer v8 SDR series. FormID mayhem there, will take care of it when I update. I hope that wasn't a source of problems on your end while developing.

Nah. I looked at it ahead of time, and I knew there would be issues until after SDR was finalized and SDR OBME addon was updated. Probably best to wait until after SDR is out of beta. More major changes coming (crossing fingers they work). I've put a note regarding compatibility on the SDR Nexus page so folks (if they read it) will know it's not compatible with the 8.x.x series yet.

Just spitballing ideas here, but would moving the 'Movement Revamped' bits to a separate mod reduce the load?

Assuming that one doesn't use it, yes. But since I use it, that wouldn't really benefit me in any way. It adds more work. So my options are either make it more efficient or lose it all together. I don't want to lose it for several reasons, which I can go into more detail if you are curious.