cyberKerb

For the record, I just tested this is 1.10.1 and it seems to function. I only grabbed a brain in sandbox and the UI works and the rocks appear puttering around the KSC. Color me amazed.

The first time loading up the ALCOR cockpit and seeing it from IVA was amazing. *drools over all the switches*

@linuxgurugamer Pull request sent. You'll need to recompile for release as I only updated the source files. Reordered PartCamera.cs Activate() function. It was also missing the InitTextures() which was causing the Target marker to not load. Added ActionGroup for camera activation to both part modules (suggestion @Atlas Gaming) Corrected the shader reference path to: 'Legacy Shaders/Particles/Additive '. Was causing NRE errors if bullets or Target ray buttons were used. Added user config option to set EC amount for camera usage. Was hard coded to 0.02. Updated part cfg files to match Found cause of not being able to restore power to camera. (Logic flaw in original coding) Added code to check EC before trying to enable. (suggestion: @Atlas Gaming) If you have time could you look into why the photo process of this mod (SavePNG function) doesn't apply the Shader to the saved image file? It just takes a render of whatever is in the camera window - but without the filter.

Not at all. I'm just a brute force troubleshooter who understands programming structure. It doesn't hurt that I'm fine trawling through all the code, tracing what calls what to find the issue. Found a few minor issues, I'll sent a pull request.

I'm looking at this source - it still has the 'UIMainCamera' in the reference. Or is there another set of source in this repository? https://github.com/linuxgurugamer/DockingCam/blob/c674936b5ea35c62992de12fad69d1de05ae1757/Source/Camera/BaseCamera.cs#L72 I'm not sure how that works, all the png and tex files all have the case with the "targetPoint". Having said that, I'm still going from the github reference code so I might not be looking at the correct code. I'm connfusing on what source I should be using now? https://github.com/linuxgurugamer/DockingCam/blob/master/Unity/DockingCam/Assets/dockingcameratextures/targetPoint.png https://github.com/linuxgurugamer/DockingCam/blob/master/GameData/DockingCamKURS/Resources/Unity_Assets_Files/DockingCam/CAB-156ac663a69c7f4d098886aaf52c3743/targetPoint.tex Maybe it's not related, but the issue fixes itself if you use the '+' button at the bottom right on the window to increase the window size. After that is clicked, the targetmarker button works fine with no error in the console. Seems like something isn't initialised in the right place.

Without even looking at that problem, it'd be a good guess it is also caused by using that extra camera that's doing it. Can you past a screenshot so I know what to look for? I'm on the bus now after works network crapped out. I'll see if I can reproduce the issue later today. I'll also look to add that Action group item and send LGG a pull request if I get time.

Ok - last update and then I've got to get to bed. (sorry to everyone else for all the coding talk) Other than removing 'Camera 01', also remove / comment out any references to 'AllCamerasGameObject[2]' as this would of been referring to 'Camera 01' in the basecamera list array. And that won't be there when removed. The Target ray / Fire bullet issue is due to the shader reference using an old 2017 path. Forum ref link Change the path from "Particles/Additive" and change it to "Legacy Shaders/Particles/Additive" https://github.com/linuxgurugamer/DockingCam/blob/c674936b5ea35c62992de12fad69d1de05ae1757/Source/Camera/PartCamera.cs#L541 https://github.com/linuxgurugamer/DockingCam/blob/c674936b5ea35c62992de12fad69d1de05ae1757/Source/Camera/PartCamera.cs#L569 I've tested this one and it does fix the error when using the 'bullets' or target ray. The transparent views on CRT and Greyscale I can only 'guess' are due to the shaders config themselves. I have no idea on those and will leave that black magic for someone else to scrape through. @linuxgurugamer Your work on that alone is heroic as that is quite dense to even get started to try and understand it.

