[Hardware, Plugin] Arduino based physical display + serial port io+ tutorial (24-11-19)

[cm2227]

17 minutes ago, zitronen said:

I can add more things to the packet, but we should have a discussion of what to include, there is limited space left. Stibbons is working on adding a bunch of orbital vector stuff as well.

If you are using a controller with throttle, couldn't you connect your dial to it directly?

 

Well that is not an option for me, as I'm a USB joystick (Saitek X52) and its throttle. Also I plan on implementing an arduino-based autopilot, which would require reading back throttle to see if the command was executed correctly.

I would gladly take part in a discussion on what to add to the VData packet. Orbital vector stuff would also be pretty interesting. What is the space limitation?

Edited April 6, 2016 by cm2227

[zitronen]

The code is there for different packets, we might need to do that at some point.

The limit isn't just the amount of data transfered though, it's also how much RAM we have to work with. If you break them into different packet sets all the data structures still have to be loaded into the RAM of the arduino. I am intentionally limiting things to 255 bytes, because I think that's a reasonably large chunk of the RAM.

[cm2227]

If you are open to discussion - which would essentially mean letting other people interfere with your voluntary work - I have several ideas.

How about adding a few float variables whose content is determined by command in the control packet, i.e. the arduino requests which values it needs?

Or a second type of packet which contains more static information, like the consumables max values or SOI and is only sent every few seconds?

Or an optional packet with rarely used info, which is only sent on request by the arduino?

[richfiles]

I do forget how small these things can be sometimes... It's also easier (for me) to remember them by the flash vs the SRAM, from a program storage point of view. Is it possible to consider the option of a KSP Serial IO "lite" (basically, just the current state of the plugin, which would run on any Arduino), and a second "extended data" version that maybe requires a Mega for installation, due to increased memory requirements? The difference would be that one version would enable at least one or three alternate packets (a single packet ID bit could, of course, represent 2 packets, while 2 packet ID bits would obviously be able to represent up to 4 packet configurations).

I'm curious what this runs on currently. I have a pile of Megas and Pro Minis, myself. Those have 8K and 1K or SRAM respectively. I think the Uno has 2K SRAM. That means for a Mini, the packet is 1/4 of the entire RAM (would it even run on a Mini?). For the Uno, the packet is 1/8 the RAM. For the Mega, the packet is a far more comfortable 1/32 of the total SRAM. I think that could be a factor for those who want more from this plugin... If you want more, splurge on a higher end Arduino. Consider making the Mega a requirement for running more than 1 packet. It would make sense anyway... Someone running more packets most likely has more analog gauges, more displays, more LEDs... They probably would need the additional I/O anyway.

I myself am already looking at a proposed minimum of 3 Arduinos for my project, and possibly a Raspberry Pi later on, just as it is! My intention is to have the main Arduino run as many analog gauges as possible, since those are just basic PWM writes. It's probably "cheaper", performance wise, to write the PWM values directly, than try to package the numbers up and communicate those serially to another device. It really already makes sense to me, that if a project is already large enough to potentially exceed the capacity of a single Arduino, that maybe asking for a better Arduino as your starting point might actually be reasonable, at least for more complex builds. Like I said... If a build only needs one packet, then there need not be a limit. If two or more packets are desired, I think it'd be fair to ask for a larger Arduino in the first place, to run it.

As for splitting my Kerbal controller project off into different microcontrollers for different distributed functions, My FDAI (navball) is certain to require it's own controller. If an Arduino can't handle the processing grunt to calculate the attenuation and polarity values for the 9 synchro signal lines, based on the angle of the three attitude axes, then I have a Teensy 3.1 as an alternative controller. That runs a whooping 72 MHz, and has 64K of RAM, and 256K of flash... Surely that will be fast enough for the task! I also have to calculate the heading vector and translate that to a pair of crosshair configured needle meters that hover in front of the navball. That's how I would show my node/attitude markers. Again, all that would be offloaded from the main KSP Serial IO Arduino. All the main Arduino would have to do is send out the three attitude axes and the heading values

Finally, I want it to send all numeric readout data to a second Arduino, where it will break the numbers down into their individual digits and send them out over SPI to my displays... I still find it amazing that it has to be done that way! I kinda (really) wish someone would come up with an "easy" library that handled breaking up simple numbers and strings and communicating with the MAX7219 chips automatically. I only got mine working by editing example code... I barely even understood how it works! Getting no compile errors was more trial and error than actually getting it... Anyhow... Those last two things ain't your problem. I just simply don't get C the way I used to get BASIC. 

