Antipaten

Some pictures of my project can be found at: https://picasaweb.google.com/100548400606454481782/Kerbal?authuser=0&feat=directlink I've also started writing a series of blog articles on this forum that describes my projekt more in detail: http://forum.kerbalspaceprogram.com/...-and-enclosure They might give you a better idea of what I'm building. Joysticks use your mod, as do stage abort, CG 1-10, RCS, Brake Light, SAS etc. Come to think of it, if you could add support for Action Groups Extended it would also solve the problem, but that would increase the packet size quite a bit over your 255 byte limit. This is the current mapping of switches to key combinations and action groups so far (I'm using Action Groups Extended): [TABLE] [TR] [TD][/TD] [TD][/TD] [TD=colspan: 2]Key combination[/TD] [TD=colspan: 2]Action group[/TD] [/TR] [TR] [TD]Power & Com.[/TD] [TD][/TD] [TD]Up[/TD] [TD]Down[/TD] [TD]Up[/TD] [TD]Down[/TD] [/TR] [TR] [TD]Reaction wheels[/TD] [TD][/TD] [TD]RCtrl + 0[/TD] [TD]RCtrl + 1[/TD] [TD]20[/TD] [TD]21[/TD] [/TR] [TR] [TD]S/A[/TD] [TD][/TD] [TD]RCtrl + 2[/TD] [TD]RCtrl + 3[/TD] [TD]22[/TD] [TD]23[/TD] [/TR] [TR] [TD]F/C[/TD] [TD][/TD] [TD]RCtrl + 4[/TD] [TD]RCtrl + 5[/TD] [TD]24[/TD] [TD]25[/TD] [/TR] [TR] [TD]Radiator 1[/TD] [TD][/TD] [TD]RCtrl + 6[/TD] [TD]RCtrl + 7[/TD] [TD]26[/TD] [TD]27[/TD] [/TR] [TR] [TD]Radiator 2[/TD] [TD][/TD] [TD]RCtrl + 8[/TD] [TD]RCtrl + 9[/TD] [TD]28[/TD] [TD]29[/TD] [/TR] [TR] [TD]Bat1[/TD] [TD][/TD] [TD]RShift + 0[/TD] [TD]RShift + 1[/TD] [TD]30[/TD] [TD]31[/TD] [/TR] [TR] [TD]Bat2[/TD] [TD][/TD] [TD]RShift + 2[/TD] [TD]RShift + 3[/TD] [TD]32[/TD] [TD]33[/TD] [/TR] [TR] [TD]LoGain[/TD] [TD][/TD] [TD]RShift + 4[/TD] [TD]RShift + 5[/TD] [TD]34[/TD] [TD]35[/TD] [/TR] [TR] [TD]HiGain[/TD] [TD][/TD] [TD]RShift + 6[/TD] [TD]RShift + 7[/TD] [TD]36[/TD] [TD]37[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]Engine & Chutes[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]Aero on/off[/TD] [TD][/TD] [TD]RShift + 8[/TD] [TD]RShift + 9[/TD] [TD]38[/TD] [TD]39[/TD] [/TR] [TR] [TD]Aero rev[/TD] [TD][/TD] [TD]RCtrl + RShift + 0[/TD] [TD]RCtrl + RShift + 1[/TD] [TD]40[/TD] [TD]41[/TD] [/TR] [TR] [TD]Intake1 Toggle[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]9[/TD] [TD][/TD] [/TR] [TR] [TD]Intake2 Toggle[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]10[/TD] [TD][/TD] [/TR] [TR] [TD]Main on/off[/TD] [TD][/TD] [TD]RCtrl + RShift + 4[/TD] [TD]RCtrl + RShift + 5[/TD] [TD]46[/TD] [TD]47[/TD] [/TR] [TR] [TD]Main mode[/TD] [TD][/TD] [TD]RCtrl + RShift + 6[/TD] [TD]RCtrl + RShift + 7[/TD] [TD]48[/TD] [TD]49[/TD] [/TR] [TR] [TD]Sec. On/off[/TD] [TD][/TD] [TD]RCtrl + RShift + 8[/TD] [TD]RCtrl + RShift + 9[/TD] [TD]50[/TD] [TD]51[/TD] [/TR] [TR] [TD]Sec. Mode[/TD] [TD][/TD] [TD]RCtrl + G[/TD] [TD]RCtrl + H[/TD] [TD]52[/TD] [TD]53[/TD] [/TR] [TR] [TD]Drogue deploy[/TD] [TD][/TD] [TD]RCtrl + I[/TD] [TD][/TD] [TD]54[/TD] [TD][/TD] [/TR] [TR] [TD]Drogue cut[/TD] [TD][/TD] [TD]RCtrl + J[/TD] [TD][/TD] [TD]56[/TD] [TD][/TD] [/TR] [TR] [TD]Main chute deploy[/TD] [TD][/TD] [TD]RCtrl + K[/TD] [TD][/TD] [TD]58[/TD] [TD][/TD] [/TR] [TR] [TD]Main chute cut[/TD] [TD][/TD] [TD]RCtrl + L[/TD] [TD][/TD] [TD]60[/TD] [TD][/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]Left hand control[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]Ladder[/TD] [TD][/TD] [TD]RCtrl + N[/TD] [TD]RCtrl + U[/TD] [TD]62[/TD] [TD]63[/TD] [/TR] [TR] [TD]Docking Toggle[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]7[/TD] [TD][/TD] [/TR] [TR] [TD]Cargo Bay Toggle[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]8[/TD] [TD][/TD] [/TR] [TR] [TD]Airbrake[/TD] [TD][/TD] [TD]RCtrl + RShift + J[/TD] [TD]RCtrl + RShift + K[/TD] [TD]68[/TD] [TD]69[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]Mission Specific[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]AG-01[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]1[/TD] [TD][/TD] [/TR] [TR] [TD]AG-02[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]2[/TD] [TD][/TD] [/TR] [TR] [TD]AG-03[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]3[/TD] [TD][/TD] [/TR] [TR] [TD]AG-04[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]4[/TD] [TD][/TD] [/TR] [TR] [TD]AG-11[/TD] [TD][/TD] [TD]RCtrl + RShift + 2[/TD] [TD]RCtrl + RShift + 3[/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]AG-12[/TD] [TD][/TD] [TD]RCtrl + RShift + N[/TD] [TD]RCtrl + RShift + U[/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]AG-13[/TD] [TD][/TD] [TD]RCtrl + RShift + G[/TD] [TD]RCtrl + RShift + I[/TD] [TD][/TD] [TD][/TD] [/TR] [/TABLE]

