Daid

Most likely you want to look at the "RenderingManager.AddToPreDrawQueue" or "RenderingManager.AddToPostDrawQueue". As this should allow you to do drawing. Check the Unity documentation on how to draw GUI elements on how to draw a full screen colored overlay. (Don't think you need to create a texture to do this)

I'm hoping they add micro transactions.

Just a small one. I have a ton of experience on Arduino USB Serial communication. (From a 3D printer perspective. As I've build and maintain one of the leading open source 3D printing applications) From this I can tell you that you are missing one important factor, USB. USB is polling based, there are wierd driver interactions happening, that even I do no fully understand. But you won't get full speeds, and there are some strange "bulk" transfers going on behind your back. So while the serial port might look like a stream from A to B, there is actually a polling based bulk transfer in between. So sending data really quick does not do much except for making it difficult on you MCU side. I would recommend updating at 10Hz. That's quick enough for you to make it feel like "real time", but won't make stuff extremely complex on the MCU side. Also, for anything serious on Arduinos, you'll better use your own UART driver. As the Arduino drivers pretty much suck at just about everything.

Not 100% sure on this. The limits are handled by the "GameVariables" object. Specificly, GameVariables.instance.GetCraftMassLimit and GameVariables.instance.GetCraftSizeLimit. Now, changing functions on a "life" object is not possible, as far as I know. However, you could replace GameVariables.instance with an new overloaded object that has a different implementation of the above functions. This might work: [KSPAddon(KSPAddon.Startup.MainMenu, false)] class MyGameVariables : GameVariables { void Awake() { GameVariables.Instance = this; } public int GetPartCountLimit(float f) { return 100; } public float GetCraftMassLimit(float editorNormLevel) { return 50.0f; } public Vector3 GetCraftSizeLimit(float editorNormLevel) { return new Vector3(100, 100, 100); } }

Yes, because the ship is not actually loaded. Else the game needs to keep all parts active all the time, which would be a serious hog on resources. So if you want to make long distance parts do something, you'll have to deal with them as protoparts, and protomodules.

You're welcome. I like investigating interesting cases like this :-) for the record, which combination worked?

https://github.com/daid/KSPHullCamera/blob/master/HullCamera.cs#L175 That should help you.

AddForce on a kerbal seems to work fine for me. Setting vessel.transform.ridigbody.useGravity to false does not seem to do much. But I do see a small upwards drift that you're also seeing. So the actual downwards force that the object gets is less then the added upwards force. Few random ideas: * FlightGlobals.getCentrifugalAcc and/or FlightGlobals.getCoriolisAcc might also get applied? * Drag could be causing strange effects? (We know the drag model isn't that awesome) As cheat, you could set the velocity to zero when it's nearly zero?

The meter on top is in a logarithmic scale.

I think the easiest solution would be to put the vessel on rails, rotate it (as then you have a single transform that defines the position and rotation) and then put it off rails again.

If you want to stop gravity from effecting the kerbal, wouldn't the Unity "useGravity" flag be a better solution? http://docs.unity3d.com/ScriptReference/Rigidbody-useGravity.html Also, to get the current gravity that is applied to the objects, "Physics.gravity" might be a more accurate reference. And I would use the "AddForce" instead of "AddForceAtPosition" function. With the ForceMode to acceleration, so you do not need to multiply with the mass, which could also be your problem, as the mass presented to GetTotalMass might not be the same as the physics mass. http://docs.unity3d.com/ScriptReference/ForceMode.html v.transform.rigidbody.AddForce(Physics.gravity, ForceMode.Acceleration);

PartResource.flowState to false does this.

I was thinking about the same problem. But you could solve it by adding a "pre-flight-check" procedure. Where, when you switch vessels, all controls are disabled until your controls match the actual ship status. With a message on the screen saying "Waiting for pre-flight-check of: Action group X"

ModuleParachute parachute_module = [ref_to_module]; Transform transform = parachute_module.part.FindModelTransform(parachute_module.canopyName); //Now modify the transform to point at the proper direction This might help? I'm worthless with how the transforms work from Unity at the moment (still learning, all the coordinate systems in KSP don't help). But I think this will allow you to point the parachute in different directions.

http://forum.kerbalspaceprogram.com/threads/84621-Paper-Space-Program-%28-a-k-a-KSP-Rocket-Parts-Papercraft%29 This explains a way. And I've done this: 1.5 year ago. Showing that it is possible. (I used a less invasive way then the above topic. Instead of a capturing tool, I made a small mod that saved the mesh data straight from the game, but without textures) However, Squad might not like it if you sell these. Obviously.

I can also do engraving (both laser and milling). But, at the time of fabrication, I didn't know what all the buttons&switches where going to do. But, find a local FabLab. You'll most likely be able to do a lot for cheap there. Most machines I have access to are also accessible in FabLabs. Started out as Artemis. But ran into many bugs and missing features, that we made our own version: https://github.com/daid/EmptyEpsilon (Still missing 1 console, and paint) If you're in The Netherlands, feel free to drop me a PM do drop by one day. Wouldn't mind having some fresh players to test on :-)

I don't think the chutes are a "lose" object, but instead, they are a part of the whole model of the part. And when the chute is deployed, the rotation of the chute is updated each frame to match the inverse velocity of the ship. As chutes "flip" around very quickly if you go from one velocity direction to another.

Not sure the maintainer of Hullcamera would agree on my changes. I pretty much changed the whole code structure so it would suit controlling from my panel better. Also introduced some bugs in the process, as well as scrapping a few features that I didn't need. Funny, it's just a side project for me. But if I hook up the stuff that I do with the mouse in map mode into the controller, you wouldn't be far from it. Also the reason why I'm sharing my code. Saves other people time figuring out how to hook into certain parts of the game. If you need assistance with code parts, send me a PM. But you should see my OTHER spaceship: http://daid.eu/~daid/IMG-20141218-WA0001.small.jpg http://daid.eu/~daid/20141106_190834.small.jpg http://daid.eu/~daid/20141106_190852.small.jpg Spending way more time on that one, also way more money. But it's a group project. And still needs a ton of work, both on the code and the hardware. But the electronics is easy on that one, all touch screen controls :-) Just that the game is 100% custom. Also found this day time shot of the panel, from before the electronics where hooked up: http://daid.eu/~daid/20140703_164805.small.jpg

Done http://forum.kerbalspaceprogram.com/threads/105251-Yet-another-Kerbal-Control-Panel?p=1636098#post1636098

So. I've had this one laying around for a while already. But I never hooked it up to KSP until a few days ago: It's my own custom Kerbal Control Panel. Quick hardware introduction: * Tons of simple flip switches from dx.com (bought in bulk, not all used in this project) * Switch with flip guard from dx.com (bought in bulk, not all used in this project) * 5 red and 5 green push buttons from dx.com (the red buttons are break contacts, which was a surprise) * Throttle control, up/down stick from dx.com. Sadly, it's 3 state (center, up, down) and not proportional. So might swap this for something custom. * Place for 3 dials. Currently not hooked up. First one has a cheap hobby servo in it. The dial holders are 3D printed. * The center joystick was bought at a flee market (1.5 euro) * The panels are laser cut 6mm ply. Painted with two layers base coat of gray. Looks perfect for the job, and cheap. * Single ArduinoMega2560 hooked up to all the switches. Now, the wood was cut at my work. The dial face and holder was 3D printed at work. Yes, I'm privileged, got a laser cutter at work, 3D printer at home, tons of 3D printers at work, and Lathe and a cnc milling machine at work. Overall, the costs for building this for myself was less then 20 euros. With the throttle control being the most expensive part. But that's because the wood was free (waste material) as well as the Arduino. On the software side, I started with KSPSerialIO: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29 But quickly figured that I wanted to do most stuff from the plugin side, and as less as possible on the Arduino. So, my code became: https://github.com/daid/KSPSerialIO (I lost the Arduino code. But it's simple code that reports all pressed buttons/switches and the analog position for the joystick as fast as possible) As I want to give it a bit more realistic experience, I'm modifiying the Hullcam mod from: http://forum.kerbalspaceprogram.com/threads/46365-0-90-Hullcam-VDS-0-90-update-Updated-16-Dec?highlight=hullcamvds Code for the modified Hullcam can be found at: https://github.com/daid/KSPHullCamera I'm modifying the Hullcam mod for the following features: * Allow to cycle only local ship cameras. (Done) * Allow viewing of your ship from a telescope camera on another far away ship (WIP, sort of works, view is blocked trough planets, but sometimes acts up) * Allow viewing of your ship from KSC telescope. (Not done) * Force one of the above cameras when available, disabling the default camera (however, it could be that no camera is available, due to no cameras on the ship, and all other cameras blocked by planets) (Note, it's still quite buggy, I do not recommend using this version of the mod in this state) Now. For the panel. I have the following controls figured out: * Left most red/green buttons, 4 of them, used to cycle cameras. * Right most red/green buttons, 2 of them, used for time warp. * Throttle lever is used for throttle up/down, but only in stage mode. Switching to docking mode sets the throttle to 0. * Joystick is used for yaw/pitch/roll (top button switches between yaw/roll as in most flight sims). In docking mode the joystick controls lateral controls, with the joystick fire/top button doing forwards/backwards. * 6 switches next to the joystick control: SAS/RCS/Gears/Solarpanels/Lights/Breaks. All on/off. * "Master switch" is the staging switch. Makes a lot of noise when you close the cap. The cap also resets the switch. So it acts more like a button. * The next 6 switches. One of the switches between staging and docking mode. The other 5 control the auto-pilot mode. If all 5 are disabled, then it's simple stability assist. Else, you can set every auto-pilot mode. 4 of them set prograde,radial,normal and target. And then there is the "alternative" switch, which sets the mode into the other direction (so normal becomes anti-normal, etc...). And the "alt mode" switch sets stability assist to maneuver node (if available). * 10 top switches are mapped to the custom action groups. However not sure if this will stay this way. Also the 4th switch is not working, might be a broken wire... Finally, I use NanoGauges: http://forum.kerbalspaceprogram.com/threads/84409-0-90-0-NanoGauges-tiny-ana1og-gauges-for-kerbalnauts-0-5-24-303 For all the information needs. I've been slowly adding a few gauges that I miss. (Time till Ap/Pe for example) Now. This allows me to control most of the flight aspect of the game. But, I still miss a few things to fly a perfect mission. I did a test mun landing yesterday to see how well it worked. And ran into a few things. For a nice mun intersection I needed to setup a maneuver node. While "burn at mun rise" still works, you still need the map to verify the final orbit. As the nano gauges Ap/Pe gauges do not go that distance. And do not tell me I have a capture. I should add a gauge that shows a SoI change, and time till SoI change. So I want to add a maneuver planning mode to the panel, not sure how to do that yet. But I still have the 10 top left switches. Currently these are mapped to the custom action groups. Also, camera setup is extremely important. I had no camera view that showed if my solar panels where unfolded and not ripped off. As I flipped the wrong switch during assent, and I wasn't sure if they had unfolded and ripped of, or that they where fine. When I got into orbit, and my telescope satellite was in view, I could verify that the solar panels where fine. Docking. I have a docking port on the lander. But I could not undock, as my camera setup did not put the docking port in view. Not sure how to handle this. Could setup action groups for the docking ports, but that's hard to remember which group is which docking port. And not sure what will happen if you dock multiple ships together. Could also just setup my cameras better. Finally undocked by using the mouse in telescope view. But I want to set this up so I do not need the mouse. (Better photos will follow later, with bottom photo showing all the hotglue on there)

It's not easy. The wheels work by looking at the surface speed. Ground surface speed. Which is a very high number when you are in orbit. You could check this by setting your ship in an near geo-stationary orbit, and check the surface horizontal speed with Kerbal flight engineer. Most likely the wheels will work when you are near a "sane" speed number. Most likely you need to adjust the "torqueCurve" parameter of the ModuleWheel to have torque on all speeds (as this is what keeps you wheels from turning, 0 torque = 0 rotation). And set the "damageable" property to false, or else the wheels will just break instantly.

Feel free to steal code. I'll push updates as soon as I make them. I'm also changing the Hullcam mod, so I can have telescope cameras pointing at the rocket. Call it a "Kerbal control panel with many buttons and switches, allowing you to fly your rocket without a keyboard", as that's pretty much what it is.

Made my own controller: Started with code based on KSPSerialIO. But quickly rewrote just about everything: https://github.com/daid/KSPSerialIO As I needed support for a lot of switches. Not all buttons do something yet. And I still need to build the dials. But the top left switches control the 10 custom action groups. The buttons below that do mostly nothing, except for 2 controlling the camera (with HullcamVDS) and 2 controlling timewarp. Joystick controls pitch/yaw/roll (hold top button for roll). The lever left of the joystick controls the throttle. Next 6 switches control SAS, RCS, Lights, Gear, Breaks, Docking/Staging mode. Covered switch controls staging. Next 6 switches control the SAS mode (bit complex, but all 10 modes can be selected with the 6 switches) But I wanted to place a thank you for this mod, as I could not have done it without your groundwork.

That helps a lot! "FindObjectOfType" really helps in this case. Note that you can cast a "VesselAutopilot.AutopilotMode" to an int to get the proper index. Making your code: if (this.part.vessel.Autopilot.CanSetMode(VesselAutopilot.AutopilotMode.Normal)) //can you set this autopilot mode? { this.part.vessel.ActionGroups.SetGroup(KSPActionGroup.SAS, true); //enable SAS this.part.vessel.Autopilot.SetMode(VesselAutopilot.AutopilotMode.Normal); //set our desired mode setSASUI(VesselAutopilot.AutopilotMode.Normal); //jump to next method } public void setSASUI(VesselAutopilot.AutopilotMode mode) { RUIToggleButton[] SASbtns = FindObjectOfType<VesselAutopilotUI>().modeButtons; //find the UI object on screen SASbtns.ElementAt<RUIToggleButton>((int)mode).SetTrue(true, true); //set our mode, note it takes the mode as an int, generally top to bottom, left to right, as seen on the screen. Maneuver node being the exception, it is 9 }

I'm having an odd problem that I cannot seem to figure out to solve. Maybe someone knows where to look... I've build this: As you can see, I have quite a few switches and buttons. Now, I want to right most 6 switches to control the auto-pilot mode. Which I can do with: FlightGlobals.ActiveVessel.Autopilot.SetMode(VesselAutopilot.AutopilotMode.[mode]); When I do this, the ships acts as if it has the proper autopilot mode. However, the GUI keeps showing the old mode (stability assist) and I cannot seem to find a way to force an update to that part of the GUI. I can find that there is a class called "VesselAutopilotUI", which has references to an array of RUIToggleButtons, so I assume this is what handles this part of the GUI. However, I cannot seem to find a way to get a reference to the instance of this VesselAutopilotUI. (Which is most likely my lack of unity knowledge) Anyone got a tip?