I agree about the fun/real balance, which is why the default settings are less harsh than reality.... even climbMult=1.5 is about 25% less harsh than reality. However, the attempts to tweak horse fatigue and encumbrance in RF v2.3 are very new and not yet that well tuned... I'm expecting to tweak these in the next version based on user feedback.

It's important to note that "feathers" are not "pounds"... they are not even close. In raw weight terms they are closer to 1/2lb. Also the weight of many things, particularly weapons, include an "encumbrance factor" that multiply their real physical weight x2 or even x4 to take into account their awkwardness to carry. So your 200 feathers of encumbrance represents about 30Kg or 66lb, which is pretty close to the real weight of a full set of armor, weapons, and equipment. Swimming in full plate is apparently a bit difficult, but not impossible.

Many of the default settings in Oblivion that at first glance seemed to be pretty ridiculous turn out to be pretty accurate when you do the research and sums. Jump heights are often quoted as unrealistic, but the current world high-jump record is around 2.3m, which happens to be what the default Oblivion max jump settings have. The default Oblivion movement and encumbrance settings at first glance appear to be too slow, but turn out to correspond pretty closely to reality for reasonable assumptions about average encumbrance. Some things, like fatigue returns/burns, are quite wrong, but lots of other stuff was pretty close to reality, and also happen to play pretty well.

The horse part is very new and still being tuned. Please let me know what seems to work for you so I can tweak the defaults appropriately in the next release.

I also find that horses are unreasonably slow. I'm looking at tweaking this in future versions. I'm not sure yet if it's that creatures in general are unreasonably slow, or just horses. I think it's just horses...the bay horse's speed is actually less than a mudcrab, and it's only the mudcrab's scale of 0.5 that makes them move slower.

If I can make movement slow down and reduce fatigue burn for low fatigue, this will also help a fair bit... it won't be as easy to push your horse to collapse uphill, as he'll just slow down a bit when he gets tired instead. It will also make those badly wounded bandits run away a bit slower because of their wounds.

Hi ABO,

First let me thank you for this mod, which I consider one of the most important mods in my install

Then, while I know I'm a minority, I'll give you my wish anyway.

While I love this mod and couldn't dream of playing without it, I'm still playing with the last 1.x version (1.13?). The reason for this is that I do not want NPCs to be affected. NPCs don't carry a sack of Fatigue Potions and don't fight smart as I do, so I just don't want the NPCs to be hampered in anyway that makes fighting them easier. So my request is simply to have an option for only affecting the player (and possibly his horse) with RF - but I must admit that I have no idea if this is simple, hard or impossible to do.

Btw, I have a couple of suggestions for your ini files. First, let me thank you for your omod installation scripts. Your scripts was what showed me that it was possible, and was the inspiration for my own omod installation scripts. But after a while it ocured to me how you can have an ini file that works for both manual install and an omod installation script. Instead of having:

set aaRFIndicator.fatigueBlurGain to ; recommended 0.5
in the ini file, and:
EditXMLReplace "RealisticFatigue.ini", "", "0.0"
in the script,

you can change it to:
set aaRFIndicator.fatigueBlurGain to 0.5 ; recommended 0.5
in the ini file, and:
EditXMLReplace "RealisticFatigue.ini", "fatigueBlurGain to 0.5", "fatigueBlurGain to 0.0"
in the script.

That way the ini file will immediately work with default values for everyone using manual or BAIN install.


...and finally, have you considered moving your ini files to the data\ini folder, as discussed in http://www.gamesas.com/bgsforums/index.php?showtopic=992755, like kuertee, I and a few others have done?

Note that in practice RF 2.x doesn't actually disadvantage NPCs much at all, because they don't carry much. The fact that they aren't carrying a sack of fatigue potions (and loot, and spare weapons, and ingredients, and etc) works in their favor because their encumbrance is nearly nothing. Most of the complaints I get are "I can hardly move without pant/stagger/trip and NPCs are pOwng me!", and it's all because the player is over-encumbered. Once people realize this they they notice the benefits of burden and fatigue poisons, which are basically useless without RF v2.x.

