stibbons

False dichotomy notwithstanding, what part of that post makes you think it's representative of the company?

Do you want dev blogs to go away again? Because interpreting statements made in them as promises deliverable by the company is how you make dev blogs go away again.

The link you want to use from imgur is the "Direct Link". Basically, it needs to be the raw image. If your URL ends in .jpg or .png, you're good.

Updated the OP. The base plugin works, and has a basic echo handler (device sends echo, game replies). The Arduino library is functional, but a little bit twitchy - it frequently doesn't start seeing full packets for me until a few seconds after the flight scene loads, sometimes not until I switch out and back in to it. Need to play with how it's dealing with partial packets, I think. The big news that I'm happy about is that my plugin's working properly on Windows 10. My initial tests were looking a bit bleak, and I was worried I'd have to do a lot of platform-specific work. But a more careful look showed that most of my problems were related to some really dumb mistakes (a divide-by-zero in the setup that the Linux KSP build happily continues on from, but the Windows build seems to abort loading the plugin). There are still some weird issues with some devices in Windows that I really don't think I'm in a position to be able to fix, so can just point to them in the docs and back away slowly. At this point I'm going to be scaling out the info it can send/receive, and see how stable the current serial stuff is under actual load.

I'm deeply disappointed that this post was a question and not a release announcement.

Unsurprisingly, my current code is running fine in 1.2.9 after recompiling it. Will only be supporting 1.2.9/1.3 going forward. My work trying to implement a simple echo provider (hardware sends an echo request, game responds with an echo reply) uncovered some poor assumptions, and I'm going to have to redesign the interface between provider classes and my serial ports. But that's good because I also recently realised the game exposes its own GameEvents interface for passing events between classes. I should be using this little fella instead of implementing my own events.

But back on interesting news, congrats on the new prerelease SQUAD! It's been a long road, but it's great to see the end finally in sight.

Well that was useful.

My experience has been that logging in from a new device causes all of my other logins to expire. So, when I bought a new phone and logged in to the forums using it, my laptop and gaming desktop browsers got logged out. But after logging those back in everything was back to normal. I think the stay logged in feature eventually times out as well, but it's long enough that I've never gotten a handle on whether that's what was happening or not.

Absolutely zero useful information, but hey at least we get to see some random user's desktop wallpaper!

The only addition I could make to @Freshmeat's excellent overview is that you'll also need to be familiar with how the Blink Without Delay example sketch works. You'll need to be able to do your debouncing and other stuff without using the delay function. EDIT: Ooops, looks like blink without delay is already covered before debouncing. I'll just crawl back in to serial testing cave.

