Ser

I have a lot of effort put into this mod but for quite some time I've been out of KSP. Let's settle this in the following way: I suggest you to implement your fixes, test'em well and create a pull request. As for Fog Of Tech, a couple of years ago it had an annoying issue with lines connecting the hidden research nodes. As another mod had it solved, I quit developing Fog. Can't recall what mod was that.

Yes, give me some more time please.

Verified KSP 1.8.1 compatibility. CKAN also should be updated.

Verified KSP 1.8.1 compatibility. CKAN also should be updated.

Version 0.4.0.181 is out KSP 1.8.1 compatible. You can download it here

Try the version from this post:

Yes, the mod hasn't been maintained quite awhile, plus some serious issues waiting to be fixed. Have plans but absolutely have no time for it yet.

You can also download from github releases: https://github.com/SerTheGreat/NavInstruments/releases/download/v0.7.1/NavUtilities.continued-0.7.1.zip It should be on the navigation page of RPM

Short answer: yes. Long answer is that some my other mods require update too along with troubles mentioned by @Gordon Dry. So it happens when it happpens.

@Eskandare, @Ger_space, @alexustas Wouldn't it be better to develop a universal data format for all of the aircraft navigation needs: runway coords, ILS positions, markers, beacons and so on? We have several mods for navigation now: NavUtilities, KerbinSide, MAS, ASET each having its own database of nav data. If we had some common standard to represent and externalize those data, the mods could work interchangably and without the need to import/convert/addapt/update. How cool it would be when KerbinSide adds a few runways they were naturally usable by NavUtilities and by every MAS-based cockpit, and ASET cockpits too. I have thoughts of creating a MM patch that forces ASET props to use configurable nav data instead of its inner hard-configured ones (now the idea is years old). The main question is the data standard. Having that we could move further and introduce, for example, an ATC that universally works with every runway and navaid added by every mod.

That's interesting. Thanks for the report, I'll look into that.

No pain, no gain

The only progress so far is in the following post. Hope that helps.

I haven't tried your solution but my problem had been caused most likely by Fraps settings: by default it has F9 key set to start recording. So every time I've quickloaded in KSP with Fraps running (and I've done that much while testing my mods), Fraps started recording in the background and ruined my FPS. After 30 seconds it stopped recording, returning FPS back to normal "unexplainably". I've found that accidentally while inspecting my harddrive and looking into the Fraps folder containing a bunch of 30 sec videos taking up around 10 gigs.

Thanks for your help. I think these settings will make their way to the release, the "space smacks" bug was there in the current version anyway.

@dave1904@Gordon Dry, or whoever has noticable performance issues with the mod I've made a beta version with some settings that should affect performance, but I need you to test them and confirm which one is the issue indeed. Download it here: https://www.dropbox.com/s/x71yvukb0kjab2m/AudioMufflerRedux-2.6.2-beta.zip?dl=1 Try the following settings in the config: objectScanFreq - this setting deals with the most probable hog - the object scan. Neither Unity nor the game itself have no means to warn me when a new sound is created so I have to scan through all the existing objects as often as I can to catch and process it immediately. The trouble is I have no means other than using the slowest method for that. The method seems to not perform any calculations, just searches through some structures in memory and that could explain why dave1904 had less CPU load with less FPS with AMR at the same time - everything just "rests" and waits until all the objects are scanned. The trick is to do it less often: value of 2 makes it happen 2 times less, 4 means 4 times less and so on. The downside is that you will hear a non-muffled "smack" sound every time an explosion happens or leg servo starts/finishes moving. So I recommend you to try some big value like 1000 first to determine if this setting helps with FPS. Then find some value suitable for you. I've found a value of 5 as 10 leads to a whole small portion of a sound to be played before it gets processed by the mod. meshScanInterval - is the period in seconds to scan where the player's camera currently is. I have to do it every frame because the camera may move unpredictably but if the position change is detected a fraction of second later you shouldn't notice that and that will reduce the number of scans in times. So try it after the first setting. The value around 0.1 should be comfortable while the value of 1 second and more will lead to a noticeable delay in the mod's reaction to camera's position changes. Try them and report here please which setting and values helped you more, if any.

I believe you. I wasn't exact on my FPS. In fact, I have 60 FPS on stock when looking at clear sky and around 44-47 on the horizon. It never goes over 60, seems like my GPU doesn't allow for more. If I could go over 60 FPS may be I saw some drop, but with or without mods it never goes from 30 to 10 just because of AMR. So, what about your CPU load? Do you see AMR pushing it to the limit? I have a pair of ideas how to optimize it further with the optional cost of muffling quality.

My PC isn't a monster one at the moment (i5-4690, GTX 550Ti). I have around 30-35 FPS on stock and exactly same with AMR. While fixing issues with ShipEffects and ALCOR mods I've noticed that ALCOR takes some FPS away on it's own but absolutely all of them are there when AMR is added. I measure this when looking at clear sky to mitigate the impact of the visuals. Have to admit that I haven't played with as many as 100 mods for a long time, though. And there's another thing I've ran into one day, so you could do the next: open Windows' task manager on performance page and GPU-Z software. And then run lagging KSP with AMR. Once you notice FPS drops, Alt-TAB and look at the envelopes. Which one has the biggest spikes and how severe are they? The only way AMR could cause lags is with CPU load as it does absolutely nothing with graphics. (The story is once I had my eyes popped out when I saw 100% GPU usage but later on I've found that Fraps had F9 bound to "Start recording" by default ).

Please post your save and vessel files. Does the performance loss get bigger with part count increase (say x10)? Also try ALCOR mod (it has a bunch of gauges and audio sources), what is the performance with AMR and without it? You should post for modders knew about troubles and their scale. Yes the mod isn't as complex as FAR or MechJeb, but it does some tricky things like eurisitics and caching parts and audio sources to not scan every single piece every fraction of second, else FPS would just drop to 1 on large vessels. The problem is some people experience lags and some don't. And it seems (in common) to be not dependent on CPU, GPU, mods, parts and KSP version. The sad thing is I don't have lags too on all the PCs in my possession so I can't reproduce it. If I could I'd new what to look for at least.

Several people report that here too. I've tried everything to isolate and fix that with no luck. "Stock game is not really demanding" - I've tried the mod on the PC where KSP barely runs with all the settings nerfed to the bottom, and AMR still had no effect on performance. One of possibilities is that some mod(s) is interfering so you could help if you tried to figure that out: first, move the mods that are unlikely to create audio sources or parts away from your GameData. If FPS drops persist, move half of the remaining mods and so on. 113 mods should take at most just 7 steps to find the one causing issues.

Why? It seems to work as is. Or have you any issues?

Verified to work with KSP 1.5.1

Verified to work with KSP 1.5.1

Verified to work with KSP 1.5.1

Verified to work with KSP 1.5.1