cyberKerb

Thanks for the heads up. I'll keep an eye on ram as I go. Ill also research the thread again to see if anyone mentioned extenders, I might of missed it the first time around. From what Ive read, they are supposed to be able to run I2c > 1 MHz, even though the Arduino can't. But, I've yet to have any experience with those chips yet so if anyone has practical knowledge about them being slow, I'd love to know more.

OK - I'm done lurking on this thread... I've pulled the trigger on some ebay items and broken out my trusty Uno to start planning a cockpit controller. Just wondering if someone could help straighten some thoughts I'm having while planning a build. I think I'm trying to solve problems that don't exist yet. You know.. the Kerbal way to troubleshooting, sort of like City Lights before Cities. I've recently gotten on the road to doing a controller/cockpit for KSP and I'm OK with coding up Arduino scripts and interfacing hardware to the point that they work. But I also know that I lack a lot in the design knowledge to properly layout the cockpit. I'm trying to wrap my head around how to balance out the design of the KSP controller with what I want to be available. As I understanding it with this KSPSerialIO mod, the Arduino would be doing two primary jobs: updating any output such as LED / indicators / digital displays triggering events in KSP based on input from specific buttons, joysticks angles, switch states At any point is the Arduino acting as a Keyboard emulator and sending a Key commands that would be read by KSP? I ask as I'm wondering if I should split the processing across two different Arduinos? i.e One that acts as a keyboard/joystick that talks to KSP via the standard Joystick USB connection, the other dedicated to just updating the indicators / displays that is sent from KSPSerial IO. I'm not sure how much processing will be needed to handle the KSPSerialIO stuff. Only just starting the design, but so far I'm up to 45 x 7-segment digits, 8 analog dials, 50 toggle switches / buttons, 13 rotary dials, 40 status indicators. I'm planning on using some I2C MCP23017 IO extenders for the arduino for the shear number of buttons and levers. I've also specced out that I'll need about 6 MAX7219 for the 7segment displays. With all this, I'm sort of going for a 1960's ASET MK1 landing can-alike. I've also setup a shell mod for executing actions that are currently not actionable in the standard setting menu. As an example, I've got a parking break action assigned to Alt-N (why? it was next to 'B' alright. it made sense to me at the time! ), and have a button that sends that command to the PC to activate the parking break in KSP. So I expect that I should be able to have a "Deploy / Retract Solar panels" button that would send an obscure custom Keyboard command (ALT-* maybe?) and my mod will do similar code to All'Yall / ALCOR and just open all solar panels on the vessel without an action group needing to be assigned at all. The downside is I won't know the exact status of the panels unless I add extra packets to KSPSerialIO, or use an ActionGroup. Reasons for not using an AG is because I want to avoid AG's for stuff that I can pickup automatically in the code, (eg Solar, Radiators, antennas, scanners, etc) so I can leave most of them for stuff on a mission. Is there any benefit to letting the PC handle the joysticks and as many buttons as I can shove onto it so it doesn't have to be processed by the Arduino? I've got a UnoR3 and while I know it's not the fastest out there, I still wanted to try to push as much game data to it as I can to keep displays and indicators updated. Or would my main bottleneck be the time it takes for the Arduino to process each incoming packet and control input doesn't really factor?

Yeah, spring return is in the plan. As for the click, the BBQ lighter investigation is worth a look. I've checked out a few breakdown on YT they were salvaged for the igniters proved interesting. Thanks for the suggestion. Actually - that search lead me to a interesting mechanism playlist: Extra Geek time: While looking for a lever, I found the aliens airlock lever and was reading about a prop group that traced the red piece to an old CRT TV grill.

I'm in the beginnings of gathering hardware for my control panel and I'm looking for inspiration on one element in particular. I've got a number of ebay orders incoming, so it's only just starting. I've seen a few panels where the 'stage' command is just a push button and for some reason I have a quirk where that's never sat well with me. Yes, I've used the spacebar forever, but when I envision using my panel, I see a pull lever of some sort recessed into the upright part of the panel that I have to pull to activate the next stage. I'm thinking doing a DIY version of "something like"TM the below pictures, although I've not decided on whether the handle will be vertical (left pic) or horizontal (right pic). It will probably end up being a hidden push button behind the panel that the unseen part of the lever would hit to activate, but the UI would be a pull action that would come out ~20-30 degrees from the panel and a spring return. If I can work out how, I'd love to add bit of a mechanical "clunk" (rather than a wimpy 'click') at the end of the lever action to indicate it did something, but still have a smooth return action and not have to go over the clunk again.. I had a passing thought to kluge/mount a ratcheting socket wrench as the lever, but decided the tinny clicking wasn't quite what I was after. Anyone done anything like that idea? Feedback is welcome.

I was looking for some reference photos for a KSP control panel and stumbled over these beauty shots. They look a lot like your REKT retro caps Just thought you'd interested to see when your model might look like if it was done in very high res. Source here

