AaronLS

Sorry, I went back and read the numbered items a couple of times thru before I saw the giant underlined heading and realized they all described the same issue I'll try those out.

I have this same issue, seems I'm on newest version 2.7.5 of module manager. Any ideas?

Mine does. I apply a force to the object, and also an equal and opposite force to the ring. Generally your ring vessel should be much higher mass than the target, so it only deorbits slightly, and the smaller object accelerates alot. My idea was to attach a solar sail that would be deployed between firings to restore the ring's orbit and prepare it for the next target. // We need to make sure we apply the force to the center of mass (AddForce finds the center of the vessel, which is not the same as center of mass and thus will cause rotation) otherVessel.rigidbody.AddForceAtPosition(forceVector, vesselPosition); // and apply equal&opposite to ourself this.vessel.rigidbody.AddForceAtPosition(-forceVector, this.vessel.findWorldCenterOfMass()); https://github.com/AaronLS/KerbalMagnetMod/blob/v00.01-alpha/KerbalMagnetMod/MagneticRingModule.cs Sorry life has demotivated me for awhile and I never really cleaned this up properly. I also kind of got stuck trying to find an elegant way to setup the nodes on the rings. The nodes floating in the center can be confusing, like fairing interstage nodes often do(I've seen the people ask about this many times on reddit in regards to fairing interstage nodes). Nodes around the edge of the ring look more sensible, but are misleading because only one node will connect and the rings will be floppy without struts.

This has taken alot of the trial and error out of SSTO design! Thanks so much! The only fault I could find is the axis's of the graph aren't labeled. It's quite confusing to begin with. It'd be alot less confusing if the markers on the X axis indicating pitch -20, -10, 0, 10, 20 etc. or whatever current scale is. Labeling the Y axis would be nice as well but obviously you'd need 3 scales for the three lines. Either way, thanks for this!

Does this mod increase deflection speed of control surfaces? I.e. if I center joystick it takes a second for control surfaces to return to neutral position, and thus feels a bit sluggish. Trying to find something that will gives me some Blue Angel snappy responsiveness

I would make a suggestion of including a description of what this mod is. I followed all the links, and they essentially just say it's a revival of the mod, but not exactly what the mod is or how it extends the stock parts. Don't mean to sound entitled, obviously you've put a lot of work into this and you aren't obligated to writeup a description. Just a suggestion. Maybe one of your users could post a brief description that would make it easy for you to copy/paste. Cheers.

The question wasn't meant to be about the Kerbal solar system. I gave that as an example only. It was meant as a question about physics. The linked article seems to deal with the affect a fly-by has on the orbit around the parent body, which is not what I'm asking about. Anyhow, not a big deal.

