stibbons

I have a) 15 years professional sysadmin experience b) a little bit of cash to spare to offset hosting costs How can I donate one or both of these to help keep KS running?

Seems to be a bug arising from the USI mod migration discussed here and here. You can try removing all of the USI mods you've installed by CKAN and try again. If it's still giving issues then I'd suggest continuing to follow Roverdude's advice and manage them manually for a little while longer. EDIT: Oh, and 'ckan update' just refers to running ckan in commandline mode. That just refreshes the ckan cache as you've already done.

I'm not so sure.

I love the idea of using I2C to shunt packets off to separate display controllers. But like I said, you really, really don't want to try to use the standard Arduino libraries to do that. I really should clean up the AVR I2C libraries I've been working with and release them properly. Also, thanks.

You're right. It was late here, sorry.

There's Telemachus, which sends telemetry over a websocket, and has a reasonable web interface for viewing data. Or if you'd prefer to really get your hands dirty, kOS uses a protobuf protocol, with client libraries in a few different languages. You can pull that data in to your code and do whatever you like with it.

The mainline Linux kernel is not real-time, right. But geeks like it enough to attempt to make the kernel fully-preemptible and do real-time work with it. See the RT wiki. As for the OP question, if you've read The Martian, the logs from Sojourner booting are pretty legit (although almost certainly not exact): LOG: SOL 0 BOOT SEQUENCE INITIATED TIME 00:00:00 LOSS OF POWER DETECTED, TIME/DATE UNRELIABLE LOADING OS... VXWARE OPERATING SYSTEM (C) WIND RIVER SYSTEMS PERFORMING HARDWARE CHECK:

I gave a short talk on some of this build at the open hardware miniconf at linux.conf.au last week. It was also the first time I've been able to get some feedback on the layout from experienced KSP players having a crack at using it, which will be very useful when I get around to re-doing how the displays are organised. https://www.youtube.com/watch?v=AVXr9tLTQEE Progress on the navball is still slowly grinding along. I've realised that the way I'm calculating relative pitch and heading is OK for yaw/AoA readouts, but completely unsuitable for rotating a navball. Got something that I think works, but haven't really had time to properly test this stuff yet. Hopefully soon.

Nobody said you should. But the question deserves a better answer than "don't use CKAN".

For posterity, the "CKAN doesn't recognise my KSP directory" problem is covered in the CKAN FAQ. CKAN uses the readme.txt to detect KSP version, and if that's busted for whatever reason (manually extracting a mod in to the KSP folder, for example), then CKAN will get confused and error out. As for "resetting" it, for a clean reinstall I'd export the list of installed mods and copy the resulting file to a separate location. Then do the reinstall, making sure you wipe the contents of the CKAN folder and all installed mods from GameData. Then load the exported file in to CKAN in the fresh installation.

Very well deserved, I'm a big fan of your work. @pjf I'll see you at LCA! KSP BoF?

It's actually slightly easier than this, because I'm already transforming the navball up to match vessel up (see updateHeadingPitchRollField()). That should mean I can ignore the world reference and just calculate the rotation relative to the vessel position. So it seems to me that for surface prograde progradeRot would be more like Quaternion progradeRot = Quaternion.FromToRotation(vessel.transform.position, vessel.srf_velocity); And I definitely do need the euler rotation, but it looks like I can easily reuse existing plugin code to convert that Quat. Thanks very much for the advice and code, @Crzyrndm. Knowing how to calculate rotations like that has really helped illuminate how transforms and quaternions work. I think I've got a handle on how it needs to be done now, but it'll be a little while longer before I've got time to properly test it.

I didn't have a large craft handy, so I just tried launching this 424 part super-heavy lifter from KerbalX in to LKO. CPU temps spiked up to 52ish, but were mostly in the 45-50 range. The GPU, which is still aircooled, was also mostly in the 40-45 degree range. Here's the psensor graph for most of the ascent.

