Bobe

So it needs to be fixed.

Are there any mods available or in the works that overhaul exhaust effects? What I'm referring to is the way the exhaust changes in appearance as velocity increases and pressure decreases. This video is a good example of what I'm talking about: Note how at about 1:20 the exhaust is a very fine column, at about 2:30 it's starting to expand out, at 3:00 it is much wider and has become somewhat transparent, at 3:50 the air is no longer burning red and we can just see a very wide vapour plume. At about 5:20 when the second stage ignites there is no visible exhaust (since there's no air to react with). I'm not too learned on the subject of engine exhaust, I'm not even sure the terminology I used was correct, so if I have misunderstood something I'd be happy to learn more about it. Anyway, I'd very much like to see these sorts of dynamic effects and I don't think it's the sort of realistic thing Squad has any intention of implementing.

Is it just me, or are ambient sounds incorrectly part of the music audio channel? I often want to turn the music off and leave the ambient sounds (birds, ominous hum, etc), but muting the music seems to disable both.

Sorry, my stupid mistake. I did in fact have the ullage motors in a stage before the decouplers. It's strange because when I checked on the launch pad they looked fine, but when I just now loaded it up in the VAB they were separated. I hope you take my word for it that I don't usually make silly errors like that.

So it probably goes without saying (and not reading the last few pages of the thread) that this is not 100% compatible with 1.0.4. I did a quick test by sending a FLAT to Duna. First thing I noticed is it messed with the staging and kept firing my SRBs' ullage motors at the same time the SRBs themselves are fired, even though I triple checked that they were in separate stages. Disabling MechJeb's autostaging allowed me to circumvent this. Not sure if it just a compatibility glitch or an omission from the start, but I feel the FLAT really should store some electric charge. Lastly was something that was partly my fault and partly something I don't yet understand. I had the FLAT configured with the landing gear and a small engine. Below the engine I placed a stack separator and a heat shield, so that it could be jettisoned after atmo entry. Naturally however, attaching a 2.5m stack separator to a 0.625m engine creates only a 0.625m interstage adapter and things get weird, especially if you use the offset tool to "correct" it. Ultimately it sort of meant I tore the engine off when separating the heat shield, which I kind of achieved by a method called "hitting the ground at 40 m/s". Amazingly all the essentials survived intact, including the FLAT, the command core and the solar panels on top (actually attached to the core). It rolled along the surface for a while before coming to a rest on its side. Now I don't know if it was just a matter of the core (RC-001S RGU) not having enough torque to move the thing, but it read the torque as idle regardless of whether I moved it manually or tried to orient it with MechJeb. Also, can you add the option to toggle off the rotation on the Centrifugium? Kinda weird that it can start spinning but then only reverse rotation and not just stop. I should add a disclaimer that I manually updated the Firespitter and LayeredAnimations plugins to override those bundled with this pack.

Oh so it just needs data, not specifically science value?

Every time I start a new career something I neglect to plan for is the Mobile Processing Lab to maximise long term science generation. However, in terms of career progression, I don't understand how it can be used effectively. To be able to build it in the first place you need quite a bit of science, pretty much all of which will come from LKO and maybe Munar experiments. So when it comes time to put a station with a science lab up there as part of a contract, you might as well use it to generate more science, but to generate science it requires experiments, all of which you've exhausted researching the thing. Am I to believe they expect us at that stage to bring back experiments from Minmus and beyond and deposit them at the station? Personally I think it would be nice to get contracts to send experiments to the station that add to the science generation. After all, we wouldn't send a rover to Mars, send back a sample somehow (assume we didn't have in situ analysis) only to have it rendezvous with the ISS.

Oh so the engine basically becomes a second cube attached to the main one. Clever. It might be nice to be able to close the bottom with a blowoff hatch, but currently it can't really attach the right way round. It will attach upside down, but the bottoms of the engine nozzles just barely clip through. However ideally I think it would be better if that payload frame acted more like a shroud that could be jettisoned once in space. From a practical standpoint the frame probably isn't good for heat dissipation and frankly it just makes it look a little less pretty. http://kerbal.curseforge.com/ksp-mods/221109-mechjeb-embedded-universal/files/2239526 In the "It's Free!" folder, there is just one config file.

Sorry if this has already been discussed, but are there any plans to add some sort of adapter to make it easier to attach to upper stages if using the prototype engine assemblies? Also, how can this be made compatible with AntennaRange? The MechJeb config that comes with BoxSat overrides the config used by MechJeb Embedded (free for career version), which allows me to use all modules at all times. Obviously I don't need things like ascent guidance once I'm in space, but if I'm using a normal command pod (like the OKTO or HECS) in the upper stage, those modules should still be available on the launch vehicle. How can this conflict be resolved?

