OrbitusII

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?!

Indeed. Until the new patcher is out (I think it's almost ready, they just need to finish bugfixing/testing? o.O) then you will have to redownload every time. It's better than the old patcher, if people remember, which took several hours to complete a download that should have taken 15 minutes at most (for Mac users at least).

The "real-life-accurate" rockets in KSP are actually scaled down in power as well as size. If you had a full-size, full-power Ariane V in KSP, getting to orbit would be trivial (you could possibly even use it to go interplanetary!).

Unfortunately I doubt the mods (moderators, not addons ) will allow for that, since it could be considered spam by some. There is, however, the "First" button that takes you to the very first page of the thread, so that should improve your navigation. I do like the idea of version-specific comments and such, maybe as an upgrade to the Spaceport... someday... However, Spaceport is having some issues for me and I don't like using it that much anymore. Why can't I upload my plugin? No idea, Spaceport gives no explanations for upload rejections... But I agree, we could use a better plugin feedback management system.

As I said, send a PM to Skykooler. He knows I'd like to see a release for the mod but if you want it within a reasonable timeframe then be sure to let him know through his inbox.

Back to the OP: As KSP is in development, the people developing it haven't put much time into optimization, but rather into expanding the systems available to the users (proof: Bac9 and Taverius have managed to optimize B9 Aerospace so that it takes less time to load than stock parts, while significantly more parts are in B9A than stock: 175 vs 30-40ish). Harv and the other programmers have only recently started implementing career mode, so we can expect a lot more content to show up over time. From Harv's Blog Post About Development Asymptotes: This may have been intended as an explanation for slower updates, but the graphic fits well with the explanation, I think. Now if you add a fourth area, "Optimization," to the graph, that will be at about the same place as "Career" since the biggest optimizations we've had are the new GameData loader and the Terrain-On-Demand feature. Squad hasn't started to optimize the physics, terrains, or other internal systems significantly yet (to the extent of my knowledge anyway) so the game will perform rather poorly compared to things that have been out for a while. Also, regardless of optimization, KSP is a very physics and CPU-intensive game, versus things like Minecraft where slowness is caused by a terrible engine (sorry Mojang, but that Java thing has got to go) or BF3/any high-graphics-quality game with lag caused by extremely detailed meshes, textures, and thus high amounts of draw calls. You could make KSP handle physics for vessels as a whole versus individual parts, performing better, but it wouldn't be KSP.

I may be American, but I prefer the S.I. unit system versus imperial and as a chemist I use mass more than weight. Mass is constant, weight is based on gravity, and constant measurements make more sense to my mathematical mind. CoM

Posted the In-Development plugin code on the OP.

So since the development is taking slightly longer than expected (crazy, right? ) I'm going to start putting the in-development versions on the development thread for public in-dev testing. This should hopefully minimize the testing required by me, but will also allow for more observable progress and will keep the mod more public. Here's How That Will Work: 1. I develop a new part of the code and do a quick test on my own 2. People interested in an incomplete version and testing that version can download it from the development thread 3. The interested people can test and use it as they please (no distribution!), providing feedback on the development thread so I can improve the code before a full release 4. Once I get all I need for a release complete, I will remove the download link from the development thread and post the complete plugin on this thread 5. The process will repeat as I develop new features for anything in the plugin (including, but not limited to, Frameshift functionality, magnetospheres and harmful radiation) I can get the current version ready to download shortly. The parts included by default are a thermometer modified to use the solar heating PartModule and a random part that will serve as a coolant system, plus the parts already included in the heat sinks download. *The zip file you download will include a readme to tell you how to set up other parts to use the solar heating and coolant system modules, plus a reminder to post feedback on the development thread, linked below Development Thread Link Just a little birthday-induced generousness, I guess...

Using mods is the choice of the user or the creator of a challenge if you choose to do it. In the case of the latter, it's temporary until you complete the challenge, then you can go back to the mods you were using before. You can take recommendations for mods to use, and if you're a YouTuber/livestreamer, then you set the rules and people can suggest mods to use following those rules. Cheating doesn't exist in a single player sandbox except as self-imposed limitations.

I call it Kerbol, but refer to it as the sun when programming plugin stuff. "Kerbol" thus goes to things like Kerbolar orbit. Pretty simple yet logical in my opinion.

Hm... try it with ModuleAnimateGeneric (the stock animator) to see if you get the same issue.

Indeed it does! What I might do is combine both PT threads into this one since the frameshift & magnetospheres will use the same .dll file as solar heating/heat sinks/coolant systems/everything, so there's no need to split up the plugin and have different versions out there. Edit/Update: Having a minor issue with actually changing the temperature, but I can fix it easily. Raycasting appears to be working, but I can't really test it with the temperature change not working properly.

You have the cases for the animation name correct? ("Spike" and "spike" are two entirely different things in programming) Find the animation in Unity and make sure you're using the animation name, not the animated object's name.

It's a part that comes with B9 Aero in the Science tab that gives customizable info on the current craft. I haven't had much success with B9 planes except for one with B9A 2.5... I need to see if I still have that lying around... it was almost an SSTO...

Are you making sure to specify the correct animation in the config file? It should look like: MODULE { name = FSanimateGeneric //or whatever it is... animationClip /*or whatever it's called*/= animationName //animationName needs to be replaced by the name of the animation you made in Unity //other stuff }

I've been trying to set up a Mun base for a while now, without much success... I'll definitely put one there and this should make it easier to expand.