faeryty

Thanks @maculator. I take it this means that to add a prop to an internal I have to export and replace the internal wholesale, and can't add props at runtime (when the view changes to the internal, for example)? The more I think about it, the more it makes sense, as you could get such cluttered internals if loads of mods were adding instruments or displays or whatever, and would require widgets for moving them around and stuff. Now I want to write a configurable internals mod that lets one arrange ones props as one sees fit. That doesn't sound like much work at all...

Sorry if I'm just being blind or this is covered in some easy to find tutorial, but looking over the RPM wiki and forum searches haven't really lead me to anything so I thought I'd ask here. If there are already resources out there please feel free to just point me in the right direction. Is there any easy way to add a prop to existing internals e.g. a stock pod, perhaps with something like a MM patch? I've prototyped a model and exported it as a mu file with part tools, and I understand how to write the prop definition for RPM purposes, but it's actually getting the model into the internal I don't understand. If I wanted to spawn an instance of the model in an internal scene, would I need to write a monobehaviour to spawn it, or is this something RPM or MM can handle somehow? If so, how do I go about specifying the model to spawn and it's location? I suppose if everyone is spawning props willy nilly, they could conflict with each other so I would understand completely if RPM doesn't support it. At the moment I'm just trying to familiarise myself with the various modding resources, tools and workflows to see what's available and possible, so it's no big deal if what I'm trying to do is simply not possible. I just thought after a couple of hours of looking around at various docs it was time to ask.

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

*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*

