Kobymaru

I have a question for the balance-pros in this thread (I guess that's @Streetwind?) I wanted to build a Big Fu.... nky Ship that boosts my dear Kerbals in high-velocity Trajectory towards Laythe. I am finding that the masses of the NF Construction parts are temptingly low, especially in comparison with RoverDude's freight transport technologies, which provides similar construction parts. For example: Your Modular Multi-Purpose Annular Truss has a mass of only 1.5 t, The StarLifter Cargo Rack (Small) from FTT has a mass of 3.75 t for a very comparable size and purpose. BTW, an empty Stock S3-14400 Fuel Tank has a mass of 9t for the same size. The NFC "Modular Annular Truss Adapter" has a mass of 0.4t, but the FTT "5m to 3.75m adapter" has a mass of 1.65t - but they have the exact same purpose and virtually identical shape. I could go on and try to find other examples of equivalency, but you get the point. Now I know that RoverDude's parts are... "loosely balanced" when it comes to mass&cost, whereas you guys usually know what you are doing. But I just wanted to ask about the rather high discrepancy and the lightness (even in absolute terms) of the parts. Are those ballpark masses or did you put some thought into them? Thanks for making such a great mod, by the way

Surface.

Depends what you want. If you want to just land, body-fixed is probably best. If you want to do aerobraking, orbit-relative is best. If you want to draw pretty, artsy pictures, try body-fixed with an inclined, high-eccentricity-orbit

You can choose. Click "body-fixed mode" for surface, and uncheck it for orbital. If you mean internally in the code, then it's "body-relative world position".

Hi, I tried to draft a small issue report, it's here: https://github.com/BobPalmer/USI-LS/issues/218 Here's a copy for the forums: In some situations, the Life Support window disappears and reappears again in an approximatel 5s interval. Each flicker is accompanied by the following exception: ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[ProtoCrewMember].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at LifeSupport.LifeSupportMonitor.CheckEVAKerbals () [0x00000] in <filename unknown>:0 at LifeSupport.LifeSupportMonitor.GenerateWindow () [0x00000] in <filename unknown>:0 at LifeSupport.LifeSupportMonitor.OnWindow (Int32 windowId) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 Full log: https://github.com/BobPalmer/USI-LS/files/747363/output_log.zip Quicksave: https://github.com/BobPalmer/USI-LS/files/747377/quicksave.zip I'm afraid I couldn't make a clean reproduction save, so my main game save is attached. That requires the mods KAS and KIS to load the scene (and NearFutureElectrical for other irrelevent ships) , unfortunately. Screenshot:

That sound like a bit more than what I saw. Were your AoA settings correct, and did you follow your programmed flight path? Thanks for testing, I saw the exact same thing with Stock Aero! Intersting that it's similar in FAR. It seems so. I tried to use the TrajectoriesDebug module to read out predicted vs actual lift/drag, but the lift/drag was staying at 0. I was using Stock Aero, but as noted by @dlrk, FAR has similar problems. Well, IRL we have the problem of wind, varying atmospheric densities/temperatures, inaccurate pitch/yaw control, and the significantly more complicated fluid dynamics So I think in the game we can hope for more precise predictions

Dear Trajectories users, I think we might have a bigger problem here. I just did a simple test with a single part, a Mk1-Command Pod, and the Predicted impact point before entering the Atmosphere deviates by about 90 km from the final actual impact point (Yes, the correct Orientation has been set). This points to a bigger issue with calculations, and kind of defeats the purpose of this plugin. Here is a GitHub issue: https://github.com/neuoy/KSPTrajectories/issues/84 Could someone help to reproduce this and report back here? When you did, I think we should summon the great Youen, because I do not have the deep code knowledge needed to fix these kind of things.

No worries. Oh, I see. Yeah, that is kind of nice. I can implement that. However what would be best is to actually draw the Trajectory in the flight scene - but that's way above my paygrade Oh, I like this actually! Yes, I will do that when I have time Could you create an Issue with a description on GitHub? You can copy-paste parts if your forum post. I don't think that's possible. The deviation from the flight path is continuous, but a maneuver node is a one-time velocity change. I have no idea how one would hook those two up.

That might be a consideration. But, what is the use case for that? What would you do with the information? What is it that you currently can't do without this feature? Why can't you just use it in the Map View Scene? That sounds technically feasible, but it would clutter up the UI for small benefit. Again, what is the use case for that? What would you do with the information? What is it that you currently can't do without this feature? I don't know about you, but I find "latitude/longitude delta in fractions of degrees" a very unintuitive unit, compared to just kilometers and the visual information of the impact point vs target. I don't quite understand this one.

It sure could. Let me give you a list of all of RoverDude's mods: Between those, he currently has a total of approximately 390 open GitHub issues. That's a lot of mods and a lot of issues, even for the One-Man-Show that RoverDude is. One could even say he's a little in over his head. The Life Support window works. It doesn't work well - but it works. There are a lot more pressing and "game-breaking" bugs and deficiencies. So while all kinds of Feature requests are nice, there is a rather low chance of them ever getting implemented. If you create a nice GitHub issue, keep it clear, concise and *short*, there is a small chance that it gets updated at the next bigger overhaul. In order to raise the chances of the change actually happening, you could sit down, code it yourself and submit a pull request. That's still no guarantee - but it's definitely a higher chance than just posting in the forums.

Yes, it does. In fact, I don't even need USI installed - it happens with NFE only. BTW, it helps to do Alt-F12 -> Debugging -> Show All Log Exceptions on the Screen and Alt-F12 -> Debugging -> Show All Log Errors on the Screen

Thanks, but I do not have such a file. I still get the NullRef, from a fresh install. I guess it's not big deal, since apparently the reactor still works.

Which is what exactly? Sorry, it's not clear to me from his post what his solution was. Anyway, I removed the file "NFElectricalUSI.cfg" from GameData/NearFutureElectrical/Patches, and I don't get the Null-Ref anymore. The downside is, now the reactor isn't controlled by NFE anymore, but by USI's simplistic reactor mechanic. Weird, can reproduce it reliably over here. Maybe the message is hidden in your log file from the debug messages? Try using the Search function with the term "NullReferenceException" to find it. I can't do "only NF Electrical and UKS", but I can do NFE and UKS with their respective depencies. Here's the GitHub Issue I just created: https://github.com/ChrisAdderley/NearFutureElectrical/issues/48 Here's a minimal save file for quick reproduction (please rename to .sfs): https://github.com/ChrisAdderley/NearFutureElectrical/files/735181/nfe-use_nre.sfs.txt Here's the full log, this time with the minimum mods installed: https://github.com/ChrisAdderley/NearFutureElectrical/files/735180/output_log.txt Here's the file listing for my GameData directory, excluding Squad: https://github.com/ChrisAdderley/NearFutureElectrical/files/735201/gamedata-filelist-nosquad.txt

It is for KER, but that doesn't mean we can't deconstruct the assumptions and make it more precise as we go. I am not sure about that. I think vesselState.up is not the vessels "up" direction, it's the direction of "up" in general, away from the current main bodies center of gravity. That's alright, apparently everyone is. Thanks for your insight! Interesting. I guess the hunt for the truth begins!

Hi! I'm getting NullRefs from NearFutureElectrical. I'm using a USI reactor. Module FissionReactor threw during OnFixedUpdate: System.NullReferenceException: Object reference not set to an instance of an object at NearFutureElectrical.FissionReactor.DoFuelConsumption () [0x00000] in <filename unknown>:0 at NearFutureElectrical.FissionReactor.OnFixedUpdate () [0x00000] in <filename unknown>:0 at Part.ModulesOnFixedUpdate () [0x00000] in <filename unknown>:0 Here's the rest of the log: https://dl.dropboxusercontent.com/u/1414175/ksp/output_log-nfe-nre.zip

Yeah. But it works well enough, so there's gotta be at least some sense.

I think there was a mixup with which DLL's got built and released, because there are 2 patches that I submitted (to MKS), that were merged, that are present on DEVELOP, but not on the release.

Hi guys! I wanted to update Kerbal Engineer Redux to handle "real" suicide burns, namely suicide burns that start out with a horizontal velocity component. I tried looking around the interwebs for examples or math for this, but all I ever found was "vertical-only"-suicide burns. Then I stumbled upon this gem in MechJeb2: public static double SuicideBurnCountdown(Orbit orbit, VesselState vesselState, Vessel vessel) { if (vesselState.mainBody == null) return 0; if (orbit.PeA > 0) return Double.PositiveInfinity; double angleFromHorizontal = 90 - Vector3d.Angle(-vessel.srf_velocity, vesselState.up); angleFromHorizontal = MuUtils.Clamp(angleFromHorizontal, 0, 90); double sine = Math.Sin(angleFromHorizontal * UtilMath.Deg2Rad); double g = vesselState.localg; double T = vesselState.limitedMaxThrustAccel; double effectiveDecel = 0.5 * (-2 * g * sine + Math.Sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g))); double decelTime = vesselState.speedSurface / effectiveDecel; Vector3d estimatedLandingSite = vesselState.CoM + 0.5 * decelTime * vessel.srf_velocity; double terrainRadius = vesselState.mainBody.Radius + vesselState.mainBody.TerrainAltitude(estimatedLandingSite); double impactTime = 0; try { impactTime = orbit.NextTimeOfRadius(vesselState.time, terrainRadius); } catch (ArgumentException) { return 0; } return impactTime - decelTime / 2 - vesselState.time; } So this piece of code here works like a charm. Except for minor errors, this provides a rock-solid suicide burn countdown timer. And obviously there is some math behind it (I mean look at all the sine's and square roots!). I don't really understand the math here though, and I haven't seen *anything* that looks remotely similar. So instead of copy-pasting it as a black box and hoping for the best, I thought I would ask you guys, if someone could help me understanding this fine piece of math. I looked at the git blame, and it seems that a guy named @The_Duck or @Meumeu is the original author. Are you still around? And obviously, @sarbian is the current MechJeb maintainer, so he might know what's going on? Any help would be appreciated. Cheers

Same Problem here. I have RoverDude's MKS suite installed, if that's relevant.

Try launching them in a vessel with supplies

Hi guys! So finally, I got my Duna Base up and running Took me quite a while, because it's not just the MKS parts - it's also the supporting infrastructure for refueling and transport. The location was carefully chosen to lie on a 3-Biome boundary that lets me mine EVERYTHING!! The downside is, it's on a sloped location which is slightly annoying for landing purposes. It's at Stage 2, by which I mean it can produce Fertilizer and MaterialKits, and it's fairly self-sufficient. Next step: SpecializedParts production! Check it out here: http://imgur.com/a/N0fhY

Hey, @dboi88 it seems that Life-Support -> Converters is missing. If I click the page in KSPedia, I immediately jump to Rovers. Life Support -> Recyclers is present though.

Hey, @cybutek and @Padishar , I wanted to implement readouts for Surface Distance and Heading to a target Vessel and Surface Distance and Heading to an active Waypoint. However, I'm not quite sure where the processing Code is supposed to go. There are two simple static (math) functions that are shared between Vessel targeting and Waypoint targeting. I wanted to put the vessel targeting in the Rendezvous category and the Waypoint targeting in the Surface category - but I feel like duplicating code is not a great option. I haven't found any math-related "Utility" class or such. Do you have any tips?

Hello Friends of the Precise landings, in the absence of Youen, I have updated the Trajectories mod. The targeting interface is now actually useful, you can: Target landed vessels Target Waypoints Show the distance between the current impact point ant the target Additionally, the mod is finally "officially" compatible with KSP 1.2.2. ps.: No pics, no clicks: I have contacted Youen so that we may see an official release soon. In the meantime, you can grab the updated DLL from here: https://github.com/fat-lobyte/KSPTrajectories/releases/download/v1.6.6-Kobymaru1/Trajectories.dll Please download and test. Have fun, and happy landings!

Some unsolicited advice: Use Mod parts only sparingly . Especially KER and MechJeb, because they are not strictly required for the functionality. The reason is that a) mods change, and updates take long. They would hold you back unnecessarily in your save after a KSP update, for example and b) it's just way easier to debug without them. In your situation, you can install this . It is a simple and light-weight patch. Alternatively, there's a KER setting that enables it without using the part on your vessel. Then you can remove the parts either with KIS, or with the "Disassemble Part" option from MKS or even with KSPPartRemover, but this requires you to have Mono.