Mostly what you notice with v2.x is NPC pant/stagger/trip tells you when they are getting wounded/tired and you are starting win the battle... if you are pant/trip/staggering all over the place and they are not, it's probably a good idea to run away.

Thanks for that tip... I will probably switch to something like that in my next version. I did actually consider something like that right at the beginning but I was using tabs to align the numeric values and found the install script clumsy and fragile to minor whitespace differences and unsynchronized changes between install script and the base file, so decided to only substitute the numbers. Things like BAIN were not really taken into consideration at the time. I'm still not familiar with BAIN, and the lack of install scripts kinda makes me loose interest. I wish that OBMM grew wrye-bash support rather than spawning a whole new packaging system just when OBMM was starting to get established. What Oblivion really needs is not another packaging system but apt-get style repositories and updates.

I was unaware that people were starting to standardize on a location for config files, and am happy to comply with any sort of rational standard. Originally I just used the Data folder because I didn't think creating a special folder for my mods was justified, and in practice they are actually a kind of primitive interpreted *.esp file. Note that *.ini as a naming convention is probably a bit misleading as they are actually executable scripts, not traditional *.ini config files. However, they are used like config files and a convention already seemed to exist of using *.ini, so I stuck to it.

@ABO

Well, I set the HorseEncumbMult parameter to 0. Went riding. It seems OK, but I still get some whinny galloping uphill. Was that in vanilla? Or, am I missing something.

Even if I'm not, I think I'm OK with this setting. It's not necessary to eliminate it. I just want it to happen rarely.

There is no whinny in vanilla at all except when hit, so it's still RF doing that. Setting horseEncumbMult to 0 turns off the rider and equipment encumbrance, but it doesn't entirely turn of the uphill fatigue burns from lugging it's own body up the hill. Having horseEncumbMult=0 means there will be no difference to your horse between carrying nothing and carrying a rider + 10,000 feathers of equipment.

I think in terms of playability it's the uphill fatigue burn that is killing the fun, and it's not just affecting horses. Try running up a hill without a horse and you will see how quickly your fatigue drains to nothing. I think it would be better to set horseEncumbMult=0.1 and climbMult=1.0.

I'm OK with the uphill fatigue burn on my toon and the NPCs. Defensively, it's a strategy. Wit the immersion mods I'm using, a couple of opponents can be quite deadly. (I'm level 7.) I prefer 1v1 fights. Just a few moments ago, I was attacked by 3 bandits--a mage with a staff, a bad guy in leather using a two handed hammer, and a soldier with a two-handed sword. I put a rock between me and the mage, ruining his line of sight. Then, I poisoned my mace with Damage Fatigue and waited for the other two to approach. As the other two approached, I fired off a Major Enverneration spell at the first approaching--the one in leather. We traded a few blows (me poisoning him with the fatigue damage, too), until the two handed sword oppoinent showed up. Then I ran up hill to a higher vantage point, throwing a Restore Fatigue spell on myself.

As the leather opponent reached me at the top of the hill, he was already tired. I wacked him a couple of times, he went down, out of breath, and I nailed him.

The one with the two handed sword was in heavy armor and slower, which is why I always fought (and planned to take out) the one in leather first. When he got to the top of the hill, he was winded too. We traded a few blows, and I dispatched him just as my vision started to darken.

Great fun!