Edited April 6, 2016 by richfiles

[Freshmeat]

17 hours ago, zitronen said:

I can add more things to the packet, but we should have a discussion of what to include, there is limited space left. Stibbons is working on adding a bunch of orbital vector stuff as well.

If you are using a controller with throttle, couldn't you connect your dial to it directly?

On orbital vectors: If we get prograde and either normal or radial, the rest will be a simple calculation. Is target and manoeuvre node in the works as well?

I am, however, worried about memory on the Uno board if we bloat the packet too much. Perhaps time to look if we receive anything nobody needs?

Edited April 7, 2016 by Freshmeat

[cm2227]

@richfiles: My approach is similar, I also have one Arduino Mega as a central unit handling communications with KSPserialIO and as many analog gauges as needed/possible plus other displays, but limited to output only. Any input is handled by other units but will in the future partially be passed through the main arduino by serial communications. I also urge everybody to spend a few moneys extra on a higher level arduino to avoid RAM shortages.

@zitronen: For many numeric values like battery or xenon gas it could be sufficient to transmit a single byte representing only the level, e.g. current / max * 255 which would indeed save memory. At least in my case where the consumables are only used for analog display. In addition I will rarely need VData members 4,5,12,28-31. Also some of the values could be calculated if needed on the arduino, like eccentricity from major and minor axis.

[faeryty]

*delurks*

My project is going very slowly, so I dont really feel the right to request anything, but I just wanted to raise my hand as a member of the multiple micro-controllers club too.  It's all theoretical at the moment and I dont even have it prototyped, but my current plan is an arudino mega as my main hub, shooting off the relevant subsets of the vdata packet to other micro-controllers over i2c. 

*lurks back into obscurity*

[zitronen]

You have to remember that if the packet sizes are increased, the serial buffer will need to be increased as well. This is already causing problems because the packet is larger than the default serial receive buffer of 64 bytes. Ideally the receive buffer size should be equal or larger than the packet size. So once we max out the 255 bytes, without actually writing any useful code, we are using half a kilo byte of RAM. I'd like to maintain the ability to run on pretty much any arduino, making it easier on new people.

I think we should be careful with remove any existing values from the packet. Almost all the things in the packets are there because people asked for them, and I wouldn't have added them if I didn't see the need. There is still like 50 bytes left, pretty much anything you ask for now probably will be added, so no need to start worrying just yet.

In any case, right now the focus is getting 1.1 working.

[richfiles]

I guess what i was asking before, isn't asking if it's possible to add more packets, but rather alternate packet frames. Each packet would use a couple bits to ID the packet type, and the code would transfer unique values where they need to be stored. In cases where a particular piece of data would benefit from being updated on every packet, you could even have that data, in the same location in every packet. It would allow portions of the packet to remain the same data on every frame, while other values could change. As long as the arduino software and the plug in both know what any given packet ID contains, the content that is the same between all different packet IDs gets handled the same way every time, aways moved to the same variable, regardless of the packet ID. The content that is unique per each packet ID would be moved to the appropriate variables, based on which packet ID is sent with each packet.

As an example, let's say around 192 bytes are the same in all the packets, but with 4 possible packets (defined by a 2 bit ID, in this example), then you'd have 64 bytes that could be unique per each of the 4 packets, making 256 bytes that are flexible (192 bytes more than sticking with a single packet), and 192 bytes that are always the same, regardless of packet. You'd need additional memory for the extra variables to store data front he flexible packets (enough to store an additional 192 bytes of data). I don't know what the overhead is for variable storage, but If i and half an idea of what I was doing, that's probably how I'd handle things... Again, no clue if I'd be right or not. The following is a breakdown of this particular example. You wouldn't need to do it this way, but it's a thought.

[Packet ID 00 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes D]
[Packet ID 01 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes E]
[Packet ID 10 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes F]
[Packet ID 11 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes G]

Memory Variables required to store data from *<A, B, C>, *{D, *(E, F, G)}
*<These values are always sent in all 4 packets. They are always the same, regardless of what packet was sent>
*{These data sets are different in each different packet}
*(An additional 192 bytes of data can be sent and needs to be stored in additional variables, but only when a packet is actually sent)

I can't really say I even know what's going on under the hood, but I'm not talking about sending multiple sequential different packets. Maybe you send packet 00 over and over and over, and then a piece of data carried in packet 01 gets updated by KSP, so the plugin sends an alternate packet with ID 01, and then returns to sending packet 00 repeatedly. Maybe another variable is updated, and it sends packet 11, then returns to sending packet 00...