If I do a fly by the Mun, and behind behind the mun's direction of orbit, then I get a gravity assist increasing my orbit of Kerbin(not sure on correct terminology here, orbital energy?). If I pass in front, then my Kerbin orbit is decreased. So if I were wanting to save some dV on deorbiting to Kerbin, then first doing a fly by of the Mun on the front side is a good way to lose some orbital energy. However, I'm wondering if this matters within the reference frame of the Mun, if my goal is to capture and orbit the Mun, will it save me dV to put my periapsis on the front side of the Mun? I would imagine if my periapsis is on the backside of the Mun(relative to it's orbital direction) then I spend more time approaching and thus spend more time accelerating and thus will need to expend more dV to slow down to capture. My fairly non scientific testing with nodes indicates this probably is the case, saving roughly 10% dV in the couple cases I tried. Basically using a radial node at the midpoint of my Kerbin orbit to set my approach up to the Mun to pass in front or behind at the same Mun periapsis height, then using a retrograde node at the Mun periapsis to compare dV needed to drop apoapsis to 100km.

I watched Masterminds last night and there was a funny analogy Zach gave. I don't remember all of it, but at one point he says "No one cares about rocket boosters. They just fall off and burn up in the atmosphere." I tried to find the rest of it online or in a transcript but the only transcript I found was way off and said "thrusters" instead of "rocket boosters". The analogy is kind of hard to explain out of context, but just the humanization of a rocket booster and saying "No one cares about rocket boosters" was just a funny statement to me.

I did a fresh install last week after not having played for awhile. No mods or saves restored. I had a craft in orbit and added two maneuver nodes. Focused on Mun, then hit backspace to focus on craft again, but it will not focus on the craft. I can switch focus back to Kerbal. If I click on the craft the only options I get are for adding a maneuver node or warp to here, as if I clicked on orbital path. Yeh, so because I can't switch focus to the craft in map view, I don't get the craft specific buttons on the right. Note I am controlling the vessel though, so I have the navball.

I just read about that higher altitude change and some of the factors considered: http://www.nasa.gov/mission_pages/station/expeditions/expedition26/iss_altitude.html It's interesting that higher solar activity raises the altitude/density of the atmosphere. I wonder at what altitude you would start seeing a significant increase in radiation. Enlightening point about self cleaning debris altitudes. I wonder what altitudes most of the current debri orbits at. I'm sure all of it slowly changes to a more elliptical orbit due to irregularities in Earth's density and would eventually starts hitting thicker atmosphere, but might be so slow that it's negligible. Perhaps they could put boost it to a grave yard orbit and operate it remotely. No human crew, only a remotely operated robot. They could even put a monorail of some sort through the ISS to allow the robot straightforward movement. It would cost more to send resupply missions to the higher orbit, but hopefully that would be offset by how rarely you'd send a resupply. You wouldn't need to send food or drinking water. Assuming you are now outside of the atmosphere completely, not more need for propellant (8,000 lbs of propellant a year is what I believe is currently needed for reboosts!) Probably there are certain things needed to keep the station operational. It leaks air, and you'd probably want to maintain a certain amount of atmosphere inside the cabin to support cooling electronics, but you could probably have a lower pressure and thus decrease the leak rate. I'm sure there's lots of other issues at a higher orbit. I wonder what the average lifespan of a geosynchronous satellite is, and what typical failure scenarios are. We're not speaking in concrete altitudes, so hard to say at what point these issues become actual issues. Without human crew, I'd wonder if there's a higher orbit that significantly reduces drag, but has radiation levels still tolerable for systems.

These U-2 landings look very much like some of my landings in KSP:

Had same issue. When the cargo bay doors are open, no problem. As soon as they are closed Rapiers and Turbo Jets all drop to 50%. Disabled crossfeed to block fuel in the cargo bay fixed issue. Took awhile to figure it out though then googled to see if it was known issue.

My mistake, it's the horizontal control surfaces I always have attached to the vertical fins. Still I would remove them when positioning wings/CoL. At least according to the Aero overlay, control surfaces don't actually produce lift when not deflected. If I had positioned my CoL with them attached in the below, I would have ended up with CoL in front of CoM. Before I first discovered this, my planes were not always stable, and after discovering this nuance, I can now consistently make stable planes.

Anytime you are comparing position of CoL and CoM, temporarily remove any vertical wings or control surfaces such as your rudder. They will cause your CoL to appear to be further back than it actually is.

What Kerbas said. Won't tear apart your vessel, but nearby debri/vessels will be accelerated towards the magnets and thus risk of collisions. My thinking with the control module was not to clutter up the magnets with additional UI. It also makes it clear which controls are global and will affect all magnets. Otherwise each magnet would have both a "This Magnet: On/Off", "All Magnets: On/Off". The Safety/Auto-undock+fire controls are already a little non-intuitive to use, almost making the instructional video a required viewing to use, and having mixed options on every magnet seems like it'd add confusion. I wanted them to be on their own part so at least it's clear that all of those controls relate to controlling the entire vessel's magnets. Opinions?

I guess it was a nice imromptu challenge for yourself. Glad you were able to salvage it. Usually if a bug/quirk bites me I don't have that much patience and either load or cheat. That's really the challenge of making any kind of hardcore game mode. If people lose/die on fair terms, it can still be enjoyable. Sometimes losing is fun, if you're familiar with Dwarf Fortress, there's lots of examples of that. But the occasions when you get burnt unfairly then it can ruin the experience.

What is the reason for using shielded docking ports on the modules, which are already hidden within the container? Not challenging the choice, I'm sure there's a good reason.

After probably 30 different variations, I have a reliable low tech SSTO for putting both large and small payloads into LKO. Others worked, but putting the payload on the front means a balanced ascent profile becomes unbalanced when the CoM moves towards the engines after releasing the payload. I often had to save about 200 LF to store in the tip of the plane to keep it stable during entry. The newest version is stable even when completely empty on re-entry. Other low tech non-MK3 designs for large payloads have a scheme to put the payload in the center so that CoM doesn't move as much after releasing the payload, which is a respectable design, but I wanted to try and refine my own approach. It's fairly easy to use bicouplers to upgrade to 6 or 8 ramjets as-needed for heavier payloads. All stock parts except for Engineer chip so I can easily observe metrics and RealChute parachutes, which I almost never use and are there just for emergencies. I need to remap the aerodynamics overlay. Alot of pictures ruined cause my screenshot key is the same. Delivery has arrived: Another example payload, the decreasingly small tanks are where I just crammed as much extra fuel as I could into the taper of the protective nose cone: One of the first versions of the concept. Required alot more ramjets, winglets to keep the nose up, and was incapable of a rolling take off. So your components had permanent winglets on them, although I could mount them on decouplers, either way it was a hack. Still, I was proud to be putting large components into orbit at a fairly low cost.

Yep, and inaccuracies get worse closer to poles due to pinching effects in the way it's interpolated.

I didn't say anything about changing engines. That's good for testing drag alone, but not for air intake supply performance.

This is wrong. Only AFTER you launch is this available. Not before. It is not accessible in the VAB nor SPH. It does not have the GUI attribute that allows it to be accessed in the hanger. Even then, after launch zooming in is not sufficient. In this case the zoom levels are not granualar enough to allow me to position the camera inside the small service bay in a way that lets me click on the controller. Only one of the zoom levels gets me inside the service bay and I'm not able to click the proto*dyne due to other components in play. Not what I'd call "very accessible". The things you mentioned are workarounds. They are not the feature I described, and therefore are not already in the game. That's like telling someone to dig a hole and giving them a spoon to do it with and saying it's the same as a shovel. It's certainly not intuitive nor is it a good UI experience.

When you have multiple command modules sometimes the default is not the one you want to use during takeoff. In my case I have a protobodyne inside a service bay, inside a fairing, and so on launch I can't access it in order to set it as the "control from here". Therefore my navball is not oriented properly since it's using the wrong command module. Suggestion: Allow access to the "control from here" right click option from VAB/SPH so that you can select it and save so that it would be persisted for future launches.

I've done tests like this with nose cones and it's straightforward, but when you introduce air breathing engines it becomes alot more complicated as some profiles only really shine on a lower angle of ascent where they have time to accelerate in thick air. Because of the way air breathing engines behave, I think it's alot harder to come up with a definitive test. Personally I've found inline nacel intakes to be nice, because you can still put a nose cone on the end of the stack. I usually use the tapered tank that holds 80 liquid fuel with a small nose cone on the tip as that provides a very aerodynamic tip. - - - Updated - - - This is a key point. Something else very non-intuitive is more air does not mean more thrust, at least for ram jets. I used to think that more velocity meant more air intake, which meant more thrust to the ram jets. I.e. an indirect relationship. This is not true. It seems ram jet thrust is directly related to velocity, and air intake affects it only when you don't have enough air to supply it's demand. The air demand itself is a function of speed+altitude. I notice when taking off, according to Kerbal Engineer, I'm only using 20% of my air intake with ram jets, and as I go faster at the same altitude I'm using a greater percentage. Which indicates that velocity factors directly into the equation of how much air+thrust your jets will use. I used to think it was an indirect relationship: My engines increased thrust as I accelerated because my intakes were in turn capturing more air. Not true though. If that were the case, then you'd see 100% air intake usage at takeoff, and then you could attribute the increasing thrust due to increasing speed capturing more air. For example my air intake demand goes from around 0.2 up to 1.08, but the entire time my air intake supply is always greater. So at no time is air supply a limiting factor. The only thing changing is my velocity. If you use Kerbal Engineer and add the air intake demand and air intake supply fields from the Vessel section, you'll be able to determine if at any point during your flight you don't have enough air intakes to meet demand. Consider though sometimes the small amount of demand an extra air intake will meet, will not provide enough thrust to counter act the drag. - - - Updated - - - Another example: On re-entry I'll get below 32k altitude and have .3 air intake, and the engines won't cut on until around 25k. Now you might say there wasn't enough air to overcome flameout, however when they cut on around 25k there is .6 air intake supply, and the engine's demand is only .2. So this indicates there was more than enough air intake for the engines demand at 32k altitude. It simply was that the engine has a direct relationship with altitude+velocity rather than air intake. Air intake doesn't determine thrust, it can only limit thrust when there's not enough air. It's very non-intuitive in my opinion.

Hey Svm, thanks for the encouragement. Hopefully this will live up to your expectations. It's pretty rough around the edges as I've been involved in other things and haven't had time to work on this. I've made a short video on its operation since its quite different. Pretty much rewrote all of the code. I created a ring that acts as a magnetic docking port. It will pull a nearby vessel, and when the vessel intersects it will become "docked". It's a little bit unrealistic in the way it operates currently. The previous version was a little bit risky as you'd get your vessel in position but it'd just be floating there and you'd quickly have to fire the magnets before it floated out of alignment. This solves that problem by allowing you to lock your vessel in place, and the Magnetic Ring Controller allows you to automate the process of decoupling and firing the magnets. If I can find time to add some polish to this and get it up to production quality, I'll probably start a new thread for it since I can't edit the root of this one. The main thing I'm not happy about is the docking ring will not apply torque to align the vessel. Some of the math regarding rotation is new to me and haven't had time to get up to speed. Looks like things have evolved beyond just being simple matrix math since I haven't done 3D in several years. I also want to making the docking ring more intelligent, and have it auto-reduce power as the vessel gets closer, to nullify the violent oscillations and hard docking. Video: Download from GitHub: https://github.com/AaronLS/KerbalMagnetMod/releases/tag/v00.01-alpha