Kobymaru

Sorry about that, I was hoping you knew whats up looking at the exception. Happens sometimes. But alas, more details are coming tomorrow.

Hey guys, I'm getting a lot of these when vessels go out of range: ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[ResourceRatio].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at DynamicBatteryStorage.ModuleDynamicBatteryStorage.VerifyInputs (.PartModule pm, Boolean isProducer) [0x00000] in <filename unknown>:0 at DynamicBatteryStorage.ModuleDynamicBatteryStorage.TrySetupProducer (.PartModule pm) [0x00000] in <filename unknown>:0 at DynamicBatteryStorage.ModuleDynamicBatteryStorage.RefreshVesselElectricalData () [0x00000] in <filename unknown>:0 at DynamicBatteryStorage.ModuleDynamicBatteryStorage.RefreshVesselElectricalData (.Vessel eventVessel) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(Vessel) Vessel:OnDestroy() Also, somehow, NFE overheats and damages my USI nuclear reactor pretty badly when I'm timewarping although I have sufficient cooling installed. I will try to provide more details and log a github issue tomorrow, this is just a heads up.

Guys, do you like this? Please leave feedback over in the development thread:

Hey guys, I have a question. Do you like the following in-flight trajectory display? The colors can be changed, but the the line thickness unfortunately can not be. The disadvantage is that the line can be only one pixel wide. The advantage is that it is one pixel wide even in the far distance, instead of being way too thin to see. I have been experimenting with Vectrosity, but so far no joy There should be a way to somehow draw a wider line using GL.Quads instead of GL.Line, but for this the DrawPath() and the GLPixelLine() functions have to be reworked, and I don't know how yet. Would you prefer this new line over the old line? Or should we keep the old line for now?

I'm afraid i need more info than that. Please read this thread and come back with more details. ps.: Next time, could you please not use such an annoying a hoster that tries to charge me for trying to help you? There's a myriad of other possibilities to upload a logfile, I don't see any reason why you have to pick the most annoying one. Try Dropbox, Google Drive, pastebin (or any other of the million services like that), GitHub gist...

Hi, does anyone here have experience with drawing lines in Vectrosity? I have been trying to draw a simply trajectory using Vectrosity, but all I get is weirdness. Here's a snipped of the module: public class TrajectoryLine: MonoBehaviour { public List<Vector3d> Vertices = new List<Vector3d>(); private List<Vector3> vl_Vertices = new List<Vector3>(); VectorLine line; public void Start() { line = new VectorLine("TrajectoryLine", vl_Vertices, 10.0f); line.SetColor(Color.yellow); } public void Update() { vl_Vertices.Clear(); foreach (var v in Vertices) vl_Vertices.Add(v); line.Draw3D(); } } The module is attached to the camera like this: FlightCamera.fetch.mainCamera.gameObject.AddComponent<TrajectoryLine>(); The result looks like this: Here, the blue line is drawn with another method (fed from the same Vertices) and is the actually correct line. The white line is the Vectrosity line (I don't quite get why yellow is white, but that's another issue). The really weird thing is that the line thickness changes if I rotate the camera, but not the position of the line. There is obviously some relationship between the correct line and the Vectrosity line, and it's probably coordinate related - but I don't understand how. Does anybody have a good idea how to use Vectrosity for my purpose?

If you have one vessel with machinery attached, then yes. But if you have multiple vessels, you would have to ship around machinery to all of them, which would be rather tedious considering machinery is excluded from local logistics. This way, you can walk around and "perform maintenance" on every part and it just draws from the nearest container that you have selected for it. Better yet, putting an engineer in a Workshop triggers "automatic maintenance" of all modules upon load.

Because (almost?) all converters consume machinery to emulate "wear and tear". Maintenance fixes this "wear and tear" by restocking the machinery back to full.

I believe that in a sense, it does. That I don't know, sorry. But testing that should be pretty easy

Draws machinery from the nearest machinery container that has local logistics enabled. If there is none, does nothing. Takes the masses of all attached parts and adds them to this part. This is needed if you have a highly asymmetric craft and don't want to deal with the balancing. Make sure to disable it when you change your craft (Docking, staging, crashing, KAS) or expect a Kraken-visit.