The idea isn't to send packet 00, 01, 10, 11, 00, 01, 10, 11, 00... and so on...
It'd me more like 00, 00, 00, 00, 00, ... 00, 00, 00, 01, 00, 00, 00, 00, 00, ... 00, 00, 00, 00, 11, 00, 00, 00, 00, ...

Maybe there could be a handshake that occurs to confirm receipt of the alt packets. Plugin would resend the alt packet if no handshake occurs, before returning to the default.

Again, I REALLY don't know the programming aspect of this all that well, but if values are moved into appropriate variables, then wouldn't the same serial buffer be used?

If I'm totally wrong, and just don't get the way this stuff can be programmed, then never mind... I'm just sorta... Spewing ideas.

I guess I also feel that it's not unreasonable to have two builds for different sized Arduinos. The normal build could be considered a standard version, and optionally, there could be an advanced version. No changes would be required for a "standard version". That'd just be what we have already (but updated for KSP 1.1, obviously). That version would obviously work for all Arduinos currently able to run it. An advanced version could simply require a Mega, or something, to handle the increased memory footprint. Or something. I don't know. Again, just ideas.

Edited April 8, 2016 by richfiles

[stibbons]

On 4/7/2016 at 4:32 PM, Freshmeat said:

On orbital vectors: If we get prograde and either normal or radial, the rest will be a simple calculation. Is target and manoeuvre node in the works as well?

My first pass at it is in https://github.com/zitron-git/KSPSerialIO/pull/10

That PR added pitch and yaw for orbital prograde, normal and radial, as well as surface prograde, target and maneuver node. Basically all of the vectors that are displayed on the in-game navball. I used all three vectors because I was only sending two axes for each; not enough to properly calculate the third.

The problem with it, though, is that those aren't suitable for my use case. That patch calculates immediate offset from vessel heading to the target vector in two dimensions. But if the plan is to render vectors on some sort of navball display (and I can't think of any other uses for it), then what's really needed is a set of Euler angles for each vector, again relative to vessel heading. Hopefully this helps illustrate what happens when you treat those immediate offsets like Euler angles: 

I started out by sending two 2-byte variables (pitch and yaw) for prograde, normal and radial. With the Euler stuff I'm pretty sure that'll have to be three variables, but I haven't thought much about whether I can send two or three vectors. Once I've got something working I'll do some tests and see if the extra Arduino-side processing is worth the smaller packet.

Note that my worst case estimates for what I'm adding to the data packet take it out to about 215 bytes though, still well short of the limit imposed by the header. And I'd like to claw back some more space by converting some of the other stuff from four-byte floats to two-byte fixed point numbers (although that's impossible without significant controller-side code change  ). Given a lot of people are already struggling to make their microcontrollers keep up without overflowing assorted buffers around the place, what's to gain from adding a whole other packet to the mix?

On 4/6/2016 at 6:23 AM, richfiles said:

I still find it amazing that it has to be done that way! I kinda (really) wish someone would come up with an "easy" library that handled breaking up simple numbers and strings and communicating with the MAX7219 chips automatically.

Most of that stuff is really easy already. What's so difficult about looping through a character array and writing characters to a display?

I did, however, write EngNumber during the course of my controller build. It's a small library that converts a float to a number in engineering notation, with as many digits as your display supports (well I've only tested it with four digits). It's based on some proposed changes to the Arduino print class that I found in the forums, uses some super fast assembly inner loops on AVR controllers, and outputs the number to an array that is really easy to write to your display.

[stibbons]

On 4/7/2016 at 0:51 AM, faeryty said:

My project is going very slowly, so I dont really feel the right to request anything, but I just wanted to raise my hand as a member of the multiple micro-controllers club too.  It's all theoretical at the moment and I dont even have it prototyped, but my current plan is an arudino mega as my main hub, shooting off the relevant subsets of the vdata packet to other micro-controllers over i2c. 

If you thought the weird buffer limits in Arduino's Serial classes were bad, wait until you dive in to the Wire library!

Using i2c with the native Arduino Wire library is great if you have half a dozen bytes to send. But it has a packet limit of 32 bytes, so if you're planning on sending subsets of data to your different devices you need to think carefully about limiting what you send. Otherwise you need to start looping over the structs that you send. It's also worth pointing out here that the Wire library is synchronous. When you send a packet the call blocks until it's been sent and acknowledged. That's probably not an issue when you start out, but if you've got two or three devices, and need to send two or three 32 byte packets to each, it starts to add up, and you have problems keeping your serial buffer drained.

