Pand5461

@Benzel Hello and welcome! You can use telnet connection which allows you to copy-paste in your OS terminal. @theJesuit None I know of. There're GUI functions that allow arbitrarily-placed textboxes, if that helps. @johansen there certainly are, just maybe not here. Check /r/Kos and the Discord server. And yeah, GUI thingies are hot topic these days.

OK, but be prepared: said change of energy depends on the initial orbital state (that's what Oberth effect is about). So, in order to make a comparison that's at least sane, the initial orbital states must be all the same as well.

That's incorrect. Past the escape velocity, the object has nonzero velocity at infinity (called the hyperbolic excess velocity), hence nonzero kinetic energy. And if you add some speed at periapsis, that hyperbolic excess velocity increases as well. Another thing that bothers me, how do you justify the calculation of work from the change in the total mechanical energy of a ship when the ship at the end is not the same as the ship you started with (because some fuel was burned)?

For GPP specifically, you'd better follow installation instructions from the official Github download page: https://github.com/Galileo88/Galileos-Planet-Pack/releases (choose you version there, I'm not sure which one is the latest for 1.3.1) The first step in that instruction is: remove all installed mods. I've seen issues on my computer when I installed some mods first, and then GPP. So, it's a reall good idea to start with installing GPP, verifying that it works and only after that adding other mods.

I think it can be possible with ScrapYard mod.

Looks like MechJeb's PEG is in essence the Apollo-level version, which can do only coarse plane matching. There's a thread on Space Shuttle PEG implementation in kOS here on forums: You can find download links there and give it a try with your rocket.

kOS вообще, конечно, крут, Хоть с него, бывает, мрут. Но какие выживают - Те до старости живут.

@Jeine092 You may ask your question in the russian section of the forums, if that's your first language https://forum.kerbalspaceprogram.com/index.php?/forum/91-russian-русский/

The velocity gain in the gravity assist is directed along the vector from the periapsis to the assisting planet. To raise the apoapsis around the Sun, the ship needs a positive velocity increase in the prograde direction, so the perikee must be behind Kerbin in its orbit around the Sun.

I have a similar script, and that works as expected - i.e. it overwrites the file in "1:/" by the edited file. So, are you sure you actually saved the file in the Ships/Script folder before calling AG1 in game? (I do forget doing that sometimes). I suggest that you debug print open("0:/test.ks"):readall:string. One way off the top of my head: set wpmarker to vecdraw(). set markerlength to 150. // arrow length in meters set markerendalt to 0. // end of the arrow AGL altitude in meters. set markerwidth to 10. // arrow width set wpmarker:show to True. set wpmarker:startupdater to { return wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt + markerlength). }. set wpmarker:vecupdater to { return wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt) - wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt + markerlength). }. set wpmarker:width to markerwidth. WPCOORD is the GeoCoordinates of your waypoint. The vector will be pointing to the ground if MARKERLENGTH is positive, and to the sky if it's negative. (some assembly may be required, I did not test the code)

Have OpenSUSE Tumbleweed with Cinnamon. Had letter keys not working once, everything went back to normal after a game restart.

Lagrange points truly exist only for a very specific problem, namely 2 massive bodies in perfectly circular orbits around their mutual center of mass plus the third low-mass body. So, where exactly should LP be placed if orbit is eccentric? At what velocity should they move (if we want to be able to match velocities with them)? And, well, there is an even easier way to have Lagrange-points-like behavior in patched conics - have the SOIs large enough to include objects that have the same orbital periods around a smaller body as the smaller body has around the larger body. In some way, that would be more realistic than the OP's suggestion: the Lagrange points won't be stable and low-energy transfers between L1 and L2 are possible. Another thing is that Lagrange points are in reality very spacious. Herschel space telescope, according to Wikipedia, "entered a Lissajous orbit of 800,000 km average radius around the second Lagrangian point (L2) of the Earth-Sun system, 1.5 million kilometres from the Earth". That is not quite what I'd call a "tiny pseudoSOI".

That's the same as survivalship bias. "People who asks about those numbers can play happily without knowing them" ≠ "No players would benefit from knowing them". Obviously, people who know what orbital elements are don't ask questions here. That does not mean they don't care about having that info. E.g., I don't need to go to tracking station and see the orbit if I see >90° inclination and high eccentricity in the contract description. I can just decline that contract immediately.

