suicidejunkie

Constructed my first successful SSTO spaceplane (as the orange tank / skipper stack doesn't count) for this game run. Aborted the first test flight to add some more stabilizers to the back, but the second made it up with ~50m/s to spare and I'm certain I can do the ascent better. Didn't have the orbital infrastructure to top up on LF and fly home to KSC, but we did have a successful if rough landing far far away on some desert island. RT-G2 in the back seat had no complaints about having to keep the meatbag alive with TACLS and also do most of the navigational work.

I'm trying to make this heat exchanger work, but for some reason it isn't moving any heat, just producing it. Got my stock drills on loop 0, and the ISRU on loop 1, with a bunch of radiators on both. There's zero flux on loop 0 despite being over temp, and just the 2kw idle output on loop 1 despite being under temp. Clicking the transfer direction button does nothing which is also confusing. Do they not work if added to a ship via KAS? I did try restarting KSP, and it is still behaving the same. Looking at the save, the problem seems to be in HeatRate being unset, possibly when built via Extraplanetary Launchpads. Fixing that value and loading makes it work. MODULE { name = ModuleSystemHeatExchanger isEnabled = True ToggleSource = True HeatRate = 0 OutletAdjustement = 100 Enabled = True stagingEnabled = True PPS: Looks like the default max transfer rate is zero instead of 2000, so just building it without tweaking in the VAB makes it useless. I think I got this figured out now :)

How can you have a signal delay if you don't have a computer? If the ship has a Kerbal on board, then it will be Local Control with zero delay. If the ship doesn't have a Kerbal on board, then you surely have a probe core which is a flight computer. If you have neither, then your 'ship' is debris, and of course you can't control it

Click the computer to (OFF) instead of (KILL) mode. Also, click the (>>) button and see if there's a list of actions queued for the future. There is an option to set an *additional* delay to your commands at the bottom right. For example, you can set a delay of 1 hour, and then command your science experiments to take readings. Then, after your ship goes out of radio contact, it will execute those delayed commands and collect your science from the far side of Mun. I've also used it a fair bit for cheap flights; on the launch pad, I set a delay of 2-3 minutes, and then hit stage to arm the chutes. Then set delay to zero, turn on sas and stage to ignite the boosters. The rest of the suborbital tourism flight is automated and I can go get a drink while the boosters are still burning and come back to the tourists on the grass waiting for recovery. Or, on a satellite launch, the whip antenna can be queued to deploy after again about 2-3 minutes, so it can coast to AP while out of contact with the ground, and not rip off the antenna on the way up.

It kinda sounds like you're stuck on "Kill" mode, although normally you can stage while that is on as far as I know. Kill seems to pick a direction to point rather than just suppressing rotation, so if you change control points "Kill rotation" will definitely swing your ship around wildly just like that. The other common-to-me possibility is that you're queuing up a whole slew of inputs because you have the additional signal delay value set and you won't see a reaction for an hour or two.

This is what I'm seeing. I'm requesting an autodrive to hdg 30, and the wheels turn the right way, but the gyro controls insist on -30 instead, and the gyro wins. The gyro is also trying to pitch the craft to upside down, which causes problems on any bumps, but at least the roll cage does its job. I could understand the upside down thing if I'd mounted the rovemate in a wacky way, but as you can see in the nav ball, the forward vector is good. I also can't fathom how it locks on to the heading of 330 instead of 30 (I could understand if it was 90 or 180 off, but mirroring is wacky), or how the wheels end up fighting with the gyro. (Note, heading of 90 makes it go -90 (270), and 45 goes -45 (315) etc) Any ideas on why this might be happening or how to fix my rovers?

Jeb is taking some tourists on a flight test of the newest shuttle design. Visited the Mun to drop off an MPL module for the local station, and satisfy the demands for Mun orbital selfies. Next, it is on to Minmus to test the VTOL belly-landing thrusters and visit the surface facilities to "expand the HQ to support 17 Kerbals" temporarily. The flight computer doesn't seem to like the engine configuration after separating from the payload, showing a mere 700m/s instead of the ~3300m/s in the design specs. The maneuver node seems to be confused as well; we went fairly far off course by overdriving into a Kerbin escape trajectory, but the fuel tank is reporting 630 m/s left after doing a ~600m/s burn. Easy enough for a pro like Jeb to compensate for now that the problem is known. For now, he's powered down the engines and will do a correction burn after some popcorn with the tourists watching the telemetry from a Minmus fuel tanker capture burn.

Not quite happening today, but I just got the pictures uploaded. Bill, escorting the mining rover (auto-driving thanks to remotetech) back to base after installing a gyro so the heavy ore bin behind the rear wheels no longer immobilized it when full. On the other end of the gravity well, Bob sends a post card from his scenic mountain science collection trip. (Pink radiation from the Mt Whoops wi-fi relay can be seen in the background. Scientists assure us that the 5g waves do not impact TWR calculations)

Update: It looks like it doesn't even need a grab. Just flipping to hard Docked and then back to Undocked has the same effect. For now, I'll move the pipes to parts that stack attach to the root of the sub-ship for safety. Will try to Science!! what a stock docking port does in a similar situation when the opportunity arises.

I got it reproduced. 1) Have a set of surface attached parts on a main body. 2) Connect resource transfer station to a connection port on one of those surface attached parts 3) Switch to Docked mode (At this point quicksave shows the tanks are srfAttach, 157, 157 and 152; I presume that's the main body (EL survey station) and the hose connector leading to the mining base root node respectively) 4) Grab the connector with a Kerbal (Now quicksave shows the tanks have srfAttach numbers of 0, 0 and -1, and the fuel flow treats that tank and its attached children as a separate vehicle) I don't see any log files, but I deleted them before making the attempt, to try and narrow things down. I guess I'd need to restart to get the logs flowing again.

No luck on breaking pipe events due to physics range loading and such either. I took a different tack, and dug into the save. Ignoring the obvious of cid/uid/persistentid/temperature fields, all the tanks are identical except for this: srfN = srfAttach, 0,COLLIDERCYL srfN = srfAttach, 0,COLLIDERCYL srfN = srfAttach, -1,COLLIDERCYL The odd one out is the one that doesn't share fuel. Not sure what -1 means, but when I changed it to zero to match the others, fuel flow works again, and the ship isn't horribly mangled as far as I can see.

The rover autodrive works great until I add a gyro... The wheels keep pointing in the proper direction, but the gyro spins the craft over to point in the wrong direction... if I nav towards 45 degrees, the wheels point at 45, but the gyro spins the craft to 315 instead. I need to disable the torque to get the rover moving properly in any direction other than due north or south. :( I can't see how such a heading mirroring could be caused by rover design, but would be happy to fix it if there's a known way how. I'm using a 6-wheeler rovemate that sometimes has a CoM almost behind the rear wheels when it is full of ore, so it wheelies during acceleration which makes the gyro important but only possible to use with manual drive. Seems to happen on all the rovers I've tried tho.

Added a 250`000 spacebucks crater to Mun after I was too stingy with the orbital refuel and also overestimated the TWR on final approach of my Megaminer base. Followed that up with a 330`000 version which descended from the launch clamps to the pad after adding more fuel and engines to the upper stage, but thankfully it was recovered with only losses from fuel burn. After another aborted rollout due to extra BACCs being too floppy, it finally made its successful landing with 190m/s to spare, thus completing the 150`000 spacebucks contract, and adding some heavy duty infrastructure for future missions.

I'll turn that on and try to reproduce now that the shuttle has landed. I know it happened sometime between landing on Minmus, refueling, returning, a bit of aerobraking, and then noticing on the return flight when the gyro/vectoring couldn't cope anymore, but that's a long window.

The X6 Clarke drive with its uranium burn rate of "0.0/sec" is not super useful UI-wise. Does KSP control when that value switches to per-minute, per-hour, or bigger (has it tapped out and doesn't want to show per-year as a unit?) I tried looking at the engine definition, but I'm apparently not mod-literate enough to extract the numbers. I see its a ratio of "1", but there's only one propellant I can probably work the math from ISP vs engine mass full vs empty, but there's gotta be an easier way to find the run time, surely? I suppose I could also start a sandbox game where the engines are all unlocked and see what the VAB reports, but the load time makes that a very slow reference.

Got 6.99.3 installed. Noticed that the hammer is using the KAS screwdriver sound instead of the bonk-bonk-bonk effect for some reason. I also found that my scientist was able to use said hammer to knock parts off, which was convenient and amusing; he's throwing out the trash while the engineer keeps working on new construction. However, that hammer also seems to allow the scientist to weld the old solar panels back on to the base, which is definitely not right.

Collected some graviolis in high space over the flats... in my rover. Wasn't the intended goal of the drive, but I'm not gonna say no to science for dinner. Also; performed some emergency rocket surgery with KAS on the way to Minmus after one of the fuel pods stopped feeding the engine, despite still being in 3-symmetry with the others. Went from 50m/s to 700m/s remaining, so we won't end up needing rescue ship assistance to capture and land.

Well, I dunno what's up with this, but I've got a couple personnel shuttles with a hitchhiker module, and 3-way symmetry fuel pods stuck to it (no separators or anything). But some of the pods don't feed the engine (on the bottom node of the hitchhiker) anymore, and can't do a fuel transfer to the others. It is still in symmetry, and the battery attached to it can transfer across the weld point just fine... Thought maybe it was due to having connectors on the pods and using them to refuel on mun, so I tried putting a fuel hose on the main body and dock/undocking the crafts, but that didn't do anything. The hitchhiker is still the root node in the savegame; I checked against that just in case since hitchhikers can't be bolted to (the side of) fuel tanks, but tanks can be on hitchhikers and wondered if the parts tree got messed up during docking/undocking through fuel hoses. I ended up having my engineer pull the problematic fuel pods off and reinstall them as close to the original position as I could get, and the shuttle is working now although it is microscopically misshaped My Minmus shuttle has the same issue, but with only one of the 3-way symmetried pods going wonky. Caused some thrust vectoring consternation and a worrying lack of dv during the burn out, but Bill left some tools on board so the new engie was able to swap some parts between the pods to spoon fuel into the working ones. Once they arrive at minmus, I think I'll try hooking the hose up to the main body again, but also unload the ship while it is hard connected there and see if that makes any difference. I don't suppose you've heard of this sort of thing before? Dunno if the KAS stuff is involved in the problem, but it did let me fix it in flight

I don't think 'more simple' can be true; there's about double the stuff on screen in 2, and a lot more text. The specific example, and static screenshot without the ability to spin the camera may be an issue. Does 2 not do the same thing if your orbit goes behind the planet?

There's an orange arrow and a purple arrow on your orbit. There's an orange arrow and a purple arrow on the target's orbit. I'm curious as to what other interpretation there could be.

Disabling roll on the gimbals seems to help a bunch, particularly on single engine craft. I'm thinking with an amount of length and flex in the ship, the engine moves slightly off center under thrust and becomes capable of impacting roll in a miniscule amount so it thrashes to try and do so.

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.