My device will be able to send keyboard commands even if I'm away fishing as it will eventually contain a small autopilot able to make launches and landings. Even if I've not yet implemented the automatic features, manual control can be destructive if it sends commands to the wrong program, and I am a heavy multitasker when using computers. I'll try to give you a use case: I'm playing KSP on my center screen, approaching Duna. On my left screen I have a web browser showing data on Duna so I know what atmospheric height it has (OK! I have bad memory. Just accept it for now.) Om my right I'm writing the next Great American Novel of my generation (not very believable as I'm not from the US and a mediocre writer at best, but you get the point, important stuff and such). As all great authors I haven't made a save for a couple of hours while writing the most profound passage ever put into words. Oh ooh! :-( I wait until I hit the atmosphere and throw the airbrake switch to slow down. Nothing happens in Kerbal, but my word processor, which has focus, quits without saving and Valentina becomes a screaming fireball going down while I curse all powers in the universe. Outcome: Player ragequitting, unistalling the game and using office chair to demolish the control panel. If I had a bit in KSP Serial IO that indicated if KSP had focus, I could program my control panel not to send the keyboard command immediately but instead sound the master alarm and indicate a computer failure. That way my novel would still be intact waiting for me to make a save. I will not be freaking out, and I can bring focus back to KSP. When my control panel notice that focus is back it can send the keyboard commands and shut off the alarm. Alternate outcome: Mission successful, happy player, Nobel prize in litterature, funny postings on forum.

I know about telemachus but i haven't tried it yet. You gave me a thought there actually. If I got a small screen and make it part of my simpit build I could use it to show telemachus data, maybe a little navball and some orbit rendering, maybe with a Raspberry Pi running the browser. Hmm... have to think about it. Thanks!

That would still not solve my problem of avoiding to send the keypresses to the wrong program. I run KSP in windowed mode as I have three screens om my desktop. I like to have the wiki on one screen and make notes and calculations on another while playing. If there would be a working solution for having mapmode on an alternate screen, I would hook up a fourth one in an instant. You can't have too many information screens in a space program. :-) Sending keypresses with an Arduino Pro Micro is trivial and a lot more compact and flexible than using av keyboard PCB. I use triple-key commands to get a bunch of key combinations that interfere as little as possible with normal Kerbal keyboard control. I want to retain the ability to fall back on flying with keyboard too until I feel that my simpit is space ready.