I understand that, but why would a station need all those tanks hanging off it? I'm not saying I couldn't do it if I tried, I'd most likely be making losses like you said, I simply don't see the practicality in it. Yes this is KSP and things aren't always realistic, but I think most things have to at least make sense.

Possibly. This was a contract to build a space station that obviously didn't have any chutes, but the agent was just RealChute not Wenkel Corp.

Does RealChute actually generate career contracts, or does the game just pick a random parts manufacturer to be the agent for each contract?

Same. The petal opens and the decouple activates, but the service module is still considered attached to the adapter. Also, I started getting pretty consistent and severe crashes (BSoD, lockups, etc) while using the petal. I had been using KW 2.7 with KSP 1.0.2 for a while with no issues and today was my first time ever attempting to use it. Almost every time I would revert to the VAB the part menu was messed up and the game would eventually crash. EDIT: May have been fixed with ATM (the crashes, not the petal), which I normally used but decided to defer after 1.0 until necessary. Is there any way around this? Before 1.0 I would often use 0% thrust to maximize the burn time and ensure a smooth acceleration. Now doing the same thing the rocket just goes up without any effects, and the boosters themselves seem far more powerful (though that could just be the aerodynamics throwing things into perspective). Also, unrelated to the above, is there some trick to attaching the 5m-3.75m interstage adapter, the one that on a Saturn V would be between S-II and S-IVB, shrouding the S-IVB engine? I'm using a Wildcat-XR engine on the upper stage, but it doesn't want to attach around any engine. The only way I can attach it is beneath the engine or in place of the engine, both of which are impractical. The alternative I'm forced to use is a normal 3.75m stack decoupler and then an LFTA 5-3 fuel tank, which makes the vehicle taller and heavier than it should be. Sorry, one more thing (for now), is it not possible to simply clone the launch clamp, edit the sound and include it as a part in KW with its own text so that I can at least tell which one is which without messing with core game data? Is it a limitation if that type of part?

Fair enough, I suppose I'll just adapt my designs accordingly and try to avoid going to 0%.

Maybe a bit exaggerated, but it was very fast. Obviously the trajectory was awfully steep because the AoA limit was on 5 degrees, but it got there.

Is it just me or are the thrust limiters on SRBs quite different post 1.0? Before, depending on the weight of the vehicle, I would decrease the thrust on the solid boosters significantly so that they weren't pushing the craft needlessly past terminal velocity. Normally I might reduce them to 20% or in some cases even 0%. In the latter configuration, the boosters still produced a fair amount of thrust and the exhaust effects were still substantial. Now however, when using 0% thrust, there are no exhaust effects and the thrust seems much higher, which means I often have to reduce my main engines to idle while the 0% boosters carry the vehicle, all the while there are absolutely no effects coming out of the engines. You might argue that I am simply just using solid boosters unnecessarily (imagine two Globe V SRBs on a 1.25m rocket 150% their height) but pre-1.0 I was flying rockets like this without issue. Is it just now with the changes in 1.0 that a rocket like this is not strictly feasible, or are there still some issues with KW?

So what is the status of MechJeb in regards to stock aerodynamics? Since 1.0 I've noticed that MJ has a really hard time limiting to terminal velocity with ascent guidance. Pre-1.0 it would throttle smoothly as it climbed higher, now it seems to just reach a hard cap and cut the throttle, and then relight to 100% a few seconds later and repeat this process for a while. I have yet to try out MJ 2.5.1, which I will do now just to make sure that hasn't been fixed. I just did a couple tests, one with a Saturn V type rocket and one with a small Redstone type rocket (a 3.75m beast vs a 1.25m bumblebee). The Redstone did as I described and kept cutting the throttle, sending the vehicle tumbling out of control as a result of loss of vector thrust. The Saturn V however seemed to just ignore the terminal velocity limiter and simply burned red through the atmosphere to reach the targeted apoapsis in about fifteen seconds, although because the engine never cut out if flew straight and true.

I did go on a bit of a rant, but decided to instead ask you, or anyone else, if they have successfully gathered and converted an entire container's worth of ore with minimal "smart throttling". If so, what methods did you use and how long did it take?

