Knockout/Paralyze player with 3rd person camera

[Dutchygamer]

For a little side-project, I've been trying to script the situation that the player gets knocked out / paralyzed for a short while, while the camera switches to 3rd person view.

 

The knockout / paralyze effect I had in mind is the same one when getting stunned by a Stun Pack Baton, or when shooting an enemy with a scoped weapon when having the Sniper 2 perk. Basicly knock the player to the ground, and after a while you will get up again, while not being able to move in the mean time.

From what I've been able to find, there is no build-in logic to apply this effect directly. After some trial and error I came across the following solution: take the spell which causes the effect, and cast it with the player as the target:

Paralyze.Cast(PlayerRef, PlayerRef)

Paralyze is a Spell property, PlayerRef is an Actor property. Both get set in the matching .esp in the Quest's properties. PlayerRef gets set to, well, PlayerRef, while Paralyze gets set to PerkSniperPush (the spell is named like this).

Upon triggering the script, it works as intended: player gets knocked out, and gets up again after a bit. So far, so good. However, when trying to enforce the 3rd person camera as follows, things get wonky:

Game.ForceThirdPerson()	
Paralyze.Cast(PlayerRef, PlayerRef)

For some reason, the Paralyze spell forces the game to use the 1st person camera. I have tried calling Game.ForceThirdPerson before and after the Cast, but it always reverts to the 1st person camera.

Additionally, I have tried with calling PerkParalyze instead of PerkSniperPush, but with same results: player gets knocked down, but enforced as 1st person.

 

Now I am not 100% sure if this actually can be performed on the player, and if so, if it works with the 3rd person camera. The times I got stunned with the Stun Baton are very rare, and I mostly play in 1st person camera, so I can't tell if this is the correct behaviour or not.

 

The question now is: can I get my idea to work? Or am I looking for something that simply can't be done? I do have access to the F4SE if this offers additional logic.

[DocClox]

I haven't tried this in Fo4. but in Skyrim you could set the player's viewpoint to use another Actor's eyes. If that still works, you could:

 

• Switch player to AI driven
• Switch player to use invisible actor's eyes
• Paralyze player actor
• Wait for effect to wear off
• Restore player pov
• Remove the invisible actor
• remove AI driven status from the player

Edited April 28, 2021 by DocClox

[Dutchygamer]

Alright, been able to make some progress. Instead of attempting to use spells, I directly call PushActorAway on PlayerRef with a small value (0.5). This gives the intended result of knocking the player down. Only downside is: the player will stand up rather quickly again with such little force applied.

I've tried two things to resolve this issue:

- call PushActorAway various times with a small delay between each call

- using SetValue with the Paralysis AV to paralyse PlayerRef, and unsetting it again when I'm done

 

The first solution is obviously less efficient, and a bit derpy in usage; the player will repeatedly try to get up again, only to get hit by the next PushActorAway and flop down again.

The second solution works more like I intended: the initial PushActorAway knocks the player down, paralyse kicks in and the player can't move, and when paralyse is unset the player will stand up again. Downside: sounds are pitched down when the paralyse effect is active, and I have the feeling the game is also slightly slowed down (which may explain the pitched down sounds).

 

As I'm playing some sound effects during this, for now the first solution seems to be the best one. If I can disable the down pitching during the paralysis then I may switch back to the second solution.

 

I do still have some issues with the initial PushActorAway tho; from what I am able to see, it should normally automatically kick you to the 3rd person camera to see your character flop down. However, at times it decides to stick to stick to the 1st person camera, with some very derpy 1st person animations as result. This also seems to happen when I first call ForceThirdPerson.

I have no clue what is the reason behind this; at first I thought it was the lack of room around the player, but when trying out in the open it still randomly decided to stick to the 1st person camera. The only thing I can think of is having a bit of a delay between ForceThirdPerson and PushActorAway; I will try this when I have the time.

[Dutchygamer]

Been getting closer to what I want. I have given solution 2 from my previous post a try again, with some tweaks:

Game.ForceThirdPerson() 
Utility.Wait(0.5)
PlayerRef.SetValue(ParalysisAV, 1)
PlayerRef.PushActorAway(PlayerRef, 0.5)
*various actions and Utility.Wait()s*
PlayerRef.SetValue(ParalysisAV, 0)

The added Wait between ForceThirdPerson and paralysing / pushing the player seems to do the trick to let the 3rd person camera always kick in and stay kicked in.

I've also reversed the order of paralysing and pushing; at first I did the pushing and then the paralysing, which at times could result in the player standing up again before the paralyse kicked in, resulting in the player being at an odd angle from the ground (don't ask), basicly glitching you out permanently.

 

I've also noticed that applying the paralysis alone without the pushing doesn't cause any downpitched sounds or slowdowns, neither does pushing alone; it seems the combination of paralysing and pushing causes this to happen. Most likely some kind of hardcoded engine thing, as I've not been able to find anything about it. However, for my intended result I do have to use both paralysis and pushing, as just paralysing will only freeze the player in place.

 

Now if I am able to fix this downpitching then it will be completely as I intended.

[LarannKiar]

I'm not sure how it will affect your code but you can also try setting the variable of the player's animation graph.

Game.GetPlayer().SetAnimationVariableBool("bRenderFirstPersonInWorld", false)