One other question for @linuxgurugamer is it possible to add a variable to the cfg file to allow a user defined electricity cost for the camera use? At the moment it's hard-coded to 0.02EC per something. In the game, it looks like it's rapidly flicking between 0.04 * 0.08 per second in the resource UI. Might be indicating it's being updated overly frequently due to when the update is running. https://github.com/linuxgurugamer/DockingCam/blob/c674936b5ea35c62992de12fad69d1de05ae1757/Source/Camera/BaseCamera.cs#L247 Lastly, I've rechecked the camera issue and the floating navball (and the floating text) disappears if you simply remove the 'camera 01' altogether. ie changing Line 72 of basecamera.cs to: protected List<string> CameraNames = new List<string> { "GalaxyCamera", "Camera ScaledSpace", "Camera 00"}; It would ruin backwards compatibility for prior to 1.9, but I don't think that's a concern seeing as this release would be specifically for 1.9 and over. Other mods that use this method do an onload switch of having the Camera 01 available only once they check the gameversion the mod is loaded in is less than 1.9. Otherwise they skip the camera completely, hence my suggestion to remove it completely. The visuals for this test were fine and had no weird extra floating stuff. Edit: it might be fine for me, but I just read Camera 01 is still used for players on MacOS and Linux. I need someone to be a guinea pig on one of those systems and test a version without the Camera 01 on the compiled DLL? However, I then had an issue with the Target Marker rendering under 'EntendedDrawWindowL2'. The .tex file for _textureTargetMark isn't loading for some reason and causing an can't render null texture error. I'm sure this is a simpler issue to fix and it might be related to the warning about still using the obsolete WWW and changing the code to use UnityWebRequest

G'day, I might as well add to this. I've gotten back into the game and figured I'd help troubleshoot this. I've done a fresh 1.10.1 install only with the following installed: both DLC 000_ClickThroughBlocker 001_ToolbarControl DockingCamKURS Camera functions fine initially, so great job getting it working again. I plan to go through each of the internal views and stick a camera inside each cockpit to see if the visible kerbal issue is consistent or specific to some parts. I've checked the lander can Mk1 and I don't see a Kerbal at all. I might of stuck the camera a little forward of the seating, but I'll check again tomorrow. Found three issues initially: The Greyscale & CRT shaders are about 50%-60% transparent. I can see through those views to the scenery behind the window. All other shaders are not transparent at all. If I use the 'photo' button, the resulting image is fine and not transparent at all. The 'Target Ray' and 'Fire bullet' button (which I assume calls the same bit of code as Target Ray) results in an NE exception. The error only occurs while the ray appears on screen. For the fire bullet button, this appear in the log for a few dozen frames. It's worse with the Target Ray as it'll spam the log file continuously until turned off and the user won't know unless they have Alt-F12 open. Probably not a major issue, as I don't think many people use this aspect of the mod, but still worth reporting. [ERR 20:11:02.283] Module PartCameraModule threw during OnUpdate: System.ArgumentNullException: Value cannot be null. Parameter name: shader at (wrapper managed-to-native) UnityEngine.Material.CreateWithShader(UnityEngine.Material,UnityEngine.Shader) at UnityEngine.Material..ctor (UnityEngine.Shader shader) [0x00007] in <5aeafee3fea24f37abd1315553f2cfa6>:0 at OLDD_camera.Camera.PartCamera.DrawScanningRay () [0x00054] in <0fb6c2b8fe8140a6a48a3c778e22312f>:0 at OLDD_camera.Camera.PartCamera.Update () [0x0001c] in <0fb6c2b8fe8140a6a48a3c778e22312f>:0 at OLDD_camera.Modules.PartCameraModule.OnUpdate () [0x002e3] in <0fb6c2b8fe8140a6a48a3c778e22312f>:0 at Part.ModulesOnUpdate () [0x0004a] in <c1858a3f77504bd1aaa946fdccf84670>:0 Last issue found was that there is some kind of weird layer peaking through with numbers showing up in the camera view. I also get the floating Navball, but this seems on the same layer as the navball. The numbers scroll through as I rotate the camera, but disappear once past about 30-45 degrees. The numbers remain of static size regardless of zoom level or shader/filter selected. For the issue to be visible at all, it seems to depend entirely where the camera is pointing. You'll probably miss it if looking at a noisy / black background. From the launch pad, I was looking towards the north towards the flag to see the numbers, the floating navball is seen when looking west to the VAB. Next up tonight is to see if anything up with the docking cam / has same issues as base camera.

