HvP

Hi @~SYSTEM~ and welcome to KSP! Docking is one of those things that doesn't seem to make any sense until you've practiced it many times. The good news is that if you are consistently getting rendezvous in the 1.5 - 4km range then you are already pretty good at one of the trickiest parts. Ideally, you want to get those rendezvous approaches down to about 0.2 to 1km for final approach. The best way to do that is to make a maneuver node 1/4 or 1/2 orbit before closest approach and experiment with very fine adjustment of prograde/retrograde and radial in/out maneuver inputs to really narrow those approach markers. Even so, you can dock from as far as 4km, it just takes a little longer. To start, when you are near your closest approach, switch your display on the navball to "Target Mode" if it hasn't switched already. This is the window at the top of the navball that normally shows your speed, but you want it to show you your RELATIVE speed and distance to your target. On the PC this can be done by just clicking on the navball window, it may be the same on X-box, I'm not sure. When you are in target mode your prograde , retrograde , and other markers on the navball now show you your relative motion towards or away from your target. The easiest thing to do at this point is to aim your ship retrograde and do a short burn to zero out your velocity. This puts you in station keeping so that your relative motion to your target is zero. Next, look for the prograde to target maker, it looks like this . This shows you the direction that you should be going to meet your target. What you want to do is to make small burns to bring your ship's prograde marker in-line with the target prograde marker. Put this directly on top of this . Now your ship is heading directly towards your target. If you are further out, like a few kilometers, then I would try to go about 200 to 300 m/s at first until you close the distance. Then at about 200 or 300 meters from your target reduce your speed to no more than about 10 m/s. You can reduce your speed by either turning the ship around to retrograde and using your main engines at low thrust - or - use your RCS controls to thrust backwards. I'm sorry I don't know what control setup you have for the assigned keybindings for RCS on X-box. You will find that as time passes the target marker and prograde marker will wander away from each other. This is because as you orbit the planet your angle between the ships is gradually changing since their paths actually follow a curve. You can correct for this with practice by adding some up/down/left/right thrust with your RCS in small bursts. You will find it most helpful to toggle your camera view to LOCKED mode and rotate the view so that you are looking from directly behind the craft as you make your final docking approach. This way you can easily see what direction your RCS controls are sending you. Look at where your prograde marker moves on the navball when you thrust. It's like a mini-game; practice keeping the on the as you get closer and closer. By about 50 to 100 meters away you should be seriously paying attention to the direction your docking ports are facing. It does you no good to be 1 meter away from a docking port if you are at right angles to it. It can be tricky, but when it's convenient you should start turning your ship with yaw and pitch controls so that the docking ports are facing each other flat, even if you are not lined up yet. You should also by now select as a target the exact docking port you are aiming for by double-clicking on the target port with your cursor. This means that instead of aiming for the center of the target ship, your controls are aiming you at the targeted port itself. Also, if you haven't done it yet, chose "Control from here" on the docking port you are using on your own ship. It will probably help to zero out your relative velocity again at about 20 meters out so that you can face parallel with the face of the target docking port and then use RCD up/down/left/right to translate into line with it. Once you have done that (easy for me to say, I know) then slowly nudge your ship forward with RCS at no more than about 1 - 5 km/s. It's a good idea to disable SAS at the last second before connection so that the reaction wheels don't hold you at any weird angles which would prevent the magnets from engaging. There are a number of good docking tutorials at the top of this forum. I can especially recommend This One by Snark. It was made with PC computers in mind, but the basics translate over (haha) to the X-box version ok.

You're welcome, of course. I hope you don't mind if I add a little something else. Airplanes can be difficult to get right, and space-planes are much harder. Don't get discouraged because everyone has a hard time with them in the beginning. One problem you will probably notice later is this: Your jet engines and your vacuum engines don't both work at the same time. This means that your thrust vector changes when your jet engines stop working and you have to switch to the rocket engines. If you want to see where the thrust vector is during atmospheric flight, then turn the thrust on your rocket engines down to zero (0) in the space plane hangar. And then, to see where your thrust will be during space flight from the SPH turn the thrust on your jet engines down to 0 and your rocket engines back to 100%. Now you can see where your thrust vector is for each stage of your flight. You might be surprised how much it changes. Just make sure to turn them both back to 100% before you launch it. There is a section of Tutorials in this part of the forum if you look at the top of the "Gameplay Questions and Tutorials" section. You might find some instructions on building planes that you find helpful. Above all, it's a game. You're trying new things, experiment, and just try to have fun with it. Good luck!

