OrbitusII

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...)

That kerbal should be dead! And I'd like to see 300 of the biggest boosters!

Simple solution: MOAR PARACHUTES Complex solution: MechJeb on all modules, pre-enabled to land safely and automatically. Mechjeb can remotely operate vessels that are not the active one, so long as the vessel (vessels) in question is (are) loaded into the physics system. Stock solution: MOAR PARACHUTES, or lithobraking, or landing gear. Honestly, there's a lot of ways you could do it, but whether those solutions are valid or not is dependent on testing. Edit: or you could do it like Spaceisbeautiful did on the top of this page.

On the subject of Unity being slow to process due to a lack of resource utilization, I both agree and disagree. Agree because rigidbodies (the Unity physics component) are not the most processing-efficient thing in the engine. I haven't paid much attention to the PhysX version that Unity uses or the upsides to upgrading to PhysX 3, but an update would be good if only for staying up-to-date. Disagree because the amount and detail of the terrain is ridiculous, and Unity terrain is even more inefficient than rigidbodies, especially when you're looking at a large amount of terrain (for example, viewing the planet from orbit will drop my framerate pretty significantly). No idea why this is, but it could definitely use some optimization.

It looks like the docking port on the module you're attaching is colliding with the adapter/hub/thing, so maybe add some batteries or something as a spacer... move the docking port on the hub out away from the hub a little, to minimize/eliminate collisions while docking.

Figured out a major issue with the raycasting: it didn't take into account the fact that colliders may be on the children of the object that the script itself is attached to! All that needs to be done is a check throughout the children of the object and it'll work!

That's a great idea, thanks! I'll search around to see if I can find him and then I might send him a PM.

Take a look at the Unity Script Reference for all your Unity needs! http://docs.unity3d.com/Documentation/ScriptReference/index.html Well, most of them anyway. The Unity reference pages don't have API for KSP stuff– that's found on the KSP wiki and is largely incomplete. http://wiki.kerbalspaceprogram.com/wiki/Community_API_Documentation The big thing you want to use is the Joint class (a native Unity thing). http://docs.unity3d.com/Documentation/ScriptReference/Joint.html The best two for rigid joints are Fixed Joints and Configurable Joints, although the latter has a bit too much configuration available for my taste. If you need help with the Unity syntax, I've used it for several years and I should be able to help, so feel free to shoot me a PM anytime.

The title should say it all, but this is for posting Starcraft 2-inspired vehicles in KSP. I will be working on these a lot, but feel free to add your own renditions of the stuff in that game. I won't limit it to SC2 only, so feel free to post things from the original, but for now I'm working on vehicles, ships, and equipment from SC2. The goal for this is to make functional recreations of the stuff you find in the game, minus the Zerg, to see how they actually accomplish the task of designing these things. I'll do my best to recreate the vehicles, and this is an ongoing project, so things can change. The Hellion "Ready to raise some hell!" Fast, agile, and easy to mass-produce, the Hellion is a great Zergling-control vehicle. Based off of: The only noticable issue I've had is flipping it over at high speeds on low-gravity bodies, destroying the RTG that serves (aesthetically) as the flamethrower. I could probably throw some more on to negate that, but keeping the mass low is critical to enabling it to go fast, which is one of the key features of this vehicle. I have two versions at the moment; one uses B9 Aerospace to get an attachment node on the back, while the entirely stock Hellion has a drogue chute to keep the look, albeit at the cost of functionality. Craft files (Dropbox since Spaceport hates me ): [Hellion] Planned: Medivac The real killer for this one is going to be balance. I'll probably use B9 or something to get the VTOL engines, making it a mod craft, but oh well. There's also the possibility of giving it two sets of engines: one VTOL, one forward flight. Still, balance will be a pain, not only for the wings and CoL but also the VTOL engines and CoM. This is one of the reasons I gave up on the SCV for now. The solution I'm considering is a set of engines under the front for VTOL mode, moving the CoT forwards towards the CoM. Only testing will tell how that works out, however... Feedback on the handling, effectiveness, and overall accuracy is appreciated, and as I said feel free to make your own. The more the merrier!

Started building a launcher for my new Mun base's command center using KW... Dear Jeb what have I gotten myself into?!