Remove the underline between SDR and Tweaks. It's just "SDR Tweaks.ini"

Thanks.

Wrapping up the technical side of things and updating the documentation.

I'm adding two new game settings:

iSDRsCompanionsMimicPlayer

iSDRsSummonsMimicPlayer

These settings will add a new "follower" token to an actor which will force the actor to run if the player is running or sneak if the player is sneaking.

Nice additions! Thank you!

So here's another question. I've gotten to the section regarding the alternate sneak skill up section. Currently I have it set up that if the closest potential detector is sleeping, then the points awarded are at a fraction of the amount.

I'm thinking about switching it up and having it work as follows: if the potential detector is sleeping, they are ignored for determining points awarded altogether. The game setting would be something like this:
iSDRsAltIgnoreSleepers

Here's an example of why I want to go in this direction. In the current system, lets say there are two potential detectors: A & B.
A is 800 units away from the player and B is 810 units away from the player. Since A is closer, if A is sleeping the player would only get 1/4 the normal points, even though B is just 10 units further than A.

If A was ignored because A is sleeping, then the player would get full points from B.

It's too difficult to track everyone in relation to the player, but what I can do is run a check to see if the actor is sleeping or not, and if so, they won't be selected as the closest potential detector.

I've pretty much made up my mind to do it this way, but if anyone has any thoughts about it, now is the time.

My guess is: everyone should give points, not only the closest/awake ones, as you're trying to hide from every single actor, and your skill/visibility/actions are compared against every single detector skill/eyes/ears, so hiding from many actors is much more difficult than hiding from a single one.
Of course, a diminishing return formula could be used to avoid fast leveling in populate areas with a chameleon/invisibility effect.


I think the sound factor could be revised a bit, as if a lone bandit hear a sound in his lair, he will get suspicious; if 20 bandits hear a sound in their lair, they won't get as much suspicious, because one of them may have caused it (fighting sounds are an exception).
So I think the sound factor should be reduced when in populated areas.
Also, I never understood how the detectors can distinguish all sounds made by comrades from the sounds made by enemies. I mean: even if I wear the same leather boots as the bandits they still react to my footsteps but ignore their friends footsteps, as if they send their "ID" with the sound, and the detector says "All right, these are John's footsteps" or "Hey, there's no ID! It's an enemy!".
How's that possible?


Finally: do the actors react when they find a death comrade?
I mean: duke patrick simply makes the actors go in alert state (SetAlert 1), but what if the whole detection formula get a bonus after an actor find a death comrade?

I used to have it that way. But I ran into two issues, one philosophical and another technical. On the technical side it became a real performance drag because the code for awarding points was on the actor token script. When only dealing with the closest actor, the majority of the code is in a dedicated quest script. Plus, there was an issue with figuring out how much to award per individual. There wasn't a really good method to do that without significant imbalance in both extremes (one person vs. 30 people).

On the philosophical side, some folks brought up a very good point, and the more I thought about it, the more I felt inclined towards "closest potential detector". Let's say you are sneaking through a bar, and the bartender sees you but a guy at the bar with his back to you doesn't, should you really get any points? I think the whole ideas of getting points for your skill is that you are making a "clean" sneak where no one is detecting you. In the example in the bar above, if you were to have stolen something, you would have been caught. Just like in many sports, it only counts if it's clean. And you get the most points from the closest detector.

My concern is that it is so difficult for sleeping actors to detect you that it's just way too easy to take advantage of them. It's "unsportsmanlike" to gain points off of them. So just like SDR ignores followers, I think it should ignore sleeping actors as well when determining points to be awarded.

I agree to some extent, but my options are limited. Currently there only a few settings that somewhat addresses this: "No LOS" penalty as well as talking/in dialog penalties. What you should keep in mind is that each individual is running detection calls against everyone around them at the same time. So it's not a matter of differentiating between friends and enemies, it's detecting each person individually. Once the person is detected, then the actor reacts to whether or not the person is a friend or enemy. When you dig down deeper, it gets complicated depending on the scenario. Let's say you are a bandit sitting around with four other bandits that you can see and you know there are no other bandits in the room. If you hear a strange noise off in the distance, you will know there is an intruder. Same scenario, but one of the bandits is out of sight getting a beer or on patrol. If I hear a strange sound, it's either him or an intruder. Depending on what I am hearing and how familiar I am with the other bandit, I may or may not figure out that the sound is coming from an intruder, depending on what I am expecting to hear, if anything. Trying to figure out some algorithm that allows a given NPC to figure all that out is a brain buster. It would also probably be a huge drain on resources.

