fitfondue

I've been using JediJosh's trainer to test the mod since the beginning, so the trainer might not be the culprit. If it is, it seems that it happens very, very rarely. Let us know if it occurs again and thanks for reporting!

@Frizio That's weird. I'll try to reproduce that bug in the next build. Thanks for reporting! @AnymYo Thanks so much for finding those values! We'll see if they can be used in scripting. 🙂

We're keeping track of all suggestions, folks, keep them coming. Currently the mod is halted due to time-consuming real-life stuff, but we plan to go back to it soon. OpenIV adding RDR2 support is amazing news and something we'd been hoping for.

@MoonShade That's weird, that disarming bug didn't happen for me when I was playing that mission with the mod active. Probably got lucky with the dice roll. And yes, this is the best place to provide direct feedback, so feel free to point out any issues. 🙂 @HughJanus You may want to add CS_JAMIE to the list of NPCs that this mod isn't supposed to affect.

I actually realized that yesterday. It was caused by some of the damage modifiers in the .ini being set to 0. That wasn't supposed to deactivate damage, it's supposed to leave the damage at the vanilla game's default values. However, some of the modifiers are actually deactivating damage for some reason. Setting all these modifiers to 100 fixed it. @HughJanus I've attached a hotfix below. I downloaded the mod from Nexus and changed those values (and ONLY those values) in the .ini. I recommend publishing this as a hotfix, both here and on Nexus. The 1.3 version that is currently published makes some missions quite difficult to beat, especially the Strauss missions which require a lot of melee. You can still beat them because some melee moves are hardcoded to knock out NPCs regardless of health, but it can take a full five minutes of fighting to pull that off. Also, for some reason, knocked out NPCs die shortly after being knocked out, and if the NPC is important this can lead to a "mission failed". Fortunately, changing the .ini values seemed to fix both problems. As for other mission bugs: I haven't encountered any. All the features work perfectly, and the game sometimes overrides the .ini with mission scripting (for instance, making an NPC die in one shot for design reasons). So far, pretty much every mission in chapter 2 is playable with the mod. The only potential problem is pacing, because the dying state can delay the progression of the mission. However, the bleed-out feature ensures that the mission will eventually progress. Plus, your allies keep shooting and killing enemies in the dying state. Ped Damage Overhaul 1.3 HOTFIX.zip