In addition to making sure that the center-of-lift is behind and slightly above your center-of-mass marker, consider the direction of your thrust vector. The purple marker shows you where your thrust vector is, that's the line of force that your engines create. For stable flight the purple marker should be directly in line behind the yellow center-of-mass marker. This is often difficult to judge because it's normal for the center-of-thrust marker to be to the distant rear of the craft. To make it easier, try lining the camera up directly behind (or in front of) the plane looking directly along the center axis of the plane. If the purple marker is above the yellow center-of-mass then it will cause a leveraging torque that is constantly forcing a downwards rotation - if the thrust marker is below the center-of-mass then it will cause a rotational force resulting in constant upwards pitch. Think of it like this. Your plane is hanging from a string that is attached to a balance point at the spot the yellow mass marker is. Your engines are trying to push the plane forward, and that force is applied to the spot where the purple thrust marker is. You want them to push from directly behind the point the plane is hanging from or else it will cause the plane to tip over. Complicating things though is the center-of-lift. This is a force applied by the air you are moving through. It adds another element of force to your plane. Imagine this force as the place where your plane catches the wind. If you are moving forward, and the blue lift marker is behind your yellow mass marker then you can move forward and the air just pulls the rear of the plane further in line behind the front of the plane. If the blue lift marker is slightly above the center of mass of the plane then you get lift pulling the plane into the air - although it also creates a slight tendency to pitch upwards, but as long as you have enough control from your pitch control surfaces this is desirable. However, if the blue lift marker is a good deal below the center of mass of the plane then you'll find that the plane is constantly trying to turn itself upside down. Try to imagine a lever arm attached to the yellow ball the plane is hanging from, and that this lever extends to the blue ball showing you your lift point. If you thrust forward and this blue center-of-lift catches the wind, what happens? The blue ball will be pushed backwards until it is directly behind your center-of-mass, but doing this will rotate the plane up or down. Your best options are to: A) Adjust the placement of your engines so that the purple center-of-thrust marker is in line behind the yellow center-of-mass marker. Then... B) Adjust the placement of your wings and control surfaces so that your blue center-of-lift marker is slightly behind and either in line with or very slightly above your yellow center-of-mass marker. C) Realize that moving around the wings will also shift the center-of-mass and center-of-thrust, so... D) Go back to step (A) and repeat each step as necessary until things line up properly, then... E) Test your configuration in flight, note the behavior of the plane and... F) Revert to the space plane hangar and continue adjusting as needed for further testing.

Your screenshots seem to confirm that all control inputs are enabled for all your control surfaces. You should deactivate yaw and roll for the largest inner pair of Big-S elevons at the rear of your plane, leaving the pitch input active. Then, for the outer pair of elevons at the tips of the wings, deactivate pitch and yaw, leaving only roll active. For the vertical tail fin make sure that roll and pitch are off and leave only yaw activated. The reason for this is not really a glitch in the game, it's just the nature of needing to isolate inputs for effective control so that you don't get crossed signals. There's just no reason that a vertical rudder should be trying to respond to pitch inputs - it won't be able to do anything but mess up the yaw of the craft. Additionally, having roll input also assigned to the control surfaces for pitch will often cause them to operate asymmetrically, lessening their effectiveness. The problem is exacerbated when SAS is turned on. Because SAS is constantly trying to keep the aircraft flying straight under most circumstances it is always adding a few degrees of roll here and a few degrees of pitch there - but because roll and pitch are both assigned to the same control surfaces it can't add roll without ALSO adding pitch. Sometimes this results in overcompensation, sometimes the inputs cancel each other out, and sometimes they end up doing the opposite of what they should be doing. The answer is usually to keep the inputs and outputs separate and discrete. As for the general design of the craft, as @Kerbal4 implied, the wings are quite far back in delta wing craft like this which often causes very stable, very flat flight characteristics. In other words, they are inherently hard to get upwards or downwards pitch under the best of circumstances. Or alternatively, they may not have enough lift in the front causing them to nose down. In this case however, those tendencies are probably offset by the wing segments near the forward section of the craft, the lifting body properties of the MK2 fuselage, and the very large elevons in the back. It'd try it first with the control inputs isolated for only the pitch, yaw and roll inputs required by each pair of control surfaces. And then if you are still having difficulty with the controls report back and let us know what is happening. This could have been due to very strong reaction wheel torque, or an odd buggy characteristic of the landing gear and wheel physics in the game. The Unity platform that the game is based on has had strange and unpredictable behavior with the wheels, landing gear and landing struts for quite a while that sometimes cause jumping around, weird bouncing oscillations, or gliding across the surface. I wouldn't be surprised if it also caused some craft to become stuck at odd angles. There are any number of reason for a plane to start spinning without SAS. It could have just been an unstable design that was barely kept level by SAS. Or sometimes part clipping and "Kraken" forces can cause wild buggy behavior. The jury is out on that one. I've not seen this behavior before. Batteries don't usually have much effect on flight physics at all. They don't even really have any physical characteristics themselves except that they add a little weight and drag to the part they are attached to. Is it possible that you also accidentally attached an extra copy of the control surface inside the plane? I've done that before and the results were not pretty. I've not investigated this design from The Kerbal Player's Guide (I think you may have pasted the wrong link) but I'm sure it's a tested and functional design. Was it this plane that started working correctly after you removed the battery? If so, I still think it could benefit from isolating the control inputs.