RF makes it possible to think tactically about using fatigue and tiring out your enemy with the terrain. Had I fought all three (still haven't faced the mage--not sure where he ran off to) at the same time, I wouldn't have won. RF leveled the playing field.

I think TheNiceOne doesn't know what he's missing when it comes to this kind of fight. It's AWESOME!



It was just the the horse the killed the fun for me.

I think I'll try it with the horseEndumbMult=0 for a while. If it starts to bother me, I'll try what you've suggested here.

What about giving the horses more Fatigue to burn and keeping the settings at default? How do we do that?

Part of the reason I think climbMult is too high is between v2.2 and v2.3 I bumped up the default from 1.0 to 1.5 and I think I overdid it. In v2.3 I added some vertical movement filtering that removed the "step bounce" climb burns so I thought I could bump it up. However removing "step bounce" doesn't reduce the burn from actual climbing. This means the movement filtering has slightly reduced the general movement burn, but the increased climbMult has significantly increased burn from climbing (by 50%). In the next version I will definitely reduce this back to climbMult=1.0.

I'd thought of bumping up horse fatigue more, and maybe that is part of the solution. The problem with doing this is although it means the horse can run uphill further before becoming exhausted, it also means it takes longer to recover. The horse only starts whinnying at 50% fatigue, which means it also stops at about 50% fatigue when recovering, and you have no idea how close to 50% it is. This means you should rest your horse for a bit longer after it stops whinnying, otherwise when you start galloping it will immediately start whinnying again. With more fatigue you have to wait even longer, with no indication of when it has fully recovered.

ABO, This horse whinny is driving me crazy. I just left Imperial city and turned on the road that leads to Skingrad. Yep, it's a bit of a hill there, and yep, my horse started to whinny about 3/4 the way up it (galloping).

Man, I need to fix this. I want to gallop my horse much of the way, but I want to use RF, too. I've changed the other settings we talked about. How can I just make my horse from not crying every time I gallop up a hill?



Idea: How about altering the horse's fatigue recovery rate, making it very fast?

Im having one problem with RL, its probably my fault but it seems that i had to change a few starting skill bouneses for my character in the CS. When i went in game my character was leveled up. I said ok to the levelup menu, then i saw that the levelup meter was still showing 100 percent. Then after leveling up one skill it went back to normal to 0. So basically did i scew something up by doing this?

Thanks

@ABO

Here's something new I'm trying, and it may be in the right direction.

I have RF set up as an OMOD, so it's easy to uninstall and reinstall in about two seconds. I did that and went with the default options on most settings (Low on trip and stagger plus Arwen's shader), but I picked FAST Fatigue regeneration.

The default FAST regen seemed a bit too much like vanilla (I have a hard time getting my fatigue to go down), I looked at the .ini and saw that the Fast sets regen to 12 whereas default RF regen is 8.

I set it to 10, but I need to play with it a bit more for a better evaluation.

I'm thinking, as I mentioned above, if we can have a specific regen for the horse, we can set it superhigh and get away from the whinny.

Thoughts on that?

It kinda depends on how exactly you want your horse to behave... there are several different settings that will all tweak the fatigue burn and recovery rates under different situations. It sounds like you just never want horses to suffer fatigue effects at all. I'm not sure that everyone would like this... personally I think that driving my horse too hard should result it in complaining and starting to stumble. It's also kinda handy to know when he's suffering because of wounds so that I don't get surprised by his death at the next minor encounter. If he doesn't stop whinnying when I walk him for 10 secs then something is wrong and he needs to be healed, otherwise he's good to gallop again after about 20 secs. If I walk him for 5 secs at the first sign of whinnying I can gallop uphill again for about 30secs before he starts to whinny again.

I still think climbMult is the main cuplrit... it's just too high for all actors and should be reduced to 1.0. With the default settings horses can gallop continuously with a rider and equipment without loosing any fatigue provided it isn't uphill... their fatigue regen rate is about equal to their fatigue burn rate running on the flat. Note that they don't regenerate fatigue when doing this... their fatigue stays about the same. So if your horse is whinnying after an uphill gallop and you keep galloping on the flat he will keep whinnying... but give him 10 secs to catch his breath and you can then gallop continuously again without him whinnying. The thing that really drains all actors fatigue is going uphill.

Because the fatigue burn/return is well balanced on the flat, I'm inclined to think that their fatigue burn and return settings are about right. Increasing their return rate or reducing their burn rate will mean they recover fatigue when running. Increasing both burn and return will be pretty balanced when running on the flat, but will burn faster when going uphill and recover faster when resting. Decreasing both burn and return will be pretty balanced on the flat but will burn slower uphill and recover slower when resting. Reducing horseEncumbMult will mean horses will burn fatigue less both on the flat and uphill when being ridden, because the rider and his equipment will have less effect. Reducing climbMult is the thing to reduce fatigue burned going uphill

You can increase horses fatigue return rates without affecting other actors by increasing their endurance. Increasing horse fatigue would mean they can gallop longer uphill before they start to whinny, but they also will take longer to recover. Increasing horse strength will reduce their encumbrance fatigue burn, but this is identical to reducing horseEncumbMult.

