NPC's realistic biophysics

[Sativarg]

Quiet a while ago Oss133 applied a script to a mod that would add a token scripted item to all NPCs in a given radius from the player. The scripted piece would monitor the NPC for speech. What I propose is a similar method to add realistic Biophysics to any NPC/creature that is targeting the player and perhaps to his companions as well.

 

When the game goes into combat mode my script would detect hostiles ant AddItem each with the appropriate item and exit. Durring combat the tokens would keep tabs on the host and modify their stats according to any realism mods you are running. Weather it be More Realistic Encumberment and Fatigue by Bayli & Mentalor, Running Revised by Deathless Aphrodite or a set of criteria chosen by the player. In this way you are not the only one who feels the burn and things become much more balanced. Having the affects shared by the opponents might allow for more realistic and harsher penalties without the unbalancing problems.

 

The tokens if applied to companions could be retained and even applied upon acquisition of said companion. An option to modify the effects of ranged magic to favor the companions and harm the opponents could be included. Each token could be tailored to the type of NPC so that health spells would harm the unread or light spells could blind a vampire... By using unique tokens the script load would not include contant checks for type ETC.

 

When combat mode is ended or upon the death of the host the tokens self destruct in such a way as to leave no trace refs.

 

My questions are. Has anyone already done this? Is it worth doing? Do you have any ideas for implementation.

[Vagrant0]

It's possible to some extent, but not recommended. Any effect which covers a wide area can cause loss of performance. If this effect is being used frequently, and isn't regulated by the situation, additional issues may occur including slow down every time it goes off. You may or may not noticed this from the mod you mentioned due to either a simple script, or a good computer. With a much more complicated script, you will notice it, no matter what computer you have, especially in areas with more than 2-3 combatants. Any script like this which makes constant checks and changes can, in itself, create some slow down. When such a script is multiplied across several NPCs, it becomes even worse. The more complicated the script, the worse the performance. The greater the frequency the changes, the worse the performance. In the end, it really wouldn't affect too much. There are already combat mods out there that provide decent variety, and most mods to make it harder for the player are there to provide some challenge to the game. The player needs a handicap, NPCs have enough handicaps already.

[Sativarg]

OK, I would have course use the simplest scripts possible and only let them activate in stages. I have several mods running that use OBSE and I know at least one is checking my weapon/Fighting state. One script can check for enemy detection only and upon detection/engagement activate the script to distribute the tokens. Each enemy can be infected one at a time so as to minimize lag/congestion.

 

I can avoid calculations by using simple branching code to quesi-table values. Resolution is not critical, only effect and balance. I believe it can be done with say two or three degrees of resolution to suite each systems FPS dynamically.

 

But as you say the NPC is at a disadvantage. I like the mods that can make fighting more realistic but I always get frustrated with NPCs that fight at 100% with less blood than a Gnat .

[Vagrant0]

OK, I would have course use the simplest scripts possible and only let them activate in stages. I have several mods running that use OBSE and I know at least one is checking my weapon/Fighting state. One script can check for enemy detection only and upon detection/engagement activate the script to distribute the tokens. Each enemy can be infected one at a time so as to minimize lag/congestion.

 

I can avoid calculations by using simple branching code to quesi-table values. Resolution is not critical, only effect and balance. I believe it can be done with say two or three degrees of resolution to suite each systems FPS dynamically.

 

But as you say the NPC is at a disadvantage. I like the mods that can make fighting more realistic but I always get frustrated with NPCs that fight at 100% with less blood than a Gnat .

The main issue with the that sort of script is really the pulsing effect which attempts to run the script on everything (not just NPCs, but anything that can be targeted by spells) within whatever distance. Even without visuals, depending on the complexity of the scene and the distance being used, even once every 10 seconds, with a simple script can cause some slow down.

 

You could always just add some scripting the actual NPCs and creatures which are randomly spawned, to the individual creatures, or just adding the token to their inventories so that that pulsing script isn't needed (the problem with inventories is that they won't automatically wear something that doesn't have a biped object, or that they havn't been told to wear by another script (scripts on items don't run unless they're worn). Using a scripted ability might also work.

 

However as with any change to NPCs, you run the risk of losing compatability with other mods, and will not have the effect carried to things which exist only in those mods. Setting a template creature in the leveled lists may be another option to reduce some conflicts, but can create others, requires mods to be using those leveled lists, and may or may not affect other aspects of what was spawned.

 

Also keep in mind that when injured, creatures and some people can actually be more dangerous since they are in a dire situation and can't hold anything back. Not everything would react the same way to such a situation, so a single script casting a single spell which forces a single token which runs a single effect may not be able to account for this difference. Adding a script, item or ability to the base NPC or creature however would, and then some.

[Sativarg]

The main issue with the that sort of script is really the pulsing effect which attempts to run the script on everything (not just NPCs, but anything that can be targeted by spells) within whatever distance. Even without visuals, depending on the complexity of the scene and the distance being used, even once every 10 seconds, with a simple script can cause some slow down.

• Only non essential actors that are actively targeting the player would receive a token.
  
• The token would only change the stats of the host IE: 70% health=-10%speed, -5%streanth...
  

You could always just add some scripting the actual NPCs and creatures which are randomly spawned, to the individual creatures, or just adding the token to their inventories so that that pulsing script isn't needed (the problem with inventories is that they won't automatically wear something that doesn't have a biped object, or that they haven't been told to wear by another script (scripts on items don't run unless they're worn). Using a scripted ability might also work.

