stibbons

Just pushed a very small plugin update with version 1.3.1 compatibility. Untested, as I'm at work right now and in the middle of some fairly big changes at home that will keep me occupied for the next few weeks. But if the build passes successfully I have no reason to doubt it'll work OK.

Heck, I liked it before the inevitable round of layout tweaks.

Sure. The wiki has all of the orbital and physical characteristics of KSP's bodies. You just have to plug those in to a simulation. Octave or Matlab can do that. Some light googling suggests that Universe Sandbox is a pretty popular tool for Kerbal simulation as well.

You're not providing any input, but that screenshot shows pitch, yaw and roll are close to max. @Gaarst is right, it's almost certainly your trim settings.

The FAQ on the KSP website still says this is fine.

Apparently Kerbal Alarm Clock used to have a somewhat functional feature to automatically add alarms for background SOI changes, but it was removed. TriggerAU wrote a little about the problems they had and why it was eventually removed in the mod thread.

Doesn't even need to be a gaming con. I took my controller rig to the local mini maker faire the last two years, and met a lot of KSP fans.

Because nobody else has mentioned it in this thread yet: I saw Halley's Comet on its last flyby. The local amateur astronomy club held free viewing events in the oval next to my school, so I got to check it out through a surprisingly powerful telescope as well as dad's modest binoculars.

Yes, there are. Start with CASR part 101 and continue from there.

I managed to avoid this problem. My partner saw my controller before agreeing to move in together. She knew what she was getting in to.

I have a machine that dual-boots Windows and Linux, with KSP installed on both partitions. So thought I might time startup times for both. Hardware: Intel i5-4690K 3.5GHz, overclocked to 4.8GHz. 16GB DDR3 RAM. nVidia GTX 970 with 4GB RAM. 2TB Western Digital Green drive, SATA3. It's a bit old now, model number WD20EARX-00PASB0. Software: Debian testing, quite up to date. Linux 4.11.0, proprietary nVidia driver version 375.66. Windows 10. Fully patched. nVidia driver version 382.05 KSP: 1.3.0, whichever minor patch release is available through Steam for each OS. I'm testing with stock, and with my usual mod list. I don't go in for huge part or planet packs, but I do use scatterer and SVE with the biggest textures. Installed mods as reported by CKAN: Method: Remove settings.cfg (to start the game with default settings) Launch 64 bit version of the game from a command line. I don't add any parameters, so what I'm running is the default launch config. Start timer when hitting enter on command. Stop when first note of menu theme song plays. Reboot between each run, to ensure the game is being loaded from disk. Subsequent runs are much faster due to the operating system caching everything in RAM. Modded times were not the first run after installing mods. I installed everything, launched the game once to let Module Manager populate its cache, and then rebooted and ran the test. There were 4908 patches applied. For Windows, I let the machine sit idle for ~10 minutes after booting before running a test - my install takes a long time to settle usually. Times: Windows Linux Stock 65s 55s Modded 123s 115s My subjective experience? I play in Linux, and that two minute start time really doesn't feel excessively long to me. ¯\_(ツ)_/¯

Yes, it's easily painted. I sanded the side of my acrylic that I was painting, but didn't otherwise do any preparation. Drilling holes is easy, just start with a small bit and gradually work your way up. Cutting internal holes should be fine with a hacksaw/jigsaw and a little bit of care. But the best way to do it would be to find a local maker space and use their laser cutter or CNC mill. Precise, square cuts and no fuss.

There hasn't been a real release of IR for a little while now, I think. Lurking in the thread, the current way to get it working seems to involve a mish-mash of the official release and assorted contributed DLLs pulled down from assorted sources. Until there's a real release marked as compatible with 1.3 CKAN won't be able to install it. It's a shame, it's a pretty awesome project. If you'd like to submit a bug report, it really should consist of: Full details of what you did ("Launch CKAN. Change filter to show installed mods. Select mod x. Hit uninstall button."). What you expected to happen ("Expected mod to be fully removed and all related files removed from GameData") What actually happened ("Client paused for a long time. Here's the full text of the error message it eventually gave me. CKAN still thinks the mod is installed and all files are present.") The more detail that goes in to these things, the better. As it stands right now, without even knowing which mods you were installing or uninstalling, this isn't a bug report.