Sooo... @richfiles not to add to your woes, but I saw this today. They do single, double or triple reproduction switch panels. The triple pictured below is a bit exxy, but they might work for some people as a flourish or as a reference piece. (Click on pic to go to their site)

It's mostly just writing code for the Arduiono. In that you have two options, You could just make a keyboard emulator using a Arduino, (only certain models can be seen by the computer as a keyboard, UNO cannot) you'd then need to write an Arduino script/program that listens to button presses and sends the desired key press to KSP. KSP let's you remap the controls, this will help avoid conflicts. The issues is not all controls are mappable. (Eg park brake) it's also a one way connection, no displays as the keyboard only sends information. The alternative is to use a mod that takes the information from the game and makes it available to interact within the arduino code. This includes both vessel controls and information displays. Plenty of options here, I've listed a few below. (I'm using KSP Serial IO) KSP Serial IO KSPEthernetIO Kerbal Simpit KrPC Telemachus Check this link out and browse through people builds so you get an idea of what's out there. There isn't really much in the way to avoid programming at least something. @hugopeeters project is the closest to having complete plans available where you would do minimal programming. However, you'd be building that controller, and not something that you might want to modify.

Aug 27 I don't remember mentioning the disco ball.... but Good guess! It's been planning to use it for a while. Here is my bootstrapped time warp display. I'll rip it apart and have the micro controller do the light display for specific patterns for physic-warp vs high time warp. Might rebuild a POV display for it, but it'll do for a starter item. As for warning lights, I just got delivery for the little dome covers with fresnel lens included - (they are just repurposed pilot light lens covers) I love these as they match pretty closely to the ASET model (you can see them in screenshots here from the ASET lander can mod) So far, I've allocated them for the 'RCS' & 'SAS' lights. 'Contact' & 'Gear deployed' lights. Red will be a 'Master warning light'. I've got an Amber lens on order for 'Master caution'. Yes, I know I'm starting to veer into Flight Sim cockpit territory, but I had to get inspired from somewhere other than KSP. The clear light is undetermined as yet, but maybe something to like a science alert. No plans for bells or whistles... yet. For dials and displays, I'm just starting the 3 hand altimeter (another construction guide nabbed from a flight sim blog. Very interesting work Mike has done. His home made altimeter is towards the bottom of the linked post and very inspiring). One stepper motor will drive all three hands with a 1:100:100 gear train connected to three concentric shafts. No store that I found sells 3 shaft stepper motors. Was only able to find dual concentric shaft ones. They just means I'll have to fabricate it myself. Working with brass tube is new for me, but what isn't in this project I'm yet to mount these beauties too... I left them alone in a dark corner to multiply and now there are 20 22 of them now. All Most are already allocated to various displays in the cockpit, they are only 6.5cm tall, but I've got one that is 6inch tall and that one will be horizontal for the Atmosphere depth gauge you normally see at the top of the KSP GUI Resources (switch to toggle between stage amt /total vessel) - LiquidFuelTotal - LiquidFuel - Oxidizer - SolidFuel - Xenon - MonoProp - Ore - Karborundum (Mod / not stock) - Ablator Power - ElectricCharge - SolarPanelEfficiency (horizontal on power display dash) Navball related - PitchRate - RollRate (Navball related) - HeadingRate (Navball related) Propulsion - EngineTemp - ThrottleLimiter - ThrottleValue - TWR - ReactionWheelAuthority - RCSLimiter Throttle note: While looking back at the 3D throttle model I made, I later worked out how to straight up import the ACTUAL ASET MODEL into sketchup. Took a bit to find the process, but after using a blender plugin to open and convert it to a DAE file, it worked fine. While I wish I'd know that BEFORE I hand-crafted it from isometric views, I promptly deleted that exact ASET model and I'll keep utilising my own version, flaws, warts and all. Oh well, live and learn something. It helped learn 3D modelling, so I can't really complain as I'm not going to an accurate replica anyway, just something close. Thanks for the interest. The shed came with the house, but I suppose now I think about it, you're not wrong. I did gut it back to bare metal and installed framing, insulation and OSB panels. No paint as yet. Mainly did all that to take the sting away while working in there during Australian summers. I didn't anticipate this KSP cockpit to be the major project at the time, but it works. Your post made me think I should post some pictures on what I've managed to get done in the shed last weekend. As it wasn't strictly KSP related, I never thought to post anything about it. The CNC bench was done a few weeks back. But last weekend I got the CNC frame and waste board constructed, just need to round over the edges. Saturday is when I get to add the X, Y & Z axis to the machine, hoping I have enough time to wire it up as well. Until then, I've added these view I make in sketchup for the planned benches I made.

