[1.4.0-1.8.1] NavUtilities continued, ft. HSI & Instrument Landing System [v0.7.2] (2018 Apr, 1)

[Hippodingo]

Hi, I have a small problem with custom runway heading. When I create a new runway, it appears in the list, no problem there.

However, the displayed "course" is not the true heading of the runway. Here is an example:

 

NavUtilRunway
{
    ident = QUIA 31C-23
    shortID = QUIA 31C-23
    hdg = 231.123367
    body = Kerbin
    altMSL = 579.94042312353849
    gsLatitude = 49.775447646167663
    gsLongitude = -141.13259149457829
    locLatitude = 49.715454971168327
    locLongitude = -141.24756682364864
    outerMarkerDist = 8000
    middleMarkerDist = 2000
    innerMarkerDist = 300
    identOfOpposite = QUIA 31C-05
}

My runway heading is 308° ingame, however the heading here is 231°, which makes the ILS useless. I tried to change it manually in files but my changes were automatically overwritten by the mod. Do you have some ideas, please ?

[Nightside]

26 minutes ago, Hippodingo said:

Hi, I have a small problem with custom runway heading. When I create a new runway, it appears in the list, no problem there.

However, the displayed "course" is not the true heading of the runway. Here is an example:

 

NavUtilRunway
{
    ident = QUIA 31C-23
    shortID = QUIA 31C-23
    hdg = 231.123367
    body = Kerbin
    altMSL = 579.94042312353849
    gsLatitude = 49.775447646167663
    gsLongitude = -141.13259149457829
    locLatitude = 49.715454971168327
    locLongitude = -141.24756682364864
    outerMarkerDist = 8000
    middleMarkerDist = 2000
    innerMarkerDist = 300
    identOfOpposite = QUIA 31C-05
}

 

My runway heading is 308° ingame, however the heading here is 231°, which makes the ILS useless. I tried to change it manually in files but my changes were automatically overwritten by the mod. Do you have some ideas, please ?

Your points are not lined up to your runway, and it looks like the mod recalculates the heading between gsLat/Lon and LocLat/Lon, which in this case is 231 degrees. Assuming the Loc. is a point on the runway, you may need to adjust the gsLat/Lon point.

You can check here:

https://planetcalc.com/7042/

[Hippodingo]

1 hour ago, Nightside said:

Your points are not lined up to your runway, and it looks like the mod recalculates the heading between gsLat/Lon and LocLat/Lon, which in this case is 231 degrees. Assuming the Loc. is a point on the runway, you may need to adjust the gsLat/Lon point.

You can check here:

https://planetcalc.com/7042/

Thanks for your link! It's useful for sure!

 

What's weird is that these points are calculated automatically by KK itself, so that would mean KK makes some mistakes when creating them... Moreover, the runway number written in white near the touchdown area is correct (31C for 308° in my example), so in a way KK does things well ingame but goes crazy in files

 

Edit: I just checked ingame and actually, the KK's heading is correct for some runways and not for some others. For instance, the 31L runway's heading is correctly found equal at 308° while 31C is detected at 231°, while they are actually perfectly parallel.

Edited June 17, 2020 by Hippodingo
more info

[Nightside]

5 hours ago, Hippodingo said:

Thanks for your link! It's useful for sure!

 

What's weird is that these points are calculated automatically by KK itself, so that would mean KK makes some mistakes when creating them... Moreover, the runway number written in white near the touchdown area is correct (31C for 308° in my example), so in a way KK does things well ingame but goes crazy in files

 

Edit: I just checked ingame and actually, the KK's heading is correct for some runways and not for some others. For instance, the 31L runway's heading is correctly found equal at 308° while 31C is detected at 231°, while they are actually perfectly parallel.

Very strange, let me know if you find anything else out.

I have hundreds of runways in my Actual Sites project and I’m hoping these are configured correctly, but I haven’t checked in depth.

[Hippodingo]

On 6/17/2020 at 6:29 AM, Nightside said:

Very strange, let me know if you find anything else out.

I have hundreds of runways in my Actual Sites project and I’m hoping these are configured correctly, but I haven’t checked in depth.

Hi, after playing a bit more, I understand what happens. The problem only happens for runways within a certain heading angle interval (which I haven't determined). If my runway heading is not in this interval, I'll have no problem and the heading created for Navutilities is correct.

[GabeTeuton]

In case anyone is wondering, works with the lastest version:

[GabeTeuton]

I have a question for you guys, cause i believe i am clearly doing something wrong... i love flying planes, actually i love building them and have the autopilot fly them, at least in ksp... so this is clearly a must have... however i'm having issues when trying to set up the correct approach, i also do like math, (don't know as much as i could though)... so in a few words... i spent the entire morning more or less trying to figure out my vertical speed setting to meet the correct glideslope selected on the KILS (kerbal ILS i woud say (?),) the thing is, i can't find to mathematically arrive at the actual value...

actually i believe i did, i'm not sure if the math is sound... but it seems okay and it's consistent with itself... i deviced an excel sheet in which for any given right triangle with an angle of 3º, and a given distance (base) it will calculate at what altitude i am, this in turn would allow me to via the gradient of the hipo figure out my optimal VS to meet the glideslope start to finish.

FYI i know this is me being extremely picky, i just do it for the sake of it, i don't need it really and managed to land semi automatically plenty of times, but i do like it when it goes perfectly... the problem is i arrived at a gradient that seems a bit odd, 0.052408, which given i used meteres to calculate, is my VS in m/s (i guess), i tried to plot it in a graph, and yeah, makes sense, at the end of the "distance", i "arrive" or the function meets the "ground", however in ksp that does not work...

i tried getting some data to figure out if the slope may not be what it seems, but i get conflicting data, from practical observation, as the angles i get with every measurement are not consistent with each other, and i guess they should if all the approach is done at a said glideslope, also i took into consideration the error on the practical reading as i was reading KM instead of m, would be a case of calculating the angle for the 100 places in the decimal read just to see if any average value would pop up, it did not for the 5 measurements only 1 was sharing some part of the number that formed the angle, not and exact match

and alternative could be that actually the slopes are divided in which case the results could potentially make sense, however i don't think that's how they work once you enter the ILS signal, so i would be surprised if the mod was created that way

