recoil force

[chaserli]

For the 6th time
@mevitar would you plz test if this works under all cases?

What's new:

• Reverted Fix issue #1216 #1217
• TiltCrashJumpjet=no units will correctly tilt in air. Since previously there's no chance for jumpjets to tilt in air so I added a small new feature to test it out:

Recoil force

• You can now tilt a voxel unit after firing to simulate the recoil force.
• The body's pseudo "moment of inertia" is simplified to be linearly proportional to the body voxel's size ratio rather than quadratically.

In rulesmd.ini:

[SOMEWEAPON]  ; WeaponType
RecoilForce=  ; floating point value

[github-actions]

Nightly build for this pull request:

• compiled-dll-270131beaaabc228d4f32b420d7cfb0032733041.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[mevitar]

RecoilForce= works. I assume it's a value between 0 to 1, since anything above 1 doesn't seem to give any effect (1, 50 and 500 had the same result).
As expected, units can flip themselves to death with their own weapon, but it depends on ROF, RecoilForce value and unit's weight. I think voxel section size also matters.
Turreted units seem to have an easier time to flip themselves, especially if firing from an angle.
Ground, hover and jumpjet voxels (default value of TiltCrashJumpjet was used) behave in the same manner, whether they are on ground or in air, and they all die if they flip themselves. Shp untis do not flip.

[mevitar]

RecoilForce= works. I assume it's a value between 0 to 1, since anything above 1 doesn't seem to give any effect (1, 50 and 500 had the same result).

Hmm, no, nevermind, higher values do work. It's more noticeable the higher unit's weight is.
Still, there is something else that limits how much a unit can flip. On some angles the unit will cap its flipping at around 45 degrees, no matter how high the RecoilForce= is, but let the same unit fire at a different angle and it's instant flip.

Well, forced flipping wasn't the intention of this feature, so i'll end saying that, for what RecoilForce is meant for, it seems to work fine.

[mevitar]

I've been testing the jumpjet facing fix for a while now, and this time, i found no issues. Also not sure what the changes around OmniFire=yes are supposed to be, but i found no problems with it either.

I only have a question regarding this line in the documentation: "Jumpjets are recommended to have the same value of body ROT and JumpjetTurnRate". Is it necessary? Jumpjets seem to use JumpjetTurnRate instead of ROT for everything now if when they are inair, so ROT value doesn't really matter anymore.
Well, I suppose ROT is still used for turrets...
(BTW, Ares' TurretROT on jumpjet still works fine, didn't see any problems compared how it behaved earlier)

[chaserli]

RecoilForce= works. I assume it's a value between 0 to 1, since anything above 1 doesn't seem to give any effect (1, 50 and 500 had the same result).

Hmm, no, nevermind, higher values do work. It's more noticeable the higher unit's weight is. Still, there is something else that limits how much a unit can flip. On some angles the unit will cap its flipping at around 45 degrees, no matter how high the RecoilForce= is, but let the same unit fire at a different angle and it's instant flip.

I admit that my math model is a bit simplified in this case. There might be a few oversights.

I assumed that the impulse was on the XY plane and inverse to the direction of the turret angle, thus I did a simple orthogonal decomposition and calculated the angular momentum separately. As for the rotation, it is assumed that the rotation axes are the front/back-bottom and sideways-bottom, the body is clamped to these axes. According to Newton's second law, the moment is the angular acceleration times the moment of inertia, and the moment of inertia is quadratically proportional to the distance to the axis.
It might be arguable that the direction should be normal to the XY plane or to be normal to the plane defined by the rotational axis and the firing position, idk.
Also considering these might not be good, especially the quadratic proportionality to the voxel size ratio. Should I just discard the Weight multiplier and stay linearly proportional to the voxel size? or just don't consider this at all?

I only have a question regarding this line in the documentation: "Jumpjets are recommended to have the same value of body ROT and JumpjetTurnRate". Is it necessary? Jumpjets seem to use JumpjetTurnRate instead of ROT for everything now if when they are inair, so ROT value doesn't really matter anymore.
Well, I suppose ROT is still used for turrets...
(BTW, Ares' TurretROT on jumpjet still works fine, didn't see any problems compared how it behaved earlier)

Before Ares introduced TurretROT, the turret's turn rate was just ROT. Jumpjet locomotor has its own facing independent of the unit's facing, and this facing's ROT is JumpjetTurnRate, it was a bad design. When a jumpjet turns it's this facing turns and the body facing synchronizes with it constantly. The glitching you had in #1216 was because I accidentally let the jumpjet facing and the body facing turn at the same time when firing with non-omnifire weapon, and if the body ROT is not the same as JumpjetTurnRate, the body's facing sometimes turns with ROT, sometimes syncs with the jumpjet facing. Even though I should have fixed it, to be safe I would say just let the body ROT the same as JumpjetTurnRate and as for the turret just use Ares' TurretROT

[mevitar]

