[1.3.X - 1.6.X] Speed Unit Changer - More units for your speed - Ap & Pe on your Navball

[Galenmacil]

Hello Ittito. I just want to report that Speed unit changer does not work correctly. Let me explain:

I am using KSP 1.1.2 but the "changed speed unit" are only shown when the NAVBall speed section is set to "Orbital" mode. In "Surface" mode, m/s are used no matter what. I am also using FAR.

[Honeybadga]

22 hours ago, Galenmacil said:

Hello Ittito. I just want to report that Speed unit changer does not work correctly. Let me explain:

I am using KSP 1.1.2 but the "changed speed unit" are only shown when the NAVBall speed section is set to "Orbital" mode. In "Surface" mode, m/s are used no matter what. I am also using FAR.

Yup, same here.

Edit: I just discovered that you can change the displayed speed unit with FAR in surface mode.

Edited May 9, 2016 by Honeybadga

[Galenmacil]

Honeybadga: Yes, you are right about this but I thought having a simple "mod" like Speed Unit Changer that would allow for quick changing would be better than FAR where you have to dig into a few menus...

[Iamsodarncool]

I do not experience this problem

[Technologicat]

@Galenmacil, @Honeybadga, @lttito: I'm getting hit by this too - in surface mode, the speed unit doesn't change when using Speed Unit Changer. The common thing is that I also have FAR, and indeed from the FAR menu the displayed speed unit can be changed. Maybe a conflict?

@Iamsodarncool: other mods installed? Do you have FAR?

 

[AdmiralTigerclaw]

I also note the interference of FAR with S.U.C.  Likely since both try to overwrite the display in the nav-ball.  Might be prudent to just create a side display or make a patch so that if FAR is installed, it doesn't try to fight with it, or disables.  Likely that'll require some digging.

 

Also, Speed Unit Changer needs to be optimized.  The moment I installed it, my framerate in flight suffered drastically, dropping from the 50s to the mid teens where it begins to get visibly choppy.

[lttito]

3 hours ago, AdmiralTigerclaw said:

I also note the interference of FAR with S.U.C.  Likely since both try to overwrite the display in the nav-ball.  Might be prudent to just create a side display or make a patch so that if FAR is installed, it doesn't try to fight with it, or disables.  Likely that'll require some digging.

Also, Speed Unit Changer needs to be optimized.  The moment I installed it, my framerate in flight suffered drastically, dropping from the 50s to the mid teens where it begins to get visibly choppy.

Yes, aparently FAR uses the same way to overwrite the Navball as SUC. But as FAR also put the speed in the navball, I think is ok to use FAR values instead of use another mod that do the same as a mod you have already in use.

Never had performance issues, never have messages of others saying so. Maybe the performance drop is due to other mods?

[AdmiralTigerclaw]

4 hours ago, lttito said:

Yes, aparently FAR uses the same way to overwrite the Navball as SUC. But as FAR also put the speed in the navball, I think is ok to use FAR values instead of use another mod that do the same as a mod you have already in use.

Never had performance issues, never have messages of others saying so. Maybe the performance drop is due to other mods?

 

No,  Performance drop is this mod.  It's quite clear when the only difference from one session to the next was me stopping to install this mod, and receiving an immediate drop in framerate from the same vehicle, in the same location, at the same game time.

[lttito]

3 hours ago, AdmiralTigerclaw said:

 

No,  Performance drop is this mod.  It's quite clear when the only difference from one session to the next was me stopping to install this mod, and receiving an immediate drop in framerate from the same vehicle, in the same location, at the same game time.

This mod only do a simple conversion (from m/s to the selected unity), that is basically a multiplication (product) of two quantities and then writes it in the navball. Just this plain and simple. Code that generate UI is alike BD Armory and other mods. So I doubt is this mod that causes performance issues. I do not deny that having a lot of mods can cause performance issues, though.

[AdmiralTigerclaw]

2 hours ago, lttito said:

This mod only do a simple conversion (from m/s to the selected unity), that is basically a multiplication (product) of two quantities and then writes it in the navball. Just this plain and simple. Code that generate UI is alike BD Armory and other mods. So I doubt is this mod that causes performance issues. I do not deny that having a lot of mods can cause performance issues, though.

 