Not 100% sure, but I think this is due to the asteroid collision mesh not being the same as the texture mesh. Collision meshes are usually just primitive shapes (box, sphere, come) so it's easier for calculating collision point. I'm not sure which is the case for KSP, but I'd guess they'd use primatives. As such, I'm also gueasing these floating / buried collision points are just part of the game. I think its the same reason we get 'floating' boulders. If you wanted to confirm, there is a debug mod that will let you see the collision meshes to see where it pokes out.

Thanks for the tip, I managed to find the code you were trying to remember https://github.com/Mihara/RasterPropMonitor/blob/b32f65c07168dfe7c6c8f786ecc00e358cc894c3/SCANsatRPM/JSISCANsatRPM.cs#L277 One question - does this method work when at high latitudes?

Is it possible to get the Lat & Lon of an object (in orbit) as at a UT time that take into account planetary rotation? I've tried the following: Vector3d VESS_Position = ActiveVessel.orbit.getPositionAtUT(FutureUT); Vector2d FutureVES_LatLon = LatLon.GetLatitudeAndLongitude(ActiveVessel.mainBody.BodyFrame, ActiveVessel.mainBody.position, VESS_Position); However, this doesn't seem to factor in planet rotation.

Oh boy - I've been digging and found this maths area fun to dig into, but I think I've worked out what I need to do. I think I have to iteratively calculate (~7-8 loops) to get a close approx of distance to the ideal flyover point. Anyone know of a way to do that with Vector3d?

Thanks - figured I was starting to lean the conversation into API references and though it would be better there.

Thanks @Arrowstar - I was pretty confident that you'd work it out with your tool. However, maybe I set up the question with too many restrictions that made you think I was after a solution finder. I've added some context below to help. I'm after a value that can be used by the player to find their own solution for landing close to a ground target from orbit. This is preferred rather than give them the complete solution. Currently there is not enough information in an IVA for this, even with mods, provided you don't look at any map screens of console that show ScanSat. The proposed calculation/function would be added to a variant of the RPM mod. RPM has a small CRT screen in the older technology controls (no glass cockpit here), hence the no map restriction. It would only be able to calculate the closest distance from ground track information. eg: Closest TGT distance to ground track: 1345Km. Calculating the required burn is not required and it would only look at the current orbital period and not multiple orbits. 'How' to use this information would be something for the player to work out. I'm hoping that helps simplify the parameters? The information would in theory allow an IVA player to plan and execute a landing burn for a ground target so it's close to desired landing point. I'd implement a small UI in the CRT display of the IVA mod RPM so the distance in KM could be visible. Depending on how intense that function is to run, it might be click-to-run and not something that is constantly refreshed. There would be only one parameter the user could modify, with the rest nabbed from the API to get current state. For parameters, i figure the function could require at least the body, craft orbit, lat/long of target and a variable of UT (Universal Time) for starting condition. Ideally, it would only calculate this on for 1 orbit period from the UT given and result in how close the ground track is to the target location. ie Example result could be '214353m'. Thinking over it more, I could re-word the problem as: What would I need to do to workout the LatLon position for when the ground track crosses the targets Latitude or Longitude? If I could get that, I think all that's required then is to do a 'great circle' calc (old forum post for reference) for the two position to find the distances across a sphere surface and select the lowest value to get the minimum distance? All of this would let me run the calc for this orbit, or if I change the starting UT, I would get the next orbit. That information would be enough (I think) for me to know which way to make an Normal / Anti-Normal burn. Specifically when my Orbit is 1/4 of the Orbit period prior to the closest AN/DN node. (90 degrees prior to the next AN/DN in the Orbit) Running the calc a third time after a guesstimate of the burn duration would tell me if I got close by checking if the distance reduced significantly. Otherwise, if there was a way to use Vector3d for this, I'd love to learn how.

