Realisic Kill Reactions

Post » Sat Nov 06, 2010 4:02 am

A mod idea people always seem to have is making enemy's respond to their comrades being killed. As it stands, if I silently kill in one-shot an NPC standing 2 feet from another NPC, it doesnt' generate a "detection event" so the alive NPC's won't go into alert state (i.e. search mode).

The solution would seem straight forward . . . create a detection event centered on the actor you just killed. So, I started thinking conceptually how such a script might work, and have it be something that works all on it's own without compatiblity issues with other mods.

Essentially, all that needs to happen is when something dies, it needs to generate a detection event (using the handy CreateDetectionEvent function). However, how could this be accomplished without assigning a script with an OnDeath block to everything?

ref xHairRefBEGIN GAMEMODE	set xHairRef to player.GetCombatTarget			; returns the players combat target (only returns a value once auto-aim engages)	if ( xHairRef.IsKiller player == 1 )			; this means the player killed the actor reference		xHairRef.CreateDetectionEvent Player 50 3	; creates a generic detection event owned by the player, 50 volume, generic type (3)	endifEND


Would this work?
User avatar
Jessica Phoenix
 
Posts: 3420
Joined: Sat Jun 24, 2006 8:49 am

Post » Fri Nov 05, 2010 10:00 pm

Mez, you might not know, but MMM already has this integrated.
It's currently in there as a test script, all you have to do is set MMMzCombatDetection to 1 to activate it.
User avatar
Laura Cartwright
 
Posts: 3483
Joined: Mon Sep 25, 2006 6:12 pm

Post » Sat Nov 06, 2010 1:17 am

Now I don't really know about detection events, but generally my first thought was:

1. Quest script that ref walks actors in curent cell and adds detection tokens to them if they are alive and don't already have one.

2. These tokens periodically check if their container (=actor) is dead, and if he is they fire detection events every 10 seconds for a minute or so everyone panics and then the token removes itself.
User avatar
Esther Fernandez
 
Posts: 3415
Joined: Wed Sep 27, 2006 11:52 am

Post » Sat Nov 06, 2010 5:07 am

Check out the MMM script, Kai may be right in that you might be able to use that.

I recommend an INT check for the NPC, as I don't suspect that a Feral ghoul would care one way or the other if the feral next to it dies - it might even think, "Hey free lunch!".

Miax
User avatar
Allison Sizemore
 
Posts: 3492
Joined: Wed Jul 19, 2006 6:09 am

Post » Sat Nov 06, 2010 8:55 am

Check out the MMM script, Kai may be right in that you might be able to use that.

I recommend an INT check for the NPC, as I don't suspect that a Feral ghoul would care one way or the other if the feral next to it dies - it might even think, "Hey free lunch!".

Miax

No, I pointed that out to explain that we shouldnt add something like this to FWE :)
The script has to be attached to every creature so it would conflict completely with MMM.

It's simpler to either tell players to use the console to activate the function, or we can add it to the MMM menu. I just avoided that because this feature is still largely untested.
User avatar
Sebrina Johnstone
 
Posts: 3456
Joined: Sat Jun 24, 2006 12:58 pm

Post » Sat Nov 06, 2010 3:52 am

No, I pointed that out to explain that we shouldnt add something like this to FWE :)
The script has to be attached to every creature so it would conflict completely with MMM.

It's simpler to either tell players to use the console to activate the function, or we can add it to the MMM menu. I just avoided that because this feature is still largely untested.


Oh I definitely agree - attaching a script to every monster would be very bad - but the idea of using "IsKiller" is what I was referring to.

One of FOSE's cell-walking functions would offer the most flexibility in my view in terms of what you can calculate and do when an NPC dies. You could even get sixy and determine a response based on how close NPC #2 is to the killed NPC #1, having some just go alert of further away and others attempt to flee for the first few seconds to get out of the way and then going alert. Or with INT checks you could even do something silly and occasionally have un-intelligent NPC's break into tears instead of going wild. ;)
User avatar
Lewis Morel
 
