cyberKerb

Thanks for the suggestion. I had a look and it seems to be a bit overkill for what I was after. It wasn't multi-threading arduinos that I was looking for, but rather a way for the process that runs in the mod DLL to talk to multiple arduinos so not all traffic is going to a single micro-controller. I've still got to do some more testing, but so far I've changed the code and added a second SerialPort object called 'Port2' (existing object is SerialPort Port). I also changed some of the subroutines (sendPacket, Port_ReceivedEvent, etc...) so each part runs it's own code or I parameterise the code to pass which serial port to use, rather than assuming it's always the default port to process an instruction. Fingers crossed I can get it to work.

Had a question for anyone that's tinkered with the protocol of this mod. Has anyone modding the code to get multiple Arduinos to connect at once that they have code to browse? I'm thinking of splitting the workload across devices (each with specific data) and wanted to check if anyone had done something similar before I continue with my Frankenstein of a project. Before anyone says "I don't need multiple devices", please know that I've already extended the existing protocol to run most of the RPM variable set through KSPSerialIO. This is done through 412 bytes (so far) split across 3 different update protocols that update at different speeds. Only 174 bytes are updating at the fastest speeds. As I'm running a Teensy 3.6, I've yet to hit a speed limit that overflows the buffer, but I'm watching like a hawk with monitoring and timing checks. Stress tests shows it works fine with 115200 baud and 50ms refresh, but I'm planning for longer term expansion plans. I figure it might be prudent to allow a compartmentalisation of the communication to give more throughput across multiple devices (using only one process in KSP) for when I need it.

The mod I'm using is made by Zitronen shown below. I've extended it a fair bit and will eventually share what I've learnt, but it's mostly just experiments at the moment.

5 Jun Haven't posted in a while, so I figured I give a blip of a heartbeat. So 2020 has been a sh*t of a thing as everyone knows. Since the last post, the immediate area around where I live was threatened by bushfires (no damage) and then we got smacked with massive hail in Jan / Feb. Due to the hail damage, car ended up being a write-off and the house has been leaking for the last 6 months anytime it rains. The house is still being repaired but on the plus side, the Insurance company finally got around to getting us water tight with a replacement roof that finished last week. Work should begin on the inside damaged 3 rooms, which included our electronics / sewing room I share with my wife. All items were saved, but work stopped while repairs are going on. As such, I've mainly been doing on prep work / shop infrastructure project to gear things up when I'm able to get back to this. The shed still isn't organised, but I've completed a new bench with a self made biesemeyer fence for the table saw I've installed into it. Now I can cut decent sided plywood sheets down with good accuracy. Also, a CNC machine I ordered was delivered this month after a big delay due to covid19. I just need to build a bench for it. All-in-all, keeping busy in all the chaos, but still working my way to have that KSP cockpit.

Just figured I'd voice a hope for KSP2. I hope they include something to measure the solar wind from the various sun in the new multi-system game. AND that they include the effects of CME (coronal mass ejections) to satellite communications. It'd be great to analyse the solar activities with equipment and find out what weird long cycle the programmers added to the various solar bodies. Our Sun has an ~11yr cycle between low/high activity. I'd be cool to find out that some solar bodies have a pattern of 21 years of "stupid-high" CMEs that make communication severely degraded around the immediate system. That way it wouldn't be just the celestial bodies (planets / moons) that get all the attention from those plucky Kerbals. The 'fun' part of all of this is none of the data is documented. It's just as something to discover if people want to investigate that dataset.

Interesting. Firstly, congrats on the work, looks like it runs well. What kind of speed / pkt size are you running?

and seeing as it's no longer a necropost, I'll add... We still love you @alexustas! Take your time with life and we look forward to welcoming you back when you pick up the hobby again

two more consoles recently posted to reddit. If there is a local forum build thread let me know and I'll add the reference to the post I'm maintaining here.

The hard one is getting consumption from the Ore Drills

I always name mine 'Indigo' station. Works O.K. around Kerbin but the plan is to move it to Eve. For Duna, I like 'Rust Belt' station.

So would I, but you could argue the results are describing the average across multiple small cups of goo. Anyone from @SQUAD got a view?

I always thought the Mystery goo container was 1 container with 'air holes' that allow the main container to be exposed to the environment when opened. I stumbled over this persons interpretation of the goo container for a 3d print. I understand this was done for a 3d model so it looks close to the in game version, but due to all the little black cups, it made me rethink it's construction. Just wondering what other people thought are on this. Is it one container, or are each of the black holes a separate sample being tested?

would this work? It has a camera you can mount to your craft.

25.Nov These are from September when I posted them onto Reddit, but I forgot to add these to the build log. They are my test of my CPU interface to control target selection, setting manuever nodes and other items that I plan to add. The aim is to have a CRT monitor display to replicate what is shown in the ASET prop pack. I also included the built-in PDAI integration for port renaming / selecting when close to targets so I can control that with just Arduino buttons. It done via a Logger mod to get the data out of KSP/Unity so it's usable for something other than shoving down the serial line to Arduino. This allowed me to update a text file as required which is then read by an independent WPF application that watches for file updates. That app just reads the updated file and formats the text using the same fonts from the ASET mod pack for the display on a small separate monitor. I've got a 800x600 monitor on order that will be it's proper display. Doesn't work as well on a widescreen.

