OrbitusII

Then I can work on prototyping the plugin. It's a fairly simple process, just find a kerbal (Kage Kerman, if you want) and replace the texture(s) on his head material with the Nicolas Cage one(s). Maybe 40 lines, if I did it inefficiently.

It would be a relatively simple plugin, actually. If you can get the textures then I can write the code! It might take a few tries to get it (the code and the textures) right, however. Best. Fan art. Ever. The only thing that might one-up it is a "Gangnam Space Program" one...

And so it has begun...

You sure? This guy became famous for putting googly eyes on rocks... But more on-topic, Rareden requires a .craft file with context (screenshots), and only when he's accepting requests, which he is not at the moment due to a lot of requests which have to be processed and/or completed.

I've noticed that the Landing Gear-based enabling is really finicky and it's caused some control issues for me. Is there a way to disable this? The brakes are also really wacky for the Mark 6 when on low-gravity bodies (I've only tested on Mun so far, but the issue remains...), resulting in some really weird wiggling around. Specifically it looks like certain points on the tread bottoms get glued to the ground and then the rest of the rover wobbles around madly. Here's the .craft file I'm using: https://www.dropbox.com/s/jny9omxbz0jri4x/Munar%20Utility%20Vehicle.craft It might just be a lack of struts, but at 33 parts I don't really want to add any.

Actually yeah, the real problem would be achieving a stable orbit in one of the sub-SoIs, since orbiting one of the bodies in a binary system is a very difficult task. The way you could do this is really small SoIs... Hm... it might be worth writing a plugin to create a binary system in KSP, just for kicks.

One of the most effective ways to reduce rigidbody wobble in Unity is to add more joints between the rigidbodies. It's like adding more screws to the connection between two pieces of wood minus the orientation and volume requirements caused by the wood and screws (Unity joints can be way off in space but still connecting two objects, and you can have two joints infinitesimally close to each other).

I don't think I'll be able to help much considering I have my own mods to work on and a computer to buy parts for and build, but if I get the ability to then I can provide Unity help (3 years worth) and some programming depending on what needs to be done.

Not necessarily, so long as you have everything orbiting the barycenter then a binary system is quite feasible in KSP. True, you couldn't have things orbiting the individual objects, but it could work well enough for a game. I'd definitely like some rings around planets. It would add so much ambience to flying around gas giants...

That's really interesting... I've been working on a plugin that models the solar heating better, and there's an In-Development build out right now if you want to try it out. Ze link: http://forum.kerbalspaceprogram.com/showthread.php/25420

My new plane, designed relatively well compared to my typical designs, supposed to be an SSTO. Knocked the tail off after taking off, then glided for about 10km. As it turns out, it's a great glider so long as you set the throttle up one small notch and the trim correctly. Unfortunately, MechJeb accidentally put it into a slow, painful flatspin. My only choice was to crash it into the water of the bay north of KSC instead of gliding to the land just past the bay. Johncas bailed at the last 30 seconds of the plane's life, but stuck on the cockpit until it hit the water. Johncas, you persistent little Kerbal, I'll be sure to promote you from VR test pilot to actual pilot for handling this maniacal plane so well.

The current demo (0.18.3) has special settings that limit the parts to the stock parts in 0.18 and plugins can't be used in the demo either.

I can check the configs real quick to see if something might be messed up. InDev3 should be out sometime in the next few days. All I have to do is a part check to prevent GUI glitching and then add in the window method. Update on the raycasting (as much as I can provide it)– for some reason KSP doesn't seem to like the raycasting, since it works fine in regular Unity... I may talk to Mu to see what's going on if I still can't get it figured out by the time the rest of the plugin is finished. -One solution I am considering is a periodic check every 5 seconds or so which sets a boolean value that either enables or disables the temperature change induced by illumination and distance from the sun... -Another could be to set the collider during OnStart or OnLoad, making it stay the same as opposed to getting the collider(s) every frame; but I think that the problem is the raycasting, not the collider detection... I also figured out why PTanimateUniversal wasn't working– as with the raycasting, I needed to access the Animation component on the child of the object that had PartTools on it when the part model was exported from Unity so that I would get the expected result; it wasn't a problem with Unity.

It'd just require a plugin to detect when the docking port is docked (or close enough for the animation to have an effect on how sturdy the docking is, which would also require a trigger or raycasting)

I've started to use KAS to provide easy means of attachment- all I need is a winch and an attachment node, then a Kerbal can go and hook them up. Good for resource transfers at least (if you don't want Kerbals moving through tiny tubes)

