stibbons

On the second machine you'll be doing the exact same thing; symlinking the folder to `saves` in your KSP directory. I've used a similar mechanism, although I was using the commandline to symlink instead of a separate application. Once you've gotten your saves in to dropbox, the same saves will work on Windows, Linux and OSX.

The separate code block handling is great, but there are quite a few times when it's good to be able to refer to code-like things in the middle of a paragraph. Explaining function calls and referring to directories or commands are the places I use it most; just now I wanted to answer a question and include the KSP install directory in a sentence, like `~/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program/` . Ideally, I'd be able to select those inline statements and declare them as code. Setting them to a unispace font is one way to do it, but I'd prefer a separate code option that applies inline formatting to make those lines look similar to full-fledged code blocks.

I think they're at home in the Add-ons release forum, tagged as modlists.

Is there literally a list of non-critical improvements that I can add to? Because speaking of the code blocks, C# syntax highlighting would be nice. That's super low priority though, because the existing C style should do a fine job for most things.

Still sad that HTCPCP was not added to mozilla.

It did, but apparently there's a long-standing bug with the Linux build not showing the build number (there's been two 1.0.5 releases, builds 1024 and 1028). You can double-check which version you've got by looking at the buildID.txt file in the root of your KSP install dir. I don't have a Linux box handy, but this is what the current build looks like on my OSX machine. % cat Steam/SteamApps/common/Kerbal\ Space\ Program/buildID.txt build id = 01028 2015-11-10_18-13-08 Branch: master

Huh, weird. Looks like all of the bbcode in this thread was ported across except for the last half dozen or so posts. I've updated what I could, and will quietly go back to nerding around with microcontrollers.

Three posts about leaving instead of just leaving. He's not going anywhere.

Over the last couple of weeks I've been working on a way to panel mount my LCD. Unlike everything else I've used in constructing this panel, it doesn't have any convenient mounting holes. I figured the best way to do it would be a couple of custom brackets behind holding it in place. Started by learning how to use OpenSCAD to model the brackets. With the display datasheet in hand I was able to come up with something that would centre the screen, despite the slightly odd dimensions. My 3D printer is... still in various pieces in the corner of my workbench, so I used one of the printers in my maker space to print my brackets in ABS plastic. And then tested them for fit. The mounting holes came out a bit larger than I would have liked, so I might print these again. But the display sits very snugly in the brackets. Once I had the brackets done, the rest was just designing and laser cutting a panel following my usual process. But, just to be on the safe side, I first cut a test piece out of some scrap bamboo ply to ensure I had my measurements right. This hole for the display is a bit bigger than it probably should be, so I'll do another test soon. But it was (mostly) a success! I've ordered some small push buttons that will sit alongside the panel to select the navball mode (surface, orbit, target). I'll add mode labels to the left hand side of the display, and highlight the currently active mode. Not sure yet if I'll keep the two buttons on the other side, still need to think of something to do with them. My controller is back in the shop. This week I'll hack a new hole to mount this in, then cut the final panel and attach it. The rest is (hopefully) just a little bit of software.

Updated all the links in the first post. Ho hum. Also just realised that a bunch of the bbcode needs fixing. More ho hum.

This is an excellent question that I still only have a vague, handwavey answer for. All of the photos and video I've made so far are with the original navball model. I've got a branch where I've been slowly increasing the detail in that model - drawing segment lines at the 45 degree marks helped a lot to break it up in to small enough segments to eyeball current attitude. Then I'll think about doing something about adding initials for the cardinal directions, and possibly drawing different coloured lines so I can easily spot North. But I'm still tweaking the final look. In addition, the navball markers are quite accurately positioned. I'm pretty sure I can get as close to a marker using this setup as I can with the on-screen ball. What I am concerned about are lag and refresh rate. I'm getting updates from the game every 80ms, so 12.5fps. That looks quite jerky, and I'm thinking about trying to increase that up to 20fps or so. And even though I haven't experienced much delay with the original i2c setup, it's way too early to speculate if there'll be any extra lag from adding another controller to the mix.