I decided early in my build that I would use the fact that i2c can broadcast to slaves (nobody talks about this much, but the spec says that if the i2c master addresses a packet to device 0 then all slaves should receive it. Arduino handles broadcasts with an option to the slave init.). When my master receives a serial packet, it relays the entire thing on to i2c. Every slave receives it, and every slave has the exact same code to read and verify it. Then it picks out the bits it needs and carries on.

Of course, the Wire library is even worse for that approach. You get to loop over this 200 byte packet seven or eight times to send it all over i2c and that entire operation blocks.

Basically, don't use Wire. For teensy based projects, use i2c_t3 (although annoyingly that library doesn't receive broadcasts, so my controller currently sends vdata twice until I can fix it). For AVR-based Arduinos like the Uno, Leonardo and Mega, there are a handful of faster i2c implementations. But I ended up writing my own based on the example TWI code from Atmel.

[richfiles]

16 hours ago, stibbons said:

Note that my worst case estimates for what I'm adding to the data packet take it out to about 215 bytes though, still well short of the limit imposed by the header. And I'd like to claw back some more space by converting some of the other stuff from four-byte floats to two-byte fixed point numbers (although that's impossible without significant controller-side code change  ). Given a lot of people are already struggling to make their microcontrollers keep up without overflowing assorted buffers around the place, what's to gain from adding a whole other packet to the mix?

Most of that stuff is really easy already. What's so difficult about looping through a character array and writing characters to a display?

I did, however, write EngNumber during the course of my controller build. It's a small library that converts a float to a number in engineering notation, with as many digits as your display supports (well I've only tested it with four digits). It's based on some proposed changes to the Arduino print class that I found in the forums, uses some super fast assembly inner loops on AVR controllers, and outputs the number to an array that is really easy to write to your display.

Regarding my comments about the MAX7219 display controller library, I just was stating that I found it surprising that the library stopped where it did. Sure, it works as is, but I think it would have been quite nice to be able to just setup the display with the library, and then use the library to feed the display controller a whole integer, float, or string, and just make it generally a little bit simpler for a person to feed data into it. I suppose once you actually learn C, it's not as hard to do, but, well... I'm still learning. 

in regards to my prior comments regarding multiple packets and the buffer... I don't know if I'm just clueless on how any of this works... I really don't get coding all that well.

What I was suggesting, was a structure, where a packet is sent, the significant data is pulled from the packet (presumably from the buffer? is that how this works?) and stored in appropriate fixed variables, and then the buffer is overwritten by the next packet. Data is read from it, and stored in appropriate variables, and then once again, the buffer is overwritten by the next packet. The buffer just holds the last packet sent... I think? It doesn't stack packets sequentially, right? Or am I wrong?

My suggestion of a packet ID was a reference to 1 or 2 bits to define the content of the packet. I read over the packet content again, and I see there is a whole byte reserved as a packet ID! That'd work too, I suppose. What I was describing would mean that if a packet is sent, if its ID is 0 (presuming that means the default packet), then the individual bits and bytes of data are read from the buffer, and stored in the appropriate variables associated with packet ID 0. The next packet is sent, overwriting the buffer. Lets say that packet is packet ID 1. Now, because the packet ID is read as 1, the data would be moved from the buffer to variables associated with packet ID 1. Same would be true of other packet IDs, and variables associated with those specific packet IDs. I am not aware of any need for a larger size packet on sending from Arduino to PC, so I'm ignoring it, for the moment. Aside from the Control frame from Arduino to PC, where controls need to be quick, do we really need all the data updated on every single frame? If we really do need some data updated every packet, I don't see why a few pieces of data could be common, across multiple packet types, so that value is updated with any packet ID that contains it.

If we are having buffer overflow problems, couldn't we use such a method to allow the switch to a smaller packet size (say, 128 bytes, instead of 256 bytes), and then use a rotating ID to send the data, sequentially spread out over a few packet "frames"? You'd end up with less data transmitted per each packet, but you'd still be able to send it all out, even more than 256 bytes, just spread out over more time. It'd give the Arduino more time to retrieve the received data (less at a time), while also allowing it to receive more total data (even exceeding the original 256 byte packet). Would smaller rotating packets solve the buffer overflow issue? Using four packet IDs, with 128 byte packets could send up to 512 bytes of data, but spread out over 4 packet "frames". Using three packet IDs, could allow 384 bytes of data to be sent over 3 frames, presumably. If the Arduino happens to miss a bit of data, that data will be back around in a few frames.