Posts: 3431
Joined: Thu Aug 16, 2007 7:40 pm

Post » Sat Nov 06, 2010 5:54 am

No, I pointed that out to explain that we shouldnt add something like this to FWE :)
The script has to be attached to every creature so it would conflict completely with MMM.

It's simpler to either tell players to use the console to activate the function, or we can add it to the MMM menu. I just avoided that because this feature is still largely untested.


Yeah, I'm aware that MMM had this feature, but I admit that:

1) I haven't tested it . . and . . .
2) I haven't even looked at it!

So basically I haven't done my homework!

Regardless, I had assumed MMM implemented it via the scripts that it attaches to various actors, but maybe not? (can't check right now). Also, I remember reading that it was only ever applied to raiders as a test.

It would seem that you could get at the "intelligence" idea, but actually tying the whether the detection event was generated based on the INT of the thing that died (since you're referencing it anyway, it wouldn't be to hard to do that). The logic of this being that 99% of the time, feral ghouls are surrounded by ferral ghouls (for example). This could actually lead to some interesting things . . . i.e. maybe glowing ones have a higher INT, and when they die it DOES make other feral ghouls start searching, compared to if random feral ghoul #246 were to die, maybe his buddies wouldn't care :)
User avatar
Marguerite Dabrin
 
Posts: 3546
Joined: Tue Mar 20, 2007 11:33 am

Post » Sat Nov 06, 2010 6:22 am

One of FOSE's cell-walking functions would offer the most flexibility in my view in terms of what you can calculate and do when an NPC dies. You could even get sixy and determine a response based on how close NPC #2 is to the killed NPC #1, having some just go alert of further away and others attempt to flee for the first few seconds to get out of the way and then going alert. Or with INT checks you could even do something silly and occasionally have un-intelligent NPC's break into tears instead of going wild. ;)



Any examples and/or better explanation of the cell-walking functions? I'm not familiar with how those work at all.
User avatar
Sophie Miller
 
Posts: 3300
Joined: Sun Jun 18, 2006 12:35 am

Post » Sat Nov 06, 2010 4:42 am

Yeah, I'm aware that MMM had this feature, but I admit that:

1) I haven't tested it . . and . . .
2) I haven't even looked at it!

So basically I haven't done my homework!

