Kobymaru

The difference between the samples is zero. Quicksave. Observe Value Timewarp 5 ingame minutes Quickload Observe Value Timewarp 5 ingame minutes Quickload Observe Value If I observe the value right after quickloading, it should be the same every single time, shouldn't it? Nothing inside the game universe changes. Thanks, I will try that! By the way, I actually just care about the surface-relative velocity at the UT, so if there's a shortcut for that that would also work. edit: Just tried GetOrbitalStateVectorsAtUT(), returns a different value than getOrbitalVelocityAtUT() but it also drifts across reloads.

Hi! I am trying to calculate the velocity (with direction) at a certain point later in the orbit. I am trying to read this with this with Orbit.getOrbitalVelocityAtUT() Vector3d orbitalVelocityAtImpact = vessel.orbit.getOrbitalVelocityAtUT(impactUT); However, something very strange is occurring: I quickload a save, and proceed along the Orbit for a few in-game minutes. Then I reload the save from where I started. But the Orbital Velocity has changed direction! I presume it is still in the state before the quickload. Here are three values that I recorded right after quickloading: + orbitalVelocityAtImpact "[169.909714097467, 29.454900938199, 10.8833349871162]" Vector3d + orbitalVelocityAtImpact "[171.443843360678, 18.5448866639756, 10.8833496607608]" Vector3d + orbitalVelocityAtImpact "[172.27266602452, 7.68307916777123, 10.8833286528833]" Vector3d As you can see, the velocity keeps rotating. This is with the argument of the function (the time) staying approximately the same. I am confused @Starstrider42 was onto something here, and he mentioned something about Planetarium.Zup quaternions. Unfortunately, I have no idea what Planetarium.Zup is, how it changes, how it relates to Orbit.getOrbitalVelocityAtUT(), and how to use it to fix my rotations. Can you guys help me out here?

Silly question, but shouldn't bigger engines be more efficient than smaller engines, inherently?

That's quite alright, I'm not opposed to stealing good code from good people Well how integrated is it? Could it be surgically removed and grafted into other mods, or do you have deep dependencies on the rest of TCA? I guess I'll take a look and see for myself ps.: Yep, that would be a T4-Phage. I'm a space-loving biologist, so there is no better avatar than a bacteriophage that looks like a SciFi spaceship

Hey allista, this sounds super interesting to me. Did you create some kind of Framework for automatic testing? This would be super useful for all mods related to automation or control/avionics!

Yes, looks great now! Awesome, thanks

Hi! It seems that the "We're looking for talented developers" banner is causing some trouble on Mobile. First, the banner itself is cut off, which wouldn't be that big of a deal: However, the banner causes the site to be bigger than the actual screen size. This also makes the menu on the right partially hidden: But most annoyingly, when scrolled to the right, there is grey "empty" space: I think that for a forum software that would make a good enough job of mobile-izing the forum just by itself, it's a bit of a shame that the banner makes things awkward. Is there any way that this can be fixed so that the site has the proper size on Mobile? Maybe make the banner smaller, or turn it into background?

