scimas

Are there plans to provide future predictions in the.. future?

@pleroy Is VesselGetPosition only supposed to give past positions? I'm extremely new to modding (even using C# at all), so I could be doing something wrong. But passing a time not in the past (eg Planetarium.getUniversalTime() + non_negative_number) throws out of range error. If it isn't supposed to work like this, I will open an issue on github.

In my experience, it's actually the parameters themselves not matching is the problem. When the state of the vessel is such that the "one SOI at a time" is not a good approximation of N-body physics, the magnitudes or anomalies of various nodes differ significantly from the conic approximations. If you turn on the "show patched conics" option in principia, and make that orbit stay in the expected limits for 10 s, the contract will get completed - even if the values change in those 10 s, they just need to remain in limits.

There is no fix for it. That comes from the fact that Principia has to inject the delta V amount again and again into the stock system for the node direction to change realistically and the 2nd bullet point from https://github.com/mockingbirdnest/Principia/wiki/Concepts#flight-planning . Basically it is only a flight planner, not an execution helper. Whether there are any plans to implement something like that in the future, only the devs can say anything about that. Not having some kind of auto-updating system does make gameplay a little inconvenient, like losing the whole flight plan just because you EVAd, but that's how it is right now. From my experience, you get used to executing the nodes based just on the burn time. And the N body trajectories are so chaotic that it's just better to do small correction burn afterwards rather than aiming to do one single perfect burn.

That is not a bug, that's how maneuvers actually work, both in real life and in KSP. A burn is not instantaneous, it takes non zero amount of time. Principia is doing burn calculations starting from your t0 time to however much time it will take for the engines to provide the required delta V. The stock maneuver planning shows exactly aligned PE/AP markers because it doesn't take into account the finite duration of the burn, which is wrong. You have two options: 1. turn on instantaneous burn calculation in principia planning UI. OR 2. Preferably, move your node around until the markers line up however you want them to.

Can't wait to check it out once it is re-released! I forgot to ask this last time, is the angular momentum conserved across scene changes? It seems like a safe assumption given that Principia will completely manage any not-landed vehicle (and of course I can just wait and check it out myself later, but who has the patience, right? )

I don't think there is any way of getting moment of inertia other than actually going through the calculation yourself. As for why dividing angular momentum and angular velocity doesn't work: Well, two reasons. 1. Both of them are vectors, so the division operation doesn't make much sense unless they are collinear. 2. Moment of inertia is not actually a single value, it is a tensor. Basically a 3 x 3 symmetric matrix. The matrix is diagonalisable, but that still leaves you with potentially 3 different values. The formula for calculating the tensor is simple enough. The problem is we (at least I) don't know how KSP models the distribution of mass. Whether you need to calculate a sum or an integration depends on that.