I just checked, and the description does not tell you that. It only tells you that more Electricity and KolonySupplies are required. However, I have found the relevant Wiki section, so thanks for the hint: https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Med-Bay-and-Colony-Supplies)#colonization-modules According to that, the duna module only provides space for one, and the Tundra modules provide space for 2/12 Kerbals. Now what I still don't quite understand is this section: So basically, the living module makes the timers go in *reverse* except when hab == home, then it stays frozen, did I interpret that correctly? Also, I can't verify those numbers from the config file, which says for example for the 3.75 Colonization module: MODULE { name = ModuleLifeSupportExtender ConverterName = Living Module StartActionName = Start Living Module StopActionName = Stop Living Module Efficiency = 1 PartOnly = false restrictedClass = TimeMultiplier = 6 ... } So I'm not entirely sure where the "12 kerbals" info comes from. I guess my first mistake was that I was using a module that's too small. But what I am still wondering (and hasn't been answered as far as I can tell): does this Living Module extend to Kerbals in nearby vessels, or does it only work for the vessel where the Colonization module is attached? Because that would be rather inconvenient. Ah, my mistake, sorry. That's not quite the point, though. Since I have more ColonySupplies that I could ever spend, I am just testing all of the functionalities that MKS provides and the living module is one of them And another reason is to enable truly permanent settlement.

Sorry, what do you mean by "kolonization module"? Do you mean the part with the name "MKS 'Duna' Colonization Module"? Because that is the part that I am talking about. It has a converter of type "ModuleLifeSupportExtender" and that is called "living module". If I understood correctly, this one is supposed to freeze the Habitation timer forever (as long as ColonySupplies are available). I was under the impression that this works for the whole base, but now I find that it only works for the kerbals inside the vessel with the "MKS 'Duna' Colonization Module". Which "kolonization module" are you talking about?

Hi, how does the living module work exactly? I have plenty of colony supplies and have enabled it, but it only freezes the hab timer for the Kerbals inside the vessel with the Living Module. Is it meant to be this way? Does that mean I need to have a Pioneer module on every single vessel on the base to extend habitation indefinitely?

Oh that's what you mean! That is the peak atmospheric deceleration and has nothing to do with the impact itself.

Ok, thanks, I think I get the picture now. The problem that I see is two-fold: First of all, simply a different color is not a great indicator of what is going on. Seems very unrelated to the Body-Fixed setting. Sure, it could be mentioned in the README - but no one reads that anyway. Button naming / icons should work without a README and be obvious without ever having touched a manual. Secondly, I just don't think that the state of "body-fixed" is important enough to change the icon color. Currently it's in the main window anyway, and the checkbox itself is plenty visible. Why would we need to make this so prominent? If anything, a color change would be warrented when the trajectory is calculated vs when it's not.

Looks good, no more NullRefs! Thanks for the prompt fix. Out of curiosity, what was wrong?

Hey guys, I am getting a NullReferenceException spam when I switch to my old base (constructed in 1.2.2) in KSP 1.3.0 with the newest MKS versions. Does anyone else have this? More details here: https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries/issues/118

Planetary logistics requires you to have a logistics module with a pilot in every single vessel that participates in it. Also, last time I checked it only pulled/pushed once after load, but that might have been unintended behaviour (a bug). Additionally, planetary logistics are pushed automatically when containers get full and pulled when they get empty. You have no way of specifying how much you want in a given container. Local Logistics itself doesn't need a pilot sitting around in a rover, but resource distribution does, so I'm not sure which one you are referring to. If it's the former, then the advantage is that you can easily and manually (!) transfer as many resources as you want. If it's the latter, then the advantage is that resources get pulled out of containers with warehousing enabled without the need for a logistics module on that vessel. Yes. If the distance is < 150m, you don't need one, then scavenging takes place. If the distance is > 150m and < 2km then resource distribution takes place, but that needs a rover.

Hey guys, can I ask you a Favor? So I watched Scott Manleys Galileo Conquest , and it seems that he's not using Trajectories quite right. If you happen to watch Scott Manleys streams, could you relay to him the following: Update to the newest version (1.7.0), where precision should be improved He can select "Prograde" or "Retrograde" or even a descent profile to calculate different reentry orientations He can pay for increased precision with performance by disabling the cache in the settings (admittedly the price is a bit hefty) I'm afraid I can't watch, because they happen in an inconvenient time zone for me. For good measure, I'll ping @illectro directly as well

