@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
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.
@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.
@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.
@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.
@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!
@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 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 @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.
@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
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.
@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.
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.
By the way, how did you not explode the rotator when it's spinning at 100??? I usually keep the input like sum(Throttle * 8) and speed at 5. Did you use any mods?
@Dragorans NACAPROP is a type of wing that SP used for prop engines. You can edit it with Overload on the Wings page. There's not a lot of differences between NACAPROP and Symmetric. NACAPROP also produces less force than Symmetric, but it does not stall whatsoever. So it makes the rotor perform better at low speeds.
I assume you are using rotators to spin wing blades. If that's correct, you need to place them in pairs to prevent spinning. Then try to change the wing type to NACAPROP which has better high AOA performance. Also, add a line in the "WIngs" section in Overload specifying liftScale to something like 5 or 10. Hope this helps!
Theoretically you could find every attribute in resources.assets file. In archaic versions that’s where you can change the default setting for parts. I recalled changing the engine output there.
@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
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.
+1@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.
+3@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.
@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@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!
Seems like it uses repeat(Time) to generate new numbers, so I guess, true random? Really creative work!
+2Looking cool! I don't quite get the point "in aggressive mode". Why is it necessary? Thx
@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.
+1Great job though the code looks pretty complicated lol
Inaccurate performance cost lol...
+2很厉害 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 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 @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.
+1@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.
But technically the mod works on android?? Guess better give user the option to work around
+4Thanks for using the ILS system! I am also still improving it as well :)
+1Possibly 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.
Android plz? Idk but I guess this might be possible in Android?
+6@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
Actually 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!
+1I 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
@Dragorans check this example. Hope it helps
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.
+3By the way, how did you not explode the rotator when it's spinning at 100??? I usually keep the input like sum(Throttle * 8) and speed at 5. Did you use any mods?
@Dragorans NACAPROP is a type of wing that SP used for prop engines. You can edit it with Overload on the Wings page. There's not a lot of differences between NACAPROP and Symmetric. NACAPROP also produces less force than Symmetric, but it does not stall whatsoever. So it makes the rotor perform better at low speeds.
I assume you are using rotators to spin wing blades. If that's correct, you need to place them in pairs to prevent spinning. Then try to change the wing type to
NACAPROPwhich has better high AOA performance. Also, add a line in the "WIngs" section in Overload specifyingliftScaleto something like 5 or 10. Hope this helps!Theoretically you could find every attribute in resources.assets file. In archaic versions that’s where you can change the default setting for parts. I recalled changing the engine output there.