KSPActionGroups is just the enumerator for... well... action groups. You want the ActionGroups property of the active vessel. Something like this should work for you if (FlightGlobals.ActiveVessel.ActionGroups[KSPActionGroup.Brakes]) { // Things to do if the brakes are on go here }

For the rest of the world, I'm a huge fan of Pi Approximation Day (22nd of July, or 22/7). Of course, there's also the strong case for Pi being wrong anyway - http://tauday.com/

This evening I spent some time testing KSPSerialIO with some of my growing collection of microcontrollers on my Windows 10 install. There's been reports that it functions properly on 3rd-party Arduino compatible boards that use the ch340g chip for the serial interface, so I thought it'd be worth confirming that and seeing what else I have that would be compatible. The setup I'm using: Windows 10 Home (fully up to date) KSP 1.2.2, no other mods installed. I tested both 32 and 64 bit binaries. KSPSerialIO 0.18.6. The KSPIODemo16 test sketch @zitronen wrote. To test, I just ran the game and loaded the Kerbal X sitting on the launch pad. Confirmed that the game reported it had opened the appropriate serial port on screen, and the KSP.log file logged that it had sent and received handshake packets. I didn't attach any other hardware to my microcontrollers. But the handshaking demonstrates successful serial comms in both directions - I'd be very surprised if any of the other code is affected here. So far I can report: A Teensy 3.2 works properly. Flashed it with the newest release of the Teensyduino package, only thing to worry about is ensuring the "USB Type" in the Tools menu is set to "Serial". This ensures the Teensy is set up with the USB Serial descriptor. I'd never used this board on my Windows box before, so it came up as an unknown device and I let Windows 10 download and install its own drivers. An Arduino Pro Mini (specifically, the 5V/16MHz board from SparkFun), with an FTDI cable. This setup also worked fine. My cable is specifically an FTL-232R-5V, but any FT232-based device should be fine (and probably any of the FTDI serial chips, but don't blame me if that's wrong). Again, I plugged it in and let Windows 10 download and install its preferred drivers. I don't yet have a CH340G serial breakout, but will be able to test that some time this week. The next time I set this up I'll also plug in a Leonardo-compatible board and see if it has any success. (Do not expect any of these to work with my cross-platform KSPSerialIO fork on Windows yet, though. Also, weirdly, the Teensy didn't work for me on OSX at all, but both of these did run with my fork on Linux.)

For what it's worth, this sticky thread on creative-commons license compatibility is also pretty great to say what can be remixed with what.

I suspect you're going to have a very hard time with a blanket rule specifying which license uploaded modpacks may use. For example, the one that you've uploaded contains your own More Habitable Planets Mod, right? From what I can see on https://spacedock.info/mod/1215/More Habitable Planets Mod! that is licensed under GPLv2. As such, you can't properly distribute it in a modpack under a creative commons license. The hairiest difference is the "must provide source code" requirement of the GPL - no creative commons license has an equivalent. For that specific mod you might scrape by, but any GPL mod that uses a plugin (for example, Kerbal Engineer Redux) will not be able to be redistributed in modpacks through your site. I think it's great that you want to contribute to the KSP community, but can only ask again that you carefully consider the concerns that have been raised in the recent discussions that you've been a part of. There's a lot of good info, and decent suggestions for how to shape your contributions in the most meaningful way in those threads.

I focus on not creating orbital debris in the first place. Launch stages either stay suborbital or have some fuel and a probe core to deorbit themselves (never manually recovered, but I've used the Stage Recovery mod before). I initially plot transfers to either crash in to my target, or crash in to Kerbin on a free return, so I can discard the transfer stage. The same principles apply for returning, but I've never brought anything back from further than Minmus, so can't talk too much about doing it for seriously big missions. I think the challenge of doing it this way (and just living with the occasional failure leaving stuff in space) is much more interesting than the grind of cleaning debris up after the fact.

I never get tired of seeing them either. I know you can see them quite easily from an equatorial orbit, but was idly wondering how often you would see them from a given point on the surface - are you guaranteed to see an eclipse every 6 days 2 hours (Mun's orbital period)? Or is there something a little more subtle going on?

Apparently you set a refresh rate (I've hardcoded at 80ms), and evenly distribute the registered callback methods through it. I committed the code to do that as a first pass this week. It's almost certainly subject to change (or at least some minor optimisation), but I'll want to bed it down on a non-trivial hardware setup first. Pretty sure my code's now at the point where all it needs is data to send. One goal that I have in mind for this is optimising on-wire data types, and eliminating the use of large floats wherever I can. Scalars like heading and throttle would end up as a two byte unsigned int. Distances and velocities will be fixed point numbers on the wire. The Arduino library will have code for getting/setting the integer and fractional parts of these, as well as converting them to and from floats if you need to.

I... forgot to. But it's something that also affects my hardware, so it'll definitely get some attention when I'm to rewriting the arduino code to support this plugin.

In a related but less precise vein, folk at my maker space were recently playing around with making polyhedron globes. I think creating a 12- or 20-sided Mun could be a fun weekend project.

Well, obviously. I haven't personally done anything like this since primary school (and don't like to think about how long ago that was). But translating a mercator projection on to the sort of gores that these folk use is fairly trivial for any modern GIS package. Even funky projections like sinusoidal interrupted is on the list. They're not the custom projection you were talking about earlier. But to be honest, writing your own software to implement your own map projection instead of reading about a list of standard ones sounds like some pretty extreme NIH-ism. (Of course, if it's NIH-ism you want to do, go right ahead! Obviously you shouldn't let randos on the Internet tell you not to write software you want to write. )

If you've solved it yourself once, you're justified using somebody else's code the second time. NASA have a map projector that's apparently pretty good - https://www.giss.nasa.gov/tools/gprojector/

There's a fair bit of discussion in the KSP Computer Building thread that you might find useful.

The plugin doesn't make any changes to how RCS inputs are interpreted. RCS 'up' always translates to craft up. RCS 'foward' always translates to craft prograde. This is regardless of the camera mode. I've never known RCS function to change with the camera view, either with this plugin or without. The only benefit you should be getting from the fixed view is that your craft stays in the same place relative to the camera, so the RCS axes stay fixed from your perspective. This will get you some of the way towards RCS being relative to the centre of mass you're orbiting. But you also need to account for the Z axis. Sorry, it's way too early here for me to get my head around the maths.