1: How many times a second does it do the math checks?   I ask this because a similar issue cropped up with Kerbal Alarm Clock in the tracking station.  The math checks per second actually got in the way and slowed the system down.  It took me a while to find it.  Similarly, if you've got code here executing checks too often, it'll get in the way of executing other sections of code.  If the code is cycling faster than the display refresh rate of the PC monitor, or the framerate of the program, then it is literally wasting CPU cycles and time.

The framerate drop from this kind of behavior is the same kind of framerate drop you'd get from KSP spamming error messages.  And that was the first thing I went to check.  (Alt+F12, Debug).  Obviously, nothing.  But it's the behavior of framerate lag that felt like something small executing repeatedly really fast.

 

2: Does it do the math checks for all conversions on every pass, or only the visible conversion?  I doubt you made this mistake, but it bears asking, the code isn't trying to do all the calculations for both the displayed value, and the undisplayed ones at the same time, is it?

 

IF 1 and 2 were to combine, the effect would easily cause problems.

 

 

[lttito]

27 minutes ago, AdmiralTigerclaw said:

 

1: How many times a second does it do the math checks?   I ask this because a similar issue cropped up with Kerbal Alarm Clock in the tracking station.  The math checks per second actually got in the way and slowed the system down.  It took me a while to find it.  Similarly, if you've got code here executing checks too often, it'll get in the way of executing other sections of code.  If the code is cycling faster than the display refresh rate of the PC monitor, or the framerate of the program, then it is literally wasting CPU cycles and time.

The framerate drop from this kind of behavior is the same kind of framerate drop you'd get from KSP spamming error messages.  And that was the first thing I went to check.  (Alt+F12, Debug).  Obviously, nothing.  But it's the behavior of framerate lag that felt like something small executing repeatedly really fast.

 

2: Does it do the math checks for all conversions on every pass, or only the visible conversion?  I doubt you made this mistake, but it bears asking, the code isn't trying to do all the calculations for both the displayed value, and the undisplayed ones at the same time, is it?

 

IF 1 and 2 were to combine, the effect would easily cause problems.

 

 

Maths are done in each call of LateUpdate, made by Unity. It calculates speed and altitude for your current selection and only for those.

Code is inside the mod, in source folder. You can have a look at it. If you find something that can be redone I will be happy to fix it as soon as I can.

[AdmiralTigerclaw]

@lttito

 

I'm looking at it now.

 

