Request of import for lua applyTorqueCenter function within the e2 methods.

[raven1934]

Hey, in past I realized the torque implementation in wiremod->expression2 is done in past with two applyforces due to back when it was implemented the chip not having access to lua implementation of applyTorqueCenter method. I've had chance to experiment with Pythons version of imported Lua function within a server I frequent in GarrysMod and I think other e2 users would appreciate the increased precision that the actual implementation offers for any use case they may have for it.

The issue with current implementation for current applyTorque function is that it's imprecise and despite it's very good implementation it does still cause issues if your chosen project demands certain degree of controlled predictability while designing things, I am a particular to the flaw of perfectionism and I would imagine some other people may be also expecting the controls to respond in a linear fashion.

At the moment you likely wont be able to seize an object with the torque function within one tick time. As I've tested the E:applyTorque(E:toLocalAxis(-SpinningObject:angVelVector())*E:inertia()/tickInterval()), is suppoced to freeze the object still due to fully countering the rotational inertia of the specific object E. But this only works in the Python1320's imported engine function and leaves either some inertia to be yet countered or even causes wobbling due to going over the given inertia value.

My suggestion is that we would embrace the engine torque function in it's own new method but leave deprecated version of the applyTorque with its current implementation on for sake of backwards compatibility. I'm sure there's a group of individuals who would appreciate the increased precision of the command and still understand the need to keep the old version in aswell as it has a significant size of implementations still dependent on it due to the age of the workaround.

Hope you side with my suggestion and best regards,
Raven1934.

[thegrb93]

It would need to be a separate applyTorque, with maybe second parameter to switch the conversion.

[raven1934]

What we at the moment have at meta (the server I'm playing at) is just basically method called applyTorqueCenter which avoids the methods overlapping by adding the word center at the end of the function name. But yeah either a different style of parameter requirement would work or just adding a different function name and adding to current one tag that it's deprecated or conserved for backward compatibility or similar stuff would be probably be a good idea.

I highly recommend also testing the benefits of complete inertial cancellation to see what the fix would implement, though it will not affect everyone's project and likely there's good workarounds that are making the issue a medium/minor one, I still think for sake of added precision and linear response to force/torque coupling we would likely see benefits to the added function especially with the people who are more involved with vehicle/aircraft/train builds. Plus if we linearize the responce we are also likely better able to control stuff like countering force generated torque while applying force in offset and similar stuff.