Thanx for the support probably not ToTM worthy with what I've done so far.. Need to get past the prototype stage first.

Mod question: is it possible for a user (not a mod) to edit someone elses thread OP / take over existing thread?

Thanks! I thought about changing the part texture, pretty much the same way that you described. However, I wanted to keep the game how it looked so I could flip back and forth (if necessary) from IVA to external view without there being an invisible part in 3rd person view. The camera I'm using is from the mod Docking Camera (KURS). I bumped the screen problem up in my priority as I needed to know if I should commit any money to the project at all. Hence the recent feasibility test for the cockpit style build I'm aiming for. I'm feeling confidant that I can proceed without too much worry. Seems like the bulk of the things I want will be possible, just need to learn some new skills / get the hard work done. I initially wanted to use the ALCOR lander can, but it has bits / panels on that part which are visible from the inside of the part (specifically the framing panels around the window. When I worked that out, I abandoned that part and went back to the MK1 lander can. I think the idea might work for other stock capsules, but I've not tested anything other parts. So far, I'm managed to get the functionality of ALCOR + RPM/MAS sandwiched into a Mk1 lander can. I'm planning to avoid glass cockpit elements as much as possible to keep the gritty 'used-look' aesthetic. So yeah - I'm inspired by things several layers deep at this point. MK1 Lander Can > ALCOR > RPM > APOLLO > SPACESHIPS! Current to-do: Print more (IRL scale) instruments on paper to work out where I want them placed on the walls / panels of the cockpit.

I used two external cameras, both placed on a cubic octagonal strut and clipped into the lander can model. (it's transparent from the inside) I used precise editor mod to place both cameras in the exact same spot, but have one with a 15 degree downward tilt, the other is facing straight forward. I'm still tweaking / testing the angles and FOV to give me what I want.

10.Nov Righty-o. Finally decided to bite the bullet and move the computer upstairs and see if I could get an immersive KSP cockpit experience with two monitors. I've been putting this off for weeks as I needed to tidy both the office where computer is coming from, as well as the spare room upstairs where I've currently got the cardboard mock-up of a cockpit. Lots of dusting and moving crap out of the way. I had to play around with the Docking Cam (KURS) mod from @linuxgurugamer to work out how I could modify the screen sizes for the external camera. I first needed to change the aspect ratio in code, then I managed to work out the steps needed to get to the size I wanted. Below is the result. The ascent was a bit hairy (Bill must of been piloting), but it did give a little bit of immersion and tweak the inner ear senses to think I'm fipping in the cockpit, so I'd call that a success!

Thought I'd ask a question that isn't 1.8 related... I found the Export map image useful. Could there be an option to allow the ground track to be included on the exported image?

Someone posted this a few months ago and another kind soul reminded people on Reddit today. First time I'd seem it and figured it needed to be added here. So inspiring for my own project - love the work for a controller you can actually SIT in. (French) Build page here: https://www.tutomotique.fr/fabriquer-un-cockpit-diy-pour-ksp/ Edit: Crikey - they keep coming! Another one was linked in the above page: (French) Build log: https://www.oximoron.fr/R/OxiKspController/controleur-de-jeu-pour-kerbal-space-program Awesome custom momentary buttons they made. Edit2: I updated the collection post with the 4 recent projects from this forum that I've seen. Up to 58 controllers now!

So I stumbled over this combination today and was amazed at both what it does and how old it was and not having known about it sooner. Note: I've not even downloaded it yet, but I figured it might be worth a mention in the fanworks section as I couldn't find a single reference to in on the KSP forums! The basic gist of the interconnection between the games is as follows: (snagged from the Github repo) KSP vessels require Factorio items to be built in addition to funds Science gathered in KSP can be sent back to Factorio in the form of space science packs Old project: https://github.com/Rahjital/KerbalSpaceFactorio Current XenoIndustry github repo: https://github.com/Rahjital/XenoIndustry Author: https://github.com/Rahjital

As has been said, start small and get the simple little things under your belt first. That DSKY was a fair bit of work, but looking back, it was just a *lot* of simple things all combined together. I did have to learn how to code a WPF form to do it though. Simple is all relative to where you are on the learning curve. Something like taking the entire RPM/MAS variable list and pushing it to the Arduino/Teensy, should not be anywhere near a first step. It sounds like your making progress though, and that's all that's required for this hobby - "small progress" It just gets built upon each time you add to it. <- There's a Kerbal saying if I've every heard one. Congrats on the baud rate, that's tripped me up a few times too. I can relate to your plan with doing a software focus first. I've tried combining the hardware builds at the same time and just burn out for a month or two due to no progress as there wasn't software planned out to run the hardware. Other people can do it the other way around, so there is a bit of personal preference there.

Despite having a monster-size workload LGG, you still managed to fit another mod into the stable.. Thanks for picking this up!

16.Sep Righty-o. Test rig constructed mainly to check placement and size of all the things I've tested and built over the last few years. Next few weeks will be creating mock-up printouts of the dials and switches I plan to install. I've already checked the size of the DSK and I managed to get that size perfect / close enough by accident. The 4 digit, 7segment LED modules are 5cm x 2cm. With two of these side-by-side, there is still room for decently sized warning lights. The CRT screen looks like it'll fit nicely on the bottom right - still waiting for the LCD screen to get here from the US.