Ped Damage Overhaul 2.0 BETA 7

Just now, HughJanus said:

Looking forward to doing more in v1.4 😄

So am I! 🙂 I'll keep testing the push randomizer to see if we can come up with something better than lying still. As for other features, here's what I propose we should start with:

- Instead of lasso disarms, we go with hogtie disarms instead. Lasso disarms are quite exploitable and look very videogamey (because the disarming occurs when the lasso is thrown). If instead the NPC is disarmed when hogtied, it makes more sense and isn't exploitable.

- Little to no damage on leg/arm shots. This would prevent immersion-breaking problems such as killing an NPC from shooting them repeatedly in legs and arms, which can easily happen with lower health values (for some reason, arm shots cause as much damage as torso shots).

- NPCs waking up in 10-15 seconds after being knocked out in melee.

What do you think?

I feel very excited！！   You are two so amazing!  Thank you two guys!  expect 1.4！

10 hours ago, fitfondue said:

 

So am I! 🙂 I'll keep testing the push randomizer to see if we can come up with something better than lying still. As for other features, here's what I propose we should start with:

- Instead of lasso disarms, we go with hogtie disarms instead. Lasso disarms are quite exploitable and look very videogamey (because the disarming occurs when the lasso is thrown). If instead the NPC is disarmed when hogtied, it makes more sense and isn't exploitable.

 

- Little to no damage on leg/arm shots. This would prevent immersion-breaking problems such as killing an NPC from shooting them repeatedly in legs and arms, which can easily happen with lower health values (for some reason, arm shots cause as much damage as torso shots).

 

- NPCs waking up in 10-15 seconds after being knocked out in melee.

What do you think?

I will have to check the natives for anything that can tell me if someone is hogtied, since I havent been able to find that out yet. I totally agree that this would be less exploitable, but I havent been able to do it yet.

Leg/Arm-shots can work but not the way you would think - we would have to check if certain bones have been hit and then give the NPC with health points - because we dont know where it has been hit before the damage is done. I would suggest giving a percentage of the NPChealth value back (depending on the setting for the damage modifier) if certain bones have been hit. What do you think?

For NPCs to wake up we have to be able to find out if they have been knocked out by melee damage - I dont know if we will be able to determine the type of damage that was done to an NPC (I dont even know if there is something like a damage type).

If it should only count for Arthur we may be able to check if he is armed and currently targeting an NPC, and if that NPC is on the ground and has less than x health -> do something. Then we have to figure out how to wake someone up^^ (but I think the arthur version will cost some performance, since we need to be scanning and checking a lot of stuff permanently)

Hi.

For the hogtied natives, I've found 2 interesting functions returning a bool. The first is https://www.mod-rdr.com/nativedb/index/task/is_ped_cuffed/ and it is quite self-explanatory but maybe it is used only for random events or cutscenes.

The second one is https://www.mod-rdr.com/nativedb/index/ped/is_ped_being_jacked/. With this you should be able to disarm any ped being lifted so it could be used also for hogtied peds.

For the legs/arms damage, your method sounds ok to me but if I've understood correctly, you have to deal damage to the npc and then retrieve the hit bone so if you kill the npc with that limb shot can you still give him back health percentage ? Also before giving back health points, you should check for arterial bleed because sometimes a limb shot triggers that and if that happens you should leave it as it is. 

I don't know if you can force an npc to get up, but I'm quite sure that npcs can only be stunned via melee damage so could try this way:

1)  Check if npc is alive

2) Check if  npc is ragdolled

3) Check if he's not fleeing and not fighting

In this way you can be quite sure that the npc has been stunned from melee impact I guess. I've found a native for this https://www.mod-rdr.com/nativedb/index/ped/is_ped_being_stunned/ so you could also try that first and check if it is usable.

Also I noticed that npc need something like 2 minutes to drown so  when you have some free time, could you add an option similar to the fall damage one?

I have now done a reimplementation of the movement in dying state like @fitfondue suggested in a private conversation (based on a duration -> moves for 5 seconds, waits for 3, moves for 5, ect -> all configurable in the ini).

lol it is hilarious. Files attached xD

The implementation is now:

• if NPC is in dying state and the dyingmovementchance checks out:
  • generate 3 random numbers between 0 and 99
  • number 1 determines the body part which is moving (arms, legs or spine)
  • number 2 determines which of the part is moving (left arm, right arm, left calf, right thigh, etc.)
  • number 3 determines the axis which is being pushed (x, y or z)
  • pushing is done for the duration set in the ini, then the NPC will not be pushed for the waiting duration in the ini, then pushing again -> for every push the 3 numbers are generated from scratch

this is only a first implementation, I am open to new randomizer-concepts!

@Frizio I'll check your suggestions during next week since I dont have that much time this weekend and I want to play around with the dying movement a little more - I think we are onto something. Thanks for the input!

PedDamOv_v1.4a3.zip

@HughJanusI'll test later today! I was actually going to suggest aim-based interactions, and this would work perfectly for waking-up an NPC (we could pick a contextual hotkey for it). Could actions such as these be checked less often (at 1/20 of a second instead of 1/1000 of a second) to optimize performance?

@FrizioThanks so much for your help and suggestions! I'll add the drowning problem to our Excel spreadsheet and see if we can make it more believable. At what health value does the NPC take 2 minutes to drown?

Adapted the code a little, so the movementchance would trigger the push for the whole duration of the seconds set in the ini. After the push a minimum of the wait time set in the ini will pass, then the chance applies again.

Also edited the chances of the body parts, so there is also the chance of body parts moving simultaneously.

All in all, just a little polish.

I also tried to fix the lawmen speaking when in dying state - hope I solved it.

New version attached.

@fitfondue Unfortunately every line of code (generally speaking - in realitiy of course not every line) in the script is executed in the same interval - so no chance of getting one check to get done less often (unless we use a timer which is counting). But I would say we worry about the performance when we notice an impact 🙂

I think the problem will be waking NPCs up, because I havent found a native for it yet^^

PedDamOv_v1.4a4.zip

@HughJanus 1.4a4 is looking much better! The continuous force push is still noticeably jerky but more promising, especially with the quiet intervals.

Here's the problem I'm running into: the force push of the limbs is relative, so they can quite easily end up in "unturnable" positions (because they start pushing against the ground). So could you add a non-relative option for each limb? I'll still need to test the relative option for each limb, because the key is in the combination. For instance, I may end up using the non-relative Z-axis (because it always pulls up), but relative X and Y. But then again, I may end up using a different combination of relative and non-relative vectors. I'll probably test all the values as non-relative first, then switch some vectors to relative to see how it looks.

So below are the booleans I would need. I do need control over each vector and set of limbs because the combination of relative and non-relative values may end up quite intricate.

IsDyingMovementRelative_ArmsX
IsDyingMovementRelative_ArmsY
IsDyingMovementRelative_ArmsZ
IsDyingMovementRelative_LegsX
IsDyingMovementRelative_LegsY
IsDyingMovementRelative_LegsZ
IsDyingMovementRelative_SpineX
IsDyingMovementRelative_SpineY
IsDyingMovementRelative_SpineZ

IgnoreDyingMovementUpVector=0 (because I actually intend to pull NPCs upward)

This should allow me to find a way to make NPCs shift out of any pose and roll realistically on the ground. They already do that in a few positions, but as I said, they quite easily get "stuck". 

As for the limbs moving simultaneously: if DyingMovementChance is set to 999, the limbs always move simultaneously? Or is it another value not included in the .ini that determines that? If so, I may need a boolean to ensure the movement is simultaneous, because I may end up using non-relative vectors to simulate a "push" off the ground, and that would require simultaneous movement. 😄

We're on to something now, this might actually work.
 

I have added a few more parameters:

;booleans for dying movement
IsDyingMovementForceRelative_ArmsX=0
IsDyingMovementForceRelative_ArmsY=0
IsDyingMovementForceRelative_ArmsZ=0
IsDyingMovementForceRelative_LegsX=0
IsDyingMovementForceRelative_LegsY=0
IsDyingMovementForceRelative_LegsZ=0
IsDyingMovementForceRelative_SpineX=0
IsDyingMovementForceRelative_SpineY=0
IsDyingMovementForceRelative_SpineZ=0
IsDyingMovementDirectionRelative_ArmsX=1
IsDyingMovementDirectionRelative_ArmsY=1
IsDyingMovementDirectionRelative_ArmsZ=1
IsDyingMovementDirectionRelative_Arms=1
IsDyingMovementDirectionRelative_LegsX=1
IsDyingMovementDirectionRelative_LegsY=1
IsDyingMovementDirectionRelative_LegsZ=1
IsDyingMovementDirectionRelative_Legs=1
IsDyingMovementDirectionRelative_SpineX=1
IsDyingMovementDirectionRelative_SpineY=1
IsDyingMovementDirectionRelative_SpineZ=1
IsDyingMovementDirectionRelative_Spine=1
IgnoreDyingMovementUpVector=0

;chance intervals for dying movement (which body parts will be moved is decided by the randomizer - if it lies between the chance01 and chance02, the corresponding part(s) will be moved)
DyingMovementLegChance01=0
DyingmovementLegChance02=13
DyingMovementArmChance01=14
DyingMovementArmChance02=27
DyingMovementSpineChance01=28
DyingMovementSpineChance02=41
DyingMovementLegArmChance01=42
DyingMovementLegArmChance02=55
DyingMovementLegSpineChance01=56
DyingMovementLegSpineChance02=69
DyingMovementArmSpineChance01=70
DyingMovementArmSpineChance02=83
DyingMovementAllChance01=84
DyingMovementAllChance02=99

I hope its self-explanatory^^

Will start testing now.

PedDamOv_v1.4a5.zip

Edit: I removed the thigh bones from the leg section (because if force was applied, there was a high chance it would make it look like the NPC thrusts its pelvis^^) - so the leg section only consists of the calves now.

For the relative force variables I also added some without the axis, which is applied when all the axis are triggered simultaneously (like with the direction).

PedDamOv_v1.4a6.zip

Edit2: I have added new code so that the NPC will "remember" the randomizers for the time it is being pushed. So from now on, as long as a push lasts, it should have the same values (combination of bones being pushed and the direction in which they are pushing).

So if you set the push phase to 5 seconds, the full 5 seconds will push the same bones in the same direction.

If you choose the pushing values low enough, it almost seems like fluent movement. Now its a matter of tweaking the pushing intervals (everything over 1 second looks like the NPC is being "tense" (like having a seizure) for that time - so I think we need to stay below the 1 second, but adjust the waiting time and pushing chance so that the change of intervals is not noticeable and meanwhile keeping the pushing values at a level that looks believable).

I think a lot of tweaking has to be done now lol

I have already played around almost an hour with the values, but have not come up with a good solution yet^^

Im thrilled to see what you will do with it - until now you were always the one better at tweaking stuff 🙂

PedDamOv_v1.4a7.zip

@fitfondue With 200 health points, npc who got almost no damage survived roughly 30 seconds which is ok for me. I advice to stick to this value regardless of the npc health. Or maybe you could add a customization just like the one for the fall damage.

1 hour ago, Frizio said:

@fitfondue With 200 health points, npc who got almost no damage survived roughly 30 seconds which is ok for me. I advice to stick to this value regardless of the npc health. Or maybe you could add a customization just like the one for the fall damage.

 

I just found a native "SET_PED_MAX_TIME_UNDERWATER" and tested it, but it doesnt seem to do anything.

WIth the mod on (NPCHealth = 450) a lawmen takes about 20 seconds to drown - no matter how high I set this value.

When did you encounter someone who hasnt drowned in half a minute? How could I reproduce it?

For me, everyone drowns in an acceptable amount of time (I throw them in water where they are totally submerged).

This is quite strange, this happened to me many times with civilian npcs, never tried with lawmen though. I'll do some tests in the afternoon and update this post.

UPDATE: I've tried to reproduce this issue with many different peds and I can confirm that there is a big fluctuation between the different "surviving times" underwater. I've tried to drown the same ped 2 different times and the first time it lasted 1 minute and 30 seconds (!!!) and the second time just 20 seconds. I've used the last version you uploaded (1.4a7) for these tests.

I've done some research and the native you found seems to set the time an npc can last underwater before getting damage. I guess this value is random generated since similar npcs with same health value die in very different times so maybe they start getting damage in different times. I suggest you to try to set it to 0 (so instant damage) for every npc in the radius when the mod is enabled and then try to drown the same ped model 2/3 times and see if the issue is still there.