@HughJanus In case you're wondering how it looks so far, I posted a video below. It's still a bit too floaty (I'm overusing x-pushes to the calves and the z-push is still a bit aggressive) but as you can see, I can always get the character to roll to a new position until they end up lying on their right side. At that point, they get stuck and I need to unceremoniously push them into a new position. In fact, at one point in the video Arthur angrily yells "MOVE!", which was unexpectedly appropriate. EDIT: At the very end you see the character get stuck while their right side is facing up. That is because their limbs ended up splayed in various positions, and the X-push is affecting the limbs (the spine is always affected by a Z-push only). I'll figure out how to avoid that later on. 😄

@HughJanus Incredible work! It's much better. I'm being able to test more thoroughly now. I already came across the first randomizer we DO need: whether the relative X push is positive or negative. Here's what I mean: if you set a relative X force push to, say, 40, it will always pull to the right of the character. So if a character ends up lying down on their right side, the force push will push them towards the ground, and that comes into conflict with the Z-force that is being used to get the character to rise from the ground and roll. Therefore, they get stuck. The relative x-force only has one use: making sure a character has SOME lateral movement so they can't get stuck in an "unrollable" position. But if the x-force always pulls to the same side, characters will still get stuck. If the code is able to randomize between, say, 40 and -40, the NPC will sometimes be pulled to their left, and sometimes to their right, therefore guaranteeing that they will, at some point, end up in a new position. A 50% chance to either side is fine. It doesn't look bad when the NPC is pushed towards the ground; they just tense up in a way that looks okay. As long as they eventually pull to their other side, it won't be an issue. A few extra details: - The randomizer's decision should be the same for all the bones, which is to say, if it decides that a X push should be negative, then it should be negative to all the bones. The reason for this is to avoid one bone pushing to the left while another pushes to the right. - The randomizer should affect the X force push of all the bones. The value of the push is always the one set in the .ini and the only thing that changes is whether it's positive or negative (in the .ini, the value is always set to positive. The decision to make it negative happens in the code). - No changes to the .ini are necessary. It doesn't have to be configurable. It can always affect all the bones and it can always operate on a 50/50 chance. I should point out that negative values don't work in the .ini, so I wasn't able to test any pushes to the left. Can this be done in the code? One other thing we'll need, but that's for later: the code will have to check whether the NPC is currently at rest, to make sure that the force push won't trigger while they are already moving. If the force push triggers while they are moving, the forces are magnified and the NPC visibly "hovers". So the dying force pushes should trigger only if the character is detected to be reasonably at rest (I think checking a spine bone should be enough because the extremities aren't as important). As I said, though, that's something to worry about later. As for the timescale values, I don't know how to access them in code, but I know they can be accessed because they're a common feature with trainers. However, there's no hurry, we can find that one later. It's a very minor bug that's not affecting the tests. 🙂

@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.

@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.

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, 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.

@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 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 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 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 😄

@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 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.

@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?

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?

No, seems to work great on my end. Just tried it on 6 different NPCs, none of which survived.

I've attached the release candidate below! I didn't change standard values, but I did add more paragraph breaks to the .ini to make it easier to read and tweak (I did the same for realistic version). Most realistic values are the same as in the previous version, except: NPCs have 100 health and their dying threshold is 50: higher than in the previous version, but it still takes two Schofield shots (or one bolt action rifle shot) to drop them permanently. A health of 100 is simply more compatible with the game as a whole, so I figured it would be better to work with that as a baseline. Firehealth is 300: This is because I found 150 to be too quick. 300 results in a more believable reaction. I'd recommend the same to the standard version, but the one I'm attaching is identical to the one you sent. All I did was add paragraph breaks. And that's it. Here's a suggested changelog: Changelog v1.3: - Every NPC can be fully disarmed now, including lawmen. Most times they'll flee, sometimes they'll keep attacking with a knife or bare fists. - Enemies now stagger around as they clutch their wounds after being shot. They may trip over scenery or lean onto walls before falling or recovering their balance. - Fall damage is now unnaffected by NPC health, so that even high health values will not make NPCs survive huge falls. - NPCs now stumble more often if you shoot both legs. Falls can also result in leg damage, so shooting one leg may result in the other also being wounded in the fall. - NPCs can be automatically disarmed when lassoed (disabled by default, but can be enabled in .ini) - The .ini offers many more customization options now so you can tailor the experience to your liking KNOWN ISSUES: - The disarming feature can be exploited to slow down new waves of lawmen. The same is true of the dying state feature. If there are too many lawmen dying or fleeing around the player, new waves won't spawn in until the lawmen die or get enough distance. - The PlayerHealth .ini value isn't working: setting it to any value other than 0 makes player invincible. If you wish to make Arthur less resilient, you can alter the NPCWeaponModifier value. - Enemies on horseback or behind cover can't be knocked back by shots (just like in vanilla). However, if an enemy leans out of cover to shoot, they can be knocked back. - On the standard version of the mod, enemies may survive headshots because the bullet didn't quite hit the brain. This is due to NPC health being higher than 100. A shot that hits the brain perfectly is always an instant kill regardless of health. - NPCs "twitch" very slightly when they're dying. This is going to be fixed on the next version. Am I forgetting anything? Ped Damage Overhaul 1.3.zip

@HughJanus Absolutely incredible work! You figured out the Z-coord problem, and that opens up a lot of possibilities. As for the individual movement of the bones: the way the game applies force is very sudden and jerky, so it looks like a weird kind of "twitching". I experimented with more values but it always looks off, even if chance is set to 999 (the force isn't continuous even then, it's a series of jerks). The best way to implement something like this would be to apply a truly constant force for a short amount of time. Smooth movement. I don't know if this is possible, but if it is, then we may achieve something that looks natural. Another thing that may be very important: a downward push (which is Z-minus in this game, I think) to create friction with the ground. That way we can apply a good deal of lateral force without the NPC sliding around on the ground; the downward push might force them to roll. Finally, one more thing that may be worth doing, now that you've made "lying down" into a recognizable state: testing ragdoll natives with it, as seen here. If I'm not mistaken, ragdolltype goes from 1 to 4 with somewhat different settings for each (it's worth trying out more numbers to see if something else comes up). It's possible to find a ragdolltype that looks more "active" while lying down. I'll now test 1.3 values for release.

@HughJanusWhoa! That's a lot of good news to wake up to! I'll do a quick test of 1.4a2 to provide any useful feedback immediately, and then examine the values of 1.3 for release (as per the suggestions you posted).

@HughJanusI'll test them as soon as I wake up! As for what you said about the dying state cancel bug, I think the solution you've proposed isn't worth affecting other behaviours such as the artery shot. The dying state cancel is a rare bug, and the fix to fall damage should make it even rarer. So in my opinion this is enough for 1.3, and we can ignore the bug for now.

@HughJanusYou did it! Lawmen are now fleeing into despawn range, so it takes less time for new lawmen to spawn in. The exploit is still there (just disarm all lawmen and shoot them in the legs to slow them down) but I think you've fixed it as much as it's currently possible. I'd say this is good enough for 1.3. I think we're ready to move on to a release candidate, if you wish. This last .asi could be it, unless you still wish to polish something else? I must go to sleep now, but once I wake up, if you agree to release, I'll playtest the values for the realistic version and send you the .ini. If not, I'll be ready to test the next .asi. 🙂