Hi, a little update on my endevour: I have implemented the "MechJeb2-version" into KerbalEngineer in this branch: https://github.com/fat-lobyte/KerbalEngineer/tree/suicide-mechjeb The timer works reasonably well, but I had to change the definition of Altitude and Distance Altitude: "altitude when to start a suicide burn" -> "Altitude lost during burn until velocity reaches 0" Distance: "distance to the point at which to start a suicide burn." -> "Distance above ground after a suicide burn" Note that both definitions are equivalent at the time of the start of the burn - but only then, not before. Turns out it's pretty hard to calculate the Altitude lost. I am also currently preparing a different approach: there is a method of calculating the velocity and time of a gravity turn as a function of the angle, for constant TWR: Computational Algorithm for Gravity Turn Maneuver By M. A. Sharaf & L.A.Alaqal There is a closed form for the burn duration from the initial conditions, but unfortunately not closed form for altitude lost. So I decided to implement that algorithm in KerbalEngineer, and do a little numerical integration. Maybe this will be a bit costly in terms of performance, but I really really want proper suicide burn info I'll keep you guys posted on my progress, and when I'm done, I'd love to submit my code for "peer review" @diomedeaI'm afraid I do not fully understand your approach, but I see a bit of an issue here: The vertical-only problem is already fully solved, and in fact is already implemented in KerbalEngineer (and keeps crashing Scott Manley because he's not aware that it's vertical-only ). The horizontal component is where the money is at, beause that's what's required for entry from orbit, and for minimal dV usage. Now I believe that the complicated part lies in "consider thrust applied retrograde" and in "craft pitch changes while horizontal speed is matched to the body surface speed and thrust is applied by sine and cosine of pitch to the vertical and horizontal portions of the problem." For infinite TWR, everything is very simple: the Energy we use is: Energy of vertical component, Energy of horizontal component and Potential Energy of altitude. So far so good. But for finite TWR, we have to consider gravity losses: while we are killing the horizontal velocity, we need to keep our head afloat to not crash into the ground. For TWR -> 1, the work that needs to be expended tends towards Infinity. Somewhere in between lies the actual value, but for sure, the Energy expenditure is not at all constant. To put it in your terms: "Work [...] is applied along the direction the vessel moves: W = F * (zb - zf)" - in the 1-D case, everything is clear. But in the 2-D case, the thrust is applied along a curve, and the shape and length of the curve is dependent on the intial speed, the angle to vertical and the TWR. Please do correct me if I'm wrong! If you can, I would be glad if you could flesh out your idea to include horizontal+vertical. If you could package it in a nice, simple formula for altitude and burn duration as a function of velocity and TWR, you would make me a very happy man

Hi! Is it currently possible to do Edit-and-Continue with KSP and Visual Studio?

Hello friends of Landing math, hello @tavert Unfortunately, your awesome derivation document and landing/takeoff calculation code have disappeared from your dropbox Would it be possible for you or for someone to upload a copy somewhere? I think this kind of math is very useful. It would be much appreciated.

Can you try deleting your \GameData\Trajectories\Plugin\PluginData\Trajectories\config.xml ?

I have been pondering to create a Telemetry library, but that would be a different focus. I would like to have a library for logging numerical values that help to debug KSP math/simulations. Kind of like writing to CSV files in every frame, but buffered and configurable (channels, frequency, ...).

Colony Mishaps? Sounds intriguing. What are colony mishaps?

But I do not have RemoteTech installed.

Actually, could someone sum it up for me again? Because all I can find with the search function is "I have it too", but no actual reply from @allista or @RoverDude about the "Coroutine could not be started". I understand that repeated questions like this get annoying - but when a thread is just a huge unstructured pile of posts, it gets really hard to find information that I'm looking for.

Sorry about that. This is again one of the times where I wish a populer Mod thread would actually be an own subforum with separate topics instead of a long sausage of mod-related talk.

Hi! I keep having the following logspam: [ERR 18:17:23.256] Coroutine couldn't be started because the the game object 'Tundra.Workshop250' is inactive! [ERR 18:17:23.257] Coroutine couldn't be started because the the game object 'Tundra.AssemblyPlant' is inactive! [ERR 18:17:23.258] Coroutine couldn't be started because the the game object 'Ranger.Workshop' is inactive! I have MKS installed, and this happens basically all the time whenever vessel config changes (KIS add/remove, dock/undock) or when vessels are loaded. No vessels have any of these Parts attached. Is there a way to get rid of this?

Yep, with v1.4.5 and 1.4.6. The impact reticle starts drifting away from the target reticle almost as soon as I hit the atmosphere and I end up around 30 km away from the initially predicted target - and that's with only the Mk1-Command Pod (or the Mk3-Command Pod) perfectly retrograde, so there shouldn't be any funky wing/lift business. I'll go back more in history in the next few days and see when it starts being precise. Because I definitely remember times when I landed on the spot - I just don't recall when that was.

