stibbons

The devblog discussing this change just went up today, and is pretty interesting reading. Seeing as the jerkiness in time warp was an intended tradeoff to ensure better shadows, and there's an implied better fix coming with a Unity engine update, it seems unlikely there'll be any change until that update.

Read the changelog in the release announcement: There's a few other related items.

This thread definitely needs more pics of uncrewed SSTOs.

How was an announcement made in April supposed to predict this alleged popularity spike?

None of this is correct. Read the announcement, published in April 2013. *sigh* It's this type of baseless complaining that led to Squad having to make that promise in the first place.

So what you mean is how do people who voluntarily write code against a changing API feel about the API changing. Fair enough.

Version 1.3 released 25th May 2017. Version 1.2.2 released 6th December 2016. Version 1.2.1 released 1st November 2016. Version 1.2 released 11th October 2016. Version 1.1.3 released 21st June 2016. Version 1.1.2 released 30th April 2016. Version 1.1.1 released 29th April 2016. Version 1.1 released 19th of April 2016. Five releases in a year? HELP WE'RE DROWNING UNDER CONSTANT UPDATES.

For what it's worth, while the text entered is not reliable, the time between keystrokes is much better and is frequently used as a source of entropy (for systems that have a keyboard, obvs).

Kerbal Simpit 1.1 is online and will be available soon: No longer throw thousands of nullref errors when Alternate Resource Panel is not installed. Added a packet containing the name of the current Sphere of Influence the active vessel is in. Only sent when the flight scene loads or the SoI changes (although I'm thinking about adding a schedule that sends these sorts of packets regularly but much less frequently, say every 5ish seconds). I haven't even updated the arduino library for the SoI packet yet, that will probably happen on my lunch break in a few hours. But thought that bug fix was worth pushing out.

No. All modern operating systems come with cryptographically secure PRNGs (see CryptGenRandom and /dev/random for details on the main ones). Just use the operating system facility - it's incredibly unlikely most programmers can do better.

Well I for one just put "add JSON validation to mod build plan" at the top of my list for the next version.

I'd like to see the research that you're basing this on.

Fair enough, those yaks won't shave themselves.

It looks like you can't turn off caps lock, either. Try this thread for details on why it's been removed. I expect it won't be coming back until the next console release is ready. For that your best bet is to watch the weekly KSP Weekly post for updates.

The serial code is quite stable now. The core message passing is working well (although I have future plans to optimise sending data out of the game). The providers that have been implemented are doing their thing. So I've gone ahead and uploaded a 1.0 release. Kerbal Simpit 1.0 is available through CKAN now. The accompanying Arduino library that helps talk to the plugin can be installed through the Library Manager in the Arduino IDE (search for "Kerbal Sim Pit"). It comes with a few example sketches demonstrating the basics, and getting started and API documentation is available at http://kerbalsimpit-arduino.readthedocs.io/en/stable/ Huge thanks again to the people who spent some of their time trying out this plugin and giving me valuable feedback over the last few months, @Benji, @monstah and @Gizzum. Your help and patience dealing with my occasionally dumb mistakes are much appreciated. For those, and anybody else who installed this plugin, I strongly recommend removing my prerelease repository from your CKAN client config; go to Settings -> CKAN Settings, select the Kerbal Simpit repository and delete it. There's still a lot of work to be done on this plugin (1.0 means stable and useful, not finished). But for now I'm going to go try out 1.3.

Hi folks. Could this thread please be moved to the Add-on Releases forum?

Idle thought while waiting for pull requests to be merged. I'd like the next batch of telemetry additions to include a packet containing the name of the body whose sphere of influence we're currently in. This would be one of those infrequently-sent packets, so I think it's completely appropriate to include the full name - ie, there's no reason I can't just sent "Laythe" or "Mun", or because doing it this way gives modded body support for free, "Sarnus" etc. But supporting localised body names almost certainly means the receiving device has to support various wide character sets. And given the receiving device is intended to be an Arduino or similar class of microcontroller, the odds of it actually having decent character set support and being able to display those characters on an LCD seems... remote to me (although I'm from an English-speaking country and have no idea how far wrong I am there). In addition, my brief experimentation using other language packs leads me to believe that body names aren't fully localised anyway (the Japanese pack displays some Japanese text followed by the traditional name in brackets, for eg). With all these and the current limited packet size in mind, I'm inclined to forgo localisation support for body names, and just stick to plain ASCII. Does that sound reasonable?

ModuleManager 2.8.0 is only for KSP 1.3. That's why it's crashing your KSP 1.2.2 install. You'll need to figure out which of the mods that you've installed included it, because the chances are good that mod is also only intended for 1.3.

You may find the lack of responses to this post interesting.

We don't even know what other versions of that video existed before the final was uploaded to youtube. They may have gone to no trouble at all to snap that shot. Sometimes a fist-bump is just a fist-bump.

That is just a retouched still from the 1.0 release video. And a fist-bump.

One factor where the extra speed/power can come in handy is dealing with floating point numbers. Neither of those processors have an FPU, but the slower chip can really start to struggle if you're trying to do a lot with peripheral comms and shunting floats around. The biggest issue I've seen in the KSPSerialIO thread is with serial comms falling out of sync because the Arduino code is too busy dealing with floating point math to keep the serial buffer drained. Not an impossible situation to deal with (most of the time, just hacking the Arduino serial lib to give it a buffer to match the KSPSerialIO packet size is enough). But something to consider.

0.10 prerelease is available. Nothing major, just making sure it builds in KSP 1.3.0. Rebuilt for KSP 1.3. Strict versioning in the CKAN metadata is turned back on. Now that KSP is out of prerelease I'd rather not continue to support 1.2.2. I haven't actually done any testing on this build yet (still at work). But given I've been tracking the prerelease for a while I'm fairly confident it should be fine. Will give it some time over the weekend, and push out a 1.0 early next week.

Small status update: The Arduino library for this plugin is now listed in the Arduino Library Manager, making it (hopefully) a lot simpler to install the library and start coding. In the Arduino IDE, go to Sketch -> Include Library -> Manage Libraries... and search for Kerbal. Select the library and hit install. Job's done. If I get time this week, I have open tasks to add data providers to send a little more info to devices - will probably do something about @Benji's request for a generic "fuel-like resources in the last stage" provider. But at this point I'm more interested in putting the final polish on this one and calling it a real release. I swear I'll get on with that immediately afterwards though.

Zero is neither negative nor positive. It is not defined, being irreversible means you break algebra, which is not an acceptable result. You can define a limit as the denominator approaches zero from the positive or negative side, but that is not the same as x/0 being defined. A mathematician and a computer scientist walk in to a bar. Neither of them believes the other about signed zeroes. Quite a few numeric representation systems in computing require the existence of a signed zero. The example I remember from my university days is ones' complement numbers, but the IEEE standard for floating point numbers that most computers use, IEEE 754, also includes the concept. That said, IEEE floats also throw the same NaN exception for division by both positive and negative zero. Also, the wikipedia pages I linked describe complicated edge cases where both signed zeroes and division by zero are defined and useful. So I'm just going to buy the next round and back away slowly.