Even sticking with 256 bytes of data, if you split it into a pair of 128 byte packets, you'd spread that data out over 2 frames, giving the Arduino double the time to do what it needs with each variable within the packets. It'd just handle the first half, then the second half, and repeat... On half the buffer size. I think.

With most readouts needing to be read by human eyes, I have a hard time believing that we can't wait 3 or 4 frames for an update. Even with my abysmal coding skills, I still managed to put in an update rate counter on my LED display burn in code, back in August, so the displays would update at a rate you actually had a chance to read, and not be a blurry mess.

Honestly, my only real issue, is me... I have never worked with C in my life, up until last August. Everything is new to me. I still don't understand half of the code I have on my Mega right now. Literally just copied code from two different examples, tweaked around on it till it compiled, and it functioned together to do what I wanted it to do. I have a Looooooong way to go before I'm even remotely proficient enough to have a clue how to even begin this project's more advanced functions. I'll certainly be able to figure out controlling LEDs, reading switches, setting analog meters and displaying data on the displays, but even if I get my FDAI hardware built, it'll be a good long while before I even know half what I need to know, to be able to write the code to make it actually operate.

I honestly had to set this project aside for a few months. Getting the wrong displays last year was annoying... Finding out the replacements had a worse than 50% defect rate was infuriating. Finding out I got fed some impossible numbers on Arduino performance capability on another forum (which lead me to build a nearly $45 10 DAC signal generator... that turned out to be utterly useless to me)... That was kinda my final straw. Between all that happening within the span of around a month or so, and the wait for 1.1, I pretty much decided to put my Kerbal controller build aside. I needed to just step back from it. I switched 100% of my build efforts into my mechanical keyboard instead. I've planned, purchased, and built that for the last half year instead. Guess where I'm stuck... I have a finished keyboard with a blinking Caps Lock key... Cause it's still running the "blink" program. 

Unfortunately, that delay also has let every iota of what I did learn of C, back in August, to ooze out my ears. I really need to start from scratch again. I seem to recall C is fond of something called a "void"...  No clue why I'm having so much trouble with C... You'd think my brain should do just fine learning C then, cause I feel like I've already got a big old void between my ears every time I try to stare glass eyed at a screen full of code! 

Edited April 10, 2016 by richfiles

[faeryty]

@stibbons Thanks for all the tips. I have heard plenty of less than complementary things about the Wire library, and so was expecting to probably end up butchering it/bitbanging the TWI protocol myself.

I've finally sent the pcbs for my altimeter off for fab.  As my altimeter is a 6 tube nixie display, and as has ended up costing me far more than I would like to admit, I wanted to give it a double purpose and have it run as a clock when I'm not playing KSP.  Not trying to make things harder on myself at all...  All the hardware is set up and ready to receive data over TWI. I should probably have tested it on my prototype first before fabbing my pcbs, but impatience finally got the better of me. At least it's theoretically just software at this point, which I'm much more confident with than hardware.

Edited April 11, 2016 by faeryty

[zitronen]

Heh I have my display showing CPU & RAM usage and stuff when I'm not playing KSP.

The thing with smaller packets is if you are still sending data at the same rate, you still need the same buffer size. The reason we need any buffer at all is the arduino can only do one thing at a time, either it's doing your code that processes the data while buffer is filling up, or it's receiving and clearing the buffer. Smaller packets won't changes how long your code takes, so instead of filling the buffer with 1 big packet, now it's filled up with 2 smaller packets. Also smaller packets have more overhead as well. I think our current 255 byte packet is manageable. The question is what is the best thing to do if in a few months time we need a more space, can we just keep adding stuff or are we simply running out of computing resources on the normal arduino?

BTW @stibbons, what did you do to get the thing working on the teensy? I remember there were some incompatibilities with 8bit vs 32bit struct packing or some such?

[stibbons]

On 4/11/2016 at 1:02 AM, zitronen said:

what did you do to get the thing working on the teensy? I remember there were some incompatibilities with 8bit vs 32bit struct packing or some such?

I add the packed attribute to the packet structs, ie:

struct VesselData {
  // snip
} __attribute__((packed));

That should be all that's required to run the demo sketch on a teensy as well, but I don't think I've personally tried it.

See my KerbalNavball sketch for the whole thing, the packets are defined in data_packets.h.

Edited April 13, 2016 by stibbons

[Gemini0915]