Because of my limited function/options, it would have to be something like this:
- Each time an actor makes a round of detection checks, an array would be created for each target a detection is made against.
- Then the script would have to loop through the results and count how many were detected that the actor had line of sight of.
- The remaining actors would be the "don't know" factor. This would be adjusted by any companions that the player has.
- Then the "don't know" factor could be applied towards the next round of detections, but only if the actor doesn't have line of sight of the potential target.

There are already a few problems with this at a technical level. Although I know how to set how often a round of detection checks are made now, I *don't* know how to exactly predict *when* the detections actually happen. I can certainly print them out to the console, but that's after the fact, so to speak. I would have to constantly clear/reset these arrays every time a round of detection calls are made by each actor.

Even if I could figure out how to do it, I'm fairly certain that something like this would cause a huge drain on performance, which is challenging enough as it is.

One possible thing that would be fairly easy to implement is two different No LOS settings, one for interiors and another for exteriors. You are way more likely to have more sounds interfering with your ability to pick out specific noises in exterior scenarios than in interiors. So it would be something like this:
set sdrQ.fSDRsNoLOsixterior to .4
set sdrQ.fSDRsNoLOSinterior to .8

There is already a game setting for interior/exterior in general, and there is already a script that switches out other pieces of info whenever the player swtiches from interior to exterior cells, so this wouldn't be difficult to do.

Another possibility is to use the GetHighActors function to get a generic number of possible sound sources. The higher the number, the more difficult it would be to separate out individual sounds (not sure what formula to use for that though). However, it's a bit muddy to do it that way because GetHighActors is player centric and could potentially include actors that would normally not be within detection range of any given actor and therefore they would be unfairly penalized. So I'm not too inclined to do it that way.

I'm certainly open to suggestions. But it's important to remember that performance is a major issue I'm battling right now, so the solution has to be relatively clean and easy to implement.

Well, unfortunately my attempts at using the GetIsAlerted command in the past caused unpredictable CTDs. There are already detection bonuses for AI behavior when in combat, searching, or hostile. I'm not sure that "being on alert" necessarily translates to searching however.

In order to do this properly, I would pretty much have to either replicate Duke Patrick's mods or come up with an "SDR" friendly patch that allows them to interact with SDR in a similar way that I handle Reneer's Guard Overhaul. I'm not inclined to do it at the moment, mainly because I'm already overwhelmed for time. I need to finish what I have and take a break from modding for awhile. I am SO burned out at the moment.

You know, if someone else wants to take a stab at it, they could probably do it with the modder's resource package information. Although they should wait until after the next release.

I see. You can't play too much with the fragile balance "AI <-> Performance", and the Oblivion engine bugs/limitations do the rest.

Who know. Maybe in the future somebody will rebuild Oblivion with a new engine, like somebody is already doing for Morrowind, and similar features could be achieved already.

Anyway, about AAV, after working with Vampire Revolution, I can confirm the float values are fully supported, as I use an AAV actor value for the vampire blood level, and I can get/set/mod float values without problems. I don't know why it doesn't work in SDR. Maybe it's the type of AAV you create.

Yup, pretty much. It would be pretty cool if someone could overhaul the Oblivion engine. That'd be amazing.

Hmmm. Very weird. I never got errors setting an AAV with a float value. But whenever I retrieved them, the fraction would be dropped. This was particularly a problem when the float needed to range between 0 and 1. Not sure why you were able to and I wasn't.

Regardless, there is no way I could use AAV and move the detection formula into the .dll, so creating SDR's CAV system was inevitable if I wanted to make any difference.

EDIT/UPDATE:
I've finished revising the Player's Handbook. I still have a few things left to do, but I hope to have the new version up before the end of the year.