It's difficult to say without knowing more about your craft. Posting a picture of the craft would greatly help diagnosis of the problem. I can give you some basic info to start with though. It sounds to me like you may have multiple pitch, yaw, and roll inputs enabled for all your control surfaces and they will interfere with each other. You should always place your control surfaces in discrete pairs, each relating to the role that they perform, and then make sure to right click them in the space plane hangar and toggle off any function that they would interfere with (yaw, pitch or roll.) It can be tricky to correctly place control surfaces on a delta wing craft, especially if you have designed it as a "flying wing" with no separate tail-plane or elevator. Your control surfaces may be trying compensate for more axis than they are able to control. In a conventional airplane design, only the horizontal elevators in the tail will control pitch, so toggle off the roll and yaw in their right click menu. And the vertical rudder should control yaw, so switch off roll and pitch for that. And of course, the ailerons placed on the rear edge of the wing tips should only have roll enabled. If your design is more like a flying wing with no rear stabilizer then you may simply not have enough leverage in the rear for pitch control authority. Maybe your elevator surfaces are simply too close to the middle of your plane. They need leverage to work, so try and get them to far rear if you can - you can try placing canards near the nose to help with pitch authority. Another possibility is that your design has the center of lift too far to the rear. This causes the plane to be exceptionally stable, but it flies like a dart with very little deviation possible. This is very common for delta wing planes because most of the lifting surface is far to the back. The center of lift should normally be just behind center of mass. And don't forget to check CoM and CoL with the tanks both full and empty. The game determines which direction to move the control surfaces based on their location relative to the center of mass. If the surfaces controlling pitch right on the CoM then the game can become confused as to which direction they should deploy.

Just be aware that if the flaps are too far back then they will cause your plane to pitch nose downwards. Ideally, they should be exactly in line with the CoM. But because in KSP it's usually not possible to control the weight precisely enough to position the edge of the wing right on the CoM, I usually have to surface attach my flaps somewhere on the underside surface of the wing, deploying downwards when needed. Experiment and adjust as needed, and happy flying.

The "Configure Vessel Naming" menu won't be available after launch. It may be best in the VAB to pre-configure new ships that will be docking to your station to have a lower name priority. Although, sometimes this causes docking ships to retain the station's name after undocking, but sometimes it doesn't. I haven't figured out yet what circumstances cause this to happen. Expected behavior is for them both to revert to their original name after undocking.

The game automatically determines the direction that control surfaces will deploy based on where they are relative to the center-of-mass. If they are in front of the center of mass they will go in the opposite direction than if they are behind it. For flaps this shouldn't matter as much because you should have auto pitch, yaw, and roll disabled from their right-click menu in the space plane hangar, and only deploy them from an action group toggle. For clarity, I'm talking about flaps which add drag and lift without otherwise changing the direction of the plane. Ailerons, rudders and elevators control roll, yaw, and pitch respectively and do need to have those specific inputs enabled (and only those for which they are meant to control.) There is an option to reverse the deploy direction of the flaps in the right-click menu (this might need "advanced tweakables" to be enabled in the settings menu.) As I understand it, this only works to reverse the direction they move when using the "Deploy" command assigned to an action group. It won't change the direction they move when under pitch, yaw or roll input - that's based on their position relative to the center of mass. I would suggest either reversing the deploy direction of the flaps if you want them on the leading edge of the wing or moving them slightly behind the center of mass marker. It's important to make sure that you check the position of the CoM marker with the tanks both full and empty, because the balance of the plane will move as you consume fuel.

Flaps would produce the same result, just with less wing area and usually less total lift as a result. Flaps do have the benefit of being able to control when and how aggressively they are used, whereas the wing incidence is a permanent property of the plane's design. If you want to add incidence to the wings: when viewing the plane from the side use the rotate tool so that the forward-leading edge of the wing is raised slightly. If you want to add flaps, put them close to the center of mass of the plane relative to the front/back of the craft. That way the will add lift without causing a torque that would pitch the plane up or down. Then assign them to an action group toggle.