[quote name='Keith Young']Do you have any ideas why this doesn't work with Windows 10?[/QUOTE] The full details are several pages back now, but the short version is that the serial connector library is supposed to fire a callback when data is received. That has never worked properly in Linux or OSX, and has stopped working in Windows 10. That means the plugin is able to send serial data out, but never gets notified of data being sent back by the arduino, so it never tries to read it. There's been a fair bit of effort put in to trying to figure out why, but nobody's been able to get a handle on it. So there's a handful of attempts at working around it, with varying levels of success. The workaround zitronen just released in the latest update is an option to put the plugin in send-only mode. With the plugin sending data, and using an Arduino's USB HID emulation to generate keyboard and joystick events you can recreate the same functionality. My personal theory is that these issues are related to the version of Mono that Unity is running on. Still holding out hope that the Unity upgrade in KSP 1.1 will improve the situation for serial ports.

The test rig I'd built for working with the navball controller wasn't really cutting it, and I didn't have a spare (functioning) Arduino Mega, so last night I ripped the brains out of my controller so I could test with the live microcontroller hardware. I'll also take the chance to redo some of the hasty wiring I carried off leading up to the maker faire. All of the wires soldered directly to boards will be replaced by decent Dupont connectors. Apart from those, I'm very happy with how easy it is to disassemble this stuff for maintenance. From there I hooked up the I2C buses on the Arduino Mega and the Teensy and wrote a bunch of test scripts to ensure I2C worked properly. First running the stock Arduino Wire library on both ends, then switching to my custom Atmel TWI library on one end, finally with the Atmel library talking to the enhanced Teensy Wire library. Once that was passing, I switched back to the KSPSerialIO plugin. I still wasn't getting any packets from it over the I2C bus, but only this morning thought to look in the KSP logs, and realised my extra code for the new vectors was throwing a boatload of exceptions. It took a couple of hours of tracing debug logs to figure out what I was doing dumb there and fix it. From there it was a matter of updating my navball sketch to pick up and validate data from I2C and, almost accidentally, I had a functioning navball. I've got most of the pieces already lined up to show orbital vectors, just need to integrate that code with my main branch. And then there's a lot of optimisation I want to do on this code. I want to convert all of the vector information KSPSerialIO sends to smaller fixed-point numbers before trying to get that code merged. Then in my rendering code I need to clear up the source of the weird vertical lines (which I think I can do with some better error handling in the vertex transformation). And then I need to look at adding buttons to switch the navball mode and finally start working on a new panel to house it all.

I've been thinking about moving to pretty much exactly the same setup (kRPC -> python daemon -> serial connection) as a way to work around the issues Unity has firing the appropriate callbacks on Windows 10, Linux and OSX. But I put it off in the hope that the Unity 5 update would improve things. I'd be interested to see the code for your current work!

[quote name='KasperVld']Simply copy/pasting the posts including the formats (links, bold text etc..) and storing it either in a new thread not in Rocket Builders or even just in Word or another text editor would probably be the best way to go about it.[/QUOTE] I don't have an RB thread. :) And was asking if there was a simpler way to do that for a large number of a posts, just in case. Was hoping for, say, a BB code export, but can make do with just saving the pages. Thanks.

[quote name='KasperVld']That said, you should back up your own content if at all possible now, because there might be a small wait time for recovered content after the fact.[/QUOTE] Is there a suggested method for doing this? I was planning on dumping an entire thread in the "printable version" view, and possibly grab source for one or two of the more complicated posts. But that doesn't scale well. :)

I'm only playing the game on Linux these days, using the plugin in this thread. But the code I'm adding to support all of the navball vectors will eventually be a PR against zitronen's original plugin (and then merged in to this one).

Each axis on your stick [I]should[/I] just work as a regular [URL="https://www.arduino.cc/en/Tutorial/Potentiometer"]potentiometer[/URL]. One of those wires connects to the 5V, one to GND, and the third feeds to an analogue input on the Arduino. Four pots means you'll be sampling four analogue inputs, which you can do on a standard Arduino without any extra parts. Simplest way to do all of that is to pick up an Arduino Mega board (just because it has a lot of I/O pins; you can hook things up directly to it without worrying about multiplexing). If you haven't worked with Arduino before I still highly recommend getting a starter kit. It'll have a book with examples you can use to learn the basics, and you'll have a good set of the odds and ends you'll need like resistors, hookup wire, a breadboard for prototyping on etc.

