Kipeo

Just looked, and yup, they're hard coded in the source in PlanetShifter.cs If you are on Windows, download Visual C# express. Create a new project as a "Class Library" Name the project the same as whatver the Alternis DLL is named Add the source files to the project. Add the refrences for UnityEngine and Assembly-CSharp from your KSP install directory\KSP_Data\Managed Edit the file to your tastes press F6 to compile Find the new DLL in the directory of your project, probably under bin\Debug, and copy that over the stock Alternis DLL For any more help, move this post to http://forum.kerbalspaceprogram.com/forums/30-Plugin-Development-Help-and-Support Which is probably a better home for it in any case.

What you're looking for would be in the source, which is available. The source files can be opened with a simple editor, and so long as you dont need to change anything in the DLL, you wont need to deal with setting up a dev environment/etc.

Good to hear! I've got it about half rewritten and refactored to current KSP standards. It's been a fun exercise, bit I look forward to seeing it fixed!

I've been spending far too much time on this. I keep telling myself I'll stop after this debug log, but I keep compiling. I cant speak for StevenRS11, but heres where I am with it: The first few lines are just for intro purposes, and things I expect you know after 10 seconds: attachJoint is now a PartJoint. PartJoint contains a Joint class. That contains ConfigurableJoint. So far, I've had to totally comment out the two methods there are to set breakingforce and breakingtorque, as those so far always give NullReferences (also commented out in servo.cs) I tried altering newJoint to a PartJoint, that made most of the code happy, but you cant set attachJoint.Joint to newJoint, as it's read-only I've gone in and am directly setting attachJoint.Joint variables. This works with the large gantry (there may be others, but so far, this is the only part to work 100%) There is no longer a newJoint object. There is still a "NpScene::createJoint: desc.isValid() fails!" being thrown, at: attachJoint.Joint.connectedBody = parent.Rigidbody; Again, it works for the gantry, not for the others I've tested. I see zero difference in the part configs, but the large gantry has the rigidbody parent of GantryLarge, and everything else has the parent as the object they're connected to. So, if I attach a gantry large to one side of a lander cabin on launch A, and the gantry 1/2 on launch B, GantryLarge is the rigidbody parent on launch A, LanderCabin is the parent on launch B, which causes the joint setup to not be valid. Commenting this out makes the joint function, but the moving portion is in the wrong location.

I went through the source code tonight, it doesn't look like it was updated for the unity 4.4 (I think?) API changes. All of the errors center around two particular function sets, and cleaning one of them up was easy once I figured out all the Unity bits. So there's one teensy little error left and I know what it _should_ be doing, but I dont know how to do it in C#. A community hotfix should be a breeze for anyone above my noviceish level.

There are definitely reasons to select the remote port as a target when docking manually! Only then will your target marker and navball center meet when you are properly aligned. Reasons you may not dock after undocking: You didnt get far enough away before coming back in. The game gives you some room to pull away before activating the magnets again, otherwise once you detached, you'd be sucked right back in. Your SAS is on, and its keeping you from snapping into place. As for documentation. Yeah, its still way early in the game's development. The tutorial scenarios are pretty basic at best. Docking is a fairly new feature (.18 I believe) and is definitely one of the harder things in the game to master...and, I think, probably the single hardest skill to explain in a tutorial/documentation.

time warp != physics warp. to use physics warp, hold alt-> and alt-< instead of > and < Physics does 2x, 3x or 4x, but does full, well, physics. Thrusting and collisions and all, and can be used any time. Time warp puts you on rails and starts at 5x but has restrictions on when you can do it.

In almost all cases, you should have a small detector on your landing craft to let you know when you're over a deposit. methods 1) watch what you're flying over as you pass over different parts of the map, and get a rough estimate from that 2) in the debug menu, there is a 'show flight debug stats' that will display the lat+lon that you're flying over. You can use this to get a better estimate of what terrain features match up with tie different lat+log 3) open www.kerbalmaps.com. there is no lat+lon markers that I can see, but the corners of the maps should the corners of the kethane map. Other than eyeballing things to get close, ISAMapSat is the second easiest. As far as I know, the landing assist on MJ is the only way to type in coords and have a mark show up on the map.

bravo! Thats a very kerbal scene ^.^

Yeah, the modeling is rough, but skill in that improves with time. As far as a rendering pass: The lack of anything outside is distracting. play around with different texture walls/skyboxes/whatever youre using. real skys work well. Perhaps dusk, get some stars and some color shifting fro a sunset at the same time? the floor is polished to a mirror-like shine! dull it down a bit. the whole scene is evenly lit. Set up 'real light' locations where actual lights would be in that scene (versus the ones set up for a good render) and have them as the shadow-casting lights. Once you have a shadow pass done, think about an AO pass as well. Probably overkill, but a good experience learning to set it up nonetheless. In your next update, tell us the story of why there are gold bars and pancakes on the table. My curiosity is piqued