Ah, yeah - I see it. Found a pic where the pin is a lot clearer: (from this site) and would be just something easily aquired from a hardware store. awesome! I've been doing my head it trying to find a solution to that all day. (I added a few other options in the post above. And yes, the original FDAI is an insane piece on engineering that I'm jealous that you have one. As an aside, in my search, I also came across this gorgeous piece of 3d printing.

Wow - that's some awesome progress! Are you still having closed loops for all three steppers? Here hoping you got some warmer weather soon, although not too soon I'm enjoying summer here at the moment. With your dome mounts, does that mean you'll have visible screws that go from outside and screw into the mount inside the ball? My other options were to either have a nut at the top of the dome and screw it on to the shaft. That idea is me least favorite due alignment issues trying to get screws on either side to line up, also a risk of the screws loosing, but it would be the easiest solution. The other one that ran through my head the other day when changing the bulb in an oyster ceiling light (but haven't thought it through yet) was using a pair of ball pins to fix the alignment issue, but still need to think of not too happy with the possibility of it flying off as I'm not sure of the holding force of ball pins. Looking for inspiration, currently trying to work out how the hemispheres are connected on this: But failing that, the last idea I had was to notch the end of the center shaft and slide the hemisphere into place, secured with an e-clip. still need to work out something to stop the dome rotating

Hey @NeoMorph Just wanted your thoughts on how to connect the Non-fixed hemisphere that lets you repeatedly get back into the guts of the ball? So far, my plan involves the dual shaft NEMA8 stepper (used for pitch) with 1 hemisphere permanently glued to a wooden disc that the shaft will connected to via a flange screwed onto it. However, I'm wondering if there another way than securing the other side.with the 4 x rod Neodymium magnets bought for that purpose to act as a screwless flange. I'll need to ensure the connection doesn't move when under rapid rotation, but I'm just worried it'll separate when the y axis is spinning. Also - how's your learning curve going with the CNC?

If you added surface attachment, you could also grab the AKI Power strip (from Pathfinder) and attach that to the Sunflower. Then you'd have 6 ports on the thing. It's easy enough to just grab the models and part config and model if that's all you want from the pack, but you'll need to use WBI folder or edits the cfg file to the correct path.

Hi @WuphonsReach - is it possible that you could update your copy of the Poodmund spreadsheet you were working from to reflect the current status of the mod? (The power of the DSN is currently set at 5000 for all three levels.) https://docs.google.com/spreadsheets/d/1yj08CJX458ZbHOsLgVckEtqvHUj5KkP1En-R1kLIYyw/edit?usp=sharing I mainly ask as I was reading the readme on Github and decided to test the ranges with the spreadsheet and couldn't replicate the numbers. Based on the following: DSN1 range of 20M DSN Modifier set to 1.0 Comm16 range of 2M I tried entering the range number in an edited copy I made from yours and the spreadsheet gives a max range of 6.3M. Which is a bit short for the 12M range needed to reach the Mun, let along cover the 91% of the orbit it should. Playing around I found that I can get 91% with a 20M DSN if the Comm16 had a 200M range. Just wondering what I'm klutz thing doing wrong when trying to get the numbers mentioned in the Readme that I've copied below? EDIT: The numbers I got from the Github file show: longAntenna - @antennaPower = 2000000 // (2G) Original: 500000 (500k) Isn't this number 2M? The comment references (2G), but wouldn't this need another 3 zeros, ie 2 000 000 000, but if it's that high, I don't get the 91% mentioned in the Readme.

This was an interesting read and stuff there that I can use too. Thanks for putting the question out there. As an aside: Because Sarbian, Dmagic, Li0N & Nightingale all responded in the one thread, does that count as Developer "Bingo!"?

Also, make sure you don't have "Better Crew Assignment" installed.

Just read the Patreon Dev log and colour me intrigued with the quirks idea. I look forward to seeing what you have planned and like the sound of it.

For once I managed to find a solution myself. *yay learning* I wanted to avoid anything that would interfere with @sarbian method of setting custom DSN ranges. As such I found a work around so that instead of "setting" the actual DSNRange values, I can edit the DSNmodifier from the Advanced Difficulty Settings screen. I'll need to add code to remember what the value was before making changes so I can restore the previous value after I monkey around with the figures. Funnily enough I found the solution within the CBK code. Thanks again Sarbian!

