stibbons

Mod authors are not for-profit companies. Mod authors are not for-profit companies. Mod authors are not for-profit companies.

For my low-voltage power and signal connections, I'm settling on dupont-style connections. These sorts of connectors plug on to plain old header pins soldered to your controller at the other end. I wrote a long post about how I debounce inputs in my controller in the KSPSerialIO thread a while ago. It was intended to describe how to latch inputs to work with action group state changes, but most of it is still relevant here. And I'm not convinced that Keyboard.write() is the best option here either. But you should also check if the current button state has already been sent. I'd implement it something like // debouncedState is the reading we've taken from the button after debouncing // currentState is the reading that has been processed and sent to the PC if (currentState != debouncedState) { if (debouncedState == LOW) { Keyboard.press('X'); // or whatever } else { Keyboard.release('X'); } currentState = debouncedState; }

My strong feelings about the kerbalstuff shutdown aside, the hubris of this statement is pretty astounding.

It's a combination of two things: KSP loads all of its textures at startup. A lot of other modern games load textures on demand - they'll load the textures for the elements that are on screen, and unload textures that aren't needed. I recall reading once that this was done to work around problems with the on-demand loading system, possibly related to the other major problem. The DirectX renderer in Unity doesn't release textures from main memory after they've been blatted to the GPU. This is why you can frequently get decent memory savings by running the game with the OpenGL renderer. I don't know if either of these issues have been fixed in the 1.1 prerelease.

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.

It would be, yeah. Having the approaching vessel catch up from retrograde means it's in a lower orbit. Not much point boosting the Dragon to a higher orbit and then lowering it again once the ISS has caught up with it.

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.

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? 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.

"Tex Mechs Robot is not in the sudoers file. This incident will be reported."

Oh, so it is. I didn't even think to look at what was happening in Start(). I guess it's reasonable that plugin initialisation is now happening before the active vessel is loaded. Slightly annoying though. Well... kinda. I've got the plugin writing values to the log files, and they almost all look like sane values (there's two or three that are definitely wrong, and some that I'm not sure how to properly confirm). I have not yet had a chance to test talking to a serial connection, or inbound traffic. That's because at home I run OS X, Linux, and Windows 10, none of which work properly. So my plan right now is to: Update KSP on my Windows 10 install and test sending data with handshaking disabled. Test the cross-platform fork and make sure it's OK. Muck around again with testing the serial callback, possibly replacing serialnet with Psimax's serial class again.

Turns out this was because of a weird null reference exception that I'm surprised doesn't happen in 1.0.5. https://github.com/zitron-git/KSPSerialIO/pull/11 should fix it. The 1.1 build still doesn't include the serial assemblies, sadly. I'll create a feedback issue on the bugtracker requesting it, but am not holding my breath. I haven't yet been able to properly test if the serial callbacks work properly on Windows 10 and other OS, mostly because the included serial library doesn't seem to play nicely on my Linux machine at all. The plugin doesn't log any errors, but I've started doing what I can to validate that everything it outputs makes sense. I'll keep adding any problems I find as new issues in https://github.com/zitron-git/KSPSerialIO/issues , before seeing what I can do to fix them.

Sydney had the warmest March on record, and that seems to be continuing in to April. Today is sunny and 27 degrees, perfect BBQ weather. Be back later.

So the handshaking finishes successfully? That's a good start! I spent some time getting 1.1 running on my system this morning, expecting to at least get a feel for how much work porting KSPSerialIO this weekend. The community generated API docs I use are at http://anatid.github.io/XML-Documentation-for-the-KSP-API/ and should still be 1.0.5. I think the only source for 1.1 changes is the thread I've already linked. Also, welcome back!

My gaming rig dual-boots, but I built it with an eye for good Linux compatibility and boot Windows as little as possible. So, no, absolutely no intention of switching to running KSP in Windows.

The way that I read sarbian's plugin conversion guide, it'll at least need to be rebuilt to include references that are now in a different DLL. But after that, I think you're right and any changes that are required will be fairly minor. I do have steam, but doubt I'll have time to spend looking in to it until the weekend.

This is lovely. Could look great running on a raspberry pi and custom display setup.

Thanks! That's really nice of you to say. I do. The short version: They're 3mm translucent perspex that's been sanded/painted on one side, then etched and cut in a laser cutter. The long version I wrote up in a blog post.

The closest I've ever seen is 4-axis sticks like this, with standard analogue X and Y axes, a rotational Z axis and push button. I ended up using two small digital sticks in my controller, here's what they looked like in an early prototype enclosure: The right hand stick acts like a full 8-way controller for X-Y control, while the left hand stick has a gate restricting it to forwards and backwards movement only for Z control. (I'm thinking of replacing it with a 4-way gate to add rotational control) While the sticks are digital only, the potentiometer next to the right hand side there controls the intensity of the signal sent, a lot like engaging fine control mode with caps lock, but much finer grained. It's a setup that deliberately looks a little cumbersome, but works pretty well for fine orbital maneuvering.

The forum underwent a large-scale software migration at the end of November 2015. Any examples of weird characters before that are almost definitely because of minor bugs in the translation from the old database to the new. The screenshot you posted is an example of that. I'm not sure if there's been much activity fixing those bugs though. The best you can probably do is just report any posts you see like that, mentioning why in the report.

Because the monkey has been pulling some long hours lately, and is self-conscious about the bags under its eyes.

Where are you shopping? I'm yet to find anybody cheaper than MSY. And you can tell that they're not wasting any money on web design.

I've got five different devices logged in right now, and move freely between them without any problems. (for the record, they're two laptops running OSX, my android phone, and Windows 10 and Linux environments on my desktop PC)

Close enough!

My desktop machine is named thunk, and I built it last August specifically for running KSP. I was taking my KSP controller to demo at the local mini maker faire and my annual bonus had just cleared, so I thought I should treat myself to a new rig to run it on. i5 4690K Asus H97-PRO gamer motherboard 16GB DDR3 RAM GTX970 video card. And a new Antec P100 case. I ran it with a stock CPU cooler, overclocking the 3.5GHz i5 slightly. But a couple months ago I splashed out on a new liquid AiO loop. I'm finding the fans a bit louder than it used to be, especially since I run Linux whenever possible so go without fan speed control. But it's currently clocked to 4.8GHz, and I'm pretty sure I can get it to 5 with some more tweaking.

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.