Anyway this is a very little problem and if you want to concentrate in other important features you should do it since I've noticed too that a good percentage of the npcs I've killed died in roughly 30 seconds and that as you said is quite acceptable.

@HughJanus I'm a bit confused by the new version and am not being able to test it because I can't figure out a way to guarantee movement in any direction. 😄 I don't know how to make it simultaneous between all limbs nor continuous.

Here's what I need in order to find the right values: no "chance" whatsoever. After the wait time is over, simultaneous movement of all limbs has to be guaranteed, or I won't be able to know which values are right or wrong. We can reintroduce elements of chance later, but first we need a baseline. If there is a chance that a limb won't move, then I won't be certain of whether or not the value I set is too low.

The code you added to ensure that the NPC remembers the direction for the entire duration of the push is excellent, please do keep that because that might fix the jerkiness. But in my experience, the force push can be applied for longer than 1 second without the tenseness problem. It's just that the force push needs to be higher and in one consistent direction.

I don't know if your .ini already allows for that, because I'm not understanding precisely what the chance interval parameters do. 😄

So to summarize: for the purposes of testing, the force push must always happen for all limbs, in one consistent direction, for the duration of DyingMovementPushTime. There cannot be a chance that it won't happen, because I have to test how every limb reacts to the force push (relative AND non-relative) individually in order to build a set of "animations" that looks convincing. Can that be done with the current version or are there still too many elements of chance?

@HughJanus An additional request, if you please, since the idea is to get rid of randomizers for this test run. Please take a look at the parameters below:

DyingMovementPushX_RFoot=0
DyingMovementPushY_RFoot=0
DyingMovementPushZ_RFoot=0
DyingMovementPushX_LFoot=0
DyingMovementPushY_LFoot=0
DyingMovementPushZ_LFoot=0
DyingMovementPushX_RHand=0
DyingMovementPushY_RHand=0
DyingMovementPushZ_RHand=0

DyingMovementPushX_LHand=0
DyingMovementPushY_LHand=0
DyingMovementPushZ_LHand=0
DyingMovementPushX_Spine=0
DyingMovementPushY_Spine=0
DyingMovementPushZ_Spine=0

IsDyingMovementForceRelative_RHandX=0
IsDyingMovementForceRelative_RHandY=0
IsDyingMovementForceRelative_RHandZ=0

IsDyingMovementForceRelative_LHandX=0
IsDyingMovementForceRelative_LHandY=0
IsDyingMovementForceRelative_LHandZ=0
IsDyingMovementForceRelative_RFootX=0
IsDyingMovementForceRelative_RFootY=0
IsDyingMovementForceRelative_RFootZ=0

IsDyingMovementForceRelative_LFootX=0
IsDyingMovementForceRelative_LFootY=0
IsDyingMovementForceRelative_LFootZ=0
IsDyingMovementForceRelative_SpineX=0
IsDyingMovementForceRelative_SpineY=0
IsDyingMovementForceRelative_SpineZ=0

IsDyingMovementDirectionRelative_RHandX=0
IsDyingMovementDirectionRelative_RHandY=0
IsDyingMovementDirectionRelative_RHandZ=0

IsDyingMovementDirectionRelative_LHandX=0
IsDyingMovementDirectionRelative_LHandY=0
IsDyingMovementDirectionRelative_LHandZ=0
IsDyingMovementDirectionRelative_RFootX=0
IsDyingMovementDirectionRelative_RFootY=0
IsDyingMovementDirectionRelative_RFootZ=0

IsDyingMovementDirectionRelative_LFootX=0
IsDyingMovementDirectionRelative_LFootY=0
IsDyingMovementDirectionRelative_LFootZ=0
IsDyingMovementDirectionRelative_SpineX=0
IsDyingMovementDirectionRelative_SpineY=0
IsDyingMovementDirectionRelative_SpineZ=0

I basically just removed the unified legs and arms movement and replaced it for individual right hand, left hand, right foot and left foot movement. The reason for this is that it should allow an additional measure of control. In my testing so far, the spine has mattered most for overall movement, and the arm and leg parameters have proved redundant. So we might as well change those to right hand, left hand, right foot and left foot because that will result in more unique movement.