[quote name='stupid_chris']The way it is, it helps you identify quickly good community contributors and helpful posters.[/QUOTE] I respectfully disagree. [quote name='r4pt0r']-post about how 1.0 was rushed. -tell people the barn was an awful idea -speak your mind on divisive issues -use snark in the correct situations. Thats how I got where I am.[/QUOTE] See?

[quote name='Stargate525']Unfortunately, Minecraft keeps firm data on any subsection of the world that has ever been loaded. It generates once, then stores the lot. That's why there are worlds that are several tens of gigabytes in size.[/QUOTE] Minecraft is a different issue. Initial terrain generation is done using a procedural algorithm, but after that the whole thing has to be stored, because it's so easily modifiable. My first thought would be to instead of storing the whole world just keep track of a delta - blocks that have been added to or removed from the procedural terrain. But no idea whether that would be more efficient or not. Remove the terrain deformation requirement and you can be a lot more efficient. My favourite example of procedural world generation is still the original Elite. 8 galaxies with 256 planets each, running on a BBC Micro with 32KB of RAM.

Thanks. I'm still feeling my way a lot with the I2C stuff as well. The system I have now has been working fairly well with an Arduino Mega and Leonardo talking for a while, but I'm confounded trying to add the third microcontroller. Current plan is to strip it right back and start from the basics. If I can get most basic hello world messages based between my teensy and another arduino first, then I can start scaling up the packet size and getting more complicated again. Slightly frustrating, but it's the best way to make sure I'm getting it right. I take no credit for the navball. The model and all of the initial work was done by others. Although, yeah, I agree that it's a great effect. I put a lot of effort last week in to making a higher-detail navball model, with a lot more faces in the bottom half. Looks a lot more realistic but it's a) slower and just didn't have the same charm. So I'm sticking with this one. Incidentally, if you'd told me two years ago when I started this project that I'd be learning Blender to finish it, I would have laughed at you. I think I played F-15 Strike Eagle on my C64 at one point. Which didn't have an attitude indicator.

I've been playing with arduino projects for a while, mostly little home automation type stuff - I've got little temperature sensors, movement-activated lights, an Internet-enabled clock, stuff like that. Got my start on my controller project because I wanted to build something with a more interactive physical interface (lots of switches and lights). Sputnix speaks truth. Get yourself an Arduino starter kit, and play around with the examples in it. That will give you a basic understanding of how to read input from buttons, and do stuff based on that. You'll have turned lights on and off, probably written numbers to a display, played basic sounds through a buzzer, and sent and received data over a serial connection to your computer. And really, once you've got that grounding, it's a fairly small step to using the same kit parts to talk to the game. I'm using KSPSerialIO, which comes with an Arduino sketch that should be fairly easy to start adding your own inputs to.

Looks great. I want to know more about what it does.

So here's how I planned on using multiple microcontrollers in my panel: A master manages the connection to the PC, and acts as a master on an I2C bus. One or more slave microcontrollers register on the I2C bus as slave devices. Whenever the master receives a VesselData packet from the PC, it sends that packet on the I2C bus, using the general call address. I don't currently have any plans for slaves to be able to send data back, but if the need arises the master can poll them. I'd implemented this system using an Arduino Mega 2560 as the master, and a Pro Micro as the first slave running the seven segment displays on my current board, and everything works great. This afternoon I started trying to integrate the Teensy running my navball display, as a second slave on the I2C, but ran in to issues with it fairly quickly. Turns out the i2c_t3 library for Teensys does not support general call packets. Probably something I should have checked before trying it instead of blindly assuming it'd work, but still. I think hacking the library to support general call shouldn't be much more than flipping the appropriate register during initialisation, but it's still a fairly intimidating proposition for me. So I may end up just updating my master to send packets to slaves individually. That seems gross and inefficient, but I should have enough spare CPU cycles on the master to get it done without any lag.

The Windows package does not ship a 64 bit binary, hasn't for some time. That command line is incorrect, and won't work at all on Linux. Please see the KSP on Steam section of The Linux Thread for the correct commandline.