suicidejunkie

I've got a strange issue, running 1.12.5 I've got Bill up in orbit with a screwdriver, and he's trying to bolt on some pipe connectors to a mun-destined craft, but it initially would only let me drop, not srfattach despite pressing x or h. I could snap the part in hand to nodes, but not actually attach only drop in place. I tried grabbing a tail fin off my refuel ship, and was able to place it back OK. Then I went to try and put the connector on the mun craft, and this time it beeped an onscreen error at me saying 'tool required'. I tried grabbing a rover wheel off the mun craft, and put it back just fine, then I was able to put the pipe connector on the mun ship. I did eventually get the fuel across, but it sorta seems like I need to pull a part off of a specific craft before I can put things onto it at the moment?? I didn't have any trouble with the wrench when I was building comms relay stations on Kerbin's mountains earlier; not sure what the difference might be, but in that case it was a single stayputnik getting a DP-10, batteries and some solar panels wrenched on from inventory. This is the first time I'm using the screwdriver this game and things are wacky in orbit. Found this in the logs. Really don't understand how I managed to finagle it to work at all given the messages: [LOG 21:27:54.533] [Part:kerbalEVA (Bill Kerman) (id=F2981789050)#Module:18] End item pickup: item=JS-1 Joint Socket, fromPart=[Part:kerbalEVA (Bill Kerman) (id=F2981789050)] [LOG 21:27:54.543] KIS UI lock acquired [LOG 21:27:54.544] Set pointer mode to: Drop [ERR 21:27:55.284] Module ModuleKISInventory threw during OnUpdate: System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.GetComponentFastPath(UnityEngine.Component,System.Type,intptr) at UnityEngine.Component.GetComponent[T] () [0x00021] in <2425394cf09642369e2109953e31f62b>:0 at KIS.KISAddonPickup.CheckIsAttachable (Part checkPart, Part refPart, System.Func`2[T,TResult] checkNodesFn, System.Boolean reportToConsole) [0x00000] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KISAddonPickup.EnableAttachMode () [0x000f1] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISItemAttachTool.OnItemUse (KIS.KIS_Item item, KIS.KIS_Item+UseFrom useFrom) [0x00003] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KIS_Item.Use (KIS.KIS_Item+UseFrom useFrom) [0x00013] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.UpdateKey () [0x000f6] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.OnUpdate () [0x00006] in <f5b78795b85e480894e49c47c6e38046>:0 at Part.ModulesOnUpdate () [0x0004a] in <be370b73275e49439ea5e41ceef6700f>:0 [EXC 21:27:59.156] NullReferenceException UnityEngine.Component.GetComponent[T] () (at <2425394cf09642369e2109953e31f62b>:0) KIS.KISAddonPickup.CheckIsAttachable (Part checkPart, Part refPart, System.Func`2[T,TResult] checkNodesFn, System.Boolean reportToConsole) (at <f5b78795b85e480894e49c47c6e38046>:0) KIS.KISAddonPickup.EnableAttachMode () (at <f5b78795b85e480894e49c47c6e38046>:0) KIS.KISAddonPickup.Update () (at <f5b78795b85e480894e49c47c6e38046>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [ERR 21:28:06.349] Module ModuleKISInventory threw during OnUpdate: System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.GetComponentFastPath(UnityEngine.Component,System.Type,intptr) at UnityEngine.Component.GetComponent[T] () [0x00021] in <2425394cf09642369e2109953e31f62b>:0 at KIS.KISAddonPickup.CheckIsAttachable (Part checkPart, Part refPart, System.Func`2[T,TResult] checkNodesFn, System.Boolean reportToConsole) [0x00000] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KISAddonPickup.EnableAttachMode () [0x000f1] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISItemAttachTool.OnItemUse (KIS.KIS_Item item, KIS.KIS_Item+UseFrom useFrom) [0x00003] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KIS_Item.Use (KIS.KIS_Item+UseFrom useFrom) [0x00013] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.UpdateKey () [0x000f6] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.OnUpdate () [0x00006] in <f5b78795b85e480894e49c47c6e38046>:0 at Part.ModulesOnUpdate () [0x0004a] in <be370b73275e49439ea5e41ceef6700f>:0 [ERR 21:28:07.481] Module ModuleKISInventory threw during OnUpdate: System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.GetComponentFastPath(UnityEngine.Component,System.Type,intptr) at UnityEngine.Component.GetComponent[T] () [0x00021] in <2425394cf09642369e2109953e31f62b>:0 at KIS.KISAddonPickup.CheckIsAttachable (Part checkPart, Part refPart, System.Func`2[T,TResult] checkNodesFn, System.Boolean reportToConsole) [0x00000] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KISAddonPickup.EnableAttachMode () [0x000f1] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISItemAttachTool.OnItemUse (KIS.KIS_Item item, KIS.KIS_Item+UseFrom useFrom) [0x00003] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.KIS_Item.Use (KIS.KIS_Item+UseFrom useFrom) [0x00013] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.UpdateKey () [0x000f6] in <f5b78795b85e480894e49c47c6e38046>:0 at KIS.ModuleKISInventory.OnUpdate () [0x00006] in <f5b78795b85e480894e49c47c6e38046>:0 at Part.ModulesOnUpdate () [0x0004a] in <be370b73275e49439ea5e41ceef6700f>:0 [LOG 21:28:08.494] Set pointer mode to: Nothing