Finally, one thing I've noticed (which may be related to chance intervals but I don't know how to solve it) is that the possibility seems to exist for multiple separate force pushes during DyingMovementPushTime (which is another thing that's making it difficult to test the features in 1.4a7). In a DyingMovementPushTime of 4000, a character was pushed upwards 4 times, instead of just being pushed upwards for the entire duration. Is this intentional or a bug? EDIT: Nevermind this last paragraph. I forgot about the Z-coord thing that cancels the force push 😄

I dont have hand and foot bones or leg and arm. I only have some fingers and the forearm as well as the calves and the thighs - more I dont have.

If you want the push to be applied all the time of the duration, then wait all the time of the pause duration, then push again for the whole time (without any randomness) the following values have to be set:

DyingMovementChance=999 (so every loop the pushing is triggered at 100% chance)

DyingMovementPushTime=1000 (pushing duration, 1000 = 1 second)

DyingMovementWaitTime=1000 (pause during the push durations, 1000 = 1 second)

If you want all limb parts (spine, legs and arms) to be moving at the same time you set the chance values as follows:

DyingMovementLegChance01=-1
DyingmovementLegChance02=-1
DyingMovementArmChance01=-1
DyingMovementArmChance02=-1
DyingMovementSpineChance01=-1
DyingMovementSpineChance02=-1
DyingMovementLegArmChance01=-1
DyingMovementLegArmChance02=-1
DyingMovementLegSpineChance01=-1
DyingMovementLegSpineChance02=-1
DyingMovementArmSpineChance01=-1
DyingMovementArmSpineChance02=-1
DyingMovementAllChance01=0
DyingMovementAllChance02=99

-1 disables and the 01 chance of "All" (meaning all body parts) is 0 and the 02 chance is 99, so that means "if randomizer is between 0 and 99, push all parts" (the randomizer generates a number between 0 and 99, so you have a 100% chance of triggering).

As for the body parts, they have chance modifiers which cant be confiured yet (making the legs, for example, either one leg move, the other leg moves, or both legs move - everyone of them having the same chance of occuring).

I dont know when I will be able to implement the requested parameters, because it will be quite some work, but I will see to get it done during the week :)

@HughJanus Wait! I actually just achieved good results! And I did it with 4000 of push time (the force applies smoothly for the entire duration). I'll add some final tweaks but I think 1.4a7 might deliver good results right away. I already have video of some surprisingly natural procedural movement.

I'll make an edited video shortly. If the parameters you just posted guarantee simultaneous movement, then no need to start work on any new code just yet. I'll do a few tests to make sure whether or not that's actually needed. 🙂

@HughJanus Below is the video. Only Z-forces are being applied (all of them non-relative). The characters move to the sides due to the interaction with the terrain and their limbs. Quite often no force push on the X or Y axis is necessary to make them roll.