yeah - that's the way I like it too. After changing the climbMult as you proposed I can't say I am having any trouble any more - I set mine at 1.2.

Since we were on the subject of horses speed, what about a 30-50% (depending on Agility perhaps) speed drain on PC's when running backwards?

By the way do you know if horses drink potions you stuff inside them?

Cheers!

I too have been having problems/annoyance at the horse fatigue situation, so the suggestinns here have been very useful. Reducing the uphill burn is the best solution, but I also set the tripping chance to low, may even go to off.

The main problem of the horse tripping is how unrealistic and weird what happens next is. The horse trips and tumbles in front of you, then your PC flies through the air in the seated position and land back on the horse oo:

Its just crazy!

A way to force a dismount during the horse trip would be perfect, or a way to throw the PC too off the horse. Wonder if thats possible with the latest OBSE?

Yeah, the flying remount is a bit strange... if you are in first person it's not too bad if you don't fall far from your horse, but sometimes it's really strange.

Unfortunately I don't know if this can be fixed. Just forcing dismounting seems to be nearly impossible, and the wiki's are full of complicated instructions on how to make an NPC dismount using a special behaviour package which will trigger the slow dismount animation. I have seen video footage of a not-yet-completed jousting mod that included animations of people getting knocked off their horses, but I have no idea how that was done, but I'm betting it was complicated.

I've been tweaking the RF trip mechanics so that the tripping model is much better. This should make horses less likely to stumble, provided you don't push them too hard. However, the crappy horse collapse animation and general unhappiness with horse stumbling is making me wonder if I should just turn off trip for horses all together.

What do people think? Make horses never trip? Make horses trip less? Something else?

They can't micro stumble like the PC right? Then turn it off and when the horse should have tripped make it stop, or make a drastic slowdown. Might combine that with a temporary speed drain.

Cheers!

hey abo!
i vote for never.
maybe try a more subtle penalty - like a pronounced mis-step (possible by doing an EVP or adding a "dummy" AI package on the horse every so often while getting ridden) or something.

