scimas

Not quite correct. As you said, SRFPROGRADE and UP are directions not vectors, so there is no cross product defined for them. Multiplication of directions does exist, but it's not the same as vector cross product. What you will need to get the expected vector is use the :VECTOR suffix on both directions take cross product of those vectors. And remember that KSP's coordinate system is left handed when taking cross products.

If I remember correctly, there are some videos about going to the Lagrange / libration points, ballistic capture. But I haven't found anything extensive, like a career play through with Principia, if that's what you're looking for.

@Nich ah, my bad, totally missed the paragraph about availablethrust from your post somehow. Hmm, I don't see any other way of getting the total current thrust value. But, assuming that you are having this problem only at launch, couldn't you just add a WAIT command? If I remember correctly, most engines have spool up times around 1-2 sec, so "WAIT 1.5" after ignition and then decouple clamps. The clamps have fuel pumps, so there isn't a problem of wasting fuel. Does that work? Though you will need to write special conditions for when your lowest stage is a solid motor instead of liquid fuel.

There is a SHIP:AVAILABLETHRUST variable, which gives the total thrust of all active engines taking into account thrust limiting (not throttle). Check out the kOS wiki, specifically the vessel structure page.

There will be a folder named glog in your ksp directory. If the cause of crash was principia, then there will logs in that folder. Those will be helpful to the devs.

Don't expect that mod to work very well with principia. It calculates everything assuming stock mechanics, but N-body gravitation perturbs things enough that the window AND transfer time both can change by several days. Read up central force problem and two body problem in any classical mechanics textbook or even wikipedia.

Never encountered this bug. I'm using a kOS script to execute nodes and the I'm tracking dV is simply summing (engine thrust * delta time) over the loop. And the prediction matches pretty well, I throttle down in the last second of the node to get burns within 0.02 m/s though.

I didn't comment on that because frankly I've never encountered this issue, the node gets deleted immediately after Time to cutoff reaches zero.. unless you're talking about the case where you have more than one manoeuvres in the plan. Then it immediately switches to the next manoeuvre, that might be your problem.

People usually use 'runmodes' to separate different functionalities of a script during a loop. For example, in my own general purpose script, runmodes 1 to 4 belong to various stages of launching and achieving orbit, and rumodes 5 to 9 belong to various stages of landing.

What you have said is true, but OP never said anything about time warping. Even if time warp was involved, the craft wouldn't tumble if the mode wasn't PHYSICS, or a mod like PersistentRotation isn't installed.