Simple kOS approach works as long as you have unlocked manoeuvre nodes (in case of career mode). Lock steering to the manoeuvre vector. Calculate the time required to burn the necessary Δv. Start burning at the appropriate time and stop once the calculated time has elapsed. Two problems with this: 1. Since the burn has to be calculated at full thrust (flight planner takes thrust limit into account, but only if it's in place before you created the manoeuvre, so it will be full thrust most of the time), and the values reported by kOS only change every physics tick, the burns will never be perfect. 2. The manoeuvre disappears as soon as the burn time, as determined by Principia, has passed. Which means you have to do some trickery in kOS to avoid errors with trying to lock to a node that doesn't exist. Which further decreases the possible accuracy of manoeuvre execution. A function that does the node execution: https://github.com/scimas/KOS-Scripts/blob/master/Script/library/lib_manoeuvre.ks Code to calculate the burn time: https://github.com/scimas/KOS-Scripts/blob/31f3a5e73358cdcd5972aa20ee5566283075d74c/Script/library/lib_navigation.ks#L230 Really excited about this! Is it supposed to conserve across time warp? And does it account for movement of resources around ship, like fuel or ore?

Yeah, although I had heard many times that youtube comment sections are some on the worst places, I had never seen anything "bad" in there. Some comment sections are filled with inconsequential "Who is watching this in...?" type of comments, but nothing inherently bad. That Scott Manley video was the first time I saw really messed up comments all over the place.

The video coverage is always so bad man... Every time I hope they will get better, but they never do. They had actual footage of the fairing separation but chose to keep showing the people instead.

Great job on planetary trajectory plotting! Though I haven't played yet.. Also, no support for 1.8.x? Since it isn't mentioned in the change log I assume it isn't there; but I thought it might be there since 1.8.1 has been out for almost a month now..

The documentation is very comprehensive. KOSPROCESSOR:BOOTFILENAME is literally the third search result for "boot" in a total of four results.. That depends on what situation your ship is in. If you're moving at a very slow speed, then it is highly likely that the retrograde direction is moving around wildly. Whereas heading(90, 0) is more or less a fixed direction. And I repeat again, SAS has to be off if you're using kos' cooked steering.

1. SAS should be off if you're using kos' steering. Or they will fight each other. 2. Simply placing a file in the boot directory isn't enough, you need to point the bootfile to your program too. Either you do that via VAB / SPH when building the ship or manually via the terminal when in flight: set core:bootfilename to "/path/to/program". From next time, that program will run automatically. Also, I would change the first line to wait until SHIP:LOADED and SHIP:UNPACKED. I have seen sometimes that using just one of them isn't enough.

https://www.youtube.com/watch?v=7iqNTeZAq-c Supposed to go live at 7:40 PM UTC

Looks really nice! But the rover (or its wheels) not moving up and down with the now visible surface details is a bit silly. I know it would require a lot more processing for that level of detail (not to mention possible wheels/landing legs kraken), but that doesn't stop me from wishing it was there...

Aren't ship:control:pilotXXX Get only, except for pilotmainthrottle?

@Eriksonn As far as I understand, your mod is going to do its job only once (when its installed in a save). So it wouldn't be a problem if it did more computation than strictly necessary. Since you're facing the problem of different density of points near the poles vs near the equator, one easy (conceptually) solution would be to sample the points thrice. Once with the regular latitude, longitude (what you're already doing). The other two times use coordinate systems that are orthogonal to the original and each other. So the "north pole" would be at the original equator at 90 degrees separated longitudes. That should give you a good enough uniform sampling density, and then simply take the mean of the generated coefficients. I think that should work, if I'm not making any mistake. Looking forward to the mod!

That would work for two dimensions, for example if your burn was only along tangent and binormal. How do you decide which one to change in three dimensions? If you adjust the normal component, should the mod auto adjust tangent or the binormal component to keep the total Δv constant? I would say don't try to get the first manoeuvre perfect, you usually can't execute it to the predicted accuracy anyway. Rather make a manoeuvre that takes you close-ish to the planet and plan more manoeuvres along the way to fine tune it.

No, only up to 1.7.2. Wait for the next new moon when Principia's releases happen, the next release might support 1.7.3. Although I'm not a dev, so this isn't a promise from them of supporting it then. Probably you or some other mod has made changes to the stock solar system, which prevents Principia from using its configurations to integrate it. See https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#kopernicus-users

Successful launch of Chandrayaan 2 to better than GTO! I'm happy today Now hoping for a good landing

@eggrobin @pleroy I discovered today that the flight plan can't handle flipping of an orbit by buring retrograde. That is going from an prograde/retrograde orbit to retrograde/prograde orbit by burning along only the tangent. There comes a point when the pro/retro directions flip around and the flight plan fails to compute the correct trajectory from that point forward. I know that no one in their right mind would plan a maneouvre like this in serious gameplay. Flipping around by burning binormal works just fine. It is just something you might want to consider handling for completeness' sake.

In stock, your ship's motion is only affected by the current body. That is, if you're near Kerbin, Kerbin's gravity is all that matters. Mun won't affect you, Minmus won't and even Kerbol (the Sun) won't affect your motion. Same goes for the planets and moons. Kerbin's motion is only affected by the gravity of Kerbol; Mun, Minmus and all other planets don't matter. Also, since Kerbol isn't "orbiting" around a body, it isn't affected by all the planets orbiting it either. Although this is a decent enough approximation for the game, it is highly unphysical. So Principia makes it so that the gravity works like the real world. Everything affects the motion of everything else. There are 2 exceptions, rockets don't affect each other (except collisions obviously). And rockets don't affect the motions of the celestial bodies. In addition to this, celestial bodies aren't perfect spheres and even if they were, the internal mass distributions are never uniform. Which further changes the shape of the gravitational field (see https://en.wikipedia.org/wiki/Mass_concentration_(astronomy)). Principia also models these features where data is available (eg The RealSolarSystem mod). All of these things taken together make many different orbits and effects possible. (see https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#interesting-things-to-do) If you want to have those in your game, this is the mod for you.

Then it's probably completely caused by the size of orbit and the sampling rate. At the 86 km orbit, the angle by which your velocity vector rotates in a finite non-zero Δt is much more than in a 100 km orbit in the same Δt. Try an even higher orbit and the error will become even smaller. Since the angular velocity goes down as r^(-3/2), the error also probably false at the same rate.

Have you confirmed whether SHIP:BODY:DIRECTION:VECTOR is an unit vector?

What is that supposed to mean?