First thing I notice is that you might be able to squeeze at least a small performance improvement out of each pass by changing it from an If > Else If ladder, to a switch statement.  Especially for code as regularly executed as this.  Evaluating all the statements on each pass (worst case if someone's using MACH for speed, and feet for altitude) is a waste.  Mind you, this ladder is small, but every little bit counts.  I think we can squeeze just that much more by changing to a switch statement.

 

I had an entire section written here about using strings, but then, an hour into researching everything to refresh my brainmeats, I realized you weren't using strings internally the way I thought you were, I'd just seen some of the string calls out into KSP and mistook them for everywhere.  However, in doing that research, I realized you might also be able to squeeze some performance in by changing all the constant int values out for char values. (Example:  int  KILOMETERS_PER_HOUR = 1 could become char KILOMETERS_PER_HOUR = b ).  You're not storing variables in them so much as using them as markers, and  I don't see your menu surpassing 26 characters.  Since Int uses 4 bytes vs char's 1 byte, the tweak can save you 3 bytes per address, and also decrease the time needed to read each address when it's called.  It's a tiny optimization, but an optimization on something that runs a LOT in flight, and is already running on top of a lot of program and add-ons.

 

 

The second thing I notice, or don't notice, is that I don't have any idea how fast your code is cycling or calling LateUpdate (or rather, how often Unity calls it).  If that could be throttled to restrict it to no more than an update rate of 60 Hz...  Well, like I said, anything faster than framerate is wasted.  However, I can only think of one way to do it, and that depends on a delay being placed into it lasting 16 milliseconds per cycle:

public void LateUpdate()
		{
			UpdateSpeedValue();
			UpdateAltitudeValue();
			delay(16);
//Technically, it's 16.66666666~ which would round to 17 ms, but I'm considering that each subroutine will take a small amount of time to execute, so I'm trimming instead of rounding up.  I'm also placing the delay on the end since I'd rather the code execute IMMEDIATELY the moment it starts and THEN wait.  I know at this speed, it's transparent to an end user but *shrug*...
		}

Assuming, of course, that version of a delay call is the one that will work here.  Also assuming unity doesn't pause to wait on the delay.  If unity stops everything to wait out the delay, then it's that idea is less than worthless.  It's obstructive.

(I'm used to simple linear programs.  I don't know how these big software engines execute linear sequences in a manner that seems like it's threading everything and it's mother simultaneously.  I know how interrupts work with a microprocessor, but not complex software engines.)

 

Incidentally, I'm into this bit of mod because I REALLY want to get my hands on that foot-based altimeter.  Aircraft flight and design is really annoying when everything is in meters on KSP, and all the rules of thumb and tricks to aviation operation are based on knots ground speed, and altitude in feet.  I love working with metric, but

 

Heck, once this gets optimized, I'd like to add in a display modifier option that converts kerbin altitude levels to the earth equivalent atmospheric scale height. 

https://en.wikipedia.org/wiki/Scale_height

 

Kerbin ASH: 5,600 m

Earth ASH: 8,000 m  (OR: 26,246 feet)

(Which simply says that an altitude of 5600 meters on Kerbin is equal to 8000 meters on Earth.  Knowing that scale is a good acting metric towards the performance of vehicles one designs when trying to compare them to real aircraft.)

 

 

 

EDIT:

Had someone point out a way to redo the code to completely forego the If statement ladder completely.  That would definitely improve things.  Won't go into it tonight, don't feel like another session of 'write me code'.

Edited June 13, 2016 by AdmiralTigerclaw

[Iamsodarncool]

Are there plans to update this to 1.2?

[lttito]

yup, i'll try to update it this weekend if real life allows me

[lttito]

Updated version 1.4.3. Details on OP.

Changelog:
version 1.4.3: 1.2 Compatibility. Also optimized code to not create several instances and less if checks.

Also, I don't use / don't know how to use CKAN, but if any kind kerbonaut is kind to update it, please do it

Cheers!

Edited October 15, 2016 by lttito

[SpaceToad]

Could you add Knots? That would be great

[lttito]

44 minutes ago, SpaceToad said:

Could you add Knots? That would be great

I just forgot to add to the mod description, but it is already added to the mod

[SpaceToad]

3 hours ago, lttito said:

I just forgot to add to the mod description, but it is already added to the mod

Awesome! Thanks

[Galenmacil]

Very cool mod. Just reporting a "problem" with it: When setting displayed speed to anything else than m/s the game take a serious performance hit. Roughly a 50% drop (from ~55-60 to 30 in the testing I did) which I assume is due to the "complex" computation involved. Could you look into this please? Perhaps you could make the computation let's hardware intensive or limit it to 5 cycle per second, something like that...

[lttito]

Updated to version 1.5.0. Details on OP.

Now it also can show different info on navball, overriding the surface/Orbit/Target texts. (thanks @Bit Fiddler for the sugestion!).

@Galenmacil I'll take a look tomorrow. Maybe I can limit somehow the number of times the logic is calculated per second.

[lttito]

Just make a quick test to try to limit the number of times the calculations are made, unsuccessfully. If I limit the number of times the speed text is updated with the calculations, stock speed (in m/s) appears.

I'll try to optimize the calculations instead of limiting the number of times they are done.

[Bit Fiddler]

oh nice... I have been asking for this mod for years now...   lol all I wanted was a simple way to see my orbit during my ascent so I know when to burn etc.  without having more windows on the screen or flipping over to map view and back.  

 

so ya this is a great change.

[Bit Fiddler]

a request on the Ap/Pe display.  in this mode can you remove the speed so there are only 2 lines of text showing.  the text with 3 lines is very small on my display, and knowing the Ap/Pe means that speed is redundant.  as speed is what is determining these 2 values.

[[email protected]]

Thank you so really much its awesome

[Bit Fiddler]

are you still working on this mod?  no real traffic here since I posted last November on the Ap/Pe changes I requested.   still would like the display changed to not show speed.  thus the Ap/Pe text lines would be bigger and easier to read.

 

The reason is if we know our Ap/Pe the speed value is not important.  We just need to see these to burn prograde or retrograde to circularize our orbit or adjust Ap/Pe etc.   the actual speed we are traveling at this time is not important.  so having these numbers bigger would be great as my navball is rather small so the numbers get hard to read.

Edited May 29, 2017 by Bit Fiddler