Ser

@Guys, As I see some of you post that you don't use the mods that are buggy. Do you report the bugs you find to mod authors or just decide to not use the mod? Sometimes I have reporters who report a bug and then just vanish not even letting know whether they quit using the mod or solved the problem by themselves. As if they're saying "screw this, 5 minutes to post logs is too much" while we waste whole evenings and weekends trying to deal with that. I don't know a modder who keeps online diaries saying "Another Saturday passed trying to reproduce that stinky bug reported" but trust me, it takes a bunch of time sometimes and we really need your help to get our mods in the shape that works for everyone.

Updated. Thanks for the reminder. Actually there's no much difference between KSP 1.2, 1.2.1 and 1.2.2 so majority of mods should be compatible between those versions.

@alexustas, thanks, I'll try that. Have you thought of the following: what if procedures from charts (approach, landing) were specified as cfg's? That would allow a great scalability, here is what I mean: Flying around KSC is cool but there are plenty of custom runways that a player can add in his game. 1. Using the data from cfg's the charts could be generated procedurally. I doubt that anyone would be patient enough to force all those custom runway creators to draw proper charts and maintain them but having them procedurally generated we could have default charts even for the laziest ones. 2. Those data could be used by an ATC mod for vectoring, landing etc., thus we'd automatically had both charts and ATC services using the same data, and for every custom runway added. Are you interested in that?

@alexustas I gave it a try and have some feedback. 1. Radio recovery seems to break something. KSC scene becomes unusable and the following is spammed in the log: [EXC 08:54:12.836] NullReferenceException: Object reference not set to an instance of an object FlightGlobals.get_ship_velocity () FloatingOrigin.FixedUpdate () [EXC 08:54:12.837] NullReferenceException: Object reference not set to an instance of an object AmbienceControl.Update () [EXC 08:54:12.838] NullReferenceException: Object reference not set to an instance of an object Vessel.Update () Don't know, maybe another mod causes this but the fact is that it is connected to the radio recovery because after the normal recovery everything is ok. 2. I've tuned to IKW at 45 km distance and pushed "IDENT" but no morse code was audible. ADF and DME worked but the code became audible only at the very moment when the glide slope was intercepted at about 10 km. Is that intended? 3. On the page 4-2 of the chart (KKSC landing) there's a fix BAKOR (id SCE) marked as NDB with its own MW frequency. Base and final turn points of the circuit reference to SCE but I couldn't find a way to tune to that MW frequency as both NAV radios are VHF. How should that be done? P.S. Sorry for breaking into your video at 13:00 I often wish that there was some magic button for the mode that automatically tells "Get lost, I'm recording" to all the other software.

It would be nice if you uploaded them or at least checked for some error spam. Also I recommend you to try clean KSP with G-Effects only to fimd out whether it is caused by the mod itself or by some incompatibility.

It shouldn't affect performance at all. Is it the latest 0.4.1 version of the mod you are using?

@alexustas Cool props, thank you. And those charts... they are super amazing. I bet no one had done anything like that for KSP before. Well, now it seems like it's time to revive KSP ATC idea. Is there any way to use Navaids data programatically? The idea is to bind in-game waypoint navigation to VOR/NDB by presenting waypoints to a pilot in the form "India-Delta-Zero-Six 135 DME 300" instead of stock blips and marks on the navball.

I've viewed the logs but haven't found anything that could lead to redout. Think I'll have to reproduce that myself. Also your log is flooded with Module Jettison threw during OnUpdate: System.MissingMethodException: Method not found: 'PartResourceList.GetEnumerator'. at Part.ModulesOnUpdate () That's not related but may be you should report that to the author of Jettison mod as it's not good for performance when something writes to log on every update.

There's also this mod that makes turbo jets behave realistically and do not care for air amount but the overall intake area instead: "Inlet. Each engine requires a minimum inlet area (see right click menu in editor). Make sure you have enough inlet till you see "Inlet Area:100%" in flight. Each inlet has a TPR(total recovery pressure) that is dependent on Mach number and angle of attack. Avoid TPR loss by facing the inlet to the freestream. "

What warp were you at that moment and what G meter was showing? To enable debug logging you should go to the file \GameData\G-Effects\G-Effects.cfg and edit the last setting to be enableLogging = true. Restart KSP and then reproduce the bug and post KSP.log. Don't forget to set logging back to false and restart KSP after that because a lot of log spam will be done.

Yes, I think there's a chance that it might be caused by persistent rotation or thrust. Or it is another weird time paradox The interesting thing is also that the warp was high but Jeb survived. Can you reproduce it with debug enabled via cfg file and post KSP.log here?

There are some troubles with that. First, Unity has audio mixers for audio sources commutation into one channel, so common filter might be applied to that channel. But those mixers cannot be created dynamically, you create the needed number of them via Unity editor, export them as a bundle and load into the game. Second, what would happen when an audio source moves from one zone to another is a sudden jump in frequencies and that would sound unrealistic and would also lead to some effects like clicks etc. You may hear them when switching from 3rd person to IVA with Audio Muffler active. And Are you sure you can hear anything that is more than 100m away in KSP? Anyway I'll check how it works in stock with a great hope it already does. If I go for implementing this myself I'll probably use the individual filters approach.

