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 😄