i was also about to request an alternative penalty for being fatigued: penalise MAX fatigue rather than a constant fatigue "burn".
so rather than a constant loss of "current" fatigue - the player, instead, cannot regain full fatigue.
(hmmm...i've complained about this before and here's that complaint again:
i really think bethesda is stupid for using the word "fatigue" instead of "stamina". "regain full fatigue" just doesn't make sense.)

(also...welcome back ot OZ! i saw a post months ago about your move back.)

I'm also voting for no trip. Although I'm sure before the horse used to do a little stumble, get up and carry on, instead of this humungus trip fall and fly that happens now. Maybe it just never happened to me in this way before.

Some other sort of penalty would be fine tho

Torrello: its interesting that you mention it seems to have changed... I didn't notice it had changed but it might be that it got worse between v2.2 and v2.3 when I added these features;

- Change trip to delay collapse recovery based on fatigueLevel2.
- Add tripFatigueDamage=16 setting to control trip collapse duration.

This means that you stay down a bit longer when you trip, based on your fatigue. The idea was to reduce the trip/stand cycle effect... by making you stay down a bit longer, when you get up you have recovered more fatigue and are less likely to immediately trip again. However, it might mean the horse stumbles are worse, making the flying remounts worse. You can experiment to see it this is contributing by varying the tripFatigueDamage setting between 1 (short trips) and 100 (big trips). At 0 it will probably turn off trips all together, and at 1 its probably going to turn off some trips, but trips will still be worse than in v2.2

Locksley: The NPC stumble animation only works when weapons are drawn, which is why you only stumble with your weapon out, and why horses can't stumble, only trip. Other ways of simulating a trip/stumble are likely to be fiddly and require lots of testing... I'm loath to apply attribute drains from a scripted ability because ability execution is a bit flakey and I'm not sure I can guarantee the drain gets removed correctly.

Kurtee: I don't even know what an EVP is, and I've not fiddled with AI packages at all. I'm not sure AI packages will work when applied to a horse the player is riding.

I'm not sure exactly what you meant by "penalise MAX fatigue rather than a constant fatigue burn". RF already includes a fatigue limit based on low health and high encumbrance. It doesn't apply additional fatigue burns as a penalty. All the RF burns and limits are based on a realistic fatigue model... fatigue represents the amount of un-fatigued muscles available for attacking/blocking/running/jumping. The low health limit represents damaged muscles that cannot be used. The high encumbrance limit represents muscles preoccupied with lifting that cannot be used. The fatigue burns for attacking/blocking/standing/walking/running/jumping are muscles becoming fatigued through use, and are scaled based on the effort required (encumbrance, weapon weight, etc). The fatigue return represents muscles recovering from being fatigued.

The only penalties RF applies for low fatigue are a trip/stagger chance, but I'm thinking of adding speed/athletics/acrobatics drains proportional to fatigue. I could use your advice on how best to apply these. I could just use modav, but I don't want to because the ability can stop or be removed at any point or the mod can be de-installed and leave a bunch of actors with drains behind. Modav2 is out because I don't want actors restoring from these drains, and can also leave drains behind. I could use a drain ability, but each actor would require different drain amounts, either requiring a different ability scaled with OBSE for each actor, or having many different abilities for drain1, drain2, drain4, drain8, drain16, drain32, drain64 and applying different combinations of them for different levels of drain. I could use short duration drain spells like this instead of abilities and repeatedly apply them. I could use drain tokens like this and add them to the actors inventory. Each of these would have different issues... what do you thing would be best? I'm kinda leaning towards drain tokens, but I'm not sure if these will just make the drain mysterious, whereas spells/abilities will show up on the actor's spell effects menu. I'm not sure if I can use a single spell and use OBSE to scale the drain effects before applying it to each actor, or if these spells will all adjust to the same intensity on all actors if I do this. I'm pretty sure scaling a single ability will not work correctly, and neither will scaling a single type of drain token.

I'm also considering changing the RF ability to a scripted token. In the early days I had quite a few problems with abilities stalling, but I've fixed them by remove/adding them again when they stall. I'm not sure that switching to a token will provide much benefit and might just introduce fresh new token related bugs.

hey abo!
evp = evaluate package. and you're right the AI packages are disabled while the horse is being ridden.
so it doesn't matter which package is applied to the horse, calling horseRef.EVP will reset the horse's animation putting a stutter in its step.
it was a bug in a previous version of Horse Commands that harlanrm eventually found and fixed.

so, the fluctuation of fatigue is actually a penalty to MAX fatigue (i.e. the fatigue limit) rather than a fatigue burn.
cool! i think i get it.
its actually what i described. i just didn't know that is how it was.

modAVs are a valid way to go.
as per the CS discussion a few months ago about this, theNiceOne logically pointed out that modAV applications from one mod ultimately do not conflict with those from other mods.

i find modifying the magnitude of effects via script to be troublesome.
i tried it with Battle fatigue and injuries and the NPCs would sometimes receive the correct magnitude and sometimes not. however, the inaccuracies could have been due to other bugs present at the mod's early stages.
regardless, i changed the mod to apply different enchanted tokens with pre-set magnitudes as injuries.

however, in my Eat and sleep mod, i have only 2 enchanted tokens: one for each Exhaustion and Hunger penalties.
and i modify the magnitude of each enchantment via script.
this is possible because the effects are applied only to the player.
the only "gotcha" that i found is that the dynamic changes to the enchantment sometimes do not stick.
so i keep a record of what they should be (i.e. i don't rely on enchantment's magnitude to be a correct record of itself) and re-modify the enchantments when the mod detects an incorrect magnitude - usually after a load in between game-session.
what may be happening is that the game is be loading the "changed" enchantment at game-start.
but the enchantment's original magnitude when a game is loaded in the middle of a session.
(i don't really know.)

i'd do these as tokens with enchantments attached to them - rather than scripted effects.
they just need to be equipped for the effects to be active. and these DO show up in the player's Active effects list.

and applying several tokens with different magnitudes that eventually add-up to the correct amount is an excellent idea.
it would have saved me creating 200 different enchantments and 200 different tokens for my Battle fatigues and injuries mod.
(they were a pain to create.)

as previously stated, i found this method inaccurate.
but finding a way to make it accurate is not impossible.

i find tokens, abilities, spell effects to have the same sort of bugs: if a script fails, it'll fail on all actors. if a script tries to access an invalid reference, the game may crash.
i'm trying to move my mods from scripted tokens to quest script with arrays.
currently my new unreleased version of NPCs yield (previously coded with scripted tokens and now coded with StringMaps) is working well.
i'll be doing the same with Battle fatigue and injuries and Crime has witnesses soon.

i hope you find something useful in that, abo.
however, here's a caveat: i cannot say that all of them are the be-all and end-all of what's what.
there are too many ways to skin a cat - so to speak.
cheers!

Will this work on a horse that the is being ridden by the player too? It might be a viable stumble in that case.

The one tricky bit is I apply my fatigue limit by using repeated applications of modAV2. The reason I do this is so the limit disappears if the ability stalls, is removed, or the mod is deactivated. This makes RL painless to uninstall and robust against ability stalls.

The problem with modAV is mods have to carefully track what they have applied and make sure they correctly undo it. This means you need a reliable way to track the applied modAV values, and provide a special uninstall process to remove them all before your mod can be deactivated. In my case I will be applying drains to all actors at various times, and scripted abilities are notoriously unreliable at keeping state (I've identified repeatable cases where abilities can get stuck in a mode where their state is erased each frame, even though they are still executing ).

Even worse, even if I used arrays to keep track of how much modAV drains have been applied to each actor, there would be no reliable way to walk through all the applied drains and un-apply them... Actors from cells that are unloaded will be unreachable and attempts to un-modAV them back for things like uninstalling will trigger errors that kill the script.

The beauty of using abilities, spells or tokens is they keep their own state; the actor either has them, or doesn't. Also, when the mod that added them is deactivated, the abilities/spells/tokens that were added by that mod are removed. This nicely solves the uninstall problem.

Yeah... it kinda disturbed me too... its very unclear what the effects will be for changing the magnitude of a spell or ability that's already applied to some actors.

Cool... that's great. If I have the drain1, drain2, drain4, drain16 etc tokens and apply different mixes of them to get different magnitudes, will it make a mess of the players Active effects list?

In my case I did some quite extensive testing, and found cases where perfectly valid ability scripts for some actors will enter a mode where their variables are all reset to zero every frame. It will be doing this for one actor, and not another. It usually happened if an actor went far away and then returned. I believe there is some sort of strange memory optimisation in Oblivion where it treats ability variables as non-critical and stops keeping any state for some ability instances on some actors when there is memory pressure. The problem is it does a really bad job of deciding which instances are important enough to keep state for, and once an actor is considered unimportant based on distance, they are not promoted back to important when they come close again.

The simple fix for this I use is I give the ability script a "version" variable that is initialised in ScriptEffectStart to the mod version number, and in ScriptEffectUpdate I remove the ability if the version number is wrong. The main quest script that adds the ability to nearby actors will then re-add it. This remove/add of the ability will kick-start it's execution and it will start keeping state again. It also means my abilities are removed and re-added any time a new version of my mod is loaded, ensuring their state is correctly updated.

It does however mean my ability cannot afford to rely too much on preserving state between frames, because the ability can be removed and re-added at any moment. If tokens are more reliable in this regard, then my mod might have less mini-hickups from these ability stalls, but I think they are pretty infrequent.

What are you putting in the StringMaps? References to Actors? I think you may find problems accessing those references if the actor gets unloaded.

I'm guessing this involves a quest script that runs every frame that iterates through all nearby actors using FindFirst/GetNext and applies effects to them, storing state information for each actor in Arrays. I'd be curious to hear how that works. It was never clear to me how efficient FindFirst/GetNext really is, and I thought that maybe doing this excessively will be a bit costly.

In my case, the ability script is quite large, with quite a bit of state for each actor (x,y,z positions, velocities, accelerations, fatigue/health/encumbrance values, etc). Having a single ability script with all the state variables declared and all the calculations as applied to only a single actor is quite neat.

Thanks for your advice... it's much appreciated. I'm pretty convinced using OBSE to modify the magnitude of drains is a bad idea, but I'm still not sure whether I should use tokens, abilities, or spells to apply the drain1/drain2/drain4/drain8/etc drains. I'm also a bit worried about spell-shaders... will any/all of these apply drain-spell-shaders to the actor? I think using spells will require casting from a persistent marker, which might be a bit of a pain. All of these are making me lean more towards tokens....

yup.
it's also a bug in Vows and Covenants: http://www.gamesas.com/bgsforums/index.php?showtopic=968853&view=findpost&p=15162235

i totally agree!

not exactly. only the effects (e.g. Drain Agility) are presented in the list.
however, if you roll-over an effect, it'll show what applied it: e.g. (drain1_name, drain2_name).

i find this as well.
and here's a more frustrating glitch (bg2408 has also mentioned this many times):
for no apparent reason, a scripted token on an inactive (e.g. very far away - and so unloaded) actor will run causing the game to crash.
my experience with this is from a previous version of NPCs yield.
an pirate i killed months ago in an unloaded cell will run its script (it'll show in the console) and crash the game.
the occurence was very intermittent (e.g. it took months for it to happen). but it was usually in a cell-change.
but once i knew where it happened, i can trigger the script to run by opening the load/save menu.
it was weird.
(my new unreleased NPCs yield uses StringMaps to track actor's properties.
when an actor is > 5000 units away, i simply remove them from the list.)


i use the actor's reference hex number as string with: actorRef.GetFormIdString
then i add the actual reference to a "ref" key.
if the ref key returns 00000000, its very likely that the actor has been unloaded.
i simply delete the actor's properties from the list.

note, however, that even if the actor's ref returns as 00000000 in the console,
they are still valid actors (e.g.: IsActor == true),
and some getAV's work on them (e.g. getAV health),
but some functions will crash the game.
i discussed this a few months ago with others (especially bg2408) in the CS forum.
you may still be able to search for it.

this is what the StringMap looks like in my NPCs yield:

					Let formIdString := actorRef.GetFormIdString					Let arIndex := ar_Find formIdString actorKeys					If arIndex == -99999						Let actors [$formIdString] := ar_Construct StringMap						Let actors [$formIdString]["r"] := actorRef						Let actors [$formIdString]["s"] := 0						If ignore							Let actors [$formIdString]["s"] := 4						EndIf						Let actors [$formIdString]["h"] := actorRef.GetAV Health						Let actors [$formIdString]["a"] := actorRef.GetAV Aggression						Let actors [$formIdString]["c"] := actorRef.GetAV Confidence						Let actors [$formIdString]["modA"] := 0						Let actors [$formIdString]["modC"] := 0						Let actors [$formIdString]["t"] := 0						Let actors [$formIdString]["y"] := 0						Let actors [$formIdString]["ct"] := 0						Let actors [$formIdString]["f"] := ar_Construct Array						Let actors [$formIdString]["lhl"] := 0

i use GetFirstRef/GetNextRef in 90% of my mods: NPCs yield, Battle fatigue and injuries, Crime has witnesses, Horse commands, Wandering encounters, etc...
all those mods continually look for actors to apply the mod's effects to.
its quite fast. (i recently tested my game without my mods. and it ran at the same FPS (between 17 and 20) as when they were active.)

those shaders were a pain to remove from "bashed" patches and with mods that actually change the shaders used.
thanks to psymon's patience, i managed to get the shaders to only play when the effects are applied.
the actual steps i took to remove the persistent shaders are:
1. ensure that effects uses their original shaders.
a LAME option changes the shaders used by the drain effects.
i had to release "kuertee bgMagicEVShader default drain effects.esp" with my mods to simply revert them back to "effectDrain".
2. in the effectDrain property, i had to set the persistent data to 0. (initial glow-all mod doesn't actually remove ALL the persistent effects.)
3. in-game effect: the purplish/redish cloud puffs around the player when the effects are applied.
i use this in several of my mods: Battle fatigue and injuries, Eat and sleep, Magicka-based jewelery limits, etc...

BUT...i think there is still a problem when mods are based and wrye-base organises the new shaders.
psymon managed to get my desired effect (i.e. default but non-persistent effectDrain) in his game.
but he might have had to do some BASH-magic.

no probs. abo!
i'm looking forward to the next iteration of your mods.
cheers!

Hey ABO, when I use Realistic Leveling in Vanilla mode, it says "RL: recalculating all attributes" in the console once per second. Should I be worried?

Yes... this either means you do not have OBSE installed and working correctly, or some other mod is interfering with RL badly. First check that you have OBSE installed and working correctly. If you do, then it must be a bad mod interaction.

RL has some optimisations so that it only recalculates all attributes when skills, fame, or infamy have advanced. Detecting when skills have advanced is a bit tricky, so RL looks for changes in various stats or popup dialog boxes and recomputes attributes when this happens. The attributes it looks at are; (GetPCMiscStat 2) + getPCMajorSkillUps + Level + Fame + Infamy + mode. If any of those attributes have changed or a popup message box has appeared, and you are not in combat, then it recalculates attributes. Note (GetPCMiscStat 2) is "SKILL INCREASES", but this stat does not include all the ways that skills can change, hence the need to also trigger on dialog boxes that are often displayed with special skill changes.

If RL is saying "RL: recalculating all attributes" every 1 second, then it is either seeing a dialog box every second (unlikely), or it is detecting changes in one or more of these stats every second, and might cause some attributes or even your level to fluctuate every second. This means RL will be applying more load to your system than it should, though it's pretty light weight so you will probably not notice until your level starts fluctuating.

I would be looking for some other mod that is dynamically adjusting your fame, infamy, or skills, and changing them every second.

Thanks for the quick response, ABO. It turns out my PCMajorSkillUps stat was set to -2147483648, probably from some other leveling mod I had used on the same save file. That value is treated as positive infinity, so it was breaking a lot of the math in RL. I set it to 0 and saved, and now RL vanilla mode works perfectly.

It would be nice to detect this problem and fix it automatically. I tried adding

if (getPCMajorSkillUps > 999999999999)	setPCMajorSkillUps 0endif

to the initialization of aaRealisticLevelingScript, and it appears to auto-correct broken save files now.

Update: I guess it also works to just add that code to RealisticLeveling.ini

I just released a new version 2.4 of http://www.tesnexus.com/downloads/file.php?id=10925 with the following changes;

2009-11-01 v2.4 by Donovan Baarda (abo)
* Add config file load success detection
* Change riderWeight not autocalculated for mode=1
* Improve trip model
* Add fatigueTripGain and moveTripGain trip settings
* Minimize horse trip to always recover next frame
* Reduce panting when collapsed, and stop panting when knocked out.
* Change config recommended climbMult from 1.5 -> 1.0
* Change config min/recommended/max tripGain from 0.01/0.05/0.10 to 0.01/0.02/0.04
* Change config min/recommended/max staggerGain from 0.05/0.25/0.50 to 0.02/0.04/0.08
* Change health based fatigueLimit changes to have less immediate effect on fatigue
* Tidy pz/dz swimming offset calculation code

I have not yet included any of the extra stuff discussed earlier... consider this a quick bug fix for horses, better tripping, and knock-out panting. Horses should not get as fatigued as quickly, changing riderWeight to zero will "stick" and reduce fatigue burned by riding, and horses should trip less with less bungee-remount effect. Tripping in general should be much less when running forwards, slightly more when running backwards, much less when not fatigued, and slightly more when totally fatigued. People collapsed from low fatigue should pant slightly less, and the Thieves Asenal blackjack should not leave people panting like crazy on the floor.

I haven't had much chance to tune the new trip model, and I have a slight feeling the recommended settings might be too low. In theory the model should be quite good now even for higher settings, but people generally reported they prefer less tripping so I turned the defaults down. If you feel like your enemies are not tripping/staggering enough for low fatigue, try turning up the staggerGain setting. Can everyone please let me know what setting they think seems to be best.

I also have some updates coming to Realistic Leveling and Realistic Health to include some fixes and suggestions from people (thanks Phssthpok) after that I'm tackling Carry Sacks again...