MrOnak

For those who prefer to work with Atmel microprocessors directly and without the overhead of the Arduino GUI, I've ported Zitronen's Demo8 to native AVR C: https://github.com/MrOnak/avr_KSPIO Enjoy

Holy cow, this might be the very best KSP-mod in existance. Here, have my rep!

@Zitronen, you have a private message

Not quite sure if this will be helpful to you but I've downloaded V0.15.3 just like you did, installed it in 24.2 without any other mods and it was working fine from what I could tell within an hour or so (only displaying data such as altitude, not using the controls). Anyway, a simple but boring way to find out whether mods conflict with KSPIO is this: First, upload a clean copy of the demo8 code onto your arduino and see if that works with all your mods. If it does, the problem is in your Arduino code. If not: - make a copy of your whole KSP folder - clear the GameData directory of any mods - install the KSPIO mod from a fresh download - upload the unaltered demo code from the first post in this thread onto your microcontroller - start KSP and see whether KSPIO works (it should) - if it does, shut KSP down and copy one mod from your "original" KSP folder to the test environment. Restart KSP and see if it works. - rinse and repeat the previous step - if a mod breaks KSP/KSPIO, delete it again, take a note and continue with the next mod That way you can easily isolate all mods that are conflicting. It's a bit tedious but very straight forward.

Pretty much. Install the KSPIO mod into KSP. Upload the sketch to the Arduino Start KSP. It'll automatically connect once you load a vessel (so not in VAB etc)

I might have missed a more recent post on this, but did you figure out how to display the current state of things like SAS, RCS, GEAR, LIGHT...? I realized I have a bit of space on my hardware for status lights and was wondering whether those might be coming in a future update?

Thanks for the clarification. I actually had some time to play a little with the Arduino code and managed the display the vessel altitude on a prototyping board pretty much straight away. Looks like tweaking this to my plan will be easier than I thought although I'm not looking forward to translate the whole thing to AVR C - nothing wrong with your code by the way, it's just generally tedious and error prone. I'll make sure to keep my inputs in this thread as I do along with the development. Also, expect a git repository when I'm done. CC BY will be maintained of course with proper credits.

Ok I've been stalking this thread for a long long while now and my other AVR projects are coming to an end so its time to start this one . Question: Any idea if / which other *duino clones are supported by the plugin? My guess is that any ATMega328p with on-board USB-to-serial converter should work. Or are there any other requirements that I don't see? If not I'd prefer to solder my own circuit with the ATMega328p and a USB-to-serial converter. A bit of background: I'll be using this plugin only to display telemetry data on a ton of 7-segment displays. For controls I have another project almost finished that will act as combined joystick/keyboard to the computer so I don't need this plugin for that. (The benefit of the other controller being that it's not limited to KSP since its a generic USB-HID device). Thanks a lot for any advice and for the plugin as a whole!

I re-installed chatterer 0.5.9.4_x64 alongside the latest MechJeb 2.3.1.0 from curse, the crash folder in a zip file is here: https://owncloud.dominiquestender.de/public.php?service=files&t=77fe02cd272b666836259fd34fd4ff0f Happy debugging

I'm apparently getting similar crashes to what Maximus88 reported above. Happens with 0.24.2 of KSP, latest Chatterer. It ONLY happens when Chatterer is installed with either MechJeb (whatever the latest version on curse is) or KER (0.6.2.10 or 1.0.2). Chatterer combined with my other mods but NOT Mechjeb nor KER works. Mechjeb with my other mods works. KER with my other mods works. That's on KSP 64bits, Win7 64bits. The crash happens as soon as you load the saved game to get the "helicopter" view of KSC.

Hmmm.... it seems that with the latest release of ProbeControlRoom the Aerocams from Hullcam don't show a picture anymore from within the ControlRoom. Or rather, they show a picture of some grey surface with changing light scatter on it but no clear picture. That is with Hullcams that show a perfectly fine picture when outside ProbeControlRoom.

Thanks for pointing that out Camacha. @erendrake, see my reply to #137.

Good chance is that you're dividing by zero somewhere. That seems to be the case for me in most cases this message appears.

Hooray! *scrambles to get scripts working again* [edit] - Found one bug with ship:controls, see #137 on github. - several bugs related to VecDraw, see github. - the rest of the changes seem to work as advertised although I didn't have a chance to test all of them yet. - on the github release note you mentioned "rcs controls are not responding." but ship:control:fore/starboard/top work fine for me. What exactly did you mean? - one change: body:distance now (correctly) returns the scalar between the center of the body and the center of mass of the ship. in 12.1. this wasn't the case (it was from the surface). I think this change isn't mentioned. - "Added Boot files that will run when you get to the pad automatically, you select which one will run in the VAB thanks @WazWaz" - how is that supposed to happen? I don't see a selection option in the VAB, nor does the boot file seem to be loaded onto the core on launch. [/edit]

Pretty much any time works for me this weekend. I'm in GMT+1 (Germany) and aside from a bit of shopping on Saturday I can't think of anything we need to get done. Its probably best if you PM me a time that works for you guys and I'll be there.

@devs I'll be more than happy to contribute to kOS by providing documentation. If you're interested we should probably set up some sort of more direct communication over the weekend.

That post, sir, is a gold mine. Thanks a ton!

I know about those. Sorry, I should be more precise... I need to figure out when to start the burn to get from body A to B. Phase Angles and all that.

ah that one... damnit I knew about that for-in. I was thinking more in terms of for i=0. i < ....... i++ {...} oh well

Hmmm.... *scratches head*... does anyone have a good webpage that explains the mechanics / math behind transfer orbits? I know about http://ksp.olex.biz/ and I can get to Mun/Minmus just fine but I want to write a kOS script that does the same. So I'm trying to figure out what actually happens behind the scene but I haven't really found anything useful yet. [edit2] I have a working Hohmann transfer orbit script, but to get to another body I need to figure out when to start the transfer burn. Right now I have no real clue where to start looking[/edit2] Thanks in advance. Oh and I don't want kOS script codes, I want to code the stuff myself - I just need a headstart on the math. [edit] I just realized that "transfer orbit" also includes Hohmann and the likes. What I meant are maneuvers that get me from one body to another. Either Kerbin to Mun or Minmus on one side or Kerbin -> different planet[/edit]

You're more than welcome

Wait what? There is a for loop in kOS?

@velve make sure you combine it with RasterPropMonitor (manned IVAs) and/or ProbeControlRoom (unmanned vessels) to get the most out of it.

Me again . Question about the booster cam which I really like to check my staging AND the fairings with only one camera. It doesn't seem to be possible to have both camera eyes register/show up in a RasterPropMonitor / ProbeControlRoom monitor? I can get one camera picture, but not both as camera 1 and 2, for example.

I guess they would be too small, yes. I think the map on the small monitor has its place when zoomed in (for landing or on a rover for example) and when zoomed-in not having the whole surface visible is kind of the point anway. Small monitor and zoomed out... I don't think there's much use. Unless.... <crazy thought warning here> Unless "zoomed out" on the small monitor would mean the vertical axis covers 100% of the body and the map auto-scrolls horizontally to keep the craft centered in the x-axis. My framerate hates me already though, not sure how feasible that would be. Ok... enough evil thoughts planted in peoples heads for today Keep up the good stuff!