Starwaster

KIDS = Kerbal Isp Difficulty Scaler. Does stuff to Isp and thrust. Some of which was already being handled by MFT/RF. If you're also using RSS (which I think you are?) then KIDS is pretty redundant. IMHO.

If you use MechJeb: For stock Kerbin, set your turn end altitutde to 50km set your turn shape to 50% For Real Solar System, Set turn end altitude to 120-150km. If you have a good amount of thrust in your upper stage then 120km is doable and I've read some literature for Orion that had it ending its turn at ~120 which is what prompted me to try ending my turn at that altitude. YMMV with your rocket design. I think most rockets are closer to 150km for their ascent profile IRL...? In each case, end pitch angle for your turn will vary according to the thrust you have in the upper atmosphere. You should still be pushing apoapsis away from you. If you're catching up to it then you should increase pitch angle. 2-5 degrees works for me. Usually. And I've increasingly been using MJ with corrective maneuvers off in the ascent AP.

Correct. Given the approach that I've taken with this plugin, it wouldn't even be enough to reduce drag for the cone to zero because it would still add mass that would affect your final delta-V. What will have to happen is that the other parts in the stack under the nosecone will have to have their drag altered. That's actually very easy, problem is going to be by how much. The test rockets that I've sent up (three times each, stock, SDF and FAR) tell me that a simple rocket without a nosecone in SDF has comparable performance to the same rocket with a nosecone in FAR. Without a nosecone, the drag FAR assesses against the rocket results in pretty substantial losses to delta-V and therefore final maximum altitude. So, with SDF, there is actually too little drag. When I do something about nosecones, I'll have to increase the total drag felt by the rocket when it has no nosecones. Also see CaptRobau's comment about stability. CoL marker is not modified at all. In theory the stock code might change it if the drag change results in changes to lift. And the plugin only operates during flight mode and not in the editor. I'll most likely look into adding another marker to represent center of drag in the editor. I'm having less luck with adding any debug markers than in other areas of code that I've done in the past however It does affect it. I wouldn't say that turning early is a strict requirement with SDF, but there are benefits to doing so because turning late (5-9km) is just plain inefficient. Early turning means that by the time you reach your orbital altitude you'll have to burn less to finalize your orbit. And it's still possible that some rocket designs might be less stable with late turns. I've never been very big on the 'asparagus' thing so even when it wasn't necessary to build aerodynamically stable rockets, I usually built them as though it were necessary. So I just don't have a lot of unstable rockets in my catalogue to test with. Except for one recent rocket that has stability problems with SDF just as it might have in FAR. It is a definite test candidate for when I finish the fairing code. I'm a little skeptical of Squad's claim about nosecones from 0.22 on. They just haven't done enough changes to the stock drag system that I can see as having any effect on cones. AFAIK they've always had a lower drag rating and the drag system has always resulted in rockets orienting towards their point of lowest drag. What I think (and this is just my opinion) is that they did make some change that they thought would affect cones but then just never really tested it to see what the actual outcome was. There are alternate drag models that might affect cones if they were set up to utilize those drag models but as best as I can tell, they just aren't set up to work with anything except the default drag. And there's actually some disabled code in SDF that attempts to assign the conical drag model to cones but AFAIK, all the conical drag model does is apply different drag to the cone based on its orientation to its velocity vector. Enabling it doesn't have any effect right now because the maximum_drag for nose cones would have to be increased. Eventually I'll go back to experimenting with it but it will always be an optional thing for SDF because it will definitely affect MechJeb's reentry predictions. (that's one of the reasons MJ has trouble with FAR is that FAR disrupts MJ's notion that drag will always be the same regardless of orientation)

unless it is manned or has a core

Well in the GameEvents list, there's onPartUndock onUndock onSameVesselUndock You're going to add either of them the same way: // These typically are going to go somewhere like Start() GameEvents.onPartUndock.Add(MyOnPartUndockFunction); // Registers a function that you create named MyOnPartUndockFunction GameEvents.onUndock.Add(MyOnUndockFunction); // Registers a function that you create named MyOnUndockFunction At the time that I write this, I have no idea what arguments either of those functions will be called with as I have never used them before. Someone else out there may or may not have documented it previously or else may have used it in their code. However, with a little exploration it should be easy to see how they are to be used. When typing in the event you want to hook into, MonoDevelop gives information about it as I type. If you use VisualStudio there's probably something similar or there's the browser feature. (right click GameEvents in your code and go to its declaration). Also, if you try to compile without passing your function any arguments then the compile error should tell you what was expected. In the case of OnUndock, MonoDevelop tells me that EventData<EventReport> is expected so.... public void Start() { GameEvents.onUndock.Add(MyOnUndockFunction); } public void MyUndockFunction(EventReport report) { } The autocomplete function tells you what fields report has. It shouldn't be too hard to figure out from that what data is being passed along.