I've given up on point to point soldering now. I have some copper clad and etchant on their way, and have designed my PCB in fritzing. So I'm going to have a play with toner transfer and etching soon. I now have a concept for my controller though. I'm going steampunk. Steampunk TARDIS console to be specific. I have various ideas floating around in my head, elements that have crystalised into solid plans include lots of nixie tubes. I even have my first set of IN-14 tubes to make a steampunk version of my altimeter. I'm also planning a peripheral DSKY with a load of little nixies, which will plug into each panel (6 of them of course, given it's a TARDIS console). Panels I'm planning are listed below, subject to a lot of change. I'll be making them one at a time, so things may well get shifted around a lot. Still, it should be fun. Main flight controls ---------------------- Altimeter - nixie tubes SOI Display - I have a plan but no idea how to describe it. Basically a rotating display attached to a servo. Throttle - large lever Stage - not sure yet - possibly some sort of flush like device, possibly a foot pedal. Possibly both, connected mechanically. Flight stick - undecided as to how to approach it DSKY port Steam gauges for useful things like fuel remaining, battery status, velocity. I say steam gauges. I'd love to actually run them on compressed air, but for now they'll just be pretty ammeters mounted on copper tubing. Docking --------- Array of 6 levers for translation and transformation. Docking Port Alignment Indicator - I'm dreaming of a small monochrome CRT with a display kinda like the eponymous app. Some edgewise meters for telemetry. DSKY Port Auxilliary Systems --------------------- Atmopheric flight -------------------- Roving -------- Panel 6? --------

I've been thinking about how to kludge together my own navBall today too, although as I have no idea how the real one works (your explanations flew straight over my head) I'm starting from scratch. My first thoughts were comparing it to a mouse/trackball but my investigations soon brought me to this ball balancing robot. Turn it upside down and you've got a controllable ball with 3DOF. I still need to work out feedback to compensate for any drift on the ball - my first thoughts are magnets and hall effect sensors, but I have to learn more about electromagnetism and I have no idea if this plan has any merit to it whatsoever, especially on the scale I'm planning. I only had this idea today, and I'm sure it's full of fatal flaws. So before i buy a load of omni directional wheels and stepper motors tell me - why won't it work?

Thanks for the info. I shall have to seek out 12v wall wart. Surely, surely I have one lying around the house somewhere. In other news, I officially hate soldering. I evidently cannot think in mirror images or follow my carefully drawn out circuit diagrams. I think I need to invest in some acetate and coloured markers for it so I can draw it, colour code the wires then turn it over and not end up desoldering half of my wires when i realise I've reversed some of them but not the others. Or maybe Ill just get some supplies to etch my own pcbs.

I love this throttle. I'm gonna have to develop some woodworking skills to make something similar. Have some rep, good sir.

Okay, so this is where my complete lack of electronics understanding comes into play. Each segment of my 7seg displays require around 20mA. So a fully lit digit, i.e. an 8 ignoring any decimal points for now, 140mA. Am I right in thinking the max7219 only actually lights one digit at a time, just looping through them so quickly that they look as though they're constantly on? My understanding is that the +5V pin of the arduino can supply up to 500mA. Given i'm currently powering by USB and that itself can only supply 500mA, the max current sourced from the +5V pin is less than that nominal value since I assume the atmega and other components on the arduino also consume some current. If I want to hook up all three 8 digit seven segment displays, that would require 420mA being available, plus around 20mA x 3 for the multiplier indicators, and another 20mA for the mode indicate. There's 500mA right there. I'm definitely going to need some external power, but have no idea where to start with that. I have absolutely no understanding of elementary electronics but I don't want to fry my circuits. I guess I need to take into account voltage of a power supply, max current and AC/DC (and I assume DC is what I need for the vast majority of things) and but what else? Do I need to do anything special to protect my circuits if I hook up an external battery for example? Do I need to do anything special because there will not only be an external power supply but a usb as well? I'm just gonna store a link to this here, because I want to be able to reference it. Good old stack exchange, a developers best friend.

Thanks for the replies I have some slide pots sitting around that I'll probably use for a throttle, but I do have an off the shelf HOTAS that I can use for input for now anyway, so at the moment I think I'm on a display all the telemetry kick and will come to controls later on. Actually no, now I've understood how a rotary pot would work as a throttle that's what I want to do. Note to self: krewmember has the right idea. I vaguely have a design for my first panel, which will have 3x 8 digit seven segment displays, LEDs for K, M and G for each of those displays (until I get some 16seg displays that I can use to display the actual letter) and a switch or 3 to control what mode the panel is in. Planning on having 3 modes that match in game - orbit: showing Alt, Ap and Peri, surface showing rAlt, vert speed and time to suicide burn, and rendezvous/docking showing distance, relative velocity and something else. That's the plan for this first panel at the moment. But I suppose software can always change that without too much hassle...

Just wanted to add my thanks to zitronen for this plugin. It's given me the motivation to actually learn some electronics and experiment with the arduino. I'm just getting started but I had a play around got an altimeter working on 7segment LEDs quite straightforwardly. Next will be apopasis and periapsis, and then something more adventurous. I may also get around to learning C# and experiment with breaking modding KSP too, because I don't want to come running and bugging you every time I want something that's not implemented in the plugin yet and if I can help contribute then great. But that's a way off yet I expect and so I'll respond to your call for a vote for what to add in next! I add my vote to the people wanting TWR or the values needed to calculate it for ourselves. Also if I'm reading the first post right, you don't currently output deltaV remaining or deltaV for the current stage. They could come in handy too, though I don't have any direct plans to use them and without looking into what the game exposes I imagine they could be a pain to calculate. I suppose outputting dry mass total would be sufficent for stage deltaV and would help with TWR but would still leave you looping through all engines, and total deltaV would also involve looping through all parts. tl;dr: great mod. thanks for the work. TWR next please.

Just started my own attempt at a simpit. Not very far yet: but I feel happy that I'm on the right track. I at least have an altimeter that reliable reports my height above sea level.... so long as that is less than 10Mm at the moment. I must get round to getting a 16 segment display so I can show an SI prefix and scale it.

So having not played KSP for months due to lack of time, I decided to give myself some motivation to do so by building my own control panel/simPit (we'll see how far I get as to what to call it). I'm really just approaching this hapharzadly with no real plan. I've collected a bunch of components from ebay ranging from necessities like resistors and potentiometers through 7 segment and thumb-joysticks up to gLCD. Not really got any concept of how I'm using most of it yet. I also have clones of both arduino uno and arduino mega to drive things and will be using zitroenen's plugin to drive things. And have some dibond to make my panels from. I'm a developer by trade, mostly a full stack web dev but do a bit of everything using various languages like C, python, Delphi and java for my job so I'm reasonably competant at switching between languages and picking up new ones. On the other hand, I failed electronics in school so this is going to be fun. Here's the current state of my project: Yep. It's a breadboard with two x 4 digit 7 segment displays driven by a max7219 that shows altitude. I feel accomplished. And here's the link to the github repo of my code.

Yeah I was wondering why it didn't kaboom if it were the case, but my knowledge of aerodynamics and how they work in ksp in particular is nonexistant, so I thought maybe velocity was related to AoA/Lift. I should read up on things before making half-thought out suggestions. Well that theory is certainly put to bed.

could it be that your central engines are skimming along the ground and so the vessel can't pitch up any further? When you've got the girders there's more clearance.

Thanks for the welcome. In good news, Jeb is safely back at the ksc. I spent all evening practicing orbital rendezvous, and think it was largely a fluke that I managed to get him. But yay! I might be a little bit obsessed already.

Great idea. Thanks for the tip.

With Jeb stranded in orbit, Bill is the first Kerbonaut in my crew roster, and he almost invariably ends up in the only pilot seat of every mission I launch, despite the fact that I have hired other pilots. Even when I've changed the crew in the VAB, if for any reason I come out of it and save the vessel, if I load it up again Bill has usurped my nominated pilot. Is there any way to change this default?

Hi Everyone, In the middle of last week I downloaded the demo, bought the full v0.90 over the weekend, and I'm already obsessed. I feel I'm progressing fairly well - already managed to strand Jeb in orbit (planning on rescuing him tonight, though we'll see how that goes), make an unmanned munar landing (albeit a bumpy one) and have an atmopheric jet plane that handles reasonably. But I thought I'd pop by here and share in the love. My names Ty, by the way