i also tried to verify my calculations (the once on the second paragraph, and they did not work either, to verify them i used a sensible point, the beacons, 10km out of the runway header there's the outer beacon, with a 3º slope, the distance i need to have from the runway should be 524.0778 (according to my second paragraph), however at that distance i'm way below the glideslope path, tested the right altitude at the outer marker and it turned out to be 675 i believe that is exactly the value when you are going thru the middle of cone the beacon transmits, so with that, let's figure out the angle/slope, which was 3.861607º, which then crosschecked at a different distance, did not match, i anyway went on and figure the VS needed to follow the slope would be 0.0675 m/s which was not haha

so i tried to experiment with different vs values and it seemed to my inexperienced eye that the glideslope was actually splitted for some reason, as the VS that followed the instrument was at first @10km out about -5m/s, then it goes down (up i guess) towards 2, and at the last moment, about 200 mts or so (may be closer) it jumps to about 4 or 5 again...

once again i may be requesting a kind of perfection that is not required whatsoever, or also i may be doing wrong calculations, or maybe i'm missinterpreting the idea of G/S, however i believe i'm not, if anyone wishes to go ahead and help me out, i'll be grateful, i guess the question would be:

is there supposed to be a unique glideslope along all the approach once you enter ILS range? (i believe the answer would be yes)

is that glideslope able to provide with math the perfect VS at which you'll hit the runway perfectly? (again, i believe it is)

am i missinterpreting anything at all? (yep, i also believe so, but i can't figure out what)

if you would like to see my calculations i can upload them

[B-STRK]

13 hours ago, GabeTeuton said:

I have a question for you guys, cause i believe i am clearly doing something wrong... i love flying planes, actually i love building them and have the autopilot fly them, at least in ksp... so this is clearly a must have... however i'm having issues when trying to set up the correct approach, i also do like math, (don't know as much as i could though)... so in a few words... i spent the entire morning more or less trying to figure out my vertical speed setting to meet the correct glideslope selected on the KILS (kerbal ILS i woud say (?),) the thing is, i can't find to mathematically arrive at the actual value...

actually i believe i did, i'm not sure if the math is sound... but it seems okay and it's consistent with itself... i deviced an excel sheet in which for any given right triangle with an angle of 3º, and a given distance (base) it will calculate at what altitude i am, this in turn would allow me to via the gradient of the hipo figure out my optimal VS to meet the glideslope start to finish.

FYI i know this is me being extremely picky, i just do it for the sake of it, i don't need it really and managed to land semi automatically plenty of times, but i do like it when it goes perfectly... the problem is i arrived at a gradient that seems a bit odd, 0.052408, which given i used meteres to calculate, is my VS in m/s (i guess), i tried to plot it in a graph, and yeah, makes sense, at the end of the "distance", i "arrive" or the function meets the "ground", however in ksp that does not work...

i tried getting some data to figure out if the slope may not be what it seems, but i get conflicting data, from practical observation, as the angles i get with every measurement are not consistent with each other, and i guess they should if all the approach is done at a said glideslope, also i took into consideration the error on the practical reading as i was reading KM instead of m, would be a case of calculating the angle for the 100 places in the decimal read just to see if any average value would pop up, it did not for the 5 measurements only 1 was sharing some part of the number that formed the angle, not and exact match

and alternative could be that actually the slopes are divided in which case the results could potentially make sense, however i don't think that's how they work once you enter the ILS signal, so i would be surprised if the mod was created that way

i also tried to verify my calculations (the once on the second paragraph, and they did not work either, to verify them i used a sensible point, the beacons, 10km out of the runway header there's the outer beacon, with a 3º slope, the distance i need to have from the runway should be 524.0778 (according to my second paragraph), however at that distance i'm way below the glideslope path, tested the right altitude at the outer marker and it turned out to be 675 i believe that is exactly the value when you are going thru the middle of cone the beacon transmits, so with that, let's figure out the angle/slope, which was 3.861607º, which then crosschecked at a different distance, did not match, i anyway went on and figure the VS needed to follow the slope would be 0.0675 m/s which was not haha

so i tried to experiment with different vs values and it seemed to my inexperienced eye that the glideslope was actually splitted for some reason, as the VS that followed the instrument was at first @10km out about -5m/s, then it goes down (up i guess) towards 2, and at the last moment, about 200 mts or so (may be closer) it jumps to about 4 or 5 again...

once again i may be requesting a kind of perfection that is not required whatsoever, or also i may be doing wrong calculations, or maybe i'm missinterpreting the idea of G/S, however i believe i'm not, if anyone wishes to go ahead and help me out, i'll be grateful, i guess the question would be:

is there supposed to be a unique glideslope along all the approach once you enter ILS range? (i believe the answer would be yes)

is that glideslope able to provide with math the perfect VS at which you'll hit the runway perfectly? (again, i believe it is)

am i missinterpreting anything at all? (yep, i also believe so, but i can't figure out what)

if you would like to see my calculations i can upload them

I'm tempted to ask for the calculations you derived, but as the old joke goes, the reason why I went to law school is that I can't do the math (and then tax law came about and RageFace.jpg).

However, both considering your disclosure that you're running an autopilot, and my own experience that I have HSI (this one), the PAPI mod, and one of the HUD mods that projects a flight path indicator, you raise an interesting point, but we may also need to check one variable.

(Though please also note that I'm running with 1.9.1 at the moment, but I don't think there would have been anything drastically altered by 1.11 to have changed anything between the compatible mods, would it?)

I can note from experience that the HSI's 3-degree glideslope does not exactly line up with the PAPI's 3 degree setting. What would be dead-center on the HSI is 3-white on the PAPI ("slightly high", but I know there is a specific slope range for that, like about 1.5 degrees I think?) .  On the other hand, by the time I can distinguish the PAPI I'm close enough that reading both instruments would be quite sensitive.

However, I can also note from a recent sweet run  where from even before the outer marker, I managed to peg the HSI centered (glide and localizer, sweeet!), and planted the HUD flight path indicator dead on  where the PAPI lights would  cross the runway (in short, the expected touchdown point), and making sure that I can keep it there, and I observed that, for as long as I was correcting to keep the flight path indicator on the touchdown point, I was flying the HSI glideslope. And the only time I deviated was at the inner marker when I saw I wasn't managing my speed properly, I was coming in too hot, so I had to kill the throttle. 

Under those conditions then, I was more or less keeping (as humanly possible) a straight line.  If the HSI glideslope indicator wasn't dancing around, then it was reading (the mod was projecting, to be more accurate programming-wise) a straight glideslope, which is exactly what a glideslope should be. 

Okay, time to dive deep into the fireworks. Spoilered because wall of text:

Spoiler

 

To answer your question: yes, a glideslope establishes a descent rate for an aircraft coming in for landing. Though some airports might require steeper glideslopes due to certain requirements (terrain, noise abatement), no glideslope I recall would wonk a a glideslope like the way your math is suggesting--especially considering how glideslopes IRL work (won't go into that here, but I can safely say that the airport ILS radio signals aren't designed to "bend"). When airfields require an approaching plane to "break" their descent rate, they do so using their published approach charts which says like, until 15 miles out from the airport do not descend below 3,000 feet, which must be flown by the pilot or input into the flight management system--but not using the ILS, and not on final approach, which is what the ILS is designed to do. 

Aside: that sort of "approach descent break" is exactly what one must be careful of on approach to KSC from deorbit. I am not sure of the math either, but there is a chance that the 3-deg glideslope from the Runway will hit the mountains west of KSC, so you don't want to fly that path until after the mountains. I think?

However, I would like to ask if you accounted for one more variable in your math and your autopilot settings: horizontal speed. A descent rate alone is immaterial in determining the glideslope, you also have to account for how fast you're going forward, which is what projects the otherwise vertical descent into a slope. 

And this goes to your autopilot settings, as well as the equation you've ginned up. Depending on which one you use (MJ, AA, etc., and I would probably want to know which one), it may or may not be controlling your ground speed at the same time as your vertical speed. Ground speed has an effect: a plane coming in hot will need to lose more altitude to hit the touchdown point than a plane going in slow, because the faster plane will get there faster and need to shed the altitude quicker. And that means faster descent rate. 

Of course, a plane is gradually shedding speed as it approaches the runway (that's the entire point!), so the descent rate would change between initial approach point and touchdown, and that has to be accounted for as well. You will notice that the vertical speed would be reducing as the plane approaches touchdown, which again is the point:  to get you to your stall speed EDIT: landing speed, though it should be close to but not at the stall speed, and so that upon flare, you're just arresting what is left of your descent rate to "butter the bread".  And if the rate of horizontal speed reduction is not constant, neither will the vertical speed reduction be.

Pilots (or their flight management systems) have to control both vertical and horizontal speeds in getting the plane to the touchdown point--and that's why there are "approach speeds" in the plane manuals to help keep things predictable. As a way of getting into the mindset: usually on Microsoft Flight Simulator, when I'm flying the standard pattern in for example a Cessna 172 (FSX, that's why), turning onto final from the base leg (meaning line up and get onto the runway), I aim not to exceed 500-700 feet/minute, and I should be at least 10-15 knots from my expected touchdown speed, or at least 5-10 knots above my final approach speed as published, precisely because of the entire VS/HS speed management thing. For a Vectors-To-Final where I use the ILS (and thus the HSI), it's almost similar, but because I am not flying with a Flight Management System to command my horizontal speed (no mods for my FSX), I just look primarily at reducing my horizontal speed using the autothrottle to get to my final approach speed (as published), but let the AP manage my vertical speed, which does evolve as I change my AT speed target and thus my throttle, so that by the time I cross the fence, I am at the speed I need to be, I kill the autopilot and wait until I have to flare. But that's my thing, and actual and instructor pilots around here will probably reprimand me for it.  (And I am open to reprimands, by the way, I am open to learning.  Though this system works for me, stop nagging me, you're not my parents!!! WAAAAAAAHHHH!!!!!!1!!!!!)

There is a way to verify this: get an autopilot to fix your ground speed instead, about 3m/s above your stall speed. Then fly the glide slope all the way down, even at that speed. All the way to disassembly-on-contact.  See if the vertical speed (measured independently, e.g., use MJ's info panels) changes so drastically as suggested by the math. Do note it will still fluctuate because the two ways an autopilot can change ground speed on landing are throttle and pitch, and pitch changes will  naturally affect vertical speed, and I don't know if or which KSP autopilots are configured to do both. (Seems like Atmo Auto does so, but I'm not sure, while I observe MJ just brute-forces with the throttle). But it should otherwise be predictably constant. 

Additional contextual information: In fact, at the landing attitude, both throttle and pitch will affect both VS and HS to varying degrees. I remember the manual from Jane's USNF, suggesting practice exercises for carrier landings, and the same exercises I also found in an ultralight manual, and the same is suggested in some FSX tutorials, in landing attitude, you'll primarily be using pitch to control airspeed, and throttle to control altitude. But, as the F/A-18 carrier missions in FSX and the infamous Top Gun for the NES Landing Sequence will show, you may end up playing with throttle as you pitch, and pitch as you throttle, to get to your speed and altitude gates for landing. Land pilots, well, they don't really have it easier, but the primary education is to be really at specific speeds and altitudes at certain points in their approach--hence my entire "where am I as a plane on the turn to final" thing up there, that was because of the FSX tutorials. It's an easier mindset to grapple with than pegging your VS to a certain "ideal" number. Better to think in terms of Velocities Never To Exceed (or shoot under). 

And this is why Flight Management Systems are a thing for commercial airliners, and why landing is a constant drill for pilots. 

TL;DR: A glideslope simply points the plane to the touchdown point, and the ideal rate at which the plane must shed its altitude. The speed at which it does so however is another thing entirely, because it depends on controlling the horizontal speed as well, which by its nature must change until touchdown. Thus the vertical speed is not a fixed number unless the horizontal speed is a fixed number. 

PS: Also, if you're using the VS indicator's needle swings in KSP to observe how dramatic the change of VS is, I recall from somewhere that the VS indicator is logarithmic, meaning that the further it goes the more it reflects larger rates. So it is not reliable to establish rate of change of VS across a wide range. Stick to just using the middle 1/3rd or 1/4th of the entire thing.)

***************

Additional Edit: I noticed in your post above yours that you have AA.  There was an older mod here somewhere that actually made for a real FMS/landing autopilot, because it allowed you to set the altitude and speed targets for the outer, middle, inner, and TD markers. So the only thing left to do was to figure out what speeds you wanted, and what the target altitudes were at the O-M-I-TD (TD being the runway altitude, of course).  And again, that means varying, but otherwise constantly reducing (so as long as the groundspeed/indicated airspeed was reducing as well), VS across the approach. 

 

 

 

Edited April 6, 2021 by B-STRK

[GabeTeuton]

4 hours ago, B-STRK said:

I'm tempted to ask for the calculations you derived, but as the old joke goes, the reason why I went to law school is that I can't do the math (and then tax law came about and RageFace.jpg).

However, both considering your disclosure that you're running an autopilot, and my own experience that I have HSI (this one), the PAPI mod, and one of the HUD mods that projects a flight path indicator, you raise an interesting point, but we may also need to check one variable.

(Though please also note that I'm running with 1.9.1 at the moment, but I don't think there would have been anything drastically altered by 1.11 to have changed anything between the compatible mods, would it?)

I can note from experience that the HSI's 3-degree glideslope does not exactly line up with the PAPI's 3 degree setting. What would be dead-center on the HSI is 3-white on the PAPI ("slightly high", but I know there is a specific slope range for that, like about 1.5 degrees I think?) .  On the other hand, by the time I can distinguish the PAPI I'm close enough that reading both instruments would be quite sensitive.

However, I can also note from a recent sweet run  where from even before the outer marker, I managed to peg the HSI centered (glide and localizer, sweeet!), and planted the HUD flight path indicator dead on  where the PAPI lights would  cross the runway (in short, the expected touchdown point), and making sure that I can keep it there, and I observed that, for as long as I was correcting to keep the flight path indicator on the touchdown point, I was flying the HSI glideslope. And the only time I deviated was at the inner marker when I saw I wasn't managing my speed properly, I was coming in too hot, so I had to kill the throttle. 

Under those conditions then, I was more or less keeping (as humanly possible) a straight line.  If the HSI glideslope indicator wasn't dancing around, then it was reading (the mod was projecting, to be more accurate programming-wise) a straight glideslope, which is exactly what a glideslope should be. 

Okay, time to dive deep into the fireworks. Spoilered because wall of text:

  Hide contents

 

To answer your question: yes, a glideslope establishes a descent rate for an aircraft coming in for landing. Though some airports might require steeper glideslopes due to certain requirements (terrain, noise abatement), no glideslope I recall would wonk a a glideslope like the way your math is suggesting--especially considering how glideslopes IRL work (won't go into that here, but I can safely say that the airport ILS radio signals aren't designed to "bend"). When airfields require an approaching plane to "break" their descent rate, they do so using their published approach charts which says like, until 15 miles out from the airport do not descend below 3,000 feet, which must be flown by the pilot or input into the flight management system--but not using the ILS, and not on final approach, which is what the ILS is designed to do. 

Aside: that sort of "approach descent break" is exactly what one must be careful of on approach to KSC from deorbit. I am not sure of the math either, but there is a chance that the 3-deg glideslope from the Runway will hit the mountains west of KSC, so you don't want to fly that path until after the mountains. I think?

However, I would like to ask if you accounted for one more variable in your math and your autopilot settings: horizontal speed. A descent rate alone is immaterial in determining the glideslope, you also have to account for how fast you're going forward, which is what projects the otherwise vertical descent into a slope. 

And this goes to your autopilot settings, as well as the equation you've ginned up. Depending on which one you use (MJ, AA, etc., and I would probably want to know which one), it may or may not be controlling your ground speed at the same time as your vertical speed. Ground speed has an effect: a plane coming in hot will need to lose more altitude to hit the touchdown point than a plane going in slow, because the faster plane will get there faster and need to shed the altitude quicker. And that means faster descent rate. 

Of course, a plane is gradually shedding speed as it approaches the runway (that's the entire point!), so the descent rate would change between initial approach point and touchdown, and that has to be accounted for as well. You will notice that the vertical speed would be reducing as the plane approaches touchdown, which again is the point:  to get you to your stall speed EDIT: landing speed, though it should be close to but not at the stall speed, and so that upon flare, you're just arresting what is left of your descent rate to "butter the bread".  And if the rate of horizontal speed reduction is not constant, neither will the vertical speed reduction be.

Pilots (or their flight management systems) have to control both vertical and horizontal speeds in getting the plane to the touchdown point--and that's why there are "approach speeds" in the plane manuals to help keep things predictable. As a way of getting into the mindset: usually on Microsoft Flight Simulator, when I'm flying the standard pattern in for example a Cessna 172 (FSX, that's why), turning onto final from the base leg (meaning line up and get onto the runway), I aim not to exceed 500-700 feet/minute, and I should be at least 10-15 knots from my expected touchdown speed, or at least 5-10 knots above my final approach speed as published, precisely because of the entire VS/HS speed management thing. For a Vectors-To-Final where I use the ILS (and thus the HSI), it's almost similar, but because I am not flying with a Flight Management System to command my horizontal speed (no mods for my FSX), I just look primarily at reducing my horizontal speed using the autothrottle to get to my final approach speed (as published), but let the AP manage my vertical speed, which does evolve as I change my AT speed target and thus my throttle, so that by the time I cross the fence, I am at the speed I need to be, I kill the autopilot and wait until I have to flare. But that's my thing, and actual and instructor pilots around here will probably reprimand me for it.  (And I am open to reprimands, by the way, I am open to learning.  Though this system works for me, stop nagging me, you're not my parents!!! WAAAAAAAHHHH!!!!!!1!!!!!)

There is a way to verify this: get an autopilot to fix your ground speed instead, about 3m/s above your stall speed. Then fly the glide slope all the way down, even at that speed. All the way to disassembly-on-contact.  See if the vertical speed (measured independently, e.g., use MJ's info panels) changes so drastically as suggested by the math. Do note it will still fluctuate because the two ways an autopilot can change ground speed on landing are throttle and pitch, and pitch changes will  naturally affect vertical speed, and I don't know if or which KSP autopilots are configured to do both. (Seems like Atmo Auto does so, but I'm not sure, while I observe MJ just brute-forces with the throttle). But it should otherwise be predictably constant. 

Additional contextual information: In fact, at the landing attitude, both throttle and pitch will affect both VS and HS to varying degrees. I remember the manual from Jane's USNF, suggesting practice exercises for carrier landings, and the same exercises I also found in an ultralight manual, and the same is suggested in some FSX tutorials, in landing attitude, you'll primarily be using pitch to control airspeed, and throttle to control altitude. But, as the F/A-18 carrier missions in FSX and the infamous Top Gun for the NES Landing Sequence will show, you may end up playing with throttle as you pitch, and pitch as you throttle, to get to your speed and altitude gates for landing. Land pilots, well, they don't really have it easier, but the primary education is to be really at specific speeds and altitudes at certain points in their approach--hence my entire "where am I as a plane on the turn to final" thing up there, that was because of the FSX tutorials. It's an easier mindset to grapple with than pegging your VS to a certain "ideal" number. Better to think in terms of Velocities Never To Exceed (or shoot under). 

And this is why Flight Management Systems are a thing for commercial airliners, and why landing is a constant drill for pilots. 

TL;DR: A glideslope simply points the plane to the touchdown point, and the ideal rate at which the plane must shed its altitude. The speed at which it does so however is another thing entirely, because it depends on controlling the horizontal speed as well, which by its nature must change until touchdown. Thus the vertical speed is not a fixed number unless the horizontal speed is a fixed number. 

PS: Also, if you're using the VS indicator's needle swings in KSP to observe how dramatic the change of VS is, I recall from somewhere that the VS indicator is logarithmic, meaning that the further it goes the more it reflects larger rates. So it is not reliable to establish rate of change of VS across a wide range. Stick to just using the middle 1/3rd or 1/4th of the entire thing.)

***************

Additional Edit: I noticed in your post above yours that you have AA.  There was an older mod here somewhere that actually made for a real FMS/landing autopilot, because it allowed you to set the altitude and speed targets for the outer, middle, inner, and TD markers. So the only thing left to do was to figure out what speeds you wanted, and what the target altitudes were at the O-M-I-TD (TD being the runway altitude, of course).  And again, that means varying, but otherwise constantly reducing (so as long as the groundspeed/indicated airspeed was reducing as well), VS across the approach. 

 

 

 

okay, that's why i came here, i feel happy!

Spoiler

https://www.youtube.com/watch?v=ZbZSe6N_BXs

I started playing FS at the 98' version haha, it's been a while since my last time actually playing FS, and when i purchased the latest one it crashed (FS) before take off, and as i was focused on other games i couldn't be bothered to re open it to try... still have a flight pending

But yeah i don't recall the ILS system descent rate changing, and yeah i do know that some approachs may require a change in VS while they are performed, but we don't have charts u.u, however I saw a chart on the back pages, it is beautiful... but that's waay too much, as this is not FS, the point is, i'm lazy, i want to set the Atmo Autopilot at a -VS @10 kms away from ksc, starting at whatever altitude, and forget about it until its time to masterswitch off and flare , that's why i'm trying to figure out an actual VS to follow the ILS suggestion. I know i can actually do my own, which i ended up doing, splitting the approach in 2 legs for the "first descent" and the last 300 meters.

however it sparked my curiosity about the mod suggested glideslope, and how it was generated as it seems that's not quite right, end even though a know a little tiny bit of coding i wouldn't know how to start searching for that module

when it comes to horizontal speed, yeah i accounted for it, in my other calculations not related to the approach, i have an excel with some formulas that calculate various things in the most kerbal way possible haha, it got a little bit serious when i started trying to calculate this as i had to watch videos to remember trig functions and triangles, and i love doing that and solving problems that way... when it came to the approach calculations i ended up disregarding the HS, as it was fixed during the entire approach to 65m/s as that's why i set as the final approach speed for the airplane, with sense rather than math (i kind of don't want to use FAR, i love the mod but i want the stock model, for now), but now that you mention it, yeah i know hs has to have a part in the calculations... but i don't know where to start, i would say that i have to add vectors to my math to split the direction of motion into the 2 vectors, BUUUUT i have a good reason to disregard HS, i use KER aswell, and as far as i can tell, the horizontal speed always matches my AA desired speed, and the vertical speed (inside AA) has no effect on the HS, AA sets up the plane parameters to meet both my desired HS and VS, so regardless of my math if i set the HS @65m/s, and the VS @-2.5m/s it will keep both values on point until changed, and i wasn't able to get a consistent VS that would follow the suggested path by this mod, keeping a constant HS

well i guess know its time to show the math, please excuse my mixture of languages

Spoiler

mostly the blue cells are inputs and the red cells are outputs
from left to right and top to bottom the first chart calculates how long will it take for a desired change in altitude at a certain speed (both H and V), the one to the right is the same calculation with different output...
the outlined one is my personal 2 leg approach after everything else failed
"second row" is some calculation i got from the internet which doesn't seem to match what i expected hahaha but it takes into account ground speed
the triangle part tells me the actual glideslope at a set distance and altitude

 

the triangle in this picture gives me altitude for a given glideslope at a distance, which makes me think about what you mentioned of HS having a part, however the actual thing i'm trying to calculated is a RATE, every glideslope will have for a set alt and distance a specific VS which has a horizontal component to it, that would mean that my calculations are taking into consideration the HS from my VS expected, but not my actual HS, which i guess is the difference between my set HS (65m/s) and the horizontal component of the expected VS, just woke up and its getting hard to explain what i mean, hmmmm, i figure you'll get it anyway, or ask away, the rest of the sheet (coloured triangles) are my experimental testing, i took note of the distance and altitude whenever they matched the glideslope in the mod, and tried to backward engineer the actual glideslope, which did not work haha

i ended up plotting all of that experimental data and then...

correcting for errors, the yellow ones are in the same range but don't seem to match at first sight (Edit: OMFG what did i mean c"orrecting for errors", it sounds so professional and sciency and can't remember the word that just came to mind (the word was pretentious), which this is not, please read "considering plausible errors" while half of the spreadsheet is just a big F error on itself, but i like it :P)

 

 

 

Edited April 6, 2021 by GabeTeuton

[B-STRK]

2 hours ago, GabeTeuton said:

okay, that's why i came here, i feel happy!

  Reveal hidden contents

https://www.youtube.com/watch?v=ZbZSe6N_BXs

I started playing FS at the 98' version haha, it's been a while since my last time actually playing FS, and when i purchased the latest one it crashed (FS) before take off, and as i was focused on other games i couldn't be bothered to re open it to try... still have a flight pending

But yeah i don't recall the ILS system descent rate changing, and yeah i do know that some approachs may require a change in VS while they are performed, but we don't have charts u.u, however I saw a chart on the back pages, it is beautiful... but that's waay too much, as this is not FS, the point is, i'm lazy, i want to set the Atmo Autopilot at a -VS @10 kms away from ksc, starting at whatever altitude, and forget about it until its time to masterswitch off and flare , that's why i'm trying to figure out an actual VS to follow the ILS suggestion. I know i can actually do my own, which i ended up doing, splitting the approach in 2 legs for the "first descent" and the last 300 meters.

however it sparked my curiosity about the mod suggested glideslope, and how it was generated as it seems that's not quite right, end even though a know a little tiny bit of coding i wouldn't know how to start searching for that module

when it comes to horizontal speed, yeah i accounted for it, in my other calculations not related to the approach, i have an excel with some formulas that calculate various things in the most kerbal way possible haha, it got a little bit serious when i started trying to calculate this as i had to watch videos to remember trig functions and triangles, and i love doing that and solving problems that way... when it came to the approach calculations i ended up disregarding the HS, as it was fixed during the entire approach to 65m/s as that's why i set as the final approach speed for the airplane, with sense rather than math (i kind of don't want to use FAR, i love the mod but i want the stock model, for now), but now that you mention it, yeah i know hs has to have a part in the calculations... but i don't know where to start, i would say that i have to add vectors to my math to split the direction of motion into the 2 vectors, BUUUUT i have a good reason to disregard HS, i use KER aswell, and as far as i can tell, the horizontal speed always matches my AA desired speed, and the vertical speed (inside AA) has no effect on the HS, AA sets up the plane parameters to meet both my desired HS and VS, so regardless of my math if i set the HS @65m/s, and the VS @-2.5m/s it will keep both values on point until changed, and i wasn't able to get a consistent VS that would follow the suggested path by this mod, keeping a constant HS

well i guess know its time to show the math, please excuse my mixture of languages

  Reveal hidden contents

mostly the blue cells are inputs and the red cells are outputs
from left to right and top to bottom the first chart calculates how long will it take for a desired change in altitude at a certain speed (both H and V), the one to the right is the same calculation with different output...
the outlined one is my personal 2 leg approach after everything else failed
"second row" is some calculation i got from the internet which doesn't seem to match what i expected hahaha but it takes into account ground speed
the triangle part tells me the actual glideslope at a set distance and altitude

 

the triangle in this picture gives me altitude for a given glideslope at a distance, which makes me think about what you mentioned of HS having a part, however the actual thing i'm trying to calculated is a RATE, every glideslope will have for a set alt and distance a specific VS which has a horizontal component to it, that would mean that my calculations are taking into consideration the HS from my VS expected, but not my actual HS, which i guess is the difference between my set HS (65m/s) and the horizontal component of the expected VS, just woke up and its getting hard to explain what i mean, hmmmm, i figure you'll get it anyway, or ask away, the rest of the sheet (coloured triangles) are my experimental testing, i took note of the distance and altitude whenever they matched the glideslope in the mod, and tried to backward engineer the actual glideslope, which did not work haha

i ended up plotting all of that experimental data and then...

correcting for errors, the yellow ones are in the same range but don't seem to match at first sight (Edit: OMFG what did i mean c"orrecting for errors", it sounds so professional and sciency and can't remember the word that just came to mind (the word was pretentious), which this is not, please read "considering plausible errors" while half of the spreadsheet is just a big F error on itself, but i like it :P)

 

 

 

OMG this is really doing the math, and also made me realize I was undeniably lucky managing to pass trigonometry in high school (God, I don't want to go back there again, haha), and I am so sorely tempted to load up a clean KSP with AA, HSI, PAPI, Flight Indicators, and what was that mod that would live-track vessel path again (Persistent Trails)? and try to fly an instrument approach, just to see what path it would trace, if I wasn't too busy trying to complete an Elcano right now along with other real life stuff. I also know there's supposed to be a mod capable of tracking flight data, so combine that and we could have a way of checking this out, finding out what's up. 

Physical data analysis really isn't my strong suit (and to think, if I have to do a case involving vehicular accidents, that's the sort of thing I have to bank on), so I admit it'll take time for me to fish through your experimental data. One thing that came to mind though, The speed measurement and AA's speed control is the airspeed control (speed along the hypo, not the triangular base), which at this regime should be close to HS but not quite. I don't know  if that should have an effect either, but like you said if you've controlled for the HS (or even the airspeed, for that matter), then the VS should be more or less fixed.  You're right, once you've stabilized on the approach, including a fixed airspeed coming in, then the VS shouldn't be varying much. The only other thing I could think about is the autopilot playing catchup/matchup to the target speeds. at the time you're capturing the data--nothing is so instantaneous, after all, and vertical speed changes could be sensitive compared to airspeed or groundspeed changes (whether as a real life physics or KSP physics thing, but I think I recall something about that in the FSX lessons field?).  All this, short of Ser actually popping the hood on his mod so we can see the details. 

This is gonna stay at the back of my head, I admit. If I ever do get the chance to try out tracing the HSI's glideslope as described above (and then the PAPI's for that matter, and maybe MJ's spaceplane landing guidance too), I'll come back to report the findings. It is not necessarily the hard numbers/data--unless there is that mod that is capable of tracking the live flight data like a black box--but at least the Persistent Trail will show whether or not there are any visually observable kinks in the glideslope. With the hard data tracking, though, we can see just exactly how varying the airspeed, VS, and ground/surface speed (if tracked), plus any control inputs, are while trying to track the ILS.  

Also, maybe the next time I fly a spaceplane in my main save (usually when I do a crew change), I'll probably be watching the instruments very closely to see if I can observe what you're observing. As a fellow FS pilot, I think you'll probably understand: oh God, the frustrations of hand-flying the perfect ILS approach. 

[GabeTeuton]

On 4/6/2021 at 9:31 AM, B-STRK said:

OMG this is really doing the math, and also made me realize I was undeniably lucky managing to pass trigonometry in high school (God, I don't want to go back there again, haha), and I am so sorely tempted to load up a clean KSP with AA, HSI, PAPI, Flight Indicators, and what was that mod that would live-track vessel path again (Persistent Trails)? and try to fly an instrument approach, just to see what path it would trace, if I wasn't too busy trying to complete an Elcano right now along with other real life stuff. I also know there's supposed to be a mod capable of tracking flight data, so combine that and we could have a way of checking this out, finding out what's up. 

Physical data analysis really isn't my strong suit (and to think, if I have to do a case involving vehicular accidents, that's the sort of thing I have to bank on), so I admit it'll take time for me to fish through your experimental data. One thing that came to mind though, The speed measurement and AA's speed control is the airspeed control (speed along the hypo, not the triangular base), which at this regime should be close to HS but not quite. I don't know  if that should have an effect either, but like you said if you've controlled for the HS (or even the airspeed, for that matter), then the VS should be more or less fixed.  You're right, once you've stabilized on the approach, including a fixed airspeed coming in, then the VS shouldn't be varying much. The only other thing I could think about is the autopilot playing catchup/matchup to the target speeds. at the time you're capturing the data--nothing is so instantaneous, after all, and vertical speed changes could be sensitive compared to airspeed or groundspeed changes (whether as a real life physics or KSP physics thing, but I think I recall something about that in the FSX lessons field?).  All this, short of Ser actually popping the hood on his mod so we can see the details. 

This is gonna stay at the back of my head, I admit. If I ever do get the chance to try out tracing the HSI's glideslope as described above (and then the PAPI's for that matter, and maybe MJ's spaceplane landing guidance too), I'll come back to report the findings. It is not necessarily the hard numbers/data--unless there is that mod that is capable of tracking the live flight data like a black box--but at least the Persistent Trail will show whether or not there are any visually observable kinks in the glideslope. With the hard data tracking, though, we can see just exactly how varying the airspeed, VS, and ground/surface speed (if tracked), plus any control inputs, are while trying to track the ILS.  

Also, maybe the next time I fly a spaceplane in my main save (usually when I do a crew change), I'll probably be watching the instruments very closely to see if I can observe what you're observing. As a fellow FS pilot, I think you'll probably understand: oh God, the frustrations of hand-flying the perfect ILS approach. 

MJ actually has a flight recorder, a quick glance at it tells me it does not record absolutly everything needed as far as i can tell, but it may work, and yes it was persistent trails (it is...), once i unlock a couple more nodes in this playthrough i may try to keep studying this and also report back.

On 4/6/2021 at 9:31 AM, B-STRK said:

Also, maybe the next time I fly a spaceplane in my main save (usually when I do a crew change), I'll probably be watching the instruments very closely to see if I can observe what you're observing. As a fellow FS pilot, I think you'll probably understand: oh God, the frustrations of hand-flying the perfect ILS approach. 

Certainly can, but it's sooooo good when it happens

 

Edit: im unable to test due to not being home, but i believe i figure out the error in my calculations, which does not mean anything yet, but i was using a 1 to 1 scale for hs and vs, which is wrong, specially if i intend to calculate the vs for the perfect approach, i need my excel for testing but seems in my head that it should work once i correct the conversion from one speed to the other, the key was in what you said earlier about the importance of hs, once qgain it seems logical to me at this point to have a broken "slope" with my calculations, i also have an idea for testing regardless of this edition, (got it from danny2462)

 

Edit 2: omggggg its "m" thats the scale, why didnt i notice it earlier, its m from y = mx +b, the love1ng gradient is the scale, maybe?

 

Edit 3:

 

Edited April 8, 2021 by GabeTeuton
idea

[The-Grim-Sleeper]

I am having serious problems while using this mod in KSP 1.12.2.

Whenever the NavUtilities box is open, either just launched from the toolbar or already active when a save is loaded, my computer slows to a crawl, and KSP itself is effectively frozen.
I am under the impression that the slowdown starts the moment the box is open, and reaches a critical state after about a second. This allows for a brief window of interaction, but I wouldn't know where to start with troubleshooting.

Log file link below. I gave it a quick look-through, but I didn't see any obvious signals.

I cannot exclude the possibility that this is caused by a weird system interaction outside KSP. I will list my system spec just in case it is:
Linux Ubuntu 18.04
KSP 1.12.2 (with Making History 1.12 and Breaking Ground 1.7.1)
NavUtilities version 0.7.2 (acquired via CKAN)

Log file on google drive:
https://drive.google.com/file/d/1mrME5DICrwW9r7YgjJcJ2ytgOGJKoE9N/view?usp=sharing

[rukhafi]

hello, I got similar problem in 1.12.2. KSP frozen when loading NavUtilities props. Maybe there is some way to fix it? Or should I relax and wait for the update? 

[bcqJC]

I'm also on KSP 1.12.2.  So far, the mod has been working ok for me.

It is a pain but you probably need to uninstall-reinstall the mods you use a few at a time to isolate which one disagrees with NavUtilities.

FWIW, here's a list of the mods I have installed.  It may help lessen the list of stuff you guys have to eliminate.

Spoiler

Mod DLLs found:
Stock assembly: Assembly-CSharp v0.0.0.0
ModuleManager v4.2.1.0
000_AT_Utils v1.9.6.0
001_AnisotropicPartResizer v1.4.1.0
002_MultiAnimators v1.2.1.0
0_00_AT_Utils_UI v1.0.0.0
CC.UI v1.0.0.0
ConfigurableContainers v2.6.1.0
ClickThroughBlocker v0.1.10.17
BlendshapeModelLoader v1.0.0.0
TexturesUnlimited v0.0.0.0
aaa_Toolbar v1.8.0.7
ToolbarControl v0.1.9.6
AECS-Motion-Suppressor v1.3.3.0 / v1.3.3
AllYAll v0.11.19.0 / v1.0.0.0
AmazingCurveEditor v1.3.0.0
AttitudeAdjuster v1.0.0.0
B9PartSwitch v2.18.0.0 / vv2.18.0
B9-PWings-Fork v0.43.0.10
PlanetsideExplorationTechnologies v1.0.0.0
CommNetVisualisation v1.0.0.0 / v1.0.4
CCK v5.1.0.0 / v5.1.0.0 for KSP v1
EasyVesselSwitch v2.3.7852.41352 / v2.3 for KSP v1.11+
KSPDev_Utils.2.6-EVS v2.6.0.0 / v2.6 for KSP v1 - EVS build
KSP_Log v0.1.1.6 / v1.0.0.0
ButtonManager v0.0.1.0 / v1.0.0.0
FillitUp v0.2.0.2
HangerExtenderExtended v3.6.0.1
GC.UI v1.0.0.0
GroundConstruction v2.6.4.1
Hangar v3.6.2.0
IXSWarpshipOS v0.5.1.2
JanitorsCloset v0.3.7.7 / v1.0.0.0
KAS-API-v2 v2.0.7239.35367 / vKAS API v2
KAS v1.9.7852.42225 / v1.9 for KSP v1
KSPDev_Utils.2.6-KAS v2.6.0.0 / v2.6 for KSP v1 - KAS build
KerbalEngineer.Unity v1.0.0.0
KerbalEngineer v1.1.9.0
HyperEdit v1.5.8.0 / v1.5.8
KIS v1.28.7685.40880 / v1.28 for KSP v1.11+
KSPDev_Utils.2.4 v2.4.7504.27510 / v2.4 for KSP v1
MiniAVC-V2 v2.0.0.0
KSPWheel v0.0.0.0
LightsOutRelit v0.3.0.2
BetterManeuvering v1.0.5.0 / v5.0
BetterManeuvering.Unity v1.0.5.0
MechJeb2 v2.5.1.0 / v / v2.12.1.0
System.Buffers v4.0.3.0 / v4.6.28619.01 @BuiltBy: dlab14-DDVSOWINAGE069 @Branch: release/2.1 @SrcCode: https://github.com/dotnet/corefx/tree/7601f4f6225089ffb291dc7d58293c7bbf5c5d4f / v4.6.28619.01
NavballDockAlignIndCE v1.1.1.1
NavUtilLib v0.7.2.0
NavUtilRPM v0.7.2.0
DockingPortAlignmentIndicator v6.9.2.2
DPAI_RPM v1.0.0.2
ModuleDockingNodeNamed v1.0.0.2
NFPropUtils v1.0.0.0
PartCommanderCont v1.1.6.3
PartInfo v0.0.6.2
KSP_ColorPicker v0.1.0.3 / v1.0.0.0
KSP_PartHighlighter v0.1.0.8 / v1.0.0.0
PWBFuelBalancerRestored v0.2.1.6 / v0.1.4.0
QuantumStrutsContinued v1.7.5.2
ReCoupler v1.0.0.0
SCANsat v1.20.4.0 / vv20.4
SCANmechjeb v1.20.4.0 / vv20.4
SCANsat.Unity v1.20.4.0
ScienceAlert v1.9.9.3
CLSInterfaces v2.0.0.6
ShipManifest v6.0.2.0
SMInterface v6.0.2.0
SimpleLogistics v2.0.4.0 / v2.0.3.9
SpaceTuxUtility v0.0.3.0 / v1.0.0.0
VesselModuleSave v0.0.1.1 / v1.0.0.0
Collide-o-Scope v1.3.1.0 / v1.3.1+Branch.tags-v1.3.1.Sha.be8f18c959e6203eda10bda6439ee775867afd14
HabUtils v1.0.0.0
KSPDev_Utils.2.6-Lights v2.6.0.0 / v2.6 for KSP v1 - Surface Lights build
SurfaceLights v1.19.7854.4854 / v1.19 for KSP v1.11+
TCA.UI v1.0.0.0
ThrottleControlledAvionics v3.7.2.0
ToadicusTools v0.22.4.3 / v1.0.0.0
BetterTracking v1.0.5.0 / v5.0
BetterTracking.Unity v1.0.5.0
Trajectories v2.4.1.0
TweakableDeployablePanels v0.2.0.1
TweakableDockingNode v0.2.0.1
TweakableEVA v0.2.0.1
TweakableFuelPumps v0.2.0.1
TweakableGimbals v0.2.0.1
TweakableIntakes v0.2.0.1
TweakableParachutes v0.2.0.1
TweakableReactionWheels v0.2.0.1
TweakableSAS v0.2.0.1
UniversalStorage2 v1.8.0.0 / vv1.8.0.0
UniversalStorage2.Unity v1.8.0.0
VesselMover v1.10.0.0
Waterfall v0.0.0.0
WaypointManager v2.8.3.1 / v2.8.1
WorldStabilizer v1.0.7275.3032
FullAutoStrut v3.0.1.0
KSP-AVC v1.0.0.0
ZeroMiniAVC v1.1.1.0
[x]_Science! v6.0.0.8

 

[The-Grim-Sleeper]

On 8/21/2021 at 10:40 PM, bcqJC said:

...

uninstall-reinstall the mods you use a few at a time

...

Just did a quick check with just NavUtilities on Stock KSP, and I get severe frame rate stutter if the NavUtilities-radar is open while I turn the camera. If the radar window is closed, the stuttering disappears/does not happen.

Logs:
https://drive.google.com/file/d/1eOeoam7mBeDC-O9v2ujDjHfYjuzR4MiM/view?usp=sharing
https://drive.google.com/file/d/1ONnuZPukJGw4L_QF6TCaqBWOXxYoyVMk/view?usp=sharing

Edited August 27, 2021 by The-Grim-Sleeper

[The-Grim-Sleeper]

On 8/17/2021 at 8:05 AM, rukhafi said:

hello, I got similar problem in 1.12.2. KSP frozen when loading NavUtilities props. Maybe there is some way to fix it? Or should I relax and wait for the update? 

Can you share a .log file of your game when this occurs? I want to look if there is any notable overlap between our cases.

[rukhafi]

On 8/28/2021 at 7:09 PM, The-Grim-Sleeper said:

Can you share a .log file of your game when this occurs? I want to look if there is any notable overlap between our cases.

It's very strange but after update of some mod/mods I don't see any freeze when KSP loading. Moreover, I checked NavUtilities in flight and only see frame rate stutter when activate NavU in RPM. It's treated by changing the camera. Unfortunately I cannot tell which mod update fix the situation, cause there have already been many updates.

[The-Grim-Sleeper]

18 minutes ago, rukhafi said:

 It's treated by changing the camera.

Change the camera as in change the angle or the view mode?

[rukhafi]

38 minutes ago, The-Grim-Sleeper said:

Change the camera as in change the angle or the view mode?

In changing the view mode ("C" key). After that there is no any frame rate stutter. 

[The-Grim-Sleeper]

11 hours ago, rukhafi said:

In changing the view mode ("C" key). After that there is no any frame rate stutter. 

I just tried this and weirdly enough, there is a positive effect, but no real solution.

In Kerbal-perspective mode, a tap of Right Mouse Button to enable free-look, the stutter quickly fades and stays away, even when I switch back the external view.
But if the free-look is turn off, and Right Mouse Button is held down enable free-look in the external view, the stutter comes back with gusto.

Rukhafi, do you use RPM? Or otherwise fly a lot in Kerbal-perspective mode?

Does anybody know if there is there some way to turn on a sort of debug mode for NavUtils?

Edited August 30, 2021 by The-Grim-Sleeper

[rukhafi]

8 hours ago, The-Grim-Sleeper said:

Rukhafi, do you use RPM? Or otherwise fly a lot in Kerbal-perspective mode?

yes, I mostly use RPM/ASET in IVA mode. 

I can only assume that the absence of serious lags in my game is due to the fact that I completely reinstalled KSP and install all used by me mods anew from CKAN

Edited August 31, 2021 by rukhafi

[The-Grim-Sleeper]

16 hours ago, rukhafi said:

yes, I mostly use RPM/ASET in IVA mode.

I don't and I think that is why our experience is different. IVA the nav utils work fine, but 3rd person vehicle view causes me problems. Could you share an assessment of your frame-rate when using that view-mode?

[rukhafi]

13 hours ago, The-Grim-Sleeper said:

I don't and I think that is why our experience is different. IVA the nav utils work fine, but 3rd person vehicle view causes me problems. Could you share an assessment of your frame-rate when using that view-mode?

It became even more interesting. I tested all modes NavUtils with all cameras regime and now there are no lags or stuttering at all. I strongly recommend that you completely reinstall the KSP (1.12.2) and all mods, preferably from CKAN.  It is better to delete the game folder altogether, as if it did not exist and reinstall it. Something to do with a change in the version of the Unity, it seems to me.

Edited September 1, 2021 by rukhafi

[The-Grim-Sleeper]

On 8/21/2021 at 10:40 PM, bcqJC said:

I'm also on KSP 1.12.2.  So far, the mod has been working ok for me.

It is a pain but you probably need to uninstall-reinstall the mods you use a few at a time to isolate which one disagrees with NavUtilities.

FWIW, here's a list of the mods I have installed.  It may help lessen the list of stuff you guys have to eliminate.

 

2 hours ago, rukhafi said:

...completely reinstall the KSP (1.12.2) ... Something to do with a change in the version of the Unity, it seems to me.

 

Just did that complete refresh, with JUST NavUtilities and nothing else. Complete starting directory wipe, fresh install from steam, all local dependencies up-to-date. The stutter starts whenever the NavUtilities-radar is open and I hold right mouse to move the view. IVA is fine, rotating the camera without the NavUtilities-radar open is fine.

No if/and/or/but about it: NavUtilities does not function properly.
The scenario for this issue is consistent. This issue is systemic.
It might be because of something on my system, but this issue is not part of KSP vanilla or related to any other mods.

If anybody has a log file that could be used to make a comparison, knows some way to turn on debug mode for NavUtilities or knows where @Ser keeps the source code, I could look at that. Until that happens, I can not do anything.

MOAR logs:
https://drive.google.com/file/d/1zsFmOCvbLPk4V8fTq67KsyQGCPIMAHIs/view?usp=sharing

[panarchist]

On 9/1/2021 at 8:10 AM, The-Grim-Sleeper said:

If anybody has a log file that could be used to make a comparison, knows some way to turn on debug mode for NavUtilities or knows where @Ser keeps the source code, I could look at that. Until that happens, I can not do anything.

Source code is here: https://github.com/SerTheGreat/NavInstruments/tree/continued