Here's what I built back in September. KSP in Linux is still the main game I'm playing, but Fallout 4 is also looking lovely on this rig. i5-4690K. Rated for 3.5GHz, currently clocked at 4.7. NZXT Kraken x61 liquid cooler. Asus H97 pro gamer motherboard. 16GB DDR3 1600 RAM. GTX 970. New Antec P100 case. I'm still using a magnetic drive, a WD Green that's maybe a year and a half old. Still feel the pain of loading times a little compared to the SSDs in my laptops, but KSP doesn't seem too bad. Starting my heavily modded game cold takes about a minute to get to the start screen. But the OS has more than enough RAM to just go ahead and cache everything I'm using, so subsequent starts are around the 20 second mark. For those times I don't even bother with a minimal install for mod development any more, just keep restarting my live install.

I am terribad at maths.

I should apologise now - I've never done any 3D programming before, and am struggling to get my head around it. Thinking it over some more last night, I'm suspecting I've been calculating this the wrong way, and yaw and AoA aren't actually want I want. To draw the prograde marker I'm taking a point on the surface of the navball representing the up vector, and doing a 3D transform to rotate it to the prograde vector. My current understanding is that I need the Euler angles for that, not yaw and AoA. Does that make sense? I didn't find anything about the limits of Angle (although, looking again, the Vector3.Angle docs are pretty clear about it always returning the smaller angle) so was just being super guarded.

