lawndart

One thing you learn quickly with Principia is Satellite Contracts around moons? - just say no.

@Kobymaru My gut instinct is you have a stale manoeuvre node and this is causing the spacecraft to lose the plot. As a relatively veteran Principia user my first action on switching to a vessel before a burn is to toggle Show on Navball off and on again, which recalculates the node marker position. Even a relatively simple plotted circularisation after a nudge to raise the orbit can leave the node 180 degrees out of position when you reach the time to perform the circularisation burn.

The Principia flight plan window shows the time to node near the top left. Once the node has been reached it counts down to burn completion, so no stopwatch needed. I use RemoteTech's flight computer to conduct burns. I usually put the required delta-V in the Burn duration field, set the throttle to 100%, use the Node button to set the attitude and smack the Burn button when the node countdown hits zero. If you use Kerbal Engineer Redux and have the time to node showing you can close the Principia windows and initiate the burn using that. This also restores the stock deltaV countdown. One thing to watch out for is if there is multiple manoeuvres on the flight plan - to prevent the ship from immediately altering its attitude to the next node's position I switch from Node to Kill mode just before the burn completes. That way I still have the ability to nudge with RCS if the plot has drifted too far. Even so, sometimes the calculated burn ends up under or overshooting the plotted path by a considerable distance (RT vs P time?). If so I F9 and do the burn again by eyeball. Possibly some of the time calculation issues are down to my game requiring a whopping 36Gb of memory and I only have 16Gb RAM installed. I'm still messing around in the vicinity of Gael in GPP, so not much issue with lightspeed time delay. I treat the multiple node flight plan as a "can it be done?" calculator. Once I have completed the first burn I immediately delete the plan and rebuild. I am so accustomed to this that I even delete the plan on those oh-so-rare perfect burns.

I already use Remote Tech's computer, but due to the way Principia has the node as the burn initiation rather than the mid point, I use it to set the node orientation and use the Burn xxxm/s function to trigger a precise burn at the node point. If you run the Execute function it tries to perform the burn early, so this is going to throw the plan out. Once the burn is complete the computer automatically switches to prograde or the next node, so messing up your orientation for any fine tuning. So not perfect. In that regard would it be possible to have a toggle to set Principia to fake a Node-At-Mid-Burn by adding 50% to the initiation time? That way automated systems using a Node-At-Mid-Burn timing would be in sync with Principia.

Occurs with Stock + KER + Principia Info log (part): 1206 16:10:34.231690 4012 interface.cpp:779] End plugin serialization I1206 16:10:35.001734 4012 interface.cpp:674] Reinstating stock gravity I1206 16:10:42.080139 4012 interface.cpp:262] Destroying Principia plugin Lots of objects being destroyed... I1206 16:10:42.087139 4012 interface.cpp:268] Plugin destroyed @ 000007FEED07E28D principia__GetPlottingFrame [0x000007FEED07E28C+236028] @ 000007FEECFEBA2B principia__SetBufferedLogging [0x000007FEECFEBA2A+573390] @ 000007FEED0100CB principia__SetBufferedLogging [0x000007FEED0100CA+722542] @ 000007FEECF4B8AC principia__CurrentTime [0x000007FEECF4B8AB+75] @ 00000000154D4E0C (No symbol) [0x00000000154D4E0B] F1206 16:10:42.097139 4012 interface.cpp:252] Check failed: 'plugin' Must be non NULL

Not yet been able to reproduce the issue with a clean install and just Principia and KER added. We can rule out MechJeb as being the cause as I don't use it. I'll keep trying different orbital parameters and hopefully it will manifest itself. From my old 1.2.2 heavily modded game: Lighter docked with fuel depot The depot after undocking. Time acceleration works normally. Possibly because it has greater mass? The Lighter. On undocking it seem to "fall off" the docking connector towards Gael. Note KER does not show the vessel as under acceleration. Quicksaving then reloading would usually fix the problem.

I have also experienced the "vessel under acceleration" issue after undocking in 1.2.2 . I wasn't aware it was as high as 0.45g though. Unfortunately I have just transitioned to 1.3.1 and not reached the point in my new game where I am in a position to perform docking manoeuvres, so unable to assist with logs.

The stock mode switch at 36km is fine. I agree it is probably not a good idea or worth the time and effort to try and defeat the switching. To be honest I'm not sure that I was making myself sufficiently clear as to what I was doing in my original request post. In Catalan I was able to prevent the switch to KCI by selecting KCKF as the frame of reference at any point on the pad or during ascent below 36km. The program switched from Surface to KCKF instead of KCI as it passed the 36km threshold and remained that way until I manually set it to KCI after ascent and orbit circularisation. Launch a Catalan rocket. Don't touch the navball. At 36km it switches from Surface to KCI. Ok, revert to pad. In Principia set frame of reference to KCKF. Again, don't touch the navball and launch. At 36km it switches from Surface to KCKF. In Cauchy the process that pins the frame to KCKF has clearly changed the way this works and the switch to KCI cannot be overridden (I've tried). While I appreciate the work done on unification, this is not really what I was hoping for. It is still confusing for people new to Principia and it doesn't help when you are trying to coax a recalcitrant rocket through the upper atmosphere with both hands on the keyboard trying to stop it biting its own backside and the navball horizon disappears. I guess I was hoping for "If not vessel sit = ORBITING then set frame of reference = <body> Centred <body> Fixed" whenever a vessel was created. Sorry if this sounds like a whinge; I'm not whining, but trying to explain.

Ah, thanks for the clarification and all your hard work on this. Although it is a pity we have lost the functionality to have Principia transition seamlessly from Surface to KCKF instead of KCI at 36km.

