@Wolfgang8261YT G limiter took me a while to refine. Don’t use VerticalG. As you rotate the plane while pitching up it takes time to develop G’s but you can predict the G force by how fast the plane is rotating and the speed you are doing. The raw variable you should target is pitchrate. I created a variable called VertG which equates the expected G based on pitch rate and ground speed (simple circular motion mathematics). You can use debug expression to see VertG next to verticalG. Difference is the response time. So limiting based on VertG is really limiting using Pitchrate but more digestible as a G limiter. I find the pitch input required for say 10G then slowly multiply that pitch input by a GLim variable which is normally 1 up to say 8G then slowly ramps down to 0.6 or whatever when it reaches 10G sort of like artificially releasing the stick (something the pilot would do). I found that’s the smoothest way.
@Wolfgang8261YT Have a look at this for some inspiration. Pretty much the original wasp but changed the MassScale of all front fuselage parts to zero to bring the CG backwards, changed the wings to Flat Bottom, changed the vertical stabilisers to NACAPROP, then funky trees for control surfaces to stabilise the aircraft. (similar code to the raptor). Because of no thrust vectoring, you NEED to use the main wing surfaces in conjunction with the tail to get stability. Plane is not perfect and can still spin particularly on Pitch down. I can however see that with the right logic, it can do whats expected.
@Wolfgang8261YT I really only made modifications to Guyfolks model. I think it’s totally reasonable to add long slim wings to the plane body to simulate body lift because fuselage parts have no lift. This raptor has that. Absolutely most important thing to do for a fighter is get the cg much more rearward than 99.99% of posted planes. It should be pretty much at the centre of lift. Then you can have the wings and tail providing lift for maximum turn performance. then you only really need subtle movements of your control surfaces, you’ll see that in this raptor (ps 1.07 flies even better than this 1.06). Fbw should create the stability to counter that effect. also aero effects increase with v^2, so you need to reduce the deflection as you gain speed, hence divide by pow(IAS,2). Make sure for example elevator is not only responding to pitch input but Pitch - Pitchrate/some constant and play with the numbers. Pitchrate is there to ensure if the plane keeps rotating because now you’ve made it balanced with the cg, it can then correct itself before it gets out of hand.
@Wolfgang8261YT The tomcat is indeed beautiful but ironically thrust vectoring makes it much easier to correct for aerodynamic deficiencies. From what I’ve learnt, I don’t think there are any aero interactions between surfaces but rather each airfoil functions independently and max lift is at ~28 AoA. Aero assessments of the f22 and su57 showed increasing lift all the way up to 40-45 AoA, yet they probably use symmetric airfoils for low drag. So I’ve canted all wings 1.4 deg forward and used flat bottom airfoils to closest approximate the desired lift vs AoA profile. Tomcat could reach 50 AoA if I remember correctly. But its controls are horizontal and vertical stabilisers and wing spoilers. Tails are also vertical rather than slanted so they won’t ever help pitch control. I just see so many limitations in simple planes physics modeling to be able to approximate a tomcat. You could make it fly smooth, but it would have to be severely aoa limited which is unrealistic and not so fun.
@Wolfgang8261YT thanks again. Yea for sure I’m open to ideas. Can’t make any promises though, based on my limited creativity, time and other commitments.
@Wolfgang8261YT Thank you my friend for the immensely kind words. It really encourages me to keep pushing the envelope. My hope is to inspire and share my learnings with others and grow the community.
@Wolfgang8261YT
Thank you my friend, since the news about SimplePlanes 2, I’ve learnt some more about fly by wire logic, I’ll release a new version of this with much more natural controls soon.
No matter the performance headroom, (12900k, 3080ti) there seems to be intermittent juddering in the motion. it varies depending on the refresh rate and gets bad at >100hz refresh rate on PC. I identified no dropped frames when it occurs, so I can only conclude its related to the physics updates that drop a refresh every few seconds. Can we manually tweak physics update rates to see if it can be improved?
@Khanhlam @MrCOPTY
Thank you so much for the kind words!
@GuyFolk
No worries mate, cant wait to see what more creations you come up with, keep up the good work!
also new version released if you guys are interested!
I might just create a new post to explain it better but in the meantime, fly my plane in a gentle manner with minimal pitch input and no rudder input. compare the values of:
"YawRate" and
"YawRate + cos(PitchAngle) * sin(RollAngle) * 561.5/max(5,TAS)" and
"rate(-AngleOfSlip)".
You are correct about keeping AngleOfSlip at 0 will make it yaw to the ground under high bank angles but thats the whole point of a coordinated turn is to keep AngleOfSlip at 0.
A really simple replacement for "YawRate" when controlling your rudder would be "rate(-AngleOfSlip)" but that has its own set of problems during PSM as the value goes crazy when abs(AngleOfAttack) approaches 90.
My final iteration of an expression which approximates rate(-AngleOfSlip) without the above issues is:
I love this plane! No-one has managed to provide anything with such smooth physics before. I hope you don't mind, I used your plane as a foundation for something I built. Please check it out and let me know your thoughts (kFlR2U).
@Wolfgang8261YT G limiter took me a while to refine. Don’t use VerticalG. As you rotate the plane while pitching up it takes time to develop G’s but you can predict the G force by how fast the plane is rotating and the speed you are doing. The raw variable you should target is pitchrate. I created a variable called VertG which equates the expected G based on pitch rate and ground speed (simple circular motion mathematics). You can use debug expression to see VertG next to verticalG. Difference is the response time. So limiting based on VertG is really limiting using Pitchrate but more digestible as a G limiter. I find the pitch input required for say 10G then slowly multiply that pitch input by a GLim variable which is normally 1 up to say 8G then slowly ramps down to 0.6 or whatever when it reaches 10G sort of like artificially releasing the stick (something the pilot would do). I found that’s the smoothest way.
This model does look really nice and low parts, I'll see if I can work on the physics.
@Wolfgang8261YT Have a look at this for some inspiration. Pretty much the original wasp but changed the MassScale of all front fuselage parts to zero to bring the CG backwards, changed the wings to Flat Bottom, changed the vertical stabilisers to NACAPROP, then funky trees for control surfaces to stabilise the aircraft. (similar code to the raptor). Because of no thrust vectoring, you NEED to use the main wing surfaces in conjunction with the tail to get stability. Plane is not perfect and can still spin particularly on Pitch down. I can however see that with the right logic, it can do whats expected.
https://www.simpleplanes.com/a/rVtKfH/Wasp-Tanker-CG12
@Wolfgang8261YT I really only made modifications to Guyfolks model. I think it’s totally reasonable to add long slim wings to the plane body to simulate body lift because fuselage parts have no lift. This raptor has that. Absolutely most important thing to do for a fighter is get the cg much more rearward than 99.99% of posted planes. It should be pretty much at the centre of lift. Then you can have the wings and tail providing lift for maximum turn performance. then you only really need subtle movements of your control surfaces, you’ll see that in this raptor (ps 1.07 flies even better than this 1.06). Fbw should create the stability to counter that effect. also aero effects increase with v^2, so you need to reduce the deflection as you gain speed, hence divide by pow(IAS,2). Make sure for example elevator is not only responding to pitch input but Pitch - Pitchrate/some constant and play with the numbers. Pitchrate is there to ensure if the plane keeps rotating because now you’ve made it balanced with the cg, it can then correct itself before it gets out of hand.
@Wolfgang8261YT The tomcat is indeed beautiful but ironically thrust vectoring makes it much easier to correct for aerodynamic deficiencies. From what I’ve learnt, I don’t think there are any aero interactions between surfaces but rather each airfoil functions independently and max lift is at ~28 AoA. Aero assessments of the f22 and su57 showed increasing lift all the way up to 40-45 AoA, yet they probably use symmetric airfoils for low drag. So I’ve canted all wings 1.4 deg forward and used flat bottom airfoils to closest approximate the desired lift vs AoA profile. Tomcat could reach 50 AoA if I remember correctly. But its controls are horizontal and vertical stabilisers and wing spoilers. Tails are also vertical rather than slanted so they won’t ever help pitch control. I just see so many limitations in simple planes physics modeling to be able to approximate a tomcat. You could make it fly smooth, but it would have to be severely aoa limited which is unrealistic and not so fun.
@Wolfgang8261YT thanks again. Yea for sure I’m open to ideas. Can’t make any promises though, based on my limited creativity, time and other commitments.
That was quick!, enjoy :)@Aviationlover101
+1@Wolfgang8261YT Thank you my friend for the immensely kind words. It really encourages me to keep pushing the envelope. My hope is to inspire and share my learnings with others and grow the community.
@Wolfgang8261YT
Thank you my friend, since the news about SimplePlanes 2, I’ve learnt some more about fly by wire logic, I’ll release a new version of this with much more natural controls soon.
No matter the performance headroom, (12900k, 3080ti) there seems to be intermittent juddering in the motion. it varies depending on the refresh rate and gets bad at >100hz refresh rate on PC. I identified no dropped frames when it occurs, so I can only conclude its related to the physics updates that drop a refresh every few seconds. Can we manually tweak physics update rates to see if it can be improved?
@Khanhlam @MrCOPTY
Thank you so much for the kind words!
@GuyFolk
No worries mate, cant wait to see what more creations you come up with, keep up the good work!
also new version released if you guys are interested!
+2@GuyFolk
I might just create a new post to explain it better but in the meantime, fly my plane in a gentle manner with minimal pitch input and no rudder input. compare the values of:
"YawRate" and
"YawRate + cos(PitchAngle) * sin(RollAngle) * 561.5/max(5,TAS)" and
"rate(-AngleOfSlip)".
You are correct about keeping AngleOfSlip at 0 will make it yaw to the ground under high bank angles but thats the whole point of a coordinated turn is to keep AngleOfSlip at 0.
A really simple replacement for "YawRate" when controlling your rudder would be "rate(-AngleOfSlip)" but that has its own set of problems during PSM as the value goes crazy when abs(AngleOfAttack) approaches 90.
My final iteration of an expression which approximates rate(-AngleOfSlip) without the above issues is:
"
(4/3) * clamp01(IAS>0.2)
*
(
YawRate * cos(AngleOfAttack) - RollRate * sin(AngleOfAttack)
+
clamp01(cos(AngleOfAttack))
*
clamp01(cos(AngleOfSlip))
*
cos(PitchAngle)
*
sin(RollAngle)
*
561.5/max(TAS,5)
)
"
try all 4 values in the console simultaneously whilst flying and tell me your thoughts.
PS made some changes since this version and I'll release an update soon.
+1I love this plane! No-one has managed to provide anything with such smooth physics before. I hope you don't mind, I used your plane as a foundation for something I built. Please check it out and let me know your thoughts (kFlR2U).
+3