Principia doesn't completely overwrite the manoeuvre node, it just keeps resetting the delta V value and updates the direction of the burn. That's how you get more efficient burns (stock burns are directed at a constant direction. Which is why your orbit gets bigger and bigger when doing inclination change, you aren't burning normal to your trajectory at all times, you are burning along normal to the trajectory at the start of the burn). There is a Time to engine cutoff readout in the flight planner, no need of a stop watch. And if you prefer the stock like burns, there's the option to have inertially fixed burns. Which I think should give you a stock ticking down node. Completely agree. You can never perform a perfect burn and due to the nonlinear chaotic nature of N-body gravitation the error between planned and actual post burn trajectory just keeps on increasing the further you move from the burn. So I tend to create long flight plans only for initial visualization. After I'm satisfied with that, I just delete the plan and create single manoeuvres plans as I go. This has been brought up before too though; I guess the devs will improve it when they get time. I am using RemoteTech in one my saves right now, but I don't use its flight computer. Unless I want extremely precise manoeuvres that would require manually changing thrust limits, I use a kOS script to execute my burns. Don't know about RT, but I have noticed kOS getting out of sync with the game clock for as much as 5 - 10 seconds when time warping. But it corrects the error almost immediately.

If you go back in this thread 2 or 3 pages, you should find the doubts I had about the R function. It turns out that for legacy reasons the parameters of the R function are called pitch, yaw and roll but are in fact rotations around the x, y and z axes local to your vessel. And of those axes, I think only the y axis is sure to point parallel to south to north of the current SOI body. This is covered in the documentation too; but I had made the mistake of taking the parameters literally because of their names too. I think the same applies to the Q function too.

I've always wanted to ask this, and finally got to taking screenshots today. What do the various markers (pro/retro grade, radial in/out) mean in LVLH navball and where does the ship point when I use the SAS pro/retro grade, radial in/out modes? As you can see, I've target prograde, and in no frame of reference that I can think of should the ship be pointing radially outward from Kerbin and the navball showing radial in. The orbit is fairly circular and the second screenshot shows that even in LVLH frame, my velocity prograde should be about parallel to Kerbin's surface. The SAS pointing to pro/retro grade in target frame is always off by a big amount when the distance is large, even when you do come close (within 200m) there's usually a slight difference in prograde marker direction and where the SAS points.

You don't need two scripts, you need to rearrange your script so that a single loop executes both the ascent code and the logging code. I don't think anyone can help you more than that without actually looking through your code. Your problem is more about programming concepts than about kOS. I suggest learning the very basics of programming in a real world language, perhaps python, and then coming back to your script. There are a lot more resources freely available online to learn something like python compared to what advice KSP players can give you here on forums on specific problems. Once you have a good understanding of conditionals (if...else) and loops (for, while), go back to your script and kOS documentation and I'm sure you will be able to work through your problem. Perhaps search youtube for 'ksp kos', there are some excellent videos, playlists that can get you started on the right path to correcting your script.

Oh, I did not know that, will check this out. Yes, I have played RP0 a little with KCT and Test Flight. I like the concept of both of those mods in terms of realism, it's just that I don't want to bother about those things until I have got the hang of ship design for RSS scale, the million different fuels and similar number of parts. Sandbox mode is one solution, but then I get overwhelmed by the sheer number of parts available. So, good to know that the career mode is playable without those mods.

Kerbal Construction Time is listed as a recommendation in this forum post for RP-0, but CKAN has it as a dependency. So does RP-0 work without KCT, or not at all? As a first time RO player I would like to get a feel for the career mode without the extra hassle of Test Flight and KCT. And test flight did get removed without issue, it was listed only as a recommendation.

Ok, I had thought that maybe mod devs have to update their own configuration files with CKAN or something like that.

@hvacengi Thanks for the update! How much time does it usually take to show up on CKAN?

Ah, I see, otherwise those actions would be just instant like stock. Yup, got it, thanks for the explanation!

Yes, the keyboard shortcuts are working, perhaps I should have mentioned that in my OP. What is really bothering me a little is the side effect I mentioned; the brakes toggling instead of turning on and off with the press and release of the B key. Opening the console and trying to clear the input locks was the first thing I tried, but I hadn't realized that those 'RT...' were RemoteTech locks. Out of curiosity, why do those input locks exist when I do have control of the vessel? I mean, I don't know anything about how KSP works internally, but shouldn't the locks be placed only when connectivity is lost completely?

I'm unable to click on UI buttons like SAS, RCS, the brakes, landing gears and lights action groups. In google searching I found an issue on RemoteTech github from 2016 (#639) which probably is the same bug. Can someone confirm this and whether it's going to be fixed or not? If this indeed is a cause of RemoteTech, then there is a side effect of it too. The brakes key actually toggles my brakes instead of turning off when I release it. On KSP 1.3.1 btw, if that matters.

I just checked some things. No, it runs at ~60 fps. If I turn on V sync, GPU usage comes down to 75 - 85%. But it still goes above 90% in mission control and to 100% in RnD. Also, interestingly, with V sync on gpu usage in tracking station ~50%. With V sync off it's about 15 - 45%. Is it strange or what?

Take a look at this Principia stock modification of Bop. I guess almost any planet pack here uses the Kopernicus mod to create the system. Kopernicus uses cfg files to describe what characteristics a planet has, like mass, radius, orbital parameters and such. You will just have to mostly modify the parameters, mainly the orbital ones, to see which ones work and which don't. There isn't any concrete method of balancing a system. It is actually surprising that the stock system is so stable with real gravity; then again it might be because of its similarity to our actual solar system. Also, take a look at this, @rhoark, @R-TEAM.

How do you quote posts like the one above my reply? Edit: Never mind, as soon as I posted this I noticed the share icon in top right

Why does GPU utilization jump to 100% in Space Centre and VAB when it's barely 25% in tracking station and ~75% in flight? I'm not experiencing any problems because of this, but wanted to know whether it's a bug or expected behaviour.