The simplest thing you could do is delete all .dll files. The next step is to find and delete all ModuleManager config files - unfortunately those end in ".cfg", just like the parts ."cfg" which are required.

Hey guys, I need a little bit of help in debugging. What was actually the last version of KSP and/or the last version of Trajectories, where the Impact prediction actually worked correctly? How to test: Load up a legacy version of KSP, find the appropriate release of Trajectories here: https://github.com/neuoy/KSPTrajectories/releases If you don't have Hyperedit, take the Kerbal 1 (Stock Craft), remove the parachute. If you do have Hyperedit, create a new craft and add in just A Mk1 Command Pod To the previous craft, add A TR-2V Stack Decoupler, upside down An FL-R10 RCS Fuel Tank 4 RCS Blocks on the RCS Fuel Tank Launch or hyperedit the craft into a 85x85 km orbit Lower your periapsis to 55km using the RCS thrusters Decouple everything so that only the Capsule itself is left In Trajectories: Next to "Descent Profile", click Retro Open the Target Tab, click "Set current impact" Timewarp to atmosphere, make sure you are pointed retrograde. In some KSP versions this is rather annoying due to broken SAS. Keep it pointed retrograde Observe if the Predicted impact point (Red) deviates from the Target impact point, and if you "hit" the target impact point. For our purposes, everything within 5km is called a hit. I actually went back as far as KSP 1.0.5, and even there the deviation was up to 30 km - with a craft as simple as a single Mk1 Command Pod. So when was this Mod actually accurate?

Thanks for the offer, but I think I'd rather stay on the Code side of things

Hi! So I have been working on the Wiki page for the Konstruction ports, because I finally figured out how they are supposed to work. You can check out my text here: https://github.com/BobPalmer/MKS/wiki/Functions-(Konstruction)#advanced-construction-port-usage I tried to make sense of the whole Angle Snap and Compress Parts (Rotate) business, and expanded a bit on the various Port settings. Please read it and give feedback if any of that makes sense to you, and if not please mention the parts where confusion arises. (obviously, you can also report or fix typos, grammar, and spelling mistakes ) I would request a little help on the illustrations, though. First, I would suggest to split up @dboi88 amazing diagram: https://github.com/dboi88/USI-MKS-KSPedia/raw/master/MKS KSPedia/Assets/Pages/Konstruction Parts/magnet diagram.png Instead of having them as one giant diagram, the parts should go into the individual sections under "Settings", below their textual explanation. Second, if you read this paragraph, your head might start spinning: Because mine certainly did when I wrote it. I think in this case, a diagram says more than a thousand words (fine it's actually, 177 ). I would suggest two or three diagrams: the first one, where the Construction Port is visible from the front, with the black rectangle towards the top and an Arrow to the Top. The second would also be the Construction Port and have four bars (like tick marks on a clock): at the positions 0°, 90°, 180° and 270° and maybe an arrow that points to the 90° position. The third is not strictly necessary, but might be helpful: it has also the construction port, with "ticks" at 0°, 60°, 120°, 180°, 240°, and 300°, with the Arrow pointing to 120° or something. If somebody could make those, that would be awesome. If not, we'll have to make do with the readers geometric imagination capabilities Oh and of course, the main point of this whole exercise was to provide text blocks for the KSPedia, to speed up @dboi88 amazing work

Thanks, that's already important information. Now we can adjust the documentation and "spread the word" That's a shame though. It's gonna be hard to report bugs for stock, since none of the stock ports actually have a roll force and don't snap either. Is there any way this is fixable from MKS? No worries, whenever you get around to it. I'll see if I can summarize the behavior in the Wiki, so you have some text building blocks that you can copy and paste.