Over powered I think. Yes, it means "over powered," but it could also mean "original post" depending on the context of its use. Anyway, the Monoprobe is powered by RCS fuel, and while it's only got 638-ish m/s dV, that's enough to land on a lot of the bodies in the Kerbol system. I should probably update it to use the 0.20 GameData system...

Unity doesn't support time machines... As far as I know. o.O You can accelerate time forward (obviously...) but not backwards. I can look into having a negative timeStep but I doubt it will work. Theoretically you can go backwards in time, but actually retrieving data that was trashed by time moving forwards will be very impractical if not impossible. It's much easier to create new data based on data you currently have, but extrapolating data backwards can only go so far before it doesn't accurately reflect the data that existed at a certain point in the past. The solution to your problem should be quicksaving after each node is performed, that way you have a backup for accidentally going too far.

Sounds good, I look forward to using this!

For the proximity detection, do you want the missiles to automatically lock onto things that come within range? I accomplished that a while back (not in KSP, just plain Unity) so I can send you code if you want to look at it. Oh– same goes for the guns. Ammo should be a pretty easy matter, I already have the single-shot reloading (you can make an 18th-century rifle or a modern machine gun by changing a single value is what that means) taken into account so it just needs to be translated to C# (trivial, believe me) and the ammo usage needs to be added.

I see what you did there I am looking forward to the release. This + Extraplanetary Space Centers (when Skykooler releases it...) = mobile launchpads EVERYWHERE!!!

I believe you have to set the IVA to layer 16 in Unity. I don't remember what the layer is called but the important thing is layer 16.

It's just a PartModule, so you can add it to any part.cfg like adding in an RTG (just add the module name and the settings, et voila!). This applies to both the Thermostabilizers (heat sinks and powered systems) and the SolarHeating modules. The one thing that SolarHeating does require on a part is a collider set up in Unity. I have been experiencing a little bit of a bug where the heating and cooling on parts with SolarHeating is jumpy, most likely due to some raycasting derp, so I'll look into it but I'm not quite sure why it's doing that... I'm implementing some GUI to improve debugging of the code, but for now I'm not quite sure what the problem may be besides weirdness in the Log... What I can do at the very least is combine all the Debug.Log() methods into one, thus ensuring that all the data for the part is spit out at once, but a window would help clean up the Log a lot and allow for a more open screen, since the Log takes up a lot of space. All I really need is to see whether or not the part is hit by the raycast when it's lit up visually, so either will work.

In-Development Code is now version 2. Solar heating works to an extent, I'll do some more testing on my own along with adding some debug GUI.

That's if you did something small; if you did a full-size planet or moon, you'd need to use a plugin to make the "planet" into an actual planet or body complete with SoI, gravity, atmosphere, etc.

You can indeed make your own planet. HOWEVER! you may not want to considering the amount of detail that Squad has put into the planets as they exist today. Compared to actually making the planet, coding it into the game should be comparatively easy (and doing both effectively may land you a job with Squad! Ok, maybe not, just wishful thinking ) If you are interested, there should be assets available on the Unity Asset Store that you can put in a plugin to procedurally generate and texture large amounts of terrain or even generate whole planets when needed (in the case of the latter, there is a "Space Graphics Toolkit" available that can generate planets and atmospheres. The former may not be worth it...)