Regardless, I had assumed MMM implemented it via the scripts that it attaches to various actors, but maybe not? (can't check right now). Also, I remember reading that it was only ever applied to raiders as a test.


Yes. I tested it but I couldn't get it to work (someone else reported it was working for them). I started a new game and went to various raider hangouts, but they were just as oblivious to their comrades getting picked off as in the vanilla game.
User avatar
Mackenzie
 
Posts: 3404
Joined: Tue Jan 23, 2007 9:18 pm

Post » Sat Nov 06, 2010 8:47 am

Here is a code snippet of a cell walk that checks for followers and moves them to one of two 'wait' spots where they remain unconscious until they are revived via another code segment.

                set rCurRef to GetFirstRef 200 0 0			;All actors		Label 10		if rCurRef				if (rCurRef.GetPackagetarget == player) && (rCurRef.GetCurrentAIpackage == 1)				Set NPCCount to NPCCount + 1				If NPCCount > 4					rCurRef.moveto FollowerSPot1				Else					rCurRef.moveto FollowerSpot2				Endif				rCurRef.setunconscious 1				set rCurRef to GetNextRef				Goto 10			else				set rCurRef to GetNextRef				Goto 10			Endif		Endif

User avatar
Elea Rossi
 
Posts: 3554
Joined: Tue Mar 27, 2007 1:39 am

Post » Sat Nov 06, 2010 1:20 am

Sure thing.

FOSE introduced a powerful set of functions that allow us to walk-through a cell's references (of any type) and act upon them. The most common are known as GetFirstRef / GetNextRef. The link to the FOSE documents can be found http://fose.silverlock.org/fose_command_doc.html

I'll provide one example below, of a custom respawn script I created:

		set RunScan to 0		set NPCcount to 0		set rCurrentRef to GetFirstRef 43 0 0 ; NPCs		Label 100		if rCurrentRef			if rCurrentRef.GetPlayerTeammate == 0				if rCurrentRef.GetDead == 0					if rCurrentRef == player						if( Logging == 1 )							printc "Found Player"						endif						set rCurrentRef to GetNextRef						Goto 100					else						if( Logging == 1 )							printc "Found NPC %n" rCurrentRef						endif						set NPCcount to NPCcount + 1						set rCurrentRef to GetNextRef						Goto 100					endif				endif 	else				if( Logging == 1 )					printc "Found player team-mate"				endif				set rCurrentRef to GetNextRef				Goto 100			endif		endif


Note the use of Goto and Label commands, which allow the code to jump back up to the top of the loop. Type 43 as shown in the "set rCurrentRef to GetFirstRef 43 0 0" tells FOSE that I'm looking for NPCs (friendly or not). Cispscis offers an excellent scripting tutorial on the use of these http://www.cipscis.com/fallout/tutorials/loops.aspx that might offer some insight.

It really depends on how far you want to go with the idea, but if it were me I would create a custom script that:

1. Whenever an NPC dies, run a check of the cell for any faction-related NPCs that are nearby to the body

2. Determine the distance between them, and thus the level of reaction that might occur.

3. Add an invisible token or item to the dead NPC after the checks so that we don't run the same scan twice.

There are a dozen ways it could be coded, and I agree it would add ALOT more realism to the game. I hate it when you shoot an NPC Now and it's neighber keeps on smoking like nothing is happening.

Miax
User avatar
Marguerite Dabrin
 
Posts: 3546
Joined: Tue Mar 20, 2007 11:33 am

Post » Sat Nov 06, 2010 6:52 am

Now I don't really know about detection events, but generally my first thought was:

1. Quest script that ref walks actors in curent cell and adds detection tokens to them if they are alive and don't already have one.

2. These tokens periodically check if their container (=actor) is dead, and if he is they fire detection events every 10 seconds for a minute or so everyone panics and then the token removes itself.


Selfquote \o/

I did a quick implementation of this and it seemed to work fine, though I did only test it exactly one time. Unfortunately nexus is down, but I just paste the scripts, it's rather simple:

Questscript, execute every 10 seconds
scn KDMainScriptfloat timershort depthref objBegin GameModePrintToConsole "Checking..."set depth to (player.isInInterior == 0)set obj to appleset obj to (getFirstRef 200 depth 0)Label 1if obj != 0	if obj.getDead == 0 && obj.getItemCount KDDetectionToken == 0		obj.addItem KDDetectionToken 1 1	endif	set obj to apple	set obj to getNextRef	goto 1endifEnd


Object script attached to KDDetectionToken (e: as token i used an armor with [ ] Playable [x] Quest item and no assigned model/biped slots)
scn KDDetectionTokenScriptfloat timershort stateshort countref actor;-------------------------------------------------------------------------------------------Begin OnAddPrintToConsole "Added token"set actor to getContainerEnd;-------------------------------------------------------------------------------------------Begin GameMode; Aliveif state == 0	if timer > 0		set timer to timer - getSecondsPassed		return	endif	set timer to 3	if actor.getDead == 0		return	endif	if actor.isKiller player		set timer to 0		set state to 1		return	endif	set state to 2	return;--------------------------------; Killed by playerelseif state == 1	if timer > 0		set timer to timer - getSecondsPassed		return	endif	set timer to 10	set count to count + 1	PrintToConsole "Creating detection event"	actor.createDetectionEvent player 50 3	if count < 3		return	endif	set state to 2	return;--------------------------------; Doneelseif state == 2	removeMeendifEnd

User avatar
Natalie J Webster
 
Posts: 3488
Joined: Tue Jul 25, 2006 1:35 pm

Post » Sat Nov 06, 2010 8:12 am

whoa . . . you guys work fast. I'll try this out when I get a chance . . . pretty cool!
User avatar
electro_fantics
 
Posts: 3448
Joined: Fri Mar 30, 2007 11:50 pm

Post » Sat Nov 06, 2010 1:07 pm

Well tickle me Elmo . . . it works! You do realize you've made a most sweet an excellent creation right?

Surely it needs more testing too, but so far so good. I should say that "schlangster" should have first dibs on posting this as a mod, otherwise, if you're not interested in posting something I'd be happy to get it packaged up once we get more testing done. I've been creeping around megaton in the evening with a silenced sniper rifle picking off settlers and watching everyone else switch into alert mode and start hunting for me. Pretty cool. If I had FRAPS I'd post a video.

Here's a link to a http://docs.google.com/leaf?id=0Bx2KSr0TXJqJMDhkMjM0ZTgtYTVhYy00M2JlLWJmNTktMGE0YmQwN2UzZjkz&hl=en if anyone would like to try it out.
User avatar
Leonie Connor
 
Posts: 3434
Joined: Mon Mar 12, 2007 4:18 pm

Post » Sat Nov 06, 2010 4:27 am

I don't mind at all if you wanna use it, it's actually better than me releasing it standalone (more downloads, higher quality, less work) :D
User avatar
Klaire
 
Posts: 3405
Joined: Wed Sep 27, 2006 7:56 am

Post » Sat Nov 06, 2010 6:42 am

I don't mind at all if you wanna use it, it's actually better than me releasing it standalone (more downloads, higher quality, less work) :D


Great work Schlangster!

It's a cool contribution that will make Fo3 seem even more dynamic. :)

I hope the New Vegas people are watching!

Cheers,

Miax
User avatar
TRIsha FEnnesse
 
Posts: 3369
Joined: Sun Feb 04, 2007 5:59 am

Post » Sat Nov 06, 2010 2:38 am

Since there were a number of bug reports, describing strangely passive NPC behaviour resulting from this, it might be a good idea to continue the discussion here.

I can't really explain what causes this, because the only thing that's done is calling create detection event.
So either
- this function is somehow bugged or
- the problem is that calling it multiple times causes the bugs.

I assumed it was practically the same as simulating a bullet impact at the position of the kill.

Do you know of any other mods/scripts that use this function successfully?

The parameters for this functions include an event type. Currently it uses "generic", which kinda sounds like "not used for anything yet", hence this might by bugged
* 0 = Bullet
* 1 = Beam
* 2 = Explosion
* 3 = Generic
Maybe using the explosion type is a better idea.
User avatar
Kayla Keizer
 
Posts: 3357
Joined: Tue Dec 12, 2006 4:31 pm

Post » Sat Nov 06, 2010 12:08 am

Since there were a number of bug reports, describing strangely passive NPC behaviour resulting from this, it might be a good idea to continue the discussion here.

I can't really explain what causes this, because the only thing that's done is calling create detection event.
So either
- this function is somehow bugged or
- the problem is that calling it multiple times causes the bugs.

I assumed it was practically the same as simulating a bullet impact at the position of the kill.

Do you know of any other mods/scripts that use this function successfully?

The parameters for this functions include an event type. Currently it uses "generic", which kinda sounds like "not used for anything yet", hence this might by bugged
* 0 = Bullet
* 1 = Beam
* 2 = Explosion
* 3 = Generic
Maybe using the explosion type is a better idea.


I was thinking along similar lines . . . either it was a result of the generic type, or that the Detect. event was being called multiple times. I'll check the first, but the latter might be the case as well.

Also, I tested things out with melee weapons _ killing people, and strangely it doesn't seem to alert people. Which is maybe good, but probably bad. I one hit killed grob while hidden in Moriarty's Saloon, actually sending gob into the air OVER the head Moriarty (who's back was turned) and he didn't react. I wonder why that's the case. Strange.
User avatar
jaideep singh
 
Posts: 3357
Joined: Sun Jul 08, 2007 8:45 pm

Post » Sat Nov 06, 2010 3:19 pm

schlangster,

In your token script, after the script has determined that the actor is dead, you have this code:

	set count to count + 1	PrintToConsole "Creating detection event"	actor.createDetectionEvent player 50 3	if count < 3		return	endif	set state to 2	return


The challenge I see here is that until count is == 3, you Will in fact trigger the detection event. Your returning before state gets set to 2, thus ensuring that the same code will enumerate in the next frame. Thus if count starts at 0, you will have 3 different times in which the actor is given the detection event - one frame after another, until count is set to 3 and the token is removed.

I recommend you remove the code bit:

	if count < 3		return	endif


That should create only one detection event, unless I'm reading this wrong.

Cheers,

Miax


User avatar
luke trodden
 
Posts: 3445
Joined: Sun Jun 24, 2007 12:48 am

Post » Sat Nov 06, 2010 5:59 am

Miaximus, thanks. I'll try disabling that code bit and see what happens.
User avatar
kasia
 
Posts: 3427
Joined: Sun Jun 18, 2006 10:46 pm

Post » Sat Nov 06, 2010 4:58 am

The challenge I see here is that until count is == 3, you Will in fact trigger the detection event. Your returning before state gets set to 2, thus ensuring that the same code will enumerate in the next frame. Thus if count starts at 0, you will have 3 different times in which the actor is given the detection event - one frame after another, until count is set to 3 and the token is removed.

Well you're quoting the part of out context, the whole thing is
;--------------------------------; Killed by playerelseif state == 1	if timer > 0		set timer to timer - getSecondsPassed		return	endif	set timer to 10	set count to count + 1	PrintToConsole "Creating detection event"	actor.createDetectionEvent player 50 3	if count < 3		return	endif	set state to 2	return

It won't be executed three times in a row but with a 10 second pause in between. The basic intention was so that the body is "hot" for like 30 seconds, so even if someone wasn't around when the actor got killed and walks by later he will still be alarmed.
User avatar
Richard
 
Posts: 3371
Joined: Sat Oct 13, 2007 2:50 pm

Post » Sat Nov 06, 2010 3:24 am

Well you're quoting the part of out context, the whole thing is
;--------------------------------; Killed by playerelseif state == 1	if timer > 0		set timer to timer - getSecondsPassed		return	endif	set timer to 10	set count to count + 1	PrintToConsole "Creating detection event"	actor.createDetectionEvent player 50 3	if count < 3		return	endif	set state to 2	return

It won't be executed three times in a row but with a 10 second pause in between. The basic intention was so that the body is "hot" for like 30 seconds, so even if someone wasn't around when the actor got killed and walks by later he will still be alarmed.


Yes but even out of context, your script can and Will result in multiple-detection for anyone that Is within the detection range - irregardless of the delay put on them. It might not fix the issue one bit, but it's worth checking no?

Mez, have you also checked to see if there are any performance hits on FPS with having this script run on every single actor? I'm just thinking of feral ghoul rampage, and having 50+ of these working at once. The code doesn't make any slow calls as far as I can tell, but we should probably make sure.
User avatar
Lavender Brown
 
Posts: 3448
Joined: Tue Jul 25, 2006 9:37 am

Post » Sat Nov 06, 2010 12:46 am

Yes but even out of context, your script can and Will result in multiple-detection for anyone that Is within the detection range - irregardless of the delay put on them. It might not fix the issue one bit, but it's worth checking no?

It is :) I simply assumed that it kinda behaves like when shooting near somebody (doing that multiple times, if anything, results in a higher chance of being spotted, which was what I was hoping for.

Mez, have you also checked to see if there are any performance hits on FPS with having this script run on every single actor? I'm just thinking of feral ghoul rampage, and having 50+ of these working at once. The code doesn't make any slow calls as far as I can tell, but we should probably make sure.

There's still a bit of potential for optimization. For example a global timer for state 1 would be possible. And there could be some kind of limit for scripts that may enter state 1, and if this limit is already reached they just skip to state 2. I think with these 2 changes it should scale pretty well even for large actor counts.
User avatar
Rob Smith
 
Posts: 3424
Joined: Wed Oct 03, 2007 5:30 pm

Post » Sat Nov 06, 2010 4:52 am


Also, I tested things out with melee weapons _ killing people, and strangely it doesn't seem to alert people. Which is maybe good, but probably bad. I one hit killed grob while hidden in Moriarty's Saloon, actually sending gob into the air OVER the head Moriarty (who's back was turned) and he didn't react. I wonder why that's the case. Strange.


That's because a detection event is only relevant if the actor is hostile to the owner of the event. It doesn't tell the actor you killed someone.
User avatar
Darian Ennels
 
Posts: 3406
Joined: Mon Aug 20, 2007 2:00 pm

Post » Sat Nov 06, 2010 3:10 pm

Ok, I did a bit of testing and the bug actually has nothing to do with the detection event, it's even still there when the respective line is commented out. The problem is the token, when adding it, it seems that sometimes the actors weapon selection gets messed up. When saving/loading, the actor resets and it works again, and when removing the token and adding a different one you can actually see pretty nicely that there's something not right because this causes every actor to randomly switch weapons.
I made numerous attempts to fix this, but nothing worked yet:
- a forced unequip of the token
- changing some flags/equip slot
- changing health
- skip getGameLoaded frame
- removing and adding the token every iteration (just for fun, actually made the problem much worse)

I made a new version that uses lists instead and only adds the token once the actor is dead. I think this is better than the first approach anyway.

So additionally needed are 2 empty form lists RKRDetectionListA and RKRDetectionListB.

Modified scripts:
Quest script (execute every 3 seconds)
scn RKRMainQuestScriptshort depthref objref oldListref newListshort phaseshort size;-------------------------------------------------------------------------------------------Begin GameModeif phase == 0	set phase to 1	set oldList to RKRDetectionListA	set newList to RKRDetectionListBelse	set phase to 0	set oldList to RKRDetectionListB	set newList to RKRDetectionListAendif; Phase 1 - Create detection events for actors that were previously alive and record still living actorsset depth to (player.isInInterior == 0)set obj to appleset obj to (getFirstRef 200 depth 0)Label 1if obj != 0	if obj.getDead == 1		if (listRemoveForm oldList obj) != -1 && obj.isKiller player == 1			;PrintToConsole "Adding detection token"			obj.addItem RKRDetectToken 1		endif	else		obj.listAddReference newList	endif	set obj to apple	set obj to getNextRef	goto 1endif; Phase 2 - Clear any elements left in old list so it can be reused as new listset size to (listGetCount oldList)Label 2if size > 0	listRemoveNthForm oldList 0	set size to size - 1	goto 2endifEnd


Token script:
scn RKRDetectTokenScriptfloat timershort countref actorshort start;-------------------------------------------------------------------------------------------Begin OnAddset actor to getContainerset start to 1End;-------------------------------------------------------------------------------------------Begin GameModeif start == 0	returnendifif timer > 0	set timer to timer - getSecondsPassed	returnendifset timer to 10set count to count + 1;PrintToConsole "Creating detection event %.0f" countactor.createDetectionEvent player 100if count < 3	returnendifremoveMereturnEnd

User avatar
Sxc-Mary
 
Posts: 3536
Joined: Wed Aug 23, 2006 12:53 pm

Next

Return to Fallout 3