Dear Kerbonauts and Engineers,

Since days i try to get this running, but failed all the time. Trying all the available SW-Versions, different Hardware, different USB-Cables, different USB-Ports, changing the COM-Port# in the device manager. I'm using this on a Win7/64bit with KSP Steam-Version.

I don't know if that has been mentioned already in those almighty 58 pages here, my solution was so ridiculous simple, i just started the ksp.exe as an admin ... and the red, the yellow and the green LEDs are working !

Thank you all for your direct,indirect and unintentional help and the inspiration you gave me to build my own KSP cockpit

[zitronen]

On 13/04/2016 at 1:53 AM, stibbons said:

I add the packed attribute to the packet structs, ie:

struct VesselData {
  // snip
} __attribute__((packed));

That should be all that's required to run the demo sketch on a teensy as well, but I don't think I've personally tried it.

See my KerbalNavball sketch for the whole thing, the packets are defined in data_packets.h.

Great, nice that the simple fix works.

On 19/04/2016 at 6:42 PM, Gemini0915 said:

Dear Kerbonauts and Engineers,

Since days i try to get this running, but failed all the time. Trying all the available SW-Versions, different Hardware, different USB-Cables, different USB-Ports, changing the COM-Port# in the device manager. I'm using this on a Win7/64bit with KSP Steam-Version.

I don't know if that has been mentioned already in those almighty 58 pages here, my solution was so ridiculous simple, i just started the ksp.exe as an admin ... and the red, the yellow and the green LEDs are working !

Thank you all for your direct,indirect and unintentional help and the inspiration you gave me to build my own KSP cockpit

OK, that's new... Has anyone had this problem before? I wonder if it's a steam thing?

 

Also I just got my 1.1, working on updating it now.

Edited April 20, 2016 by zitronen

[zitronen]

Update 0.18.1:

Changes:

• Recompiled for KSP 1.1
• Included null reference fix from @stibbons

Download link:

https://sites.google.com/site/zitronfiles/KSPSerialIO_018_1.zip

I have only briefly tested this to see if it works, I wanted to get this out as quickly as possible. Please let me know if you find any problems.

Edited April 20, 2016 by zitronen

[stibbons]

2 hours ago, zitronen said:

I have only briefly tested this to see if it works, I wanted to get this out as quickly as possible. Please let me know if you find any problems.

I'm pretty sure all of the VesselData apart from the current/total stage count is OK. But I didn't really test any of the controls at all.

[Freshmeat]

That would be at what time in the night? You're a machine.

[Mattew]

Wau, we have 1.1 version?! Amazing Z !! Thanks. I cant play KSP without my nixie tubes  

Hopefuly they fix graphics soon and we are r2g

[Sputnix]

RE: 0.18.1

Switches/buttons for RCS / SAS / LIGHT / GEAR / BRAKE / ABORT are all working.
Throttle works (i have no 'controls' on my board yet).
Displays seem to show appropriate data (Mission Time, AP / PE, Time to AP / PE, Radar Alt);
Fuel readouts reflect those displayed in game.

The one thing I found didn't work was the 'stage' button... of all things 

Edited April 21, 2016 by Sputnix

[sarbian]

Reference to Staging should be replaced with StageManager (and .lastStage => .LastStage) and will require adding a "using KSP.UI.Screens" 

see : http://forum.kerbalspaceprogram.com/index.php?/topic/135179-info-on-how-to-convert-your-plugin-to-ksp-11/

 

[zitronen]

Thanks guys. Has anyone tried the overheat thing? They might have changed some thing with heat transfer stuff.

 

5 hours ago, sarbian said:

Reference to Staging should be replaced with StageManager (and .lastStage => .LastStage) and will require adding a "using KSP.UI.Screens" 

see : http://forum.kerbalspaceprogram.com/index.php?/topic/135179-info-on-how-to-convert-your-plugin-to-ksp-11/

 

Well, that was easy. Thanks a lot! I think I got the staging button issue fixed. I think the stage number should be too, I'll have a look at that tomorrow.

[Colray]

12 hours ago, Sputnix said:

RE: 0.18.1

Switches/buttons for RCS / SAS / LIGHT / GEAR / BRAKE / ABORT are all working.
Throttle works (i have no 'controls' on my board yet).
Displays seem to show appropriate data (Mission Time, AP / PE, Time to AP / PE, Radar Alt);
Fuel readouts reflect those displayed in game.

The one thing I found didn't work was the 'stage' button... of all things 

I take it that this does not include windows 10?

Thanks!