stibbons

I agree. Now stop trying to tell us how unplayable the game is without your preferred mods.

Nope, this is probably the best place to ask. But not the best time, I'm currently in the middle of moving house. At first glance that looks like it's OK. I did see reports of similar stuff happening, which I think I've gotten a handle on. The only suggestion I think of is making sure you've got the most recent arduino library. Unfortunately the library manager isn't updating properly, which I need to figure out with the arduino folk. But you can get the most recent from https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/ Hopefully that will help.

To control remote probes from a ship, you need to add a command station to your ship, which isn't easy to do and definitely not worth it to control a satellite in kerbin orbit. The only practical way to control probes in Kerbin orbit is to establish a connection back to KSC. But if you're in low orbit, less than a thousand km or so, then that will be pretty easy to do just with the Communotron antennas. As long as your satellite and your ship both have one Communotron each, then the satellite will either link directly to KSC or via your ship as appropriate. If you need to perform a burn without a connection, say you have to circularise your satellite while it's out of range of KSC, then you need to learn to use the flight computer to plan maneuvres. I usually do it by placing the maneuvre node where I need it, then setting the flight computer to execute that node. The computer will then go ahead and perform the burn, whether I have a connection while burning or not.

What on earth is the point of that video? Pointing at a community-written wiki, and then at some Squad parts? What's happening?

@Freshmeat is right, the standard Arduino Wire library is great for simple projects, but very slow. It sends data synchronously, and that's almost certainly what's slowing your sketch down enough to lose sync. It also has an internal 32 byte buffer, so if you try to start using it to send KSPSerialIO data packets, you'll find yourself having to loop through the packet half a dozen times to send it, and then the receiver will have to loop through half a dozen times to assemble the fragments again. All using the synchronous interface. It's probably going to fail. Using I2C is a great way to send to slave controllers; in my setup I'm using an Arduino Mega to handle the serial connection to my PC, and whenever it gets a data packet from the game it immediately rebroadcasts it over I2C to three slaves. You just won't be able to use the Wire library to do it. Have a look at my KerbalController sketch. The TWI_Master library there is a much lower-level I2C library, which makes full use of the I2C hardware built in to the Atmega chips on Arduino Uno and Mega boards. The code in twi.ino sends vesseldata packets from the game, as well as my own data packet, that's used internally in the controller for things like setting the display mode and brightness. The KerbalDescent sketch is a fairly simple example of how my slave controllers work. They use a TWI_Slave library, the slave counterpart to the TWI_Master lib. Hope that helps.

Quick read says it looks fine. I'll probably have to dig in to how the plugin is working, sorry. I'm in the middle of moving house, it'll take me some time before I'm settled and able to work on much. As per the docs at http://kerbalsimpit-arduino.readthedocs.io/en/stable/payloadstructs.html - parseAltitude returns an altitudeMessage struct, containing values for sealevel and surface altitude in your current SOI. The KerbalSimPitAltitudeTrigger demo sketch has an example of how to use parseAltitude and extract data from the struct it returns. In unrelated news, I've just uploaded version 1.2.6 of the plugin, which is just a rebuild for KSP 1.4.2. I've also released a small bugfix release of the Arduino library, version 1.1.4. I'm hoping this release will also sort out the issue I'm having with the Arduino library crawler.

Yes, CKAN is designed to only show you mod versions listed as compatible with the version of the KSP install it's working with. Just grab the latest CKAN client and proceed as normal.

This line is telling you that the file length is not what the client was expecting, which usually indicates a download that was corrupted somehow. If you've tried once or twice and it's still not working, it may be easiest to download the required file manually from the forum thread below, and use the CKAN client's import function (File -> Import downloaded mods...) to install it under CKAN control.

The wiki has some other tips on reducing garbage at https://wiki.kerbalspaceprogram.com/wiki/Garbage_Reduction It's mostly just a summary of info Squad published about what they did in the cleanup @linuxgurugamermentioned. But useful reference.

No. If you bought the game through Steam, then you can only update it through Steam. But you can learn how to use Steam! The properties pane for each game has an Updates tab with options to control automatic updates. It looks like this: You can disable automatic updates for all of your games and manually update KSP. Or you could set KSP to be High Priority so it gets downloaded first, and disconnect afterwards. Or you could even disable background downloads for everything except KSP and launch some other game - Steam will go ahead and download the KSP update in the background.