• Why Add scripts to the actor when adding a token is safer?
  
• Why Add scripts until actor actually targets player?
  
• I propose to only affect active hostiles and only while engaged.
  

However as with any change to NPCs, you run the risk of losing compatibility with other mods, and will not have the effect carried to things which exist only in those mods. Setting a template creature in the leveled lists may be another option to reduce some conflicts, but can create others, requires mods to be using those leveled lists, and may or may not affect other aspects of what was spawned.

True, but many mods can not be used together. I could optionally(at the users discretion) test for the actors having scripts and not tag these.

Also keep in mind that when injured, creatures and some people can actually be more dangerous since they are in a dire situation and can't hold anything back. Not everything would react the same way to such a situation, so a single script casting a single spell which forces a single token which runs a single effect may not be able to account for this difference. Adding a script, item or ability to the base NPC or creature however would, and then some.

True, thank you, I should add tokens to actors according to their proclivity for aggression. I had planed on tailoring the token to types, profiling if you will. If the type would become more powerful as wounded then so be it, give an adrenaline/anger affect to a point . But I still feel that at 10% health there should be some' penalties.

 

I am hoping that the item in the inventory of the actor does not have to be activated by the actor in order to have affect. Perhaps the token could be clothing/armor for the tail slot that has a high value and offers a relatively high armor rating. During testing the item could even give off light of a given color so I can see changes as they happen: red for say negative affects and green for the positive or when inactive.

[Vagrant0]

The main issue with the that sort of script is really the pulsing effect which attempts to run the script on everything (not just NPCs, but anything that can be targeted by spells) within whatever distance. Even without visuals, depending on the complexity of the scene and the distance being used, even once every 10 seconds, with a simple script can cause some slow down.

• Only non essential actors that are actively targeting the player would receive a token.
  
• The token would only change the stats of the host IE: 70% health=-10%speed, -5%streanth...
  

Yes, but in order to give those actors a token, you have to have a scripted ability on the player which casts an area effect spell frequently. Even though your intended targets are NPCs and creatures, that spell will still hit doors, containers, and activators, and still run the script on those things. Even a simple

 
begin scripteffectstart
set target to getself
if target.get isactor == 1
message "actor found"
else
return
endif
end

Might still cause some slow down because even those things which aren't actors, but still run scripts, will still end up going through the steps of the script. Even though the script ends right away, when you multiply it times 20+ simultanous instances, it can be enough. Any additional blocks within the script will also run on those targets, so you should avoid using a "scripteffectupdate" block at all costs since these get run every frame. Even though non-actors can't have duration effects, a "scripteffectupdate" still ends up running 2-3 times on those targets.

 

The point of just applying the token effect to the NPCs in the CS is to remove the necessity of any such spell, and reduce the chance of such problems occuring.

[Sativarg]

Yes, but in order to give those actors a token, you have to have a scripted ability on the player which casts an area effect spell frequently. Even though your intended targets are NPCs and creatures, that spell will still hit doors, containers, and activators, and still run the script on those things. Even a simple

 
begin scripteffectstart
set target to getself
if target.get isactor == 1
message "actor found"
else
return
endif
end

Might still cause some slow down because even those things which aren't actors, but still run scripts, will still end up going through the steps of the script. Even though the script ends right away, when you multiply it times 20+ simultanous instances, it can be enough. Any additional blocks within the script will also run on those targets, so you should avoid using a "scripteffectupdate" block at all costs since these get run every frame. Even though non-actors can't have duration effects, a "scripteffectupdate" still ends up running 2-3 times on those targets.

 

The point of just applying the token effect to the NPCs in the CS is to remove the necessity of any such spell, and reduce the chance of such problems occuring.

Ok. How does a companion who is following me know that an enemy is in the next room has detected me and go running after them when I can't even see said enemy. Isn't that functionality available to the modder? If the wolf I have with me can do that why can't my script?

[Vagrant0]

Ok. How does a companion who is following me know that an enemy is in the next room has detected me and go running after them when I can't even see said enemy. Isn't that functionality available to the modder? If the wolf I have with me can do that why can't my script?

Most of it is part of the AI. You can do it with scripting to some extent to make it so that pulses are only done when the player is in combat (player.getisincombat == 1), but even then you're still "pinging" every object within 5000+ units every time it runs. And as combat is one of those areas where fps and reaction times are crucial, still isn't recommended. The problem with a code like:

short trigger

begin scripteffectupdate
if player.getisincombat == 1
if trigger != 1
player.cast <area spell>
set trigger to 1
endif
elseif player.getisincombat == 0
set trigger to 0
endif
end

is that it would only cast the effect once battle started, which might be before anything gets close enough to be affected by the spell. Remember, the larger the area, the more things that get caught in it and the more strain the spell has, the smaller the area, the more often the spell needs to be cast to detect what has recently entered that area. Even with a large spell area, you would still need to cast the spell more than once per combat since that script would only detect change in combat state, not how long the player was in combat. If the player was in a prolonged state of combat, only those things nearby when combat started would be affected, anything that came later, like summons, or offscreen reinforcements, would be unaffected until the next pulse.

 

Anything which uses a similar "ping" effect just simply doesn't work well from a performance standpoint. Those that use it don't stop to think about how they're affecting other players games. If there are other ways to do what you want, it's usually best to use them, no matter how much more complicated they may be.