Those things look super fun, but I suspect I'm going to go ahead and refer to my long standing complaints about how terrible Arduino's Wire library is. Driving them quickly enough to work with a decent refresh rate with KSPSerialIO or Simpit would be a struggle.

What is this, a rocket ship for ants?!

I mean KAC. The flight computer can automatically add alarms for scheduled actions. Haven't used kOS enough to comment on how it integrates with the flight computer.

RemoteTech replaces the stock commnet, and brings more antennas, a slightly different and arguably more realistic mechanic, and (optional) speed of light delay. It also has the Flight Computer, a fairly advanced sequencer that will let you schedule all sorts of actions to happen at future times, and even integrates nicely with KAC.

What did your lawyer say about it?

Adding a handler for that should be relatively simple, especially if you've done any work playing with KSP plugins before. The only concern is that my current workflow relies on tools that only really exist in Linux, and there's probably some extra work required before you can make the code build using Visual Studio or similar. If you're interested in trying it out, the source code for the plugin lives at https://bitbucket.org/pjhardy/kerbalsimpit . You'll find some details about how to configure your IDE to build the project, as well as how to structure a new class to send or receive data, at https://bitbucket.org/pjhardy/kerbalsimpit/wiki/PluginHacking.md .

Hi! Not yet. I'll get to adding fine control toggle at some point, but at the moment I'm focussing more on less visible work making the internals more stable. For what it's worth, I keep track of everything I've got in progress and planned on a trello board: https://trello.com/b/t6YUftuS/kerbal-simpit-progress .

I'm doing something similar to this already, the terrain alarm goes off if your radar altitude is below a given threshold and vertical velocity is negative (you're going down). The important thing for a build like this, I find, is to start small. Focus on just one of your wishlist items, and see it through to completion. You may like to start with the first, because if you've already got the tablet it's probably the cheapest option. After that, buy yourself an Arduino and a few components, and work towards just one simple little component at a time. It's easier to fit it in to your budget that way. And I find it much easier to stay motivated to extend an existing system when I'm able to see how much progress I've made on finished and working parts.

After a month off working on other projects (and, it must be said, getting a little lost in Breath of the Wild), I'm easing back in to KSP and hacking on this mod. Testing pulling several channels and doing (light) work on a mega I'm unable to reproduce any issues with the Arduino library. It seems as solid as can be. So I'm not going to worry any more about bug fixing in the Arduino library for the next little while. Currently working on enhancing how the plugin schedules data to be sent to devices. Right now all data providers are run, in a fixed order, whether they're actually sending to a device or not. For the next release I'd like each serial device to be able to track what it's subscribed to, in the order it subscribed, and only run data handlers for those subs. I'm hoping this will help spread channel updates out over the refresh period, because right now it's way too easy to inadvertently bunch everything together.

Out of morbid curiosity I went and looked up the Roblox Terms of Use. And, yep, there it is in section 3A: Attempting to appeal a ban by admitting you violated the terms of use is an interesting tactic.

Yeah, that's the code I'm talking about. The high level way to do that is: Copy all of those source files in to a directory of your project. Change the namespace to something that makes a little more sense. Fix the handful of compile errors that will crop up. I realise at this point that using kRPC with your preferred language is probably the more attractive option. But if you want to play around with doing serial yourself, it might be easier to have a look at my KerbalSimpit.IO.Ports class. I've been meaning to split that out to a separate KSP mod, but you can probably just drop that folder in to your project, and use `KerbalSimpit.IO.Ports` exactly the same way you'd use System.IO.Ports.

Or "I refuse to use Windows because I need my OS to have a native TCP/IP stack".