Ser

Members
  • Content Count

    998
  • Joined

  • Last visited

Community Reputation

613 Excellent

1 Follower

About Ser

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

4,318 profile views
  1. Version 0.4.0.181 is out KSP 1.8.1 compatible. You can download it here
  2. 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.
  3. 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
  4. 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.
  5. @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.
  6. That's interesting. Thanks for the report, I'll look into that.
  7. The only progress so far is in the following post. Hope that helps.
  8. 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.
  9. 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.
  10. @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.
  11. 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.