It makes perfect sense and I've already done that, whats left is all the extra goodies I want to connect to swithces. I want to accurately control open/close docking port, intakes and cargo bay too on two-way switches and that can only be done by flipping AG bits in KSP Serial IO, not by keyboard commands. So I used four of the ten custom bits for that. I would love to get full support of Action Groups Extended in KSP Serial IO but as Zitronen seems to have set an upper limit to 255 byte total I guess that's out of the question atm as it would require another 32 bytes. I want MOAR SWITCHES! :-) Its actually less cumbersome to map switches to bits. All it takes is a single line of C to map, somewhat like connecting a wire, whereas making keyboard commands needs about six code lines including a delay.

The reason I didn't make a cutout in my desk is that I use it for more than playing Kerbal (?!?! gasp!) and need the surface from time to time. If I had the space to build a permanent simpit I would, but my apartment is a bit too small for me, my wife and all our hobbies. I actually don't know what keyboard it is. It's a PS2 keyboard I found in the scrap pile at work. It's completely functional as we're phasing out all PS2 equipment in favour of USB. I fell in love with it immediately as it had the right lack of color and measured almost exactly 45x15 cm which was an even multiple of my module size. I have a few more detailed pictures in higher resolution but the upper limit of what you can see is set by the optics of my old phone. https://picasaweb.google.com/100548400606454481782/Kerbal?authuser=0&feat=directlink I've made a few design decisions that didn't work when testing so I'm going to make a few changes and print new front panels for the modules. One change is to use AG7 - AG10 for fixed actions as some parts only has a toggle option. In those cases I can't use keyboard commands as there is no way to assure that the game is synced to the two-way switch. I will also repurpose the switches for RTG (which has on/off actions that don't do anything) and GC power to instead fold and extend the new radiator arrays. I might also add an arming light to the chutes section. The front panels are printed on transparent slides and I glued a paper as diffusor to the acrylic front of the modules as I planned to add lighting inside the box for backlights. The problem is that I had a lot of problems with static charges in the printer during printout causing sparks that spread out the toner before fixation. The next set of fronts will be plastic laminated paper printouts instead. The plan for backlighting doesn't work anyway due to the amount of components on the back of some panels. There would be just to many shadows to get a good illumination. I'll leave the backlighting for later when I feel like doing a full redesign of the modules and then integrate in the module itself instead.

Hi Mulbin! If you feel like it you can add me to the collection of simpit projects. I spent part of this summer tinkering on it and there's still a lot to do. Joystick and most of the switches works as intended. Still a lot of stuff to code, such as; display modes, guidance computer functionality. Made a couple of assumptions that proved to be misaligned with reality, so I'll need to reprint some front panel stuff and change a few lines of code in some of the modules. I started a blog (one entry so far) documenting it for those who might be interested in what I'm doing. There isn't much yet, but if all goes as planned there will be. Project: K-42 Blog: http://forum.kerbalspaceprogram.com/entries/3701-K-42-KSP-console

Hi Zitronen and everybody else too! When using an Arduino based on Atmega 32u4 it is possible to send keyboard commands when throwing switches and pushing buttons. One thing that messes things up is that I have no way of knowing if the key sequence actually is sent to KSP as I have no way of detecting if the KSP window is in focus or not. This may mess things up a lot when control keys are sent all over the place, writing in my editors or autosurfing the web. It would be great to have in the mod is a simple flag that tells if KSP is in focus, and if possible also if the key press is received by KSP as a keyboard command (as opposed to entering numbers into MechJeb for example). I guess getting this wish fulfilled might be a lot more complicated than it sounds as it crosses the border between Unity and the operating system as well as between KSP and a diverse variety of mods. Anyway you decide, I love this mod as it makes it possible to create a much deeper immersion in the game than a simple keyboard, mouse and joystick combo ever could.

But all that reasoning was much later during the construction of the Kuran Space Shuttle. In the old days during the Kerpollo program they used regular 60W light bulbs. The engineers assumed it would be much better to have a light source that could be easily attained from any nearby store, eliminating the weight of keeping spare bulbs in the space craft. Needless to say, none of the original Kerpollo engineers was transferred to the Kuran program. They still do public appearances but once you have heard them say "Do you want fries with that" a few times, you'll be bored to tears by them. Jeb became legendary as the first (and only) kerbal who managed to survive a night landing with blacked out instruments. He actually doesn't know how he did it himself as all he could do was to throw a few random switches while bitching in the dark. Ahhh, those were the good old days...

