Bobe

These might be of interest to you: http://forum.kerbalspaceprogram.com/threads/86695-0-25-USI-Exploration-Pack-Small-parts-big-adventure%21-v-0-2-5-2014-11-01 http://forum.kerbalspaceprogram.com/threads/94947-Exploration-Rover-System-by-A-S-E-T-(10-10-14) http://forum.kerbalspaceprogram.com/threads/86343-Portable-Rover-Components-New-project-from-ASET-%28up-29-07-14%29

Why would you put solar panels on a heat shield? What's wrong with Near Future Solar? What is DR gameplay?

Looks good. Even though it says it depends on SDHI, it looks more like a replacement for it. No big deal, just more parts to experiment with. However, one thing I'm really struggling with is trying to include a dish for RemoteTech. The DTS-M1 is too large and prevents placement of RCS blocks on one side of the service module. It looks like Orion has a small dish that extends (flips) up from the underside of the service module. Is there an addon that has a similar part to this?

Would it be possible to make a shrouded version of the adapter to replicate the Orion in its transfer configuration: I don't suppose you have any plans to replicate the interim cryogenic propulsion stage? I know someone was working on it a while ago, but I don't think there's been any progress on that since earlier this year. I can sort of emulate it with KW Rocketry tanks and a structural adapter, but it just looks kinda weird.

Is it possible to create a plugin that automatically adjusts the output of a solid rocket booster such that thrust decreases at an exponential rate as fuel approaches zero? This would eliminate the abrupt and often violent deceleration experienced by the vehicle when the boosters suddenly cut out and allow you to jettison the boosters while they are operating at low thrust in order to maintain near-constant acceleration during separation. Since autostaging occurs when fuel reaches zero, and you'd likely want to jettison the boosters shortly before that point, since the thrust output during the last few seconds would be too low compared to the dry mass of the boosters, perhaps the plugin could somehow trick the game into thinking they are empty when they are actually at about 1-5% fuel remaining. Also, I'm not sure exactly how parts work in the game, but it would be nice if it could be applied to all boosters as a category rather than individual parts to allow easy support for add-on parts. I suppose also it would be convenient if this behaviour could be toggled as a tweakable while in the VAB/SPH.

Right, like I said. So would you think it's reasonable to have SRBs in the game gradually lose thrust as the fuel approaches zero? Not sure if something like this is achievable with a mod.

Do you mean in game or in real life?

I was just about to post a thread in the suggestions forum about making SRBs throttle down before separation (essentially just by adjusting the thrust output asymptotically towards 0 fuel), but then I thought maybe I am misunderstanding how solid boosters operate. Obviously in Kerbal SRBs burn at a constant rate, varied only by the thrust limiter, until empty, at which point the vehicle experiences an abrupt change in acceleration, depending on the mass. When I watch a real launch, solid boosters appear to throttle down and burn at a low rate before separation while still burning so as to maintain constant acceleration. Is this the case, or do we just get the illusion of the boosters burning at lower thrust because the lower air density doesn't produce the same exhaust condensation as near the ground?

I recently gave RemoteTech another go (a proper go this time), and I found it unnecessarily frustrating trying to position the satellites relative to each other. I know they don't have to be exactly equidistant, but I like to be as perfect as possible. What I'm proposing is a simple (I believe) tool that would allow you to set a target and then right click anywhere along that craft's orbital path to plot a point. This point would emulate the orbital parameters of the target craft at this point, meaning the point would orbit around at the same velocity as the target craft at any given position. This would allow you to then rendezvous with this plot point rather than an arbitrary distance ahead or behind the target craft, which is often difficult to do with precision, especially when the maneuver node is shaking. This ties into another request I have: Maneuver Planner Interface Overhaul. In addition to manually adding points, some sort of preset configurations would be nice. So say you set the target, you could then right click the target (or have a separate UI window, whichever works best) where you can select either a degree value for a single point. So say you select "180°", this would plot a point on the opposite side of the orbital path to the target. Similarly "90°", "270°" or even a manually entered whole number could be used. Or you could input a number of points to plot at equal angles from the barycenter, similar to the symmetry duplication in the VAB. This would have come in handy when I was trying to launch six equidistant LKO satellites. I managed to get them roughly in a hexagonal arrangement, but it could have been a lot more precise and far easier with a tool like this.