Consider adding a few degrees of positive incidence to the wings. This means that the leading edge of your wings are rotated up slightly. It increases your lift while still allowing you level flight, giving you better control than if you were constantly trying to pitch up to maintain lift. It also allows for better visibility from the cockpit view during maneuvering, especially during landing. Depending on the design it can cause more drag because the main wings present a larger area to the air - or it could actually reduce drag, because the fuselage and tail plane no longer have to add as much drag as they would when you constantly pitch up for lift in a zero-incidence design. Either way, you produce more lift at slower speeds by adding a slight upwards angle of incidence to your wings.

The science category in the map filter was intended to only show the Breaking Ground surface deployed science experiments. If assigning other vessels to that category breaks the map mode then I would say it should never have been provided as a selectable assignment when renaming craft, and thus is a bug.

Embed a small weight on just one side of the nosecone. Not near the tip, you want it near the base so that you can move it as far off the center-line as possible for maximum torque. A Mk-12-R radial drogue chute seems to work well. It's not so heavy that SAS can't compensate for the off center weight, but it's heavy enough that it will torque the nosecone to one side when you eject it.

I'm done. No more money from me TTI/Squad. Sending my certified letter for all the good it will do. This will be my last post here on the forums. Goodbye all. It was fun.

So I now have to send a certified letter to New York at my own expense to ensure that I still have access to my constitutional right to the public court system in the case that my account information stored with Take Two is compromised or misused. Look, I'm well aware that this is a widespread corporate policy, and that's the problem. Rest assured that I only participate in this farce because at least an opt out was offered, however tedious they intend the process to be. To say that I'm disappointed is a massive understatement. I left my bank and switched to a credit union over this; I refused to operate with a car dealership over this; I do not own a cell phone due to this; and I gave my landlord hell over this until I was given the option to opt out. I now refuse to buy any other DLC or paid content from Squad/TTI until this policy is lifted. I'm only keeping my KSP store account for the moment in order do download patches for a program that I already paid money for and assuming I get signed confirmation that my opt out has been accepted. I do not pay money to any company for the favor of nullifying my constitutional rights!

Hello @NutellaonToast welcome to the KSP forums! Very few stock parts completely block fuel crossfeed, and those will have orange text in the part description which says "No Fuel Crossfeed." Those are: the M-series structural panels and I-beams; the SP-series structural panels from the Making History expansion; and all of the heat shields. The launch stability enhancer technically cannot transfer to other parts, although it is rarely an issue. Some parts will block crossfeed by default, but you have the option to toggle crossfeed on individual parts from the right-click part action window. These parts have orange text in the part description which says, "Crossfeed toggles in Editor and Flight. Default Off." Those include: every decoupler and separator, both radially attached and stack node attached decouplers, including the small hardpoint and structural pylon. This does not include the engine plates from the Making History expansion since they always allow crossfeed. All of the docking ports have crossfeed turned on by default, but this can be toggled off in the right-click part action menu. Everything else will always allow crossfeed.

I'd bet on that happening at some point. With the most expensive blockbuster films running a quarter-billion dollars the cost of a SpaceX flight seems like a match made in heaven... er, the heavens. The biggest hurdles to that would be the weight cost of equipment and the space required to block out filming. You can rent a whole "vomit comet" for less than $200,000 with plenty of room to work. Of course, you're stuck with short takes of thirty-seconds or less. Still, with the cost of launches coming down and the cost of movies going up, it's only a matter of time.

I believe you're partially right. The triangle (or down arrow?) is meant to represent what state the craft is in. (some time later) - Ok. I've just googled it and found some old old posts from years ago that I won't bother linking to here. Apparently, if the triangle is unlit then the craft is unstable and you can't leave the flight scene. An orange triangle means the craft is stable but there is something that prevents you from saving or changing scenes, such as if you are moving over terrain. A blue triangle means you can leave to the space center and the drop down buttons appear (the space center button is blue). A green triangle means you can recover the vessel (the recover button is green.) I don't consider myself a particularly unobservant person, but I never connected all those situations.

Fair enough. At the very least I'm happy to potentially have one less mod in my game. Another one down and only... 70 to go!