As the video demonstrates, DyingMovementPushTime can be over 4000 and look extremely convincing (because it allows the movement to happen slowly, which makes more sense for someone who's wounded). It's also silky smooth, so the jerkiness bug is gone.

Problem is, regardless of the parameters I choose, I can't trust the same movement to happen every time, and in many cases the force push doesn't trigger at all (despite DyingMovementChance being set to 999). Additionally, it's currently impossible to guarantee that force push will trigger for all limbs at the same time, even with the parameters you suggested above. Most of the time, it will trigger for a set of limbs only, and quite rarely will it trigger for all limbs.

The parameters I'm working with are in the description of the video:
 

@HughJanus Incidentally, the reason you encountered the "tense up" problem is that the force you were using was only enough to move the NPC up to a certain point, so they would kind of "freeze" once they went as far as they could go. If you try a strong Z-force on the spine over 8 seconds or so, you'll see that you can keep the NPC "suspended" in mid-air at the same height, because at that height the force reaches an equilibrium. And you got rid of the jerkiness, so the push is now so smooth that the NPC literally hovers at a certain height.

This is actually perfect for our purposes, because we can pick a Z-force that makes the NPC rise to a certain height while their limbs are still touching the ground. In that situation, the Euphoria physics engine does most of the work, and the NPC naturally rolls or looks like they're trying to stand up (you can see that in the video above). Therefore, if the force push can be guaranteed to happen every time and for the selected limbs, I can come up with a value that consistently delivers believable results, and we can randomize on top of that later 🙂

@HughJanus Oh, one more thing: your .ini may have a mistake in it. It looks like this:

;chance intervals for dying movement (which body parts will be moved is decided by the randomizer - if it lies between the chance01 and chance02, the corresponding part(s) will be moved)
DyingMovementLegChance01=-1
DyingmovementLegChance02=-1
DyingMovementArmChance01=0
DyingMovementArmChance02=25
DyingMovementSpineChance01=-1
DyingMovementSpineChance02=-1
DyingMovementLegArmChance01=26
DyingMovementLegArmChance02=40
DyingMovementLegSpineChance01=-1
DyingMovementLegSpineChance02=-1
DyingMovementArmSpineChance01=41
DyingMovementArmSpineChance02=58
DyingMovementAllChance01=59
DyingMovementAllChance02=99
;DyingMovementLegChance01=0
;DyingmovementLegChance02=13
;DyingMovementArmChance01=14
;DyingMovementArmChance02=27
;DyingMovementSpineChance01=28
;DyingMovementSpineChance02=41
;DyingMovementLegArmChance01=42
;DyingMovementLegArmChance02=55
;DyingMovementLegSpineChance01=56
;DyingMovementLegSpineChance02=69
;DyingMovementArmSpineChance01=70
;DyingMovementArmSpineChance02=83
;DyingMovementAllChance01=84
;DyingMovementAllChance02=99

As you can see, the same parameters show up twice with a different set of values, and that may be causing conflict. I removed the duplicates and continued my tests, but that didn't fix the problems shown in the video. I'm warning you in case you think that the duplicates might be to blame. Apparently they're not.

@fitfondue

Awesome video xD

Yeah, theres still randomness because inside the body zones you can set in the ini, there is a randomizer which can not be set (so a case can occur where both calves are pushed and only one arm and one of the spine vertebras, so the calf push is much stronger).

Before changing any of the present logic, I would like to brainstorm a bit with you. If I change it now so that we can set forces separately for each bone and axis, what would be the end goal (so I can already put the code into the right places, when making it new)?

Would we like to create x different behaviors (e.g. bone pushing setups) which we then randomize (like the rolling in your video, then some squirming behavior, and some very slow crawling-like behavior, and whatever...)?

Or would we like to completely randomize the bones being pushed, so arbitrary behaviors can occur (maybe some we didnt even think of - but this may also lead to weird behavior)?

Or do we set up rules for randomizing - like if the left forearm is pushed, there always has to be the right calf pushed in the same movement..?

Because when I start to re-do the code, I will have to break up everything I currently have and then I want to make it proper :)

Thanks for testing so thoroughly all the time!

6 minutes ago, fitfondue said:

@HughJanus Oh, one more thing: your .ini may have a mistake in it. It looks like this:

 

;chance intervals for dying movement (which body parts will be moved is decided by the randomizer - if it lies between the chance01 and chance02, the corresponding part(s) will be moved)
DyingMovementLegChance01=-1
DyingmovementLegChance02=-1
DyingMovementArmChance01=0
DyingMovementArmChance02=25
DyingMovementSpineChance01=-1
DyingMovementSpineChance02=-1
DyingMovementLegArmChance01=26
DyingMovementLegArmChance02=40
DyingMovementLegSpineChance01=-1
DyingMovementLegSpineChance02=-1
DyingMovementArmSpineChance01=41
DyingMovementArmSpineChance02=58
DyingMovementAllChance01=59
DyingMovementAllChance02=99
;DyingMovementLegChance01=0
;DyingmovementLegChance02=13
;DyingMovementArmChance01=14
;DyingMovementArmChance02=27
;DyingMovementSpineChance01=28
;DyingMovementSpineChance02=41
;DyingMovementLegArmChance01=42
;DyingMovementLegArmChance02=55
;DyingMovementLegSpineChance01=56
;DyingMovementLegSpineChance02=69
;DyingMovementArmSpineChance01=70
;DyingMovementArmSpineChance02=83
;DyingMovementAllChance01=84
;DyingMovementAllChance02=99

 