If you're using a stereo 3.5 mm jack or 3 slip rings you can discard the optical communication gizmo completely. The simplest form of 1-wire communication you can do is to connect TTL-serial to RX on the controller inside the ball using the third connector to get one-way communication. You don't need two way communication or error correction if you send the positioning data as a constant stream and filter out values that differs too much from what could amount to a reasonable rate of turn/roll. If there is a glitch in communication it will in worst case show like a small shudder of the ball and the position is corrected almost immediately at the next successful transmission.

You absolutely win!

With your TTL skills you actually don't need computers. Logic IS good enough. After all a computer is built from logic circuits and a program is just a bit pattern that is shifted through a bunch of gates, multiplexers and demultiplexers. Both AD and DA converters can be bought as individual components or built from scratch using simple resistor ladders and OP-amps. Computers makes complex logic easier than using discrete logic, but this is a hobby. A hobby doesn't have to be easy, it have to be fun. There is a fun value in building your own stuff from TTL and feel that Apollo feeling. I guess using RTL would be the ultimate Apollo feeling, but I don't think its easy to find a seller nowadays. I have a few RTL circuits that I scrapped out of some old electronics 30 years ago, but those are the only ones I've ever seen. PS. I live in northern Sweden. We have similar seasons as you have in Minnesota (guess that's why so many swedes emigrated there). Instead of dust season we have a two month rain period and the mud season is also two months. In between those we have a two month insect swarm period when we have to impregnate ourselves in poison to survive outdoors. Travel is all but impossible during the less cold months as the roads are dug up and what's left of them are filled with slow moving caravans constantly moving between identical beaches where they sell identical ice cream cones. In other words Kerbal season is all year round here too.

The language most uses to program Arduino is basically standard C and you only have to know a subset to get going. If you've done any coding in C and have a basic knowledge of electronics, you'll be reading potentiometers, playing sounds, and blinking LED:s within the hour. It took me a couple of hours more as I my C knowledge was a few programs in university 15 years ago and I hadn't built anything digital in 25 years. If you don't know how to do something it is almost always possible to find program libraries, code examples and explanations on the web. The world of digital electronics have changed during the last decade. I also started out thinking about shift registers and latches for serializing data to conserve Arduino IO-ports, but when I realized that I could buy Arduino Pro Mini for $4-5 apiece from China I realized that it is simpler to add more computers and use an I2C interconnect bus than to build with TTL circuits. My newly started simpit project, should it proceed further than planning, will be modular with a main Arduino Pro Micro that handles most of the logic, acts as I2C master, USB serial and keyboard emulation. Every module will be equipped with its own low cost Arduino Pro Mini communicating with the central unit using I2C as a slave unit. The theoretical upper limit is 119 modules with a total of 600-2000 lights, buttons, potentiometers, analog instruments, digital displays, speakers, switches and other parafernalia. There's really no real practical upper limit to how much IO you can have. Just buy MOAR KOMPUTERS. :-) - - - Updated - - - I really must go dumpster diving for analog instruments. EDIT: I don't know why, but I remembered erroneously that the first 8 addresses were reserved, they are not. It's possible to use 128 slave devices as no adresses are reserved and the master doesn't use an address. In other words, my original maximum number of 119 modules is too low.

You need to build a complete KSC control room with a Kerbin map on the wall. Those 10" displays are perfect to show position and mission time. There's a lot of people building cockpits, but you got the stuff for Kerbin Control too. Plenty fun for you and five to ten friends. (where do you live by the way?) :-)

Tested with 1.00. Still working as intended. Resilient Mod this is. Happy player I am.

I'm afraid I have to make a correction to my earlier statement. I'm not sure what mod (as I have many) caused the bug but something increased the thrust by three or four and the Isp tenfold. After a few updates of stuff I found that the engine is not as overpowered in game terms as I initially thought. It is however still very overpowered as for realistic physics, but not in the kerbophysical sense. :-)