Also see my edit; I just added a link to GameEvents, which you should take a look at if you're looking for places to hook into.

PartModule is meant for modular code to be incorporated into Parts via MODULE{} nodes (in the config file) (i.e., ModuleDockingNode, ModuleDeployableSolarPanel, ModuleDecouple, ModuleAnchoredDecoupler, etc) Part is the class used by the actual parts that are configured via the PART{} node in a config file; typically in files named part.cfg You are not likely going to get much use out of extending the Part class from a practical standpoint and are most likely looking for PartModule instead. Edit: Also, if you are looking for hooks for events, look into GameEvents. For example, if I wanted code to execute every time a ship comes out of TimeWarp I would attach it to GameEvents.onVesselGoOffRails. GameEvents.onVesselGoOffRails.Add (MyFunction); public void MyFunction(Vessel v) { } Here's a list of GameEvents events http://forum.kerbalspaceprogram.com/threads/36727-GameEvents-documentation?highlight=gameevents

Download this and drop it somewhere in your GameData folder. Preferably in a folder dedicated to Module Manager tweak files if you have one. (requires Module Manager) https://www.dropbox.com/s/uj3i4i6c488otca/breakingforce_fix.cfg Explanation. Those engines and many other Squad parts use the default breaking torque/force values of 22 which is not enough even for phantom forces that tend to strike ships, especially (but not limited to) ships in solar space. (literally, ships in Kerbol's SOI)

Just so....

There's that word again.. impossible. Nothing is impossible, there's only the amount of work you're willing to put in to make it happen. Take a look at Porkjet's inflatable 'F.L.A.T.' habitat. A hatch that pops out when inflated & three integrated docking ports The bar is raised a little high here. Here's six of them assembled into a floating hotel.

I'm on a Mac, OpenGL is all I have and it works the same as it did on my PC.... I have no idea why you're having trouble, sorry.

Read the thread; there's a bug in it that is known and talked about.

Not at this time, but that's going to be in the next update. Right now I'm just trying to nail down the exact method I go about implementing how payload is detected. (all payload parts will have drag zeroed out) Procedural Fairings will be easiest to check that for. Nose cones are also something I'm looking into....

not at all. it's just like losing your car keys or your wallet. haven't you ever lost anything before?

Interestingly enough, I just did have a rocket flip out using this. It was a lot squatter than what I usually make but it didnt seem unreasonable as a design. I had to lengthen it quite a bit to stabilize it, from a single stage to two stage. Ferram had indicated that instability could still be a thing since it was possible for center of drag to be different from center of mass but I hadnt seen it happen yet.

Did you try looking behind the sofa cushions?

I dont think its range related. I think it just randomly flakes out. cancel and reengage if it doesnt immediately make sensible moves

Not an ideal solution. You don't want other parts named 'fuselage' to be considered cargo bays if they really aren't. For instance if another parts pack has something called fuselage it could result in things being shielded that you might not want shielded. Best to manually add the cargo bay module to the part. (all the name/title thing does is make FAR add the module anyway to parts that don't have it in their configs) Edit: Also, Ayana put out some FAR configs a few pages back. They put a lot of work into it already; why not give those a try.

What would be really great is if instead of switching between multiple huge ass textures: would be if the main shuttle texture stayed the same and if the name were a quad with the name textures and you just switched between those. You could have lots more names for a lot cheaper.

3 worked for me but I can't say that it needed to be that high.... if you find a minimum let us know!

Sounds like some of the parts have changed breaking the craft file. Or it got corrupted in the game and then saved in a corrupted state. I don't think it's RSS related though...

Re: The real shuttle's center of mass: Its center of mass was further downwards, close to its wings. Keep in mind, that area was empty cargo hold, the bottom was heavier structural components, hydraulics, machinery, etc. Top is lightweight cargo bay doors. But the B9 parts you're using have their CoM at the geometric center of the mesh by default so naturally its CoM would be above CoL. To make that more realistic, it would have to have a comOffset (or is it CoMOffset? it is case sensitive...) of maybe 0, -0.125, 0 (just eyeballing / guesstimating) Also.. airbrakes on the rudder. I did that to the KSO25 to help keep its nose up.

Found the problem: In both the standard and inline cockpit: storageRange is too low for a cockpit that wide. It should extend as far out from the center to the furthest point that a Kerbal will be occupying (at least to his center) who is trying to add something to the science container. Or maybe to the furthest point on the Kerbal (to cover all angles) MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 1.3 }

what are you using to compile? and are you compiling against .NET 3.5? ( you should be)

Trivia note: In the Space Odyssey books (2001 / 2010) Discovery is known to have carried ammonia as propellant for its nuclear drive which is why it didnt all boil off before Leonov arrived at Jupiter.