kujuman

I was so suspicious that I tried this on an entirely different install than my career save. I'm very glad I did

icymi http://forum.kerbalspaceprogram.com/threads/86682-Appilcation-Launcher-and-Mods?p=1280014#post1280014

Aside from what FleetAdmiralJ said, there may be some differences in how the part is activated. I had to test a nuclear engine in orbit and pressing spacebar would not activate it, right click on it revealed "Run Test" which started the engine up as if I had staged it.

I was wrong about RUI* (it may be useful drawing parts of buttons) We probably want to look at UIApp. This is going to be easy

Just for any potential modders seeing this topic, steps 1&2 are easy enough to do http://forum.kerbalspaceprogram.com/threads/50384-WEB-Parachute-Calculator-Updated%21?highlight=parachute

It seems to me that the place to look is RUI* I'm an idiot If past is any indication, Mu will post some documentation within the next week or so. Also if past is any indication, someone will figure it out by then too

Neat. Not for me, but it did take me a bit to get used to designing for mach tuck and exploiting slats (they seem to work at increasing AoA before stall, but it could just be additional lift area/placebo), and I've got a pretty decent understanding of aero. I can see the lack of mach effects being a huge difficulty reduction for the spaceplane crowd.

Company names and pictures are in GameData/Squad/Agencies It looks pretty easy to add/change companies using module manager, but this is untested. That's almost as easy as I was hoping it would be. Thanks for taking the time to figure this all out.

For me, the portraits are more CCTV like (slow frame rate, possibly grainier, but very subtle) like how it used to be before ~.19-.20. Between then and .23.5 the portrait animations were very smooth. In the changelog it says the old C7 radiator and nacelle now are intakes and small fuel tanks. But the changelog hides the fact that the radiator is now backwards to be more like an intake (this is stated in the part description basically ). The radiator looks pretty cool. Link to full size

For me, the portraits are more CCTV like (slow frame rate, possibly grainier, but very subtle) like how it used to be before ~.19-.20. Between then and .23.5 the portrait animations were very smooth.

I am assuming you mean the big station hub thing? If so 1) Yes, you need to add docking ports for each side you want to dock to. 2) You shouldn't need to add a separator. A docking port can be in the middle of two parts in the VAB/SPH, and right clicking the part once in flight will allow you to "Decouple" the part. 3) If each node will have equal TWR (or thereabouts), you don't need anything else for a reasonably sized vessel. However, I'd remind you that if your docking is anything less than perfectly aligned, you will create a rotation when you fire the engines (assuming that my mental picture of what you're planning is correct) To help with problem 3, many people use multiple docking ports to attach two items (it can be tricky getting the spacing of them perfect though). This example: | is a fuel tank, ^ is an engine, - is a docking port. | | | | - - | | | | | | - - | | ^^ I hope this helps.

I've not been able to get a seafaring hack to work, but primarily because I can't get the transforms figured out.

Good morning, Today's link is to v0.3.9, the 0.4.0 release candidate (assuming no bugs are found, 0.3.9 becomes 0.4.0). Please be aware that this download is not fully tested (particularly the Custom Runway feature) in all types of vessel, bodies, flight states, etc. For this reason I am not updating the main post yet. The link to the github download. Do not use unless you are still in KSP .23.5, use v0.4.0 or higher ===v0.3.9 Changes=== *RPM keys are now softcoded to prop.cfg file definitions. This should allow much more flexible adaptation of the HSI to various RPM props. *RPM now features same text overlay as standalone, including runway elevation. *Included MM configs updated to reflect this -New Features: *Custom runways from in game. Position your vessel at the desired touch-down point and either use auto heading and elevation or use your own (auto based on current vessel's orientation and elevation). Custom runways do not have marker beacons (can still be added in .cfg). Custom runways saved to separate file. Custom runways can be deleted in game. The custom runway GUI can be accessed from the Toolbar.

All of the parts (repulsor included) have a stock ModuleWheel which is a container for the WheelCollider and all of the physics associated with wheels. The custom PartModules attached to these parts modify that ModuleWheel. There may be a way to force the ModuleWheel to collide with the ocean's layer (though I think he'd have to do something like ocean.enableraycastcollisions), but a better bet would be to calculate and add an up force on the collider itself. This second way wouldn't get WheelHit information, but I don't think the repulsors use that method anyway. So possible probably with enough work, but it's set up that way (AFAIK). Edit: A more hackish way that is so stupid it might work would be to dynamically create a collider at sea level under each wheel when over the ocean. I'm actually trying this now.

I think "Because the update has come to include the (assumed) extra distance" means, "If extra physics distance were to be included at some point in KSP development, this update would be a good choice to do so as it would improve gameplay in a meaningful way" rather than "extra distance confirmed for KSP .24".

I really like this idea. I'd like to be able to fly the main KSC flags at half-mast too.