Well, I'm not sure what exactly is up, but adding more gyro mitigates the overshooting. I've taken to just locking the gimbals down to 3% or so, and smacking on moar torque to settle things. The computer doesn't seem to like the tiny stick on gyros and demands something beefier I guess.

Was a bit of a fluke while plotting a trajectory, but after multiple mun encounters, and just before being ejected from the Kerbin system, the current path is pretty much bang on the requested contract orbit's periapsis and inclination. Just needs a 0.04 m/s butterfly fart of a midcourse correction, and then a braking burn 7 days later into mun orbit. Feels like a real life mission plan!

When I was building a radio tower out of girders and struts at the poles, I had a separate relay probe in a bowl at the top of the tower, so it counts as being 50m up. Getting power to the transmitter in the nest is the tricky bit, but at least the two vehicles should be stable. Mountains, of course, make things simple. I used a cargo plane to dump octos with a parachute, DP-10 and solar, and buzzed the mountain peaks close enough that the probes land before going out of physics range. BTW, is anyone else having issues with the RT orientation commands in 1.12.5? It is always overshooting, and wobbles the gimbals like it is trying to orbit the aim point instead of going there, even in cases where manual control is easy to hold. I've also got a satellite set to "kill rotation" but it is just SHMming a wobble back and forth over 230 degrees... I'm not super clear on PID settings, but shouldn't kill basically use 100% "I" and zero "P"/"D" to stop the rotation without any particular destination? Rather than what seems to be 100% "P" and no damping at all? I tried jiggery-poking the PID settings; in theory bigger "I" should damp it harder and not overshoot even though it might take forever to get to the target. The settings clearly had some sort of effect, but I was unable to get anything more useful in practice, so I've put them back to default.

One thing I miss from long ago was when I had some config in which the low level clouds were sometimes thick enough that I couldn't see the nearby hills on stormy days and I scrubbed some flights for safety reasons. I've no idea what I did to get that, so any suggestions on how to reproduce such an effect would be appreciated.

Extremely low (3-5km) kerbisynchronous orbits which guarantee that the relays do not drift. Also, if I did the math correctly, a 50m tall tower at the pole holding a probe with longer range dishes should almost always have line of sight to everything in the system.

It seems plausible to me that a combo variant of the "Oh, you've got a base Y? Add/do X to it!" and "recover lost part X" contracts could be used. "Hey, that asteroid you've clawed? We want it recovered. There's science and rep in it for you if you do!"

The jetpack does not have TWR >1, but the Kerbal's *legs* do! See:

If the planet is small enough, then jumping + jetpack will get you past the distance where the jetpack has >1 TWR. If the planet is small enough, then running eastwards could get you the required orbital velocity and the jetpack merely has to circularize.

Oh. That's a good idea. So; what needs to be done is to make some wacky mechanical contraption that counts the number of Kerbals who walk through its gates and displays a 2-digit result. And land that on Eve to keep track of the number of Kerbals being stranded there.

That would be pretty awesome for me. I'm on 1.3. Hotseat when available, otherwise a network share to dump craft files one way and savestates in the other direction. Just to have fun with the challenges of flying and design. After making orbit, we'll have to negotiate some safety requirements for a Mun flyby, and then depending on the state of lifesupport tech, a Minmus landing. To actually get all the stuff, we'll have to go interplanetary, so that's probably in the cards for 2020.

Well, so far, we are still just trying to make orbit and do part testing & tourism on a shoestring budget of 20% science modifiers. But the plan is to upgrade the tracking station and then have mission control (aka Dad) plot maneuver nodes from the map to follow before I jump back into the cockpit for the burns. I suppose it would also be possible to do the eyeball mun transfer, but I'd demand a far better cockpit window or at least a good camera placement because I really don't want to die on impact or have to wait for the O2 to run out. In terms of launch windows, I've only launched two interplanetary missions, and the games ended before I arrived, so I'm not very good at those.

I'm the friend :) And as above, RPM is the one doing the heavy lifting. There is a lot more stress when your rocket is built by the lowest bidder, with unclear design requirements and limitations, and then not being able to see much of what's going on. *Cockpit shaking wildly* ... er, was this stage supposed to be an explosive decoupling? *Noise and numbers dropping* It doesn't seem to be burning through... We might not be going to space today. *BANG* Uh... *clickety-click on cockpit screens* Uhm... I dunno; lets hope that was just the thermometer burning off.

If you're really picky about your orbital periods, you can deploy a satellite constellation at 5km geosynchronous. Deploying them is quite inexpensive and scenic, particularly if you've added clouds and scatterer and such.

That would simply waste time and velocity. The 100% inputs are for correcting attitude in between the 0% inputs generated while doing trim adjustments. I should probably look for a mod to make large trim adjustments easier.