I'm currently trying to add relative pitch and heading of the various orbital vectors to KSPSerialIO, so I can render them on an external navball display. Some research dug up a useful discussion on calculating pitch and heading, and using that as I reference I have the following functions to calculate relative pitch and heading of a Vector from the current vessel. private double[] getOffsetFromHeading(Vessel ActiveVessel, Vector3d targetVector) { Vector3d yawComponent = Vector3d.Exclude(ActiveVessel.GetTransform().forward, targetVector); Vector3d yawCross = Vector3d.Cross(yawComponent, ActiveVessel.GetTransform().right); double yaw = SignedVectorAngle(yawComponent, ActiveVessel.GetTransform().up, yawCross); Vector3d pitchComponent = Vector3d.Exclude(ActiveVessel.GetTransform().right, targetVector); Vector3d pitchCross = Vector3d.Cross(pitchComponent, ActiveVessel.GetTransform().forward); double pitch = SignedVectorAngle(pitchComponent, ActiveVessel.GetTransform().up, pitchCross); if (Math.Abs(yaw) > 90) { yaw = -yaw; // This condition makes sure progradePitch doesn't wrap from -x to 360-x if (pitch > 0) { pitch = pitch - 180; } else { pitch = pitch + 180; } } return new double[] {pitch, yaw}; } private double SignedVectorAngle(Vector3d referenceVector, Vector3d otherVector, Vector3d normal) { Vector3d perpVector; double angle; //Use the geometry object normal and one of the input vectors to calculate the perpendicular vector perpVector = Vector3d.Cross(normal, referenceVector); //Now calculate the dot product between the perpendicular vector (perpVector) and the other input vector angle = Vector3d.Angle(referenceVector, otherVector); angle *= Math.Sign(Vector3d.Dot(perpVector, otherVector)); return angle; } And I'm now trying to use it to calculate the position of orbital prograde by doing this Vector3 progradeVector = ActiveVessel.GetObtVelocity().normalized; double[] progradeHeading = getOffsetFromHeading(ActiveVessel, progradeVector); Debug.Log(String.Format("Prograde pitch: {0:F2} heading: {1:F2}", progradeHeading[0], progradeHeading[1])); This code seems to work properly when the heading is around 0 (or 180). But I'm seeing very unexpected behaviour with the reported pitch varying drastically as the heading gets close to +/- 90 degrees. I tested by lining up with prograde and then pitching down slightly so the prograde marker was above my heading. Then started yawing to the left. Here's a log of a full rotation. It shows the heading (yaw) increasing fairly linearly, and I would expect the pitch to remain close to constant. Instead it gets very high, peaking at -90 degrees yaw, dropping lower than the original pitch at 180, and then climbing to another peak at 90 degrees yaw. The only rational explanation I've come up with that might explain it is that I need to apply the pitch number first, then the roll, and I'll end up with the vector in the right place. So I tried doing that on my display, and it still doesn't look right. This is from a different run of the same test, but with similar results. Any other suggestions for what I might be doing wrong here? Do I need to transform the prograde vector? I assumed it was already in the right reference frame.

A Raspberry Pi cluster won't be a reasonable replacement for a PC for general purpose computing. But if you're at all interested in learning how distributed computing works, you can run up a small Hadoop cluster using Pis very cheaply.

I opened a pull request last week. Still a fair bit of work to do on the plugin before it's ready, and I really want to make sure I've got reasonable arduino-side example code to go with it before it gets merged. But it'll happen soon(ish).

A bit more fuel than a regular landing, and just some practice. Quicksave, pitch your landing site a little bit ahead of your target, see how that one goes, then quickload and try again. The flats on Minmus are a pretty good place to work on this, actually. The gravity's low enough that you can bring yourself to a dead stop 10km directly above your target and then come down without burning too much fuel.

So get creative - Send an uncrewed lander first with extra supplies, and then try to land your crewed mission nearby. For bonus points, use the KIS/KAS mods to transfer fuel and life support supplies from the supply drop to your crewed lander for the trip home.

I'm playing with TAC-LS too, and the main reason I started doing that was for the added challenge of never losing a Kerbal. Accidents have happened, but no I never deliberately send them on one-way missions.

I spent a very late night last week fixing the buttons on my navball display. I'm using hardware pulldown resistors for every switch on this build, and I'd forgotten to connect the pulldowns on my navball buttons to ground. That left all of the buttons floating and some very confusing inputs to my test code. But after I fixed those I was able to implement the GUI for the mode switching to emulate the on-screen display. I also uncovered a bug in the RA8875 display library. Attempting to use customised fonts leads to the user icons becoming corrupted and not rendering properly. So all of my text is being written with the single built-in font. Luckily after trying it I absolutely love the single built-in font, and am very happy with the overall retro look of the navball. This is seriously one of my favourite photos from this build. There's a good chance I'll increase the navball rendering size, and probably move it to the right a little. But it looks awesome. The rest of my current work lies in completely overhauling the vessel attitude code in KSPSerialIO, and adding a lot of code to send orbital vectors. The current code sends floats showing pitch, heading and roll as straight degrees. But I'm trying to save space by converting all of those to unsigned integers. I've had to tweak all of the conversions a lot to make sure I had something that was still accurate and backwards compatible with the old system with minimal effort. I develop both my arduino code and my plugin code on a tiny Mac Air. I have a large Linux gaming rig that I run KSP on, and the controller is plugged in to that. So the way I'm verifying all of my code is to have the laptop SSHed in to the gaming rig and streaming KSP logs. At the same time, I have a serial connection from my laptop to the arduino that runs the navball rendering and it's dumping its interpretation of the KSPSerialIO data. And finally I've started using the kOS terminal to set the orientation of my test vessel, so I'm using the telnet console through my laptop as well. It's a wonderfully bizarre workflow. It's taken a few attempts at modifying how I'm converting numbers back and forth, but I think I've finally got a system that is reliable and easily backwards compatible with the old KSPSerialIO directions. Anybody who was using the old stuff will need a new function added to their arduino code, but nothing too onerous I hope. The first time these two images consistently lined up tonight was super satisfying. My KSPSerialIO patch is sending prograde, normal, radial, as well as surface prograde and target direction and prograde in the same format. In theory I just need to use my existing code to transform each of those back to degree rotations, then use those to rotate a (0, 0) point to get the coordinates to draw the appropriate icon. But that's a job for next time.

The Logitech Extreme 3D Pro is super cheap and cheerful. Mine's also a few years old, and has always been reliable. No problems using it with KSP.

Quick update full of pretty pictures now that I've finished assembling all of the hardware. Started by cutting a bezel from thin blue cardboard, and a cover from a sheet of thin clear PVC. Took a few attempts to get this right, and a lot of fiddling around. But I'm super happy with how it looks. And it was great to finally remove the protective sheet on top of the display. From the back, my 3D printed brackets sandwich the display, bezel and cover in place. Above that, the display controller and teensy are mounted on a prototyping board, along with header pins to connect the switches, and terminals to connect power and the i2c bus hooking it up to the rest of the system. I'm really really proud of how the front and back of this panel look, to be honest. Probably my favourite part of this build. The final step, screwing this panel in to place and hooking it up. Boom. The Arduino code and my KSPSerialIO changes to drive all of this is still in a fairly broken state. I've been putting off tying all of the pieces back together until I had the hardware fully assembled. But I've now run out of excuses. Back to software hacking!