• Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About lawndart

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @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.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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?
  11. 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.
  12. 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.
  13. 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.