Yeah - I figured if you did do the ground station it might be done via being dynamic with a quick raytrace to find the nearest to the vessel you currently in map mode from, then use that DSN station transform to be the DNS in your map menu. I'll give the orbital plan problem a crack so see what comes up. I've been playing with setting a procedural primitive to stick out from the planet surface. I'll see if I can get the cone I was using to be over the KSC and keep it perpendicular. Yeah - I'd thought of something similar but couldn't work out how to do a dynamic mesh to poke additional holes when something was in the way. If only you could turn a raycast into a something visible, then the game would put those gaps in fine. Would the seam be visible if it was drawn on the same pixel layer? I was optimistic that it would just blend, but practically, I figure there would of high change of Z fighting flickers. But as it was the same color, wasn't sure if that artifact would be visible. Other low grade idea for poking holes in the disc was to take advantage of what I think is a bug. Somehow use a capsule primitive the same size as a planet. The body would be in the closest end-cap and the other end cap would be stretched away far enough that it would occlude the area behind the planet to the range of the antenna. It wouldn't be accurate as it really should be at an angle from the craft origin, but it might close enough and could be a way to poke multiple holes in a disc if a ray casting mesh wasn't possible. As far as hiding the existing disc mesh, I remember there was a post that described a circumstance where a shader took precedence and effectively wiped out any other shaders behind it . Something to do with KSP only bothering to render the top shader visible or something like that. It might be a pie in the sky idea thought. - but I joined that idea with the disc and capsule primitive where it might be able to hide a section of the disc due to the conflicting shaders. I saw the donut idea the other day when I realized I'd not read the whole thread. It's a good idea, but I'm not sure I'd use it without knowing WHEN the overlapping donuts occur. Lastly, there is zero expectation here. I figure most of my ideas are hair-brained and likely to be dismissed with a quick feasibility check. If it's useful, then awesome.

Hi @Li0n I've been brushing up on my Trig for some charting I'm doing at work and during some idle time, I've thought up a few ideas for this mod in case you're looking for expansions These are just suggestions, so nix them all if you don't feel like they'd fit for the mod. Suggestion 1) Change the location of the DSN from the center of Kerbin to the KSC. This will make it appear off center from Kerbin. I haven't tested this property, but I think the transform for the KSC is here: CommNet.CommNetHome.nodeTransform (I almost suggested adding the other ground stations, but that might end up looking messy with circles at difference heights over the globe.) Suggestion 2) investigate adding half circles to the full circles you currently use so as allow drawing of arcs with the orbited planets occluding the signal. - Way to do that would if current antenna range is less than the orbit altitude, use the full circle as it wouldn't clip the planet. - If the antenna range is greater than the orbit altitude, then have a 1/2 disc still set to be centered around craft/DSN, but perpendicular to the surface then add two other 1/2 discs either side of the first and rotate these extra 1/2 circles so they are at the angle that result in a tangent line with the planet. This would result with the 3 half circles overlapping, but with a pie slice missing where the planet would be to represent the signal occlusion. Caveat: The idea would only work to give a pie shaped gaps in the circles for the nearest planet and wouldn't create gaps for moons or other planets Little pic to help explain: Calculating the a) angle to rotate the 1/2 discs so it's tangent to planet. r = radius of planet a = altitude of craft / DNS above planet d = r + a //distance of craft / DNS from center of planet L = sqrt(d^2 - r^2) //length of hyponenuse of tanget line h = L * r / d //height of right angle triangle a-Angle (in radians) = 90 - asin(h / L) // Angle is inverse sin of h/L a-Angle (in degrees) = 90 - asin(h / L) * (180/Pi)

Outside of the CustomBarnKit method - is there a way to SET the DSNRange property to adjust the value while in the flight scene / after the save game has loaded? I've only seen CustomBarnKit do this on Game Load to preset the available options for upgrading levels / costs. I'm thinking what I'm after is probably not possible, but wondered what the wisdom of the crowd says? Checking the values for stock - I can see the current DSNRange via the GameVariables.Instance.GetDSNRange(trackingStationLvl) all fine there. Different idea - is it possible to overwrite the GetDSNRange function to perform my own lookup of values based on some custom criteria? While it's not DSNrange, I did notice a curiosity that the returned level int for the GameEvents.OnKSCFacilityUpgraded for the tracking station gives the levels as 0, 0.5, & 1 - pretty much everywhere else uses the range 0,1 & 2. Separate question - is there a nice way to set a DestructibleBuilding to the destroyed state without having to get through the DemolitionFX?

Thanks for the quick reply - I figured as much, but wanted to make sure there wasn't something I didn't understand. cheers.

Hi @sarbian - Just an idle thought for a mod, is it possible to use CBK to use the DSNRange property to adjust the value while in the flight scene? So far, I've only seen a mod or two modify the upgrade levels / costs. I'm going to try this tonight and figured I'd ask the question in case there's some 'gotcha' I don't know about. I'd like to change the DSNRange to a value based on certain conditions that would happen in the flight scene. I figure if I try to do this (in the unlikely event it's possible), it probably won't be a nice change with respect to how KSP expects this to be managed and I'll have to (maybe?) do a scene reload to see the change.

Hey LGG, probably best to ask in the new thread - I get these thread mixed all the time. Thread development / Releases here VVVVVV

yeah - I'd be one of those 1%'ers. I have my EVA penalty set to -30 at the moment.

I was wondering where the message would be and found it in the stock messaging system. Awesome use of that part of the game to communicate with players! Checked my stations again and the float HPs gone down this time to a flat 60% for a 1 star Kerbal. Guess I need to work on some interplanetary missions now to get the experience to get closer to 70%. Thanks for the release!

Do you think this might have inadvertently found / fixed the issue with Science Relay as well?

Hmm.. this might allow me to not be afraid of using the death options in Life support mods. Also, do you know how this might play with Final Frontier? Would the resurrected Kerbal still have all the ribbons, or starting from scratch again?

thanks, I'll give those a mess a around this week