I'm not sure that's entirely fair. Clearly, from my previous posts in this thread I agree with your assessment of the use of space in the altimeter design, but I don't think Squad is hiding behind anything. Affordance was only one of at least four different considerations that Maxsimal gave for their design process which also included allocating development time, player familiarity, flexibility for different languages, and consideration for screen resolutions and visual impairments. Now I don't know how much time and effort in programming is required to redesign that interface, but the current Squad development group inherited this design from previous developers that aren't around anymore. I doubt that there is anyone left on the design team that had a hand in creating that UI layout. The current guidance among this dev team seems to be to favor layout consistency first, supplemented by optional and unobtrusive additions. And Maxsimal DID explicitly say that they ARE considering community feedback. I think that's reasonable considering that this instrument cluster was intended to be a quick glance display. Many players could be frustrated if things weren't in their familiar places at critical moments. Having said that... I agree with almost every issue you pointed out in your post and I personally wouldn't mind a little streamlining.

I use it too, but only when I don't need to be too precise about when I stage off fairings, or switch mode on Rapier engines, or see how fast reentry is progressing. Although, since the TWR display was introduced along with delta-v in the staging display I use that now more often to see when I need to switch over to orbital engine mode. After a few launches you get an intuitive sense for these things. I'll be the first to admit that the atmosphere density gauge helps to tune that intuitiveness, so I'm not suggesting to eliminate it. I'd just love to see it in a smaller, vertical aspect.

Hello @Randalf welcome! How is your trigonometry? I admit that I'm not skilled in the mathematics, but I can help explain why this problem is more complex than you are imagining. Sometimes it's helpful to take an example and push it to the most extreme limit to see where the underlying problem is. Imagine that you have two ships orbiting the planet in coplanar (parallel) equatorial orbits at the exact same altitude. Because their orbits are identical they are going exactly the same speed, let's say 2000 m/s. If they were traveling in the same direction their relative speed would obviously be zero (0). If they were traveling in opposite directions their velocities would combine so you add them together for a relative velocity of 4000 m/s. Now, imagine that one of the ships is on an equatorial orbit going 2000m/s. And the other ship has the same orbital altitude and speed but its orbit is inclined by 90 degrees and is on a polar orbit. They both have the same shaped orbits, the same altitude, and the same velocity. But you can NOT simply add or subtract their velocities to find the relative velocity. It's somewhere in between. Now what about this case? In this case, the data shown in the orbital information is the same: 2000m/s for both ships, same apoapsis, same periapsis. The orbits intersect and you can see that the ships will be in the same place when they converge so they could hit each other. There must be some positive relative velocity; it will be lower, but not zero. But you can't subtract 2000 from 2000 and find the actual relative velocity for orbits that are inclined in respect to each other. You need more information than just what is presented on the screen. In your case, there will always be some small difference in inclination or some small elliptical difference, and the point where those ships are in their orbits also changes the outcome.

While Raptor9's suggestions would certainly be an improvement over the new altimeter's preview, I think there may be even more room for improvement in efficient use of space. In my opinion, the atmospheric density gauge at the bottom doesn't really provide enough vital information to justify such a large portion of the screen. At least, the number and width of the subdivisions is more cosmetic than vital - you don't need any numbers there after all. I would rotate the atmosphere scale to vertical, shrinking it by about 1/3, and place it on the left. This would not only match the vertical aspect of the atmosphere, but would free up at least two whole lines of text space at the bottom of the altimeter for ASL/AGL indicator and (hopefully) apoapsis/periapsis information. I would gladly accept a wider altimeter if it intrudes less on the middle of the flight scene.

Here is a simple wiki on making KSP flags. https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Create_custom_flags! They have to be .png files at 256x160 pixels in dimention. The simple way I do it is to just make a copy of any of the default flags in the GameData/Squad/Flags folder, remove the previous design, add my own and then save it under a new name. You can place them inside the default KSP flags folder at "Kerbal Space Program/GameData/Squad/Flags". Or you should be able to make any new folder in the GameData folder as long as you have a folder called "Flags" they should show up in the game.

When you wish upon a star Makes no difference who you are Anything your heart desires Will come to you... -------------------------------------------- 58 tons and 1176 parts, almost half of them could be lights but I wouldn't hazard a guess on the number. Mods used are heavy use of Tweakscale, Aviation Lights, Surface Mounted Lights, and for camera effects Scatterer, and KS3P with the camera bloom effect turned up. Direct screen captures from in game, no photoshop used.

Welcome to the KSP forums @STORMPILOTkerbalkind, you've certainly found a very Kerbal way to get into the game. How fast were you going when your rocket car failed? At some point it simply won't be possible to overcome even the most minor instability caused by steering wobble before parts of your vehicle slam into the ground. And even if that doesn't do you in, atmospheric heating will probably start to explode things if you aren't using spaceplane parts. At the highest speeds KSP can't even process interactions with the ground consistently. If you don't mind construction spoilers, this video by Stratzenblitz75 gives you an idea of what's possible.