I'm sorry if this has been diskussed already. There´s over 600 pages and I have probably missed some. There is a problem with the LARJ engine being really overpowered. It is possible (and not very hard) to build an SSO rocket with space for seven kerbals (!) that can start from Kerbin, go to Eeloo and return without refuelling, twice (!!), by using the LARJ engine. Furter more, the amount of energy needed can be provided by batteries alone during ascent through the atmosphere (I use around 3000 units of electricity for six engines). (Edit: It was a bug in my installation that increased thrust and Isp ALOT. The rest of my reasoning is sane however. At least as far as I myself can tell, but how do you gauge your own sanity???) I think there is a misunderstanding about the limits of resitojet augmented engines that needs to be adressed. A fairly normal resistojet thruster has a thrust of around 0.5 N using 750 W of Power. This can easily be increased to 1 N by using chemical combustion of around 1 kW and then heating it further with 750 W of electrical power. The problems are that there is an upper limit to the temperatures you can handle as well as how much propellant flow the resistojet can handle. Let's first make two three assumptions that will break immediately when applied to real world physics. 1. There is no upper limit to how hot emission gases we can handle in the resistojet. 2. The temperature increase is linear to the amount of electrical power we use for heating. 3. The exhaust of a chemical rocket has the same molecular weight as hydrogen gas. :-) If, under those assumptions, we have a resistojet that produces 0.5 N at 750 W we can built a 25 N thruster using 37.5 kW of electricity. We could do this either by heating 50 times as much reaction mass or by heating it to a temperature that is about 50 times higher (creating a massive increase in Isp). If we have a chemical rocket of 0.5 N using we could heat that exhaust gas and double the exhaust velocity to produce 1 N thust by adding 750 W of resistojet augmentation. To make a 18 kN resistojet with an Isp of 600 s, we would then have to provide an amount of chemical fuel that provides is burned at a temperature of around 4000 K to achieve the first 400 s of Isp, and then heat it 50% more to 6000 K to get our 600 s Isp. That means that we will have to provide around 6 kN extra thrust using electricity which equates to around 12 MW (!) of electrical power. When applying real world physics we will probably melt the parts of the engine that cannot be cooled (the resistor), we will further more have a much heavier exhaust than hydrogen, for example water, and even with all that not taken into account we need to have batteries capable of providing 12 MW of power for three minutes to get to a low Kerbin orbit. In short. The engine has far too high thrust and/or too low electrical consumption. As the engine is based on, and balanced against (the also severely overpowered) RLA resistojet, we cannot make it realistic without making it obsolete in game terms. What could be done is to reduce the thrust increase of the LARJ mode to 12 kN and not reducing the electrical need compared to the normal resistojet mode (it is halved now which there is no reason for). It's still hilariously OP, but that problem has to be adressed in the RLA mod too. I haven't play tested the change but I guess it would require more than double the battery power to get to orbit, and probably halve my delta-V. I can still fly my SSO to Eeloo and back, but only once.

Made some testing with 0.90 and it looks like it still works fine. Didn't check the logs though...

It doesn't work in 0.90. Tested in vanilla game with only toolbar 1.7.7. Window doesn't open when icon is clicked

I have this strange bug when staging. If I have two or more boosters it only stages one of them each time I press space, even though are all in the same staging group. When I remove KerbQuake staging works normally, jettisoning all boosters at once.

There might not be much of a high priority demand but there are some genuine user interest, mine as an example. As I'm not killing nearly as many kerbals as I hire, I really could make use of a non-lethal way of getting rid of the excess. I'm a bit squeamish about blowing them up unnecessarily, and it costs money too nowadays. :-)

Made a quick test with 0.25 and it works!!! Yay! \o/

Thanks a lot. I've only had time to test it against my test cases so far and there were no glitches. I'll let you know if it breaks some of the weird contraptions that I usually build when playing. As for the effect on cancer in mice, I cannot confirm your results. All my white mice look like large lumpy raisins so I think it's to early to expect that you found the cure.

I've found a (couple of) bug(s) in TweakableEverything that is quite annoying (to me at least) that breaks staging/fairings on the LV-N atomic engine. How to reproduce A: Build a rocket with an LV-N upper stage and a TR-18A decoupler (probably any other decoupler too but this is the one I used). Launch. Stage to upper stage. The stages will separate and the LV-N vill fire, but the shroud will not sepate from the engine. How to reproduce B: Build a rocket with an LV-N upper stage and a TR-18A decoupler. Remove shroud from LV-N engine. Launch. Stage to upper stage. The stage will NOT separate but the LV-N will fire anyway. It is possible to right click on the decoupler to fire it but staging but it cannot be activated by staging. Tested with: KSP 24.2, 32-bit, clean install Windows 7 Pro, 64-bit TweakableEverything versions 1.3.1 and 1.4 Hope it's solvable as this mod is one of my (many) must-haves. :-)

How about Koins? :-)