Couple things worth checking with controllers in KSP: Previous versions of KSP have had issues with the settings getting messed up if you start the game without a controller present. In that case, it's worth wiping all of your settings by removing settings.cfg from the root KSP folder, then starting the game with the controller plugged in. Controllers don't seem to work at all in KSP 1.4.0 and 1.4.1 on Linux. There appears to be some workarounds, but the best bet is probably to wait for a new release. See this thread for details.

Ten. The fact that I used a 10-digit calculator in high school is related.

The original announcement from SQUAD after the absurd hissy fit that resulted in free DLC is at http://kerbaldevteam.tumblr.com/post/47730955705/expansions-dlc-and-the-future-of-ksp . Note this bit: So, end of April 2013 was chosen as the cutoff because that's when they announced it. Nothing more, nothing less.

You can tell this is true by the fact that this post was removed.

Great to hear that's working properly. Keen to see how you get on with the full setup. Soon.

To be honest, I for one wouldn't mind seeing an active maintainer just... start a new OP.

Mea culpa. I didn't properly test the throttle handling after adding it, so of course it was hideously broken. I've fixed the handler so that the plugin is at least able to receive and process throttle packets. But working my test rig (a 10k potentiometer hooked up to an arduino ) I was still getting erroneous values. Unfortunately I'm going to have to bust out the logic analyser to get to the bottom of that. But in the interest of releasing early and releasing often, version 1.2.5 is now out. Throttle packets are now received and handled. Probably incorrectly. With "verbose" set to true in the config file, the plugin will log the contents of every throttle packet received. Work is still progressing on the throttle, after that I'd like to make the handlers and their logging a little bit more robust. Don't expect to be adding very many user-visible features on the plugin end for the next little while, sorry. And adding insult to injury, it looks like the Arduino Library Manager updater hasn't been crawling new releases of the Simpit Arduino library. Right now installing through the Library Manager will get you version 1.0.0, while the most recent is 1.1.3 (and is definitely worth using instead). Still trying to get to the bottom of what's wrong, but the best I can suggest right now is making sure you install the library from https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/kerbalsimpit-arduino-1.1.3.zip

I think what you're looking for is the 3rd of Qawl, or 25th of November.

It's a minor thing, and I'd have to think hard about how a "no really I know what I'm doing when I'm setting version requirements" feature would work. Would much rather continue playing around with Xamarin.Mac.

Thank you for confirming it. I'll take a closer look when I'm home from work this evening. Better logging is already on my todo list for the next (real) release, the fact that people apart from me are starting to use this plugin is pretty good motivation to do some more work on it soon.

That's mildly disappointing. Thanks for looking in to it.

This is where I get mildly grumpy because there's precisely one country in the world that localises dates as <month>.<day>. We get where you're coming from, but it just doesn't work for me. And this is why the 22nd of July is the one true Pi Day.

I set `ksp_version_strict` to true in my netkan. Does setting compatible version in the CKAN client override that flag, or does it just influence what the client considers as "generally recognised" compatible (ie, only influence behaviour when ksp_version_strict is false)?

@EricccMa Wait, are you using an RC transmitter to control KSP? That's really awesome. for(int i=0;i<4;i++) { RC[i]=map(RC1[i],1100,1900,-97,97); RC[i]=map(RC[i],-97,97,-31000,31000); } So the values you're reading from the controller are in the range 1100-1900, and you're mapping that to the full range of a signed 16 bit int. That's fine. RC[2]+=3000; RC[2]=RC[2]<0?0:RC[2]; RC[2]=map(RC[2],0,6000,0,1000); Are you sure you want to be discarding negative values of RC[2]? I don't know how your controller behaves, but I do know that the throttle on my Logitech USB joystick uses the full 16 bit range, so "throttle off" is actually -32767. Finally, I'm not sure of the impact of using the map function when the input is outside the specified range. But I think you're effectively dividing the throttle value by 6? That could end up lower than you'd expect. The plugin treats the throttle data the same as the pitch/roll/yaw data, with the exception that negative values are ignored. So send a 0 for throttle off, and 32768 for full throttle. I'm worried that second block altering RC[2] ends up setting it to a value that is too low to be useful. Maybe try writing the throttle value to your LCD before sending it as well to confirm it's giving decent data. Unfortunately my test hardware rig is still in a box somewhere after a recent move, so still getting my life back to the point where I can put decent time in to investigating this and doing serious development on the plugin. But it's getting there!