I'm trying to learn how I would calculate when a craft in orbit would have a ground track that flies over/close to a Target that is on the ground. I know you can use the stock map for this, but if you're in IVA, that information is not available. (ignoring Scansat and other such mods for this query) It's all so easy with the visual representation that scansat gives... Providing you're not brute forcing it, just need to wait until the orbit looks close to passing over the landed vessel. Then perform an orbit adjustment burn so that ground track line goes right over the lander. I've seen the "closest approach distance" and "time to closest approach" calculations in IVA mods MAS and RPM. I'm hoping there was someone who knew the funky maths involved for this calculation, who might be able to modify that calc so it works for a the target on the ground? ie the closest approach would be the from the ground track path, not the distance from the orbiting vessel to the ground vessel. I know @Arrowstar, has got their awesome trajectories tool with all it's wonderful visualisations, but what I'm after is a calculation that can be used to find the future orbit when I should perform that orbit adjustment so the ground track gets very close to the point where the landed vessel is at.

Thanks for the suggestions. The transparent pods option is probably the closest, but the camera would be fixed on the IVA prod and only good for static shots. As soon as you moved the EVA Kerbal, the moving camera would cause you to lose the fixed perspective of looking from the IVA position.

20.Jul Okie dokie. I tinker of the code fairly regularly, but I don't post updates that often as it's mostly me trying to get code 'just right. I'm going to try something new and see if I can keep focused on this project longer by posting more frequently with smaller updates. Yesterday I managed to add the drill/harvester information to the data available to sent to arduino / teensy devices. The plan would be to have a 'Harvester' sub panel for the resource gauges / indicators. It includes the following status flag indicators: - Drills Extended (off =no, on=if at least one is extended) - Drills Active (off =no, on=if at least one is actively digging) - Active Drill Count (not sure if/how I'll use this value yet) Also added three numeric values for some indicator dials giving what I'd like to monitor at a glance - Drill Core Temp (only give the average core temp of active drills, if at least 1 is active / if none are active, give average core temperature of all drills) - Thermal Efficiency (only available when drill are running, so gives average of all active drills) - Resource Abundance (I'll only allow this value to be visible on two conditions, 1) I have the surface scanner part on the vessel and 2) the vessel is under the max scanner height, usually 1000m above the ground) Below is a mockup of what I'm thinking. IT would be using 3 of the cheap rectangle panel meters rotated so they look like quadrant meters. might put a scale selector switch for the Abundance meter. This will allow for x10, x1, x0.1 scaling.

Is there a mod that does something like this? What I'm hoping to find is something that lets the player have the camera in an IVA view of a cockpit, and then switch to an EVA Kerbal, but not have the camera switch to the external view. I swear I've seen a KSP YouTuber do something like this when they had a Kerbal walk past a cockpit window. However, I'm either not be remembering correctly or they setup that via the EVA follower mod. The end result I'm looking for would be controlling a Kerbal that you can see though the cockpit window that is actively controlled. Mods I've checked already: - I'm aware of the "EVA Follower" mod, but that would be programming movement and the switching to EVA to watch. I'm looking for something that gives you active control. - "Kerbcam" doesn't like being in IVA camera - Haven't tried CameraTools as yet, but I've assumed that is for manipulating the cameras position of the active craft. Edit - Thought of another way to ask the same question: Is there a mod that 'locks' the camera in IVA and stays there even when EVAing the kerbal. (QuickIVA mod switches to IVA on launch, but doesn't keep it there for EVA.)

Well, I'd say for the vast majority, that will be fine for those whole don't want to code up some custom monstrosity. A KSP cockpit has so much data to display and the potential for sci-fi blinky-lights all around me was far too appealing. I'm regularly browsing aircraft cockpit builder forums looking for tips and tricks in both software and hardware.

16.JUL Today's update is a bit of a shout out to @alexustas again and referring back to the first post all of 1 whole page back (I know... I post updates slowly). I'd love some feedback if you have thoughts on what I've got so far and if there might be other ideas. I've generated an animation for the planned internal mechanism for the throttle. I think I'll be fine with the electronics, but the pull-out and shove-down option was a bit tricky. I still think I'll used it for "shifting" into reverse thrust, but I suppose it could be used as a staging action. The downside is it would mean I'd have to cut throttle any time I wanted to stage though, which might not be ideal. Can't mentioned enough that credit for the design is all Alexustas. I've used that as the starting point and will be trying to bring it into the real world. The throttle will be motorised to get to full and zero throttle. Other than QOL reasons, it will also help to automatically set the throttle to zero if I switch crafts in game. Also, there will be another small potentiometer to the left of the LCD (not shown). This pot will have a small lever arm on it to allow me to push fwd and back to set the throttle limit for all active engines that you normally would do via the PAW in game. The current throttle value and throttle limit (if set) will both be visible on the LCD it to character high custom text sprites. I've continued work to confirm the viability of what I want to build for a KSP Mk1 cockpit. I pulled on the reigns a bit after starting the throttle and tried to focus on software development so I wasn't spending money on cool switches and buttons just yet. When you browse cockpit building forums, it's really hard to resist the urge to jump on ebay or whatever and grab a few of the switches I just saw, but not having a detailed plan for where it goes in the cockpit or if it's the right shape, size, style. My main fear with the project is to get to a point and find out I'd have to compromised whole section of what I want to build because it's just not possible with the limited API that KSP supplies to modders for cockpit builds. The KSP SerialIO mod had some limitations that worried me for my build. It was originally created with only 255 bytes to send data to a micro controller (which should be plenty for most people). But seeing as I potentially will be putting up to 800 RPM / MAS mod variables down the pipe to micro controllers for status lights, indicators, dials, displays and whatnot, I needed to know this limit could be completed stomped on. I've worked out how to both extended that (up to 412 bytes now) and also figured out how to send data to multiple micro controllers at once to distribute the load the the data display outside of the KSP game using only one mod cobbled together for the bones of other mods. All of this was to make sure that I could build what a want and be confidant that after learning a few skilled and a bit of time, it all should still be possible. House repairs are mostly done, and I'm back in the mood for making stuff with electronics and KSP again. Shed infrastructure is still WIP, but progress is being make each weekend. I've got the CNC bench made and just need to unpack the CNC machine. Oh, also need to work out how that works too. Cheers to progress!

I managed to answer my own question. After a rather late night of testing (2am here and going to bed now), I've found that it isn't too hard to just add another SerialPort object into the DLL code and so long as you are careful about the making sure the routines all work for the separated ports, it's certainly viable. It also lets me know that if I ever hit any limit of what I can push to my existing micro-controller or it gets too busy with whatever I'll be demanding of it, I can always bang on another connection to a separate micro-controller and pipe data to it as well.