@MobileBuilder21 If you consider how many years SP has been around for, then you might find it already surpassed many other games in terms of development. SP is not dependent on an active server except for the forum, so players may continue. For any computer software, the development cycle needs to come to an end. Especially, working on ancient architecture is far less efficient than making something newer and better. That appears to be same between MSFS 2020 and 2024. So I am optimistic about the project anyways.
I believe this is the TextMesh Pro document you wanted. You can use {FTcode} to substitute the number after the equal sign, or {FTcode ? "<color=>" : "<color>"} to substitute some tags.
If you consider how many years SP has been around for, then you might find it already surpassed many other games in terms of development. SP is not dependent on an active server except for the forum, so players may continue. For any computer software, the development cycle needs to come to an end. Especially, working on ancient architecture is far less efficient than making something newer and better. That appears to be same between MSFS 2020 and 2024. So, I am optimistic about the project anyways.
@MrCOPTY That's funny, I didn't check for any other content before publishing. I just found some unlisted posts from months ago and decided to make them public so others may find it. Let me know if this post is improper so I can remove it, yet I guess we had different approaches to implementing basically the same feature.
@FlightFun Hi, IIRC you need to copy a few variables using the lower-right button with an "x" on it. They define the location of the simulated beacon. If ILS still doesn't move, you might be too far away from the runway. I haven't touched SP for a while and don't know if anything has changed.
Nice work! I wonder if you prefer 3 digits in the 7-seg display, such as HDG 000 instead of HDG 0? This can be achieved by HDG {THEAD;000}, which is just IMHO.
@PlaneFlightX @pilotman10 Some of the functions are not implemented yet. Now only Heading, LNAV, Altitude, VS, and Approach (only at Yeager), plus Autothrottle. To change the navigation point, disengage LNAV then use the Numpad to enter a new coordinate. There's no way to smoothly change altitude now (cuz the code is overly complicated). I am following the setup of the B777 autopilot unit.
There's also that seated green passenger in ancient builds which was cute. Though I cannot remember the code, you can possibly find it in old plane posts.
@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.
@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!
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.
@jerome4895 Well yes, in the variables list, change the active LOCX/LOCY to the coordinates of your VOR station, and map RAD to another input to change OBS. The GSX/GSY/ALT stuff are not needed. I cannot remember where is range defined, likely in the Localizer variable.
Edit: I looked at the code again, and it is not that simple, unfortunately. Apparently, GS position is needed in trigonometry and I haven't worked on this project for years. Perhaps someone might find a creative way of adapting the code. I know that is possible because I've already implemented that on my other proof of concept
@PlaneFlightX Well full needle deflection is only 5 degrees off course. It will become very sensitive when you get close to the runway (end, indeed). At a few miles from the threshold, you need to be really off-center to observe the indicator move away.
@PlaneFlightX I don't quite get what you mean by the sensitivity of localizer. In theory if you fly parallel to the runway at an offset, the needle should drift away because the course deviant becomes greater when you get closer to the runway.
@PlaneFlightX If I can still remember, LOCX and Y are runway ends because localizer antennae are situated there (approximately) and GSX and Y are touch-down zone. RAD is the radial of localizer (aka runway heading) but it is there if you need to offset the signal. ALT is just Altitude-AltitudeAgl. For calculation, I once used GeoGebra (free) to map all coordinates and calculate IAF and FAFs and other navaids. Because the coordinates in SP are projected (ie. in meters not DMS), it is easier to work on it than trying to fit into a GIS system.
@PlaneFlightX Sorry for the late reply. Actually, those numbers are touch-down zone (biggest white block) and runway threshold (piano keys on the other end of runway) coordinates. I literally drove the buggy to that spot and used debug function to take measurements.
Your PID equals to 0.08×(Agl-10)+0.06×VS, so at Agl10 and stabilized, the output is 0. IIRC, PD controller without integral constant is prone to drifting, which means staying in a position other than Agl10.
@UltraLight Just from my experience tuning the autoland system, probably the best way to touch down is by aiming for a fixed pitch angle, just as real-world autopilots flare. That's mostly because VS is slightly delayed than attitude change of the aircraft, and with a correct configuration and speed, the aircraft will stabilize itself for landing when you hold a proper pitch angle.
@Guat3757 Sorry to hear that, unfortunately, however, I have been far away from SP in the past year or so even though I had had a passion to make a very advanced AP system. (And I've been addicted to XP and MSFS😂) What comes down to the basis of these FT codes is just trigonometry, and the glideslope is calculated from the arcsine or arctangent function (△Height divided by horizontal or spatial distance to TDZ). For anyone interested, please feel free to explore the possibilities of the basic algorithm!
@PlaneFlightX Hi, IMHO there isn't much to do with the basic code, except fine-tuning the PID constants, which vary from plane to plane. Check if this one is newer. I am currently drawing a new HSI panel and many others, but I am not interested in building an entire plane.
@PlaneFlightX As far as I know, the ailerons work much better than the elevators. It doesn't have a yaw damper now and the autothrottle is problematic.
I'm not sure what you mean by reset, but it will disable if you push the mode button again. Also, currently roll and pitch control the target rollangle and pitchangle when AP is off, so it is entirely fly by wire.
Interesting concept! By the way, I'm wondering what is the range of input for FT? Is it possible to process long integers over 16 digits? And what about the part after the dot? Thanks
@Dragorans it works and works surprisingly well! I honestly never thought about this configuration, but I also made two modifications here. Basically I changed the rotator to 180degrees and change the blade angles to 30deg. Now you can take off from the runway. Advance to 20% throttle until 50knots and then use full throttle. It can reach 550kts.
Android plz? Idk but I guess this might be possible in Android?
+6But technically the mod works on android?? Guess better give user the option to work around
+4@MobileBuilder21 If you consider how many years SP has been around for, then you might find it already surpassed many other games in terms of development. SP is not dependent on an active server except for the forum, so players may continue. For any computer software, the development cycle needs to come to an end. Especially, working on ancient architecture is far less efficient than making something newer and better. That appears to be same between MSFS 2020 and 2024. So I am optimistic about the project anyways.
+3I believe this is the TextMesh Pro document you wanted. You can use {FTcode} to substitute the number after the equal sign, or {FTcode ? "<color=>" : "<color>"} to substitute some tags.
+3Seems like it uses repeat(Time) to generate new numbers, so I guess, true random? Really creative work!
+2Inaccurate performance cost lol...
+2I actually found a new way of calculating horizontal location, which might be interesting for you. The model is here.
+2If you consider how many years SP has been around for, then you might find it already surpassed many other games in terms of development. SP is not dependent on an active server except for the forum, so players may continue. For any computer software, the development cycle needs to come to an end. Especially, working on ancient architecture is far less efficient than making something newer and better. That appears to be same between MSFS 2020 and 2024. So, I am optimistic about the project anyways.
+1@MrCOPTY That's funny, I didn't check for any other content before publishing. I just found some unlisted posts from months ago and decided to make them public so others may find it. Let me know if this post is improper so I can remove it, yet I guess we had different approaches to implementing basically the same feature.
+1@FlightFun Hi, IIRC you need to copy a few variables using the lower-right button with an "x" on it. They define the location of the simulated beacon. If ILS still doesn't move, you might be too far away from the runway. I haven't touched SP for a while and don't know if anything has changed.
+1It's making me really want to code a PFD, hopefully, someday.
+1很厉害 I would recommend adding ;f3 or ;f2 in the brackets so the output is less sensitive. Such as pos={sin(RollAngle);f3}px
+1@MrCOPTY May I have the link please? Thanks!
+1Nice work! I wonder if you prefer 3 digits in the 7-seg display, such as HDG 000 instead of HDG 0? This can be achieved by HDG {THEAD;000}, which is just IMHO.
+1@PlaneFlightX Same for me, a little while means weeks. Thanks for checking!
+1@PlaneFlightX @pilotman10 Some of the functions are not implemented yet. Now only Heading, LNAV, Altitude, VS, and Approach (only at Yeager), plus Autothrottle. To change the navigation point, disengage LNAV then use the Numpad to enter a new coordinate. There's no way to smoothly change altitude now (cuz the code is overly complicated). I am following the setup of the B777 autopilot unit.
+1Thanks for using the ILS system! I am also still improving it as well :)
+1Actually flies faster with half throttle, because the amplitude is not very much at full throttle, interesting physics 🤔
+1Thought it's an update to the stock plane lol
+1There's also that seated green passenger in ancient builds which was cute. Though I cannot remember the code, you can possibly find it in old plane posts.
+1Best way to use a jet engine!
+1@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@PlanariaLab
+1@PlaneFlightX
@SnoWFLakE0s
@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!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.@jerome4895 Well yes, in the variables list, change the active LOCX/LOCY to the coordinates of your VOR station, and map RAD to another input to change OBS. The GSX/GSY/ALT stuff are not needed. I cannot remember where is range defined, likely in the Localizer variable.
Edit: I looked at the code again, and it is not that simple, unfortunately. Apparently, GS position is needed in trigonometry and I haven't worked on this project for years. Perhaps someone might find a creative way of adapting the code. I know that is possible because I've already implemented that on my other proof of concept
@PlaneFlightX Well full needle deflection is only 5 degrees off course. It will become very sensitive when you get close to the runway (end, indeed). At a few miles from the threshold, you need to be really off-center to observe the indicator move away.
@PlaneFlightX I don't quite get what you mean by the sensitivity of localizer. In theory if you fly parallel to the runway at an offset, the needle should drift away because the course deviant becomes greater when you get closer to the runway.
@PlaneFlightX If I can still remember, LOCX and Y are runway ends because localizer antennae are situated there (approximately) and GSX and Y are touch-down zone. RAD is the radial of localizer (aka runway heading) but it is there if you need to offset the signal. ALT is just
Altitude-AltitudeAgl. For calculation, I once used GeoGebra (free) to map all coordinates and calculate IAF and FAFs and other navaids. Because the coordinates in SP are projected (ie. in meters not DMS), it is easier to work on it than trying to fit into a GIS system.@PlaneFlightX Sorry for the late reply. Actually, those numbers are touch-down zone (biggest white block) and runway threshold (piano keys on the other end of runway) coordinates. I literally drove the buggy to that spot and used debug function to take measurements.
Your PID equals to 0.08×(Agl-10)+0.06×VS, so at Agl10 and stabilized, the output is 0. IIRC, PD controller without integral constant is prone to drifting, which means staying in a position other than Agl10.
@UltraLight Just from my experience tuning the autoland system, probably the best way to touch down is by aiming for a fixed pitch angle, just as real-world autopilots flare. That's mostly because VS is slightly delayed than attitude change of the aircraft, and with a correct configuration and speed, the aircraft will stabilize itself for landing when you hold a proper pitch angle.
@Guat3757 Sorry to hear that, unfortunately, however, I have been far away from SP in the past year or so even though I had had a passion to make a very advanced AP system. (And I've been addicted to XP and MSFS😂) What comes down to the basis of these FT codes is just trigonometry, and the glideslope is calculated from the arcsine or arctangent function (△Height divided by horizontal or spatial distance to TDZ). For anyone interested, please feel free to explore the possibilities of the basic algorithm!
Looking cool! I don't quite get the point "in aggressive mode". Why is it necessary? Thx
Great job though the code looks pretty complicated lol
@PlaneFlightX Hi, IMHO there isn't much to do with the basic code, except fine-tuning the PID constants, which vary from plane to plane. Check if this one is newer. I am currently drawing a new HSI panel and many others, but I am not interested in building an entire plane.
@MrCOPTY Thanks for your support! Honestly, I am not doing a lot with SP these days, but I have lots of ideas that I am still exploring.
@PlaneFlightX As far as I know, the ailerons work much better than the elevators. It doesn't have a yaw damper now and the autothrottle is problematic.
I'm not sure what you mean by reset, but it will disable if you push the mode button again. Also, currently roll and pitch control the target rollangle and pitchangle when AP is off, so it is entirely fly by wire.
@PlaneFlightX @pilotman10 I was working on a better autopilot but it takes forever. If you are interested, please try this.
Possibly the best real-world map so far?
Created On Android??
@se34ruy Yes but I'm not really a fan of jets. Also, I'm not currently working on it until I find a better navigation system.
@Ian_Yashima Just learned a new XML attribute!
Interesting concept! By the way, I'm wondering what is the range of input for FT? Is it possible to process long integers over 16 digits? And what about the part after the dot? Thanks
I checked use Gravatar in account settings, so it looks like this umm
@hpgbproductions Thanks for the explanation! I was wondering about that 9.81 and forgot it is a constant. Now, this totally makes sense to me!
NICE display! How did you infer LateralG from GS and YawRate though? I am not sure about the physics behind lol
@Dragorans it works and works surprisingly well! I honestly never thought about this configuration, but I also made two modifications here. Basically I changed the rotator to 180degrees and change the blade angles to 30deg. Now you can take off from the runway. Advance to 20% throttle until 50knots and then use full throttle. It can reach 550kts.
Does this one work for you?
This is the XML code. If it's an older version of SP, I do not know if it works