@PlaneFlightX Hi! Changing the glide slope is fairly simple. You only need to change the variable GlideSlope into 6 - clamp(atan(), 5, 7). And in the display, you need to change the multiplier. If you use the HUD, the code will be voffset={GlideSlope * 2 + 0.5425}.
I think if you want to make it easy to tune in the frequency, 0.5 is fine. You just need to redefine all the frequencies in the variable list (in the activator field). In real life, the NAV frequency often adds by 0.05, and for COM it can be 0.025.
@SnoWFLakE0s I find variables really useful at retaining values! I think my next step is to make a dial input, but I hope SP will someday add the turnable nob button 🙃
@Formula350 I agree. There is a general lack of documentation around more advanced features (say XML). Still, I find this document helpful. But I do not know if it is extensive.
Actually {FTcode} is probably what you mean. It can be inserted anywhere following =. There is something not mentioned though. {FTcode;000} is a way to formulate the output display of numeric values. {FTcode?"Atext":"Btext"} produces strings.
@PlaneFlightX Thanks for the review! I see why you thought the GS is buggy because I chose to use 3 deg as the glide path. The diamond only moves between 2.6-3.4 degrees. It is pretty shallow for SP.
Yes, I find my trigonometry pretty different. I am still exploring all the methods. But for now, I will try to stick with asin rather than atan because the output is more manageable. I will want to use your frequency switch if you would agree. Thanks!
@PlaneFlightX Good point! I'm also pretty busy these days lol. By the way, credits of the original HUD goes to PlanariaLab. I only made a couple of changes and added ILS support.
Hi! I somehow started coding ILS for integration into the HUD system, and I noticed your posts about the similar subject. I really like how you explored the coding and building process in YT videos! As I continue work through the detailed codes, I do have some recommendations:
!A screenshot here
1. In the real world, pilots fly to the needle, unless back course. So it may be better to have the needle swinging left when you are to the right of the runway. By the way, it's better to use RWY36 rather than RWY0 (which does exist).
2. I saw you struggle with managing multiple runways, and my suggestion is to use the variable system. I defined variables such as LOCX, LOCY, GSX, GSY, ALT, RAD that can be coded into the localizer/glide slope script. So it's making a selection in the variables to feed into the function. I use clamp(atan((Longitude - LOCX) / (Latitude - LOCY)) - RAD, -5, 5) for the localizer. It is working for runway heading 0, not others yet.
3. I'm also thinking about the activation method, and I haven't checked your gauges there. But I think maybe we can collaborate a bit? Idk, just wondering.
4. I had struggle figuring out a way to solve the problem of atan because it only ranges (-90, 90). I though about using deltaangle for the localizer, which might be useful.
@TheSeventh So I’ve already made a working sample but just want to learn more about SP physics. I am particularly confused about the aerodynamic effects of a fast spinning wing as well as the rotator itself.
@edensk I do agree with you for the last part, but I do not quite understand how to use smooth to cancel out the last value. However, I just want to point out that the sum function can record a value based on the activation of another group, which means continuing a previous procedure even when disturbed by a sudden input.
@PlaneFlightX Hi! Changing the glide slope is fairly simple. You only need to change the variable
GlideSlopeinto6 - clamp(atan(), 5, 7). And in the display, you need to change the multiplier. If you use the HUD, the code will bevoffset={GlideSlope * 2 + 0.5425}.I think if you want to make it easy to tune in the frequency, 0.5 is fine. You just need to redefine all the frequencies in the variable list (in the activator field). In real life, the NAV frequency often adds by 0.05, and for COM it can be 0.025.
Also, really looking forward to your new design!
+1@SnoWFLakE0s I find variables really useful at retaining values! I think my next step is to make a dial input, but I hope SP will someday add the turnable nob button 🙃
@Formula350 I agree. There is a general lack of documentation around more advanced features (say XML). Still, I find this document helpful. But I do not know if it is extensive.
Actually
{FTcode}is probably what you mean. It can be inserted anywhere following=. There is something not mentioned though.{FTcode;000}is a way to formulate the output display of numeric values.{FTcode?"Atext":"Btext"}produces strings.@PlanariaLab
+1@PlaneFlightX
@SnoWFLakE0s
@PlaneFlightX
@PlaneFlightX Thanks for the review! I see why you thought the GS is buggy because I chose to use 3 deg as the glide path. The diamond only moves between 2.6-3.4 degrees. It is pretty shallow for SP.
Yes, I find my trigonometry pretty different. I am still exploring all the methods. But for now, I will try to stick with
+1asinrather thanatanbecause the output is more manageable. I will want to use your frequency switch if you would agree. Thanks!I actually found a new way of calculating horizontal location, which might be interesting for you. The model is here.
+2@PlaneFlightX Good point! I'm also pretty busy these days lol. By the way, credits of the original HUD goes to PlanariaLab. I only made a couple of changes and added ILS support.
Hi! I somehow started coding ILS for integration into the HUD system, and I noticed your posts about the similar subject. I really like how you explored the coding and building process in YT videos! As I continue work through the detailed codes, I do have some recommendations:
+1!A screenshot here
1. In the real world, pilots fly to the needle, unless back course. So it may be better to have the needle swinging left when you are to the right of the runway. By the way, it's better to use RWY36 rather than RWY0 (which does exist).
2. I saw you struggle with managing multiple runways, and my suggestion is to use the variable system. I defined variables such as LOCX, LOCY, GSX, GSY, ALT, RAD that can be coded into the localizer/glide slope script. So it's making a selection in the variables to feed into the function. I use
clamp(atan((Longitude - LOCX) / (Latitude - LOCY)) - RAD, -5, 5)for the localizer. It is working for runway heading 0, not others yet.3. I'm also thinking about the activation method, and I haven't checked your gauges there. But I think maybe we can collaborate a bit? Idk, just wondering.
4. I had struggle figuring out a way to solve the problem of
atanbecause it only ranges (-90, 90). I though about usingdeltaanglefor the localizer, which might be useful.I should have thought about counter-rotating rotors earlier lol: https://www.simpleplanes.com/a/0yhN7U/Surprisingly-stable-copter
@TheSeventh So I’ve already made a working sample but just want to learn more about SP physics. I am particularly confused about the aerodynamic effects of a fast spinning wing as well as the rotator itself.
@edensk I do agree with you for the last part, but I do not quite understand how to use smooth to cancel out the last value. However, I just want to point out that the sum function can record a value based on the activation of another group, which means continuing a previous procedure even when disturbed by a sudden input.