Got a seemingly random crash in the 2nd build (not this newest one). Didn't get it before, and can't get it again. EIP is 00000000 so don't even know if it's in YR range or outside.
https://drive.google.com/file/d/1ubk9SyLSZypvZfsgVojYODimtkWtapXo/view?usp=drive_link

[mevitar]

Newest build, and i'm not sure removing weight was a good idea. It seems extremely difficult now to make voxels recoil only a little bit, and I don't really see any difference between RecoilForce 1 and 500 no matter which unit i test,
If it stays this way, i think that the force should be reduced further.

[chaserli]

Newest build, and i'm not sure removing weight was a good idea. It seems extremely difficult now to make voxels recoil only a little bit, and I don't really see any difference between RecoilForce 1 and 500 no matter which unit i test, If it stays this way, i think that the force should be reduced further.

The weight was merely a multiplier, therefore I removed it. The value for the force is a floating number, and it was even usually not bigger than 0.1. Now I take the voxel size into account, and used a new model for the moment of inertia, now firing 45 deg to the front would not tilt the most anymore, and you could scale the value up a bit.

I haven't tested a big number like 500, theoretically such a large angular velocity would tilt the unit to death

[Fryone]

example with RecoilForce=0.3 on Howitzer and RecoilForce=0.7 on Tank destroyer.

Recoil is awesome, wanted to re-create it through FeedbackWeapon
Useful params are between 0.2 and 2.

[chaserli]

Recoil is awesome, wanted to re-create it through FeedbackWeapon Useful params are between 0.2 and 2.

@Fryone It should depend on voxel size, but yeah the order of magnitude is around that range.
How's the behavior turret and jumpjet vehicles?

[Fryone]

Tested on grizzly and on robot tank. Works fine.
One thing is that on low values, it looks like turreted vehicles tilting on side, but I'm not sure. Maybe its just draws like that.

[chaserli]

Tested on grizzly and on robot tank. Works fine. One thing is that on low values, it looks like turreted vehicles tilting on side, but I'm not sure. Maybe its just draws like that.

@Fryone no it's my current physics law imposed on this logic. Do you think it should be the inverse? I mean given the same force, firing forward should tilt more than firing sideways for a voxel that has longer dimension on forward direction?

[Fryone]

I mean this:

Should it be like that? This is RecoilForce=0.22.

On higher values expected tilt direction is exact opposite of firing direction.

[Fryone]

Overall physics and logics is 100% good.

[chaserli]

Should it be like that? This is RecoilForce=0.22.

On higher values expected tilt direction is exact opposite of firing direction.

I think it should be the game's rounding error when processing falling back from tilting in this case

[mevitar]

RecoilForce scaling is much better now.

On higher values expected tilt direction is exact opposite of firing direction.

I couldn't reproduce such behavior myself. Does that voxel have a barrel separate from the turret? Unit having a turret does affect tilting, so maybe separate barrels will also affect it in some way.

I haven't tested a big number like 500, theoretically such a large angular velocity would tilt the unit to death

That was my intent testing such high numbers. That's also why i specifically mention that there seems to be a cap on how much a unit can tilt per each shot, because even such numbers do not make it flip instantly. One needs multiple shots in very rapid succession to completely flip a unit (and you don't need high RecoilForce= value to achieve that).

[mevitar]

What happened? Why was this closed? I thought it was completed and just needed to be merged.

[chaserli]

What happened? Why was this closed? I thought it was completed and just needed to be merged.

• I've been doing fluid mechanics these years and I'm no longer familiar with solid mechanics. Sure, it won't take long to revise a bit rigid body dynamics but I don't have time and mood. Once the math is determined it can't be changed.
• What if an infantry firing inside an opentopped vehicle, how to define that behavior?

[mevitar]

• I've been doing fluid mechanics these years and I'm no longer familiar with solid mechanics. Sure, it won't take long to revise a bit rigid body dynamics but I don't have time and mood. Once the math is determined it can't be changed.

For me personally, the feature felt done and ready, so i don't see the need to change anything. Whatever calculations are there, just keep them as they are.
The entire flip logic in YR is a mess anyway. Only in a situation where that entire thing is rewritten completely, the math for recoil force should be reconsidered and revisited, so everything is consistent.

• What if an infantry firing inside an opentopped vehicle, how to define that behavior?

I don't know how it works from inside, so i don't know what's the issue. Can't just apply recoil force from the AlternateFireFLH coord of the weapon being fired? Does OpenTopped logic need some special handling here?
If it's such a problem, you can always add a note that recoil force doesn't support firing from transports.

[Metadorius]

Suggested change

	if (jjLoco->State == JumpjetLocomotionClass::State::Grounded)
	pThis->PrimaryFacing.SetDesired(tgtDir);
	if (jjLoco->State == JumpjetLocomotionClass::State::Grounded)
	pThis->PrimaryFacing.SetDesired(tgtDir);

[Metadorius]

Suggested change

	- RecoilForce
	- Voxel unit weapon recoil force

[Metadorius]

So the consensus was to simplify the logic behind this and tie the stuff onto Weight, and in general be inline with how Rocker warheads work.