As you can see, the same parameters show up twice with a different set of values, and that may be causing conflict. I removed the duplicates and continued my tests, but that didn't fix the problems shown in the video. I'm warning you in case you think that the duplicates might be to blame. Apparently they're not.

The ones below with the semicolon in front are comments, they are not being executed (I just saved them so I wouldnt forget the initial values I tested with) 🙂

2 minutes ago, HughJanus said:

 

The ones below with the semicolon in front are comments, they are not being executed (I just saved them so I wouldnt forget the initial values I tested with) 🙂

Oh! Goddamn it, I didn't notice the semicolons 😄 Fortunately I deleted them instead of the parameters that were actually active.

As for what you asked:

Would we like to create x different behaviors (e.g. bone pushing setups) which we then randomize (like the rolling in your video, then some squirming behavior, and some very slow crawling-like behavior, and whatever...)?

Exactly! So, what I have in mind is to experiment with different parameters to see how characters react from different positions. For instance, if a character is lying face down and I set parameters that look good for that, will those same parameters look good for when they're facing up or lying on their side?

And yes, I do intend to see if I can create behaviours that don't just involve rolling around. By experimenting with wait times, it might be quite possible to create an "agitated" behaviour that would fit being shot in both legs, for instance. Hell, we may actually pull off a crawling behaviour, but that one would be quite difficult and require special code to alternate force pushes between different bones. I suggest we leave that one for later 😄

So yes, as you suggested, once I have a set of parameters that create unique behaviours, we could have the code switch between those parameters for different situations. As for the other possibility you suggested:

Or would we like to completely randomize the bones being pushed, so arbitrary behaviors can occur (maybe some we didnt even think of - but this may also lead to weird behavior)?

This will absolutely lead to weird behaviours, based on the testing I've done thus far. The parameters have to be carefully set in order to look believable, otherwise we'll get anomalies such as NPCs who start breakdancing (happened a lot in my tests), or who simply move in ways that look unnatural. The perils of uncontrolled procedural generation.

Or do we set up rules for randomizing - like if the left forearm is pushed, there always has to be the right calf pushed in the same movement..?

I think we'd best start simple and leave that for later, as that is exactly the kind of behaviour that would be needed for crawling to work, and I think we should try to nail the rolling and squirming first to see how detailed we can get. But yes, I do expect that this kind of alternation will be required later on.

Because when I start to re-do the code, I will have to break up everything I currently have and then I want to make it proper

The key here is to keep the smooth force push in one consistent direction that the NPC remembers for the entire duration of the force push. You've absolutely nailed that, and now NPCs can be moved without any jerkiness and with no random changes in direction, and it looks incredibly natural. Excellent work, by the way, that was the key feature we needed for this whole thing to function 🙂

@HughJanus Oh, by the way, X and Y vectors will still be necessary. I only used Z-values in the video above, but X and Y can actually deliver good results too if they can be trusted to occur every time the force push is triggered. Since the force push wasn't being triggered sometimes and only for certain bones, I stopped using X and Y vectors in order to simplify the tests. Once force pushes become more consistent and always occur for the selected bones, I'll be able to test all the vectors (both relative and non-relative) with much more precision and predictability. I might need X and Y to untangle an NPC from certain positions, so they won't get stuck.

@HughJanus Incidentally, I just noticed a bug: if the game goes into slow motion (because, say, you went into dead-eye or opened the weapon wheel), the force push is magnified for the duration of the slow-motion and NPCs are thrown off the ground. This may be easily fixed, I think, by disabling force pushes if the timescale isn't equal to 1.0.

@fitfondue I have now dumbed the code down so that everything you set in the ini (all the x, y and z values for the different bones) will be executed at once. I omitted all the randomizers and the "remembering" of the NPC push, because the push will always be the same anyway (= whatever you set in the ini). All the randomizer logic, we can re-do when we know what we want.

With this code you should be able to force certain behaviors. Would be cool if you share some values here, once you get close to something :)

Thanks, as always, for your great work and effort!

Did a quick search for the timescale check but couldnt find anything useful. Have you found something already?

PedDamOv_v1.4a8.zip