What is the "impact g-force" and how do we calculate it? Depending on the how the craft "crumbles", impact g-force can be infinite I'm not sure if putting numeric readouts into popup windows is a good idea, because that will make them hard to find for novices and annoying to read out for those who need them. On the other hand, I understand the desire to "put them away" since I don't recall ever having used them in day-to-day life. I had a thought: what if we add some sort of "Info" section (or popout window?) that looks similar to a Kerbal Engineer Redux window with all kinds of numerical readouts? This doesn't have to be configurable (for now), we'll just stuff it full with all that we have now. That reminds me... we should really polish up the API so that maybe we can even plug Trajectories into Kerbal Engineer. Well if it takes less than five minutes, you could do it real quick and show us the result, and we go from there I am very much in favor of that and have been missing this feature forever. I don't know yet when to find time to implement that, though... By the way, as it so happens, I am currently working on a section about feature requests in the contributors documentation. It's not completed yet, but you should check it out!

Please create an Issue here: https://github.com/neuoy/KSPTrajectories/issues/ Make sure to explain what your suggestion does, what the benefits and the potential disadvantages are. I'm a "code-only" guy, I don't do modeling or even light Photoshop So any Icon changes would have to come from other contributors (maybe you? ) . Also, right now I can't even imagine how to get the "symbolism" right - meaning how to make abundantly clear that Body-Fixed mode (how do you even symbolize that?) is off or on in as little as 36x36 pixels.

New release is up! Version 1.7.0 improves precision and fixes a crash. Download from GitHub or SpaceDock. Provided that the CKAN fairies have heard prayers and pleas, the update should propagate to CKAN soon™. Full Changelog: A huge thank you to @PiezPiedPy is in order for his help with the maintenance of this mod!

That is mostly correct. We try to re-use the KSP functions as much as possible. Just so you know, the distinction between "drag" and "lift" is a bit silly, because as @Boris-Barboris likes to point out, drag and lift are just components of the same vector. That means you'll run into situations where ignoring "lift" will produce inaccurate results even when you're not classically "flying". Thanks for the tips! I think implementing RK4 is not that hard (I believe I did that in C++ once for a class), but integrating it (no pun intended ) into the mod is the difficult part.

Don't forget to give Kudos to @Youen who created this awesome mod, I'm just the maintainer Good point, I could probably write down what the code does. At its core, the math and the algorithms are actually kind of simple (it's just packed in a confusing way that's necessary for efficiency) We use a mix of calls to original and duplicated KSP functions to figure out parameters for atmospheric density, temperature, reynolds number, mach, .... from altitude and velocity. We feed these values into the original KSP DragCube functions to calculate the forces on the ship for a given point in the future. Then we simply aggregate these forces and calculate velocity and position. The "aggregation" part is important, because if you do it wrong (like simply adding up the velocity/position changes over time), you will end up with big errors. Currently this is done by "verlet integration", but I was hoping to implement Runge-Kutta 4 in the medium future. If you want, I can look up the places of these calculations in the C# code. Sounds interesting, but the most difficult case here is to calculate the drag from aerodynamic parameters. KSP does all kinds of funny things with the "DragCube" system like occlusion and bonuses for pointiness and maluses for open stack nodes. Trajectories can get away by simply calling the functions inside KSP with the right parameters and interpreting the results. I think it might be very hard to replicate all these systems in JavaScript, especially since you would have to dig in KSP code (which technically isn't even allowed). If you have more questions, don't hesitate to ask!

Wow, that looks amazing! I'm really looking forward to it Just as a side note though: you shouldn't recreate the old UI one to one, instead we should try to find a more "natural" user experience. That's why I asked to put early versions in this thread: I'm sure you could recreate the old UI without problems, but I wanted to use the opportunity to clean it up and make it clearer. For example: the craft position in lat/lon is not really necessary at this place, is it? It doesn't necessarily help with landing, and if I *did* need it, I would take the readout from MechJeb2 and Kerbal Engineer.