So what needs to happen (for the outside turn wheels) is for the wheelcollider proper to be forced down with the same force as the attached rigid part is forced up. There is no net translation force on the vessel, the outside wheel increases its force on the ground, and the body of the vessel rolls towards the inside wheel. To check, this is the same net result as increasing the spring force? I think so. I'm away from my development computer, but looking through the unity scripting API, there's an attachedRigidBody member of WheelCollider. I think for all intents and purposes that's the same as the main part collider. If you add a force to the attachedRigidBody and an equal and opposite to a force added to WheelCollder.collider (or whatever the actual wheelcollider is), this should produce the anti-roll behavio(u)r you're looking for. Of course, whether or not Unity lets you actually apply forces to these parts correctly is anyone's guess. I hope this helps, and good luck. If you need any help with lists, I can help, though they are pretty straightforward. Edit: I have a hard time judging dynamics (I don't know what the behavior should "feel" like), but here's a static test.

Ok, thank you. I didn't find a HL fuselage cockpit, did you mean the S2 Reusable Pod (it looks kinda like a space-shuttle with black tiles on the bottom)? I'm thinking it's a problem with that cockpit/config files because everything else indicates it should work fine. I've D/L'd and installed B9 and the K3 internals, and it seems to work fine for me :/ This warrants additional investigation. 1) Does it work in the stock cockpits?

1) Which version of RPM do you have? Are the other features working as expected? 2) Which command pod are you using? 3) Please describe "just isn't there" more. Is the display not cycling when you press the "A" key on the MFD? 4) You need toolbar/the standalone version to make the RPM version work. Are you able to use the HSI with toolbar outside of IVA? 5) This mod is very particular about where it gets installed. Is the folder "KerbalScienceFoundation" directly inside of "GameData"?

What it does is increase the angle of attack (AoA) of the flap relative to the wing. Increasing AoA will generally pass through three stages, in increasing amounts of AoA: 1) increase lift, 2) increase lift and drag, 3) stall the wing, massive decrease in lift, increase in drag. Long answer short: yes, you can fly more slowly unless your flap/brake max setting is too high. I try to keep my flaps centered around my center of Lift. If your flaps are behind you center of lift and they then create more lift, your plane will tend to pitch down. So flaps on the tailplane can cause your plane to nosedive. Spoilers on the tail will tend to do the opposite and pitch the nose up. "Flaps/Brake M..." is Flaps/Brake Max angle. Flaps get set in four settings. At flap 0, AoA is 0. At flap 3, AoA is Flaps/Brake Max angle. Flap 1 and flap 2 provide intermediate values. For simple aircraft, a good starting place for flaps is 40. If you use the FAR analysis tools you can tweak these values to get the performance you want. For a starting point I only use flaps on the wings unless I'm doing something special. An example of this: Sometimes my spaceplanes will have the Center of Mass shift very far forward when they are low on fuel. This can make keeping the nose up difficult. To solve this, I sometimes add positive value flaps to canards or negative value flaps to my tail plane. I hope this helps

Progress update for 0.4.0 -The RPM buttons that control G/S and runway are now configurable in the .cfg for each RPM installation (btnNextRwy = btnID basically) -The RPM display no longer uses RPM for text display, and now looks identical to the standalone version -Work is progressing on the "Add/Edit/Remove a Runway definition in game" feature. I have successfully saved runways created in code to a .cfg file, which would load next time KSP loads. --next major step is implementing the GUI to work with it. I know what I want to have it look like, so it's really just sitting down and writing it. should be fun The plan is to have the user enter a runway name and then move a vessel to the location they want the touchdown to be at. Heading and elevation will be automatically determined, unless the user wants to have manual values. the Loc beacon is planned to be located automatically 1km from the touchdown point. note: I'm not redoing how runways are defined, at least not until there's a reason to do so (like other types of nav aids). Cross-posted in the development thread.

Progress update for 0.4.0 -The RPM buttons that control G/S and runway are now configurable in the .cfg for each RPM installation -The RPM display no longer uses RPM for text display, and now looks identical to the standalone version -Work is progressing on the "Add/Edit/Remove a Runway definition in game" feature. I have successfully saved runways created in code to a .cfg file, which would load next time KSP loads. --next major step is implementing the GUI to work with it. I know what I want to have it look like, so it's really just sitting down and writing it. should be fun The plan is to have the user enter a runway name and then move a vessel to the location they want the touchdown to be at. Heading and elevation will be automatically determined, unless the user wants to have manual values. the Loc beacon is planned to be located automatically 1km from the touchdown point. note: I'm not redoing how runways are defined, at least not until there's a reason to do so (like other types of nav aids). Cross-posted in the release thread.

This gave me an excuse to break out .15.2 and see what was in it. Throttle defaulted to 50% on launch then. https://www.youtube.com/watch?v=YvwFnZTI3ME&feature=youtu.be Note: this video...is not quiet.

You can't file a lawsuit and then adjudicate it. Unless you're Q. And you're not Q. Even if you were Q, Q lost his case. Besides, preponderance of evidence It's Maxmaps narrating...</sorry></read:>

Once the player gets past the scripted early missions, the hope is that they can do their "chosen accomplishments" by picking the procedurally generated contracts that are most appealing to them. We may not see things like station resupply missions or building a kethane refinery on Eve, but the understanding we have is that those sorts of missions can be modded in with some relative ease. And anything like setting up a RemoteTech network or sending a mapping satellite might not get its own contract, but it could be a "capital improvement" that your space program eats to better be able to pull off other contracts. These are my hopes anyway, we'll see when the update drops.