I'm getting the same thing. After the 0.25 update, I started fresh; deleted all saves and mods, essentially just deleted everything except the core data and re-downloaded the rest. Then I installed about a dozen "essential" mods including Active Texture Management (basic) and Environmental Visual Enhancements. I never had this issue before with the same setup on earlier versions. It could always be related to my memory sticks, I've had some issues with them recently. But those have been related to bad sectors resulting in BSoDs, it shouldn't really cause a game to crash because of low memory before reaching such a critical error.

Good call, I didn't even consider the throttle. It really seems very simple when you can consolidate four different manipulations with just one modifier.

I suggested this a while ago in the main suggestions and development forum but it was more or less ignored or misunderstood. However, it's pretty safe to say Squad wouldn't make such a big change to the maneuver nodes, so I thought I'd give it another shot here. I'm only linking this original thread for reference, I don't want it to be necrobumped: http://forum.kerbalspaceprogram.com/threads/65655-Creating-maneuver-nodes-by-dragging-orbital-points In a nutshell, it would basically reverse the process of planning maneuvers by allowing you to plot where you want to end up, not how you burn at the node. Too often I've become frustrated trying to make minute adjustments to the nodes six axes and its position along the orbital path, whose interface allows for anything but. It just made sense to me that maneuvers should be determined by the desired output, not the guesstimated input parameters. Some people might argue that this is not in the spirit of KSP, which is why it would work best as an optional add-on. Why don't I just use MechJeb? Well I do, but sometimes I want to plan my own maneuvers, and MechJeb doesn't allow for some of the more obscure varieties of maneuvers.

Welp, looks like it was just the center of lift. I removed those leading strakes such that the CoL and CoM are in the same position when the fuel is almost empty and it glides perfectly to a soft touchdown. I did have canards on an earlier version, but it got out of control and I had too many control surfaces working against each other, ultimately only adding more useless weight. I knew only having those four surfaces at the back would make atmospheric flight tricky, but I really don't need much maneuverability (though it does turn quite well with enough thrust). I didn't expect such a massive aerodynamic effect if the CoL was slightly off the CoM, usually it just means the attitude trim is off.

This is my first attempt at making a SSTO spaceplane. It took me a fair few iterations to get the design right in order to achieve a 100km orbit with leftover fuel, but I finally got it working perfectly. However, the issue now lies in the landing sequence. Bear in mind that it's designed first and foremost as a shuttle, so I wasn't expecting fantastic aerodynamics in atmo. While approaching the runway, which is often powered to compensate for bad estimation of re-entry drag, I constantly have to pitch down slightly, but this is merely a minor annoyance no doubt caused by the center of lift being too far forward without the fuel. But as I'm roughly ten seconds from touchdown, I'm typically going just under 100m/s on a normal glide slope. In normal circumstances I would throttle down or idle the engines to glide to the runway, but as I do this, my plane just lurches upwards. If I didn't hold pitch down, it would probably just point straight up and stall if not flip over. Then it comes back down, after losing about 50m/s, and typically crash. It's like it detects a drop in vertical speed below a threshold velocity and goes into panic mode to avoid a crash. No matter how careful I am with my attitude and speed, it always performs this "Oh .... the ground pull up pull up pull up" maneuver. I don't suppose anything in Mechjeb could be playing with it? I wasn't using Smart A.S.S. or spaceplane guidance, I even toggled off all utilities just to be sure. Hell I tried landing using Mechjeb and that was sure to crash it before it even reached the runway. This is roughly the configuration during landing, with a bit of fuel left in the aft fuselage:

https://soundcloud.com/nasa I know some mods already make use of freely available sounds, so perhaps this could also be useful to someone. It contains a lot of various ambient clips like engines and quindar tones, as well as mission-specific callouts an commentaries. Maybe you might just enjoy listening to them. The Cassini Saturn Radio Emissions is particularly creepy. Source article with links to more libraries: http://createdigitalmusic.com/2014/10/nasa-posts-huge-library-space-sounds-youre-free-use/

I could've sworn I tested after installing that, but either I didn't or it just didn't work that time for some reason. It's working fine now. I assumed that "dependency" just animated the decouplers rather than added the actual functionality.