Sandbox, so Bill was max level. The ore level at the landing site was a little over 7%, so I wasn't expecting it to go quickly, but surely that shouldn't factor into the drill heating. Obviously the higher the level the more ore it can extract before overheating, but I would expect there to be a way to prevent overheating. You can place engines and RCS relative to the CoM to ensure propulsive balance, you can place enough solar panels and generators that exceed usage to ensure constant operations, so why can't you reasonably place parts that prevent overheating. I'm sorry, but the way thermal absorption seems to vaguely be attributed to the parts in general seems somewhat silly to me. If there is need to dissipate heat, especially the seemingly volcanic heat from the drills, there needs to be radiators. It's no fun if I have to sit there manually stopping and starting them, and even doing that I really get nowhere and all I can do is think about how simple it was to drill with Kethane (again, I'm just using it to compare, I'm not saying stock should be like Kethane).

After taking into consideration the things I learned in this thread, I landed a "base" of sorts on the Mun. This comprised a command pod for three kerbals, including an engineer, a trio of RCS engine and landing gear clusters, a large ore container with two drills, a converter module (mainly just to balance the CoM, but enables relocation), six large batteries and six Gigantor solar arrays, as well as various equipment like scanners. However, the drills still overheat in a matter of minutes, with only a couple units of ore extracted. I'm finding it simply impossible to create any stable mining platform.

Ok it looks like there's a lot more to this than I expected. After all, it's finally 1.0 and I guess I didn't really anticipate things to actually start working as one might envision. The various levels of scanning makes sense, I'll play around with that some more. And the one-time scan I can understand. After all I did the same thing by just time-warping until the scan was complete, so there's nothing lost there. About viewing the overlay, I must have missed the button to show it, I was changing targets, double clicking on planets, opening the side panels, but nothing. I didn't expect thermal absorption to actually be a real factor, but I found it strange once I noticed the heat overload that there were not parts to compensate for it (ie. radiators). I didn't know solar panels could be used as radiators, does that work in real life? In any case, I did have two Gigantors on this thing, but I guess even that's not enough. Also, I had no idea the kerbals themselves would affect performance. I had always just used unmanned probes, because who wants to spend their entire life just going back and forth between a moon and a space station (actually I would probably sign up to do that for free). Looks like I'm going to have to completely rethink the way I approach ISRU. Thanks for the input guys.

First of all, I get it's the second day of release and I'm sure many hotfixes and content updates will come in the near future, however I wanted to address my impressions of resource mining. Like many others, I enjoyed using Kethane as a way to create some purpose in the game and tackle the challenges of extraterrestrial refueling. When I heard Squad was introducing this concept into KSP, I just assumed they would essentially incorporate Kethane into the game. There are a few things I thought weren't as they should be, as compared to Kethane; Kethane orbital scanners survey the planet in real time, assessing each cell in a grid for deposits. KSP's scanner simply turns on and magically the whole planet is scanned. Kethane had parts of various sizes for different jobs. For instance, I liked to set up a station in Mun orbit that had fuel and kethane tanks, as well as a large converter. Meanwhile, my lander had a few small tanks and a small converter, so it could top up before ascent. This system allowed me to efficiently ferry kethane from the surface where it could be converted into the station's storage tanks, allowing passing ships an easy way to refuel. Stock KSP only has a large converter, making this system near impossible, as the lander needs to be much larger to compensate for the extra weight. The drills themselves are fairly bulky as well, but I guess that can't be helped, they do look pretty cool. It doesn't make sense to me that the overlay is only visible when controlling a spacecraft with a scanner module or from the tracking station. Sure, this makes sense in real life, but this is KSP. Kethane's overlay toggle is simple and it works. Regarding this next one, I'm not sure if it's something weird with Squad's implementation or if I'm just doing something wrong. I scanned the Mun and found quite a dense deposit, above 70% or so cutoff. I landed, deployed my two drills and got to work. It took them two whole years to fill a single large ore container. Their information showed something like 97% overheat, 2-3% load and a rate of maybe 0.001. Was this because this particular landing site wasn't actually above an ore vein, or were the drills actually overheating, causing them to slow down?

Perhaps? I'm not talking about recording all the time, you'd have to start and stop manually, assuming the data size is an issue.

It's been a while since I was last here so forgive me if this had been discussed. Couldn't find anything through searches or the do not discuss list. Quite simply, I'd like a way to essentially record the game data so that it can be played back, manipulated (speed) and viewed from various angles. This provides far superior tools to work with when creating videos as opposed to just recording as it happens. Rather than pre-define a few different camera angles, give the user the ability to place the camera where they want, allowing them to zoom as required, and most importantly include an option to track the spacecraft's center of mass and automatically zoom based on distance. This would allow us to replicate most standard broadcast cameras. Obviously I wouldn't expect this to be anything more than a low priority addition, but something I would like to see nonetheless.