Well, I've done some research . It is called "Atmospheric sound absorption" and is calculated like that: Pretty simple as you can see Need only to understand where to get the values for some of the variables. Unity has some means to specify cutoff as a function of distance, so at least it seems to be doable. The trouble is that it would be inevitably done by adding an audio filter to every audio source, which I tried to avoid in the current implementation because that would introduce some additional overhead that would potentially hurt FPS depending on the number of sounds that are not only playing but just exist on the scene at the moment.

Do you mean the effect when thunder from a very close lightning sounds more like "Crrack!" and the remote one sounds like "boom", because of high frequencies lose their energy faster than lower ones (noticeable mostly at large distances)? I'll check but hope that guys from Unity took care of this because that's the basics of sound positioning. If we are talking about changing sounds when a camera is moved from 1 to 10 meters distance, don't think that would be realistic. Could you explain how do you want that to work?

I guess if Kerbal Space Program had some economical model behind it then funds and values would have settled down to more adequate numbers, though I'm sure we'd get some surprising results compared to real life. Fuel from ore? What a... I've always looked at that resource mining stuff with suspicion. You're not quite right. I'd say the game is balanced in the way you could get a significant income from your resources for, say, 100 flights rather than 10 thousands or else mining would be infinitely boring as it is in real life.

I don't get it, what is the latest Scatterer release? This thread says that it is 0.0300 as Spacedock also does:

Yea, I forgot to mention WIP mods. Except for the cases they promise some essential features.

Version 0.4.1 is out Available on SpaceDock This update includes the latest bug fixes

Actually I mean various science-from-funds, funds-from-nothing stuff, alternative tech trees also. And I avoid the mods adding new science experiments, especially easy reachable because that means to have just more science for almost free. For me simplifying mods are automatic science gathering, 100% transmit etc. KER just lets me to not waste time on calculations on paper so it doesn't count.

I think he is wondering whether it has enough dV or something should be added.

The question is more related to the whole mod types rather than a concrete mod. So, why don't you use some mods (or any at all)? My answer is: 1. I don't use balance altering mods because I doubt that they are well tested (at least not as well as stock game is) and it would be a bad surprise to find that things are significantly unbalanced in the middle of a career. 2. I avoid part mods because of balance and they often have inconsistent cost/usefulness ratio (at least in the context of the stock game), also because of visual inconsistency with stock parts (and other part mods). 3. I don't use mods that simplify things because the game is already simplified, except for boring calculations aids. 4. I don't use mods that reduce realism, not to mention the ones increasing absurd level of the game (various space sausages etc.) 5. I don't use planet packs because I haven't visited all of the stock bodies yet. 6. I don't use military mods because it's out of this game's scope. What about you?

I've tired of typing too, but don't think that I'm arguing just to argue. I find your concept interesting and tried to understand how do you solve some inconsistencies. I'd like to change the current system too but in the way that doesn't require writting a new game from scratch, you know, I feel kinda lazy to do that

Then we just might not debate instead of being rude or aggressive, right? What's wrong with you people..

Wow. Did I say something offending?

Because we both want to make the game closer to real life, don't we? In RL there are a whole bunch of different teams, bureaus etc. in the single space program, some of them even have the same goals but practice different approaches because you can't tell which one wins at the end. So, one team doesn't just sit while another one generates parts, the "atmospheric" team may do a lot of theoretical work while "materials" one works on a girder. And you don't wait for anybody. In the game everything happens momentarily and that's another great abstraction. So an order to develop a new tech may be thought of as start of a new "turn", or a research cycle iteration when science data are fed to R&D to be distributed and processed in a way you don't know. Say, 15 science points "transfered" for a girder tech may in fact contain 90% of atmospheric data and only 10% of material study. Those data are processed behind the scenes into "theoretical" aerodynamic results that might be used up later when you'll order to develop Advanced Flight tech. I can agree that connecting instant research to real time flight is a problem. It makes things really look like we chase any atmospheric data to get ourselves a girder. But you may think of those data not as of data required for girder but as of data required to start next research iteration which would give you a girder, whose blueprints and technological processes were prepared during previous iterations from other science data. "I really need to know. Please explain." - research may come from and end up in quite unexpected results There's another problem: In real life data collected from Mars are useful mainly to understand how the things may be done in Martian conditions and to create materials, parts, rovers and landers specifically for Mars, not Moon or Earth. In KSP parts aren't specialized at all, except for atmospheric and non-atmospheric ones. They vary, in general, only in size(mass) and power. In fact, we build rovers from your example every time. And that's another great abstraction that neither science points, nor your approach helps. I'd say, that's a totally different conception to what we have in KSP.