Anyone have any idea why I don't get the decouple option for the service module either in the action group manager or the right click menu? It's attached to a Mk1-2 command pod with heat shield as standard.

No problem, glad to hear you're on top of it.

I can't check right now, but I think I'm getting the same issue. It occurs when I switch from a vessel to my station, which has FusTek parts. Very frustrating as Ship Manifest basically shuts down and you have to go to the Space Center and back to reset it, unless there's a manual reset I haven't found. I'm not sure the problem lies solely with FusTek, as it does work with a FusTek vessel, it's only after switching to another vessel and back does it break. Versions (of what I believe are the relevant mods): Ship Manifest v0.23.3.5.3.2.3 CLS v1.0.3.0 FusTek vX0.04-3-1 DEV BUILD Module Manager v2.0.7 EDIT: I've just checked and it seems I get a different error: Error: in Ship Manifest Window - SourceTransferViewer. Error: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[Part]].get_Item (System.String key) [0x00000] in <filename unknown>:0 at ShipManifest.ManifestController.SourceTransferViewer () [0x00000] in <filename unknown>:0 In the log file that block is repeated what seems like a couple hundred times. This occurs when switching from and back to a FusTek vessel with the transfer window open. When switching from and back to a FusTek vessel with just the main Ship Manifest window open, the resources buttons cease to work. Clicking on them flashes the CLS part highlights briefly and returns to normal. This error doesn't seem to output anything to the log.

Just thought I'd mention that Kethane seems to stop working properly when combined with Cargo Transportation Solutions. The parts will load fine, but scanners won't record data properly, at least not in real time. Kethane extractors and other parts still work, just the scanners as far as I can tell. This was also patched with MM 2.0.7.

That is the complete opposite of the most economical way to reach orbit. On a body without an atmosphere, like some have already said, you want to apply thrust at as low an inclination to the surface as possible as early as possible. Depending on the mass of your craft, there is no point going straight up initially, that method is used on planets with atmospheres to minimize the amount of drag. When ascending, keep an eye on your ship's pitch relative to its thrust vector. After lifting off, pitch down until the ship's vector starts to drift away. As your velocity increases, you can continue to decrease the pitch as long as you are travelling in the direction you are pointing the ship in, but obviously not below 0 degrees.

Basically this. All parts for repairs and experiments would have to be stored in a cargo compartment ala KAS.

I'd like to be able to repair some parts, such as solar panels, but the repaired state penalty might be a bit too much. After all, in real life when a component needs to be repaired, they either replace the faulty parts or the whole component itself. There would really be no reason it would perform worse than if it were never damaged. In reference to the engine example, I don't see any way an engine can or should be repaired. I know it's still a game and doesn't have to follow real world scenarios, but being able to repair every single part perhaps diminishes some of the challenging aspects of the game. I'm not even sure how an engine could come to be damaged yet still repairable. But in general, it would be great if we could launch repair missions. This would involve loading packaged parts into a cargo bay, perhaps a stack part similar to 6S Service Compartment Tubes, but instead of actually attaching the parts you are simply adding them to an inventory, like in KAS. The cargo bay part itself would just be a solid object in terms of the model. Then during an EVA, a Kerbal could go to the cargo bay, retrieve a part and use it to replace a damaged part.

I agree. Perhaps a per-mission debris bonus could reward more proactive debris reduction techniques. Successfully returning a piece of debris could yield a bonus score or reputation points proportionate to the cost of the part. For example, say you launch a rocket with two SRBs that cost 1000 "whatevers" each. Separating and letting them fall back to the surface would reward you 5% of the cost (100 total). Having them fall into water would be 10%. "Soft" landings with parachutes would yield 15% and 20% for land and water respectively.

I really like the checklists idea. It would probably suit the scenario I had in mind when asking about multi part transfers well. The scenario involved docking a lander that had multiple kethane tanks to a station and then unloading as much kethane as possible from all tanks equally, so that if there was any excess the lander would remain balanced. It would make things much more convenient to have all the steps in the process planned out and executable as single action. This is probably going far beyond your intended scope, but would it be possible using a system like that to formulate a timed launch sequence? For example, executing a launch command might include waiting a few seconds (for a countdown), igniting the main engines and then a couple seconds later releasing the clamps and igniting any SRBs at T0.