And there are others who uses kOS or kRPC and need those numbers to code the guidance for automatic transfers to those orbits. The same "extra numbers in the interface are scary for newbies and bad for sales" rationale has already taken away any hope for stock DeltaV info for vessels. To not "make it harder for those who are learning", the info has to be represented in a "newbie-friendly" way, not taken away entirely.

OK, I'm glad you could find the source of the error. I still don't get your maths, frankly. After getting to the infinitesimals, I just can't resist the urge of taking the integral and getting the rocket equation. I'm assuming, it's something about having a product of the form (1 + A1z + A2z2 + o(z2))×(1 + B1z + o(z2)) which gives a third-order polynomial but is insufficient to get a correct third-order expansion.

How exactly did you arrive to (2)? That looks kinda weird. (the whole point of this effort evades my understanding, but I'm trying to be polite)

No, they mean you can't unlock science nodes that cost more than your building allows. With resource transfer unlocked, you can transfer liquid fuel/oxidizer/monoprop/ore/xenon/electricity between tanks (or batteries, in the case of EC). Maybe not critically needed right now for you, but will be required when you start building bases and get contracts for resource delivery. I suggest taking rescue, rendezvous and EVA. They will be accomplished in the same mission. Overall, taking several contracts that can be done in one launch is a good idea, especially with expendable rockets (I know, they are not trendy these days but reusable rockets are not readily available in the early game and even in a late game require more attention than expendable stuff). Oh, and don't forget solar panels and monoprop for the rescue mission. Before you get proficient with rendezvous, you're going to spend lots of EC and RCS fuel.

If you have too much final velocity, you can try throttling down the engines (or setting thrust limiter to a lower value, if it's possible at your current career level). Overall, try not to take contracts that involve crazy Part+Alt+Speed combinations. They usually pay less than you spend trying to complete them.

There is a formula to decide whether a bielliptic inclination change is better than a single-burn: where ra is the ratio of transfer orbit apoapsis (plus the body radius, of course) to the radius of initial circular orbit, i is the inclination change. Consequence: for changes less than 2arcsin(1/3) = 38.94°, single burn is favourable. From 38.94° to 2arcsin(sqrt(2) - 1) = 48.94°, a bielliptic transfer with some finite apoapsis radius is optimal. For inclinations changes by more than 48.94°, a bi-elliptic change with any apoapsis radius will be better than a single-burn change.

Kerbin's atmosphere is 70 km, which is about 11.67% of the planet's radius. On Earth, that would translate to about 750 km of atmosphere. In reality, rocket go to the low-Earth parking orbit at about 250-350 km with a continuous burn. If the payload needs to get to 750 km altitude, a series of transfers from a parking orbit is more efficient. Space Shuttle didn't typically go even that high by a continuous thrusting. It went first to ~110×250 km orbit at about 150 km altitude, dropped the orange tank so that it reentered on the next orbit, and the orbiter itself circularized at apoapsis about a third an orbit after SSME cutoff. In fact, going full gas until you get wanted apoapsis altitude and then coasting to apoapsis is in fact the most fuel-efficient strategy in KSP for most crafts, except very-low-TWR upper stages. A typical KSP rocket is powerful enough to orbital velocity way before it can jump out of atmosphere. The idea that continuous burns at non-maximal thrust are more fuel-efficient than burn-coast-burn sequence is a common misconception here on forums. If you have to throttle down to optimize fuel consumption - the best way is to throttle down all the way to zero! Because in that case, you spend less time thrusting above horizon and having gravity losses because of that. If the atmosphere thickness was about 25 km, then continuous burns would be the way to go.

To fit coefficients into the known functional form for force dependence on position and velocity - yes, maybe. Certainly not for the actual path prediction.

Use AI to compute a motion of a dynamical system when there is a myriad of numerical integration methods with proven accuracy and rate of convergence... Probably CS students who learn things beyond buzzwords are too awkward to show in a fancy video.

The MM version seems dated. 2.6.6 was released in June 2015, way before KSP 1.2.2 came out (December 2016).

Cool! Now I know that there is an explicit way to set maxPressure. Yes, 15000 kPa (150 atm) tolerance should be reasonable. That's about the same pressure as 1500 m underwater, so the pod should weigh roughly as much as a bathysphere.

Edit: Ninja'd