Jumpjet facing additial fixes, TiltCrashJumpjet minor fix, recoil force

[chaserli]

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

What's new:

• Reverted #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 moment of inertia is simplified and normalized to take only the body's weight and the body voxel's size ratio into account.

In rulesmd.ini:

[SOMEWEAPON]  ; WeaponType
RecoilForce=  ; floating point value

[coderabbitai[bot]]

Walkthrough

This update introduces significant enhancements and fixes to unit and building behaviors, particularly focusing on recoil force implementation, jumpjet functionalities, and various logic improvements in the Phobos mod. It addresses visual glitches, firing restrictions, and enhances control mechanics, ensuring a more refined and bug-free gaming experience.

Changes

Files	Change Summary
CREDITS.md, .../New-or-Enhanced-Logics.md, .../Whats-New.md	Introduced RecoilForce and improved tilting for voxel units.
docs/Fixed-or-Improved-Logics.md, .../New-or-Enhanced-Logics.md	Enhanced unit behaviors, fixed bugs in animations and interactions, updated weapon and jumpjet logic.
src/Ext/Unit/Hooks.Jumpjet.cpp, src/Ext/WeaponType/Body.cpp, src/Ext/WeaponType/Body.h	Addressed jumpjet issues, added RecoilForce property, and other related enhancements.

Related issues

• Phobos-developers/Phobos#1216: The fixes and enhancements to jumpjet behavior and firing restrictions could potentially address the irregular jumpjet behavior when attacking with an OmniFire=no weapon.

🐰✨ In the realm of code, where logic intertwines, A rabbit hopped through, fixing lines. With a leap and a bound, errors fell, As it cast on the code, a magic spell. Recoil and jumpjets, now finely tuned, In the dance of battle, gracefully pruned. 🚀🐇

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

:bangbang: IMPORTANT Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions[bot]]

Nightly build for this pull request:

• compiled-dll-406b19bb43f20c13a7fb36279fec7bcc5ca7fcf1.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.