I think there may have been a misinterpretation of my navball request. With Cauchy and prior to launch at KSP the navball shows KCKF instead of Surface. On ascent past 36km the navball is still switching to KCI, whereas I was expecting KCKF to maintain the planetary horizon for orbital insertion while the vessel was still suborbital. Toggling the mode by clicking the navball only switches between Surface and KCI; KCKF is only reselectable by the Principia interface. Prior to this version I was selecting KCKF in the Principia interface prior to launch so the navball would switch from Surface to KCKF at altitude instead of KCI. Once the 36km altitude has been passed and the navball switches to KCI you cannot set it to KCKF until you have reached 70km. Trying to switch to KCKF in the Principia interface just switches to Surface on the navball, with Surface velocity. Once in space the navball displays KCKF but the velocity is still the Surface velocity - KCI reads ~200m/s higher. Unless I am doing something wrong?

Excellent, thanks

Possible bug? Stock + Catalan. I've been getting random loss of function while setting up a rendez-vous to cover the issue mentioned earlier. When switching between two vessels the switched-to vessel appears as normal but I am unable to access the map view, escape, load or time warp. All flight controls are working normally and so does the return to Space Centre button, fortunately. Dropping back to the menu and reloading doesn't help; the only recourse is to close KSP and restart. Also had this when I went from the Tracking Centre to a vessel that had its engine deactivated. Can someone please confirm this is happening?

I have also seen the time-warp position jump when attempting rendez-vous, however I am running a heavily modded KSP so I wasn't too sure where the issue lay. The vessels jump back on restoration of 1:1 time. Might be related: I am also getting excessive supplies depletion in Tac Life Support when time warping and flying a ship in space, with the time remaining on the supplies clocks running down faster than the warp is accelerating the time. This does not happen when time warping at KSC, I'll try and reproduce the jumping issue in Stock + Principa for you and create a save file. If you don't mind a mod that should be in the stock game anyway, Kerbal Engineering Redux can show relative inclination on screen, presumably because it's looking at the conics value. I use this for getting my alignments - seems to work so far. Pleroy and eggrobin will now tell me that KER is using inaccurate values and shouldn't be used As for plotting the target's trajectory, I find the Principa method more intuitive than the stock method once you get used to it.

Thanks to both of you modders.

Confirmed. On quickload the vessel's horizontal velocity is increased. If you are going straight up when you save the vessel rotates towards the 90 degree line as it compensates for the increase.

A request: Would it be possible to use the <body> Centred, <body> Fixed frame of reference as a default for vessels launching from the surface? When the navball switches to Orbital during ascent it defaults to <body> Centred Inertial. This is all well and good for real-life computerized launches ( I know the Shuttles switched to inertial during ascent ) but most Kerbal launches are the familiar manual fin and engine waggling ascents and the horizon line on the KCKF Orbital navball is really useful for guiding rockets into a near circular orbit. It's just another thing to remember to switch over before launch and must cause considerable confusion for people new to the mod when everything goes Right Ascension.

Hi Pleroy, I have been trying to save just before the issue manifests itself, but it appears the act of pausing the game to save the file prevents the issue from occurring, or at least it has in the dozen or so attempts I have tried so far. I have also noticed the on-screen altimeter occasionally jitters for about half a second as the spacecraft transitions into the atmosphere but I have not had time to check whether this happens only when the 200m/s is added. I have also sent a spacecraft to Eve, but haven't been able to replicate the velocity change on hitting the atmosphere we get at Kerbin as yet. I've only made half a dozen re-entries at Eve so far, so it may manifest itself at some point. I'll try to get more testing in when I can, but I am supposed to be doing some decorating

More testing... I made a completely new install of KSP and added Principia Cartan as the only mod. A simple ship of Mk1 capsule, small nose cone, T800 fuel tank, T400 fuel tank, 4 winglets and a T1 Aerospike engine. Saved just before apoapsis. Without Kerbal Engineer Redux installed I can't see the numbers for periapsis until it is raised above 0km. I'm also getting mixed results. The bad news is the 200m/s addition is still occurring. Suborbital flights do not trigger the 200m/s addition where the periapsis is below Kerbin ground level. Once above ground things get complicated. Suborbital flights with a periapsis as high as 68km were not triggering the addition. Others did trigger the addition, but only where the apoapsis was higher than ~84km. So the issue may be apoapsis dependent.

OK, think I have found something regarding the 200m/s addition. I made a copy of my current Principia Cartan install which is modded with such things as Kopernicus/Galileo, as mentioned previously. I rolled back to Cardano and there were no obvious problems in a new sandbox game. I then deleted Cardano and installed Cartan and started a new sandbox game with the 200m/s problem reoccurring. I built an entirely stock ship for testing. I then noticed that suborbital flights on Gael (which has the same planetary values as Kerbin) were not triggering the 200m/s addition. Putting a ship in orbit then reducing the periapsis so it fell below the atmosphere entry point at 70km did trigger the addition as the ship crossed the boundary. So I launched a ship into a suborbital trajectory, saved, then experimented with different periapsis heights to see if the problem occurred at a specific point. And it does. If your ship's periapsis is below -70km the 200m/s does not get added. Above -70km (e.g. -69km) the 200m/s is added to the ship's velocity. Please could someone confirm this?

Hi Bobkabob, Yes, I'm getting this too. My deorbit burn should have dropped me to 23Km at periapsis, but I reached periapsis at 67Km - my velocity had kicked up by 200M/s as I hit the atmosphere and I was never able to deorbit. I also have quite a few mods installed, including Kopernicus and the Galileo Planet Pack. I'll also do some testing. Hopefully it's caused by mods/parts that are actually installed on the spacecraft, e.g. Kerbal Engineer Redux, or some flight characteristic modifiers, such as Persistent Rotation.