Jump to content

stormdot5

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by stormdot5

  1. Hi guys, just tried to install FAR to KSP 1.9 and The control surfaces aren't responding as expected from the menu. All control surfaces are deflecting different amounts, even though I've set them up as flaps/ailerons/elevators etc. Any idea what is causing this/how to fix it. Can't see anthing related in the last couple of pages, and searching only brings up control surface tutorials rather than bug fixes.
  2. In previous KSP you could only reach ludicrous speeds modded engines, cheats, or an encounter with the kraken. In KSP2 by default there will be engines that will be able to take you to an appreciable fraction of c. Do you think they will be adding in anything to simulate the effects of time dilation on the travelling craft or changing the way collisions occur at relativistic speeds? Mostly we expected the game to bug out when we pushed the limits before. But people can set up a collision specifically at relativistic speeds now. In old KSP I would just expect the crafts to just pass through each other between physics ticks. In KSP2 I'd expect something more consistent. With time dilation I reckon it's going to get real complicated for life support mods.
  3. I think it has been established that adding monoprop at any point in the mission planning our on route would be inefficient. Secondly, it you end up with more monoprop than you need, you might as well burn it, in any mission. The change in weight due to using monoprop will improve the delta v of your craft. You can factor this in when designing. In regards to the oberth effect, I think that yes, you could improve the efficiency of the liquid fuel engines by burning the monoprop at the same time. Even using RCS ports to burn the fuel. Calculate the increase in thrust, and therefore the reduction in burn time. This would allow you to burn for a shorter time and closer in to the planet, which provides the Oberth effect improvements. But as stated, it would have been more efficient to not have brought any extra fuel to begin with. As for your designing, I think I would leave the monoprop and pack as much liquid fuel as possible. Better to have more delta v and burn it slightly inefficiently than try to make up TWR by burning monoprop. I don't know the numbers but it's possible packing oxygen instead and a detachable LFO engine might even be more efficient than monoprop if you need a short term TWR boost.
  4. I think there is another factor at work here that is due to the way KSP deals with controls rather than the physics of the situation. I think these two items need to be addressed as they are a bit of misinformation in an otherwise well thought out post. It's funny that these appear as you've quoted and agreed with EpicSpaceTroll139 who has linked the specific explanation of why this does not work: Pendulum rocket fallacy I think it might be simpler to say that you cannot arrange your engines for inherent stability on a VTOL. To explain the issue of how to arrange engines to give them the best control of orientation, including stability when using SAS, I think the best answer is throttle controlled avionics, as linked above by EpicSpaceTroll139 The reason for this is that the normal position of engines when building a VTOL, arranged around the center of mass, puts them in the best location to provide torque to rotate/stabilise the craft. However, they cannot apply torque as the throttles are all linked and each engine counteracts it's opposite. Allowing them to throttle individually shows they can provide lots of torque and therefore be used to stabilise the aircraft. Discounting mods, the stock SAS only provides control though gimballing (ignoring reaction wheels). When a rotation command is input from the player or the SAS, both opposing engines gimbal the same amount, reducing torque around the center of mass equally in both directions, and trading it for translation. See picture A, The blue arrows show no net torque, and the green arrows show the resulting translation. http://i.imgur.com/0j3sTAf.png This means that engines on the same level as the center of mass cannot provide any rotational control. So if we rotate the engines in towards each other and then apply the same rotation command we get image B. The built in angle is offset by the gimble on the left engine, meaning it provides a lot of torque around the center of mass. This is only weakly opposed by the right engine, which puts it's thrust into translation instead. The result is a net torque and ability to control the rotation of the craft. In picture C the engines are located below the level of the center of mass. This is exaggerated but effectively during a rotation command the left engine is providing thrust almost perpendicular to the line to the center of mass, giving only torque, whereas the right engine is aligned with the center of mass providing only thrust. This would be the same if the engines were above the level of the center of mass. So how should you arrange your engines? If they have to be on the same level as the center of mass, then angling them in gives you some control. However, as Snark pointed out you need more overall thrust to lift the craft. This means that the craft will be wasting fuel in when VTOL mode. If you can lower them below or above the level of the center of mass then you can provide control authority and only require the minimum thrust to lift the craft therefore being efficient. There will be a translation induced while you are holding the controls, but it should be minimal. If you are really serious about VTOLs, then it's probably best to try out throttle controlled avionics. It's worth noting that KSP could provide the same functionality as TCA without individual throttles. If a player or SAS makes a rotation command, and the net effect of gimballing the engines is very little rotation, then don't gimble the engines on the side the the player requested. The net torque should provide some rather than no control authority.
  5. I've been playing with manually building a ground level communication network on Kerbin. I've been using mountains and hills to elevate my relay stations to allow a much longer communication link between stations. My question is, is it worth elevating a sea level relay station to increase range? Is the communication link drawn from the center of mass of the vehicle? So If I built a sea comms tower, balanced with a mass at the bottom, it would move the CoM so low that the height would be irrelevant.
  6. In previous versions I would neter the map screen before launch and activate the navball so that I could control my craft when I went from flight screen to map navigation. In the 1.2 prerelease the navbal won't staty visible when I reenter the map screen, it has minimised itself again. This means I lose control of my craft for a second as i have to click the show navball button with the mouse and temporarily have no idea of it's orientation. This happens every time I re-enter the map screen. Is there a new setting that decides this functionality or a lock button? Has this been put into 1.2 intentionally?
  7. I've been trying to test out the functions of the suspension setting and thought it would be good to share it here. I tested by using a MK2 Fuselage with wheels on, along with Vernier engines to induce oscillations/simulate bumps. I also dropped it from a launch clamp. I tested with the fixed, and small folding gear. Kerbal engineer was required for precise ride height as it measures surface altitude to centimeters. Spring strength I assumed this would vary the ride height depending on the setting, and therefore set the suspension travel available. It turns out that setting it below a certain point, depending on the load on the spring, will cause the vehicle to sag or bottom out. This means that there is a certain minimum setting for the weight on your landing gear. If you set it below this then you won't get full travel / bottom out, and your plane is likely to be unstable. Trying to test the effects of setting it higher showed me that landing gear dropped vertically is incredibly resilient. Once you have the minimum setting as above then it appears you are likely to be able to smash your plane into the ground at any reasonable speed and get away with it. Setting it higher may give you more leeway with high speed impacts with the fixed gear as it may clip through to the ground. Setting it too high for the weight of your plane can lead to it breaking on impact. Damper Strength This does function as you would expect, dissipating the energy in the suspension over time. Setting it too low can cause the vehicle to become unable to shed the energy from driving. You can determine this using RCS to disturb the vehicle and seeing if settles back to a stable state. It is very obvious when rolling around whether it has enough damping. Setting this further up can cause the suspension to respond slowly, possibly causing issues with uneven runways or terrain at speed. Setting this high in conjuction with spring strength can lead to brittle landing gear, stiff, but likely to break on impacts. Peculiarly, setting it to the maximum setting, or close to it, can cause similar effects to too low, where the vehicle is unable to stabilise and apparent phantom forces keep vibrating it on it's wheels. Hopefully some people might be able to use this information to help set up their craft. I think it should be as simple as testing minimum sping strength for the weight using ride height. Then the minimum damper setting for stable rolling. Then if your craft has issues with landing, add spring strength to address breaking landing gear, and damper strength to reduce bounce, in small increments.
  8. I think you might have a problem with your frame of reference. Watching the two objects from a third position in real life shows you the difference between the two after a collision. In KSP you are locked onto one of the objects, and only the other object appears to move. This might skew your observations. Place two craft in a high circular orbit so that their speeds are constant, then collide them at a known collision speed. Calculate the change in velocity on each craft taking mass into account and it should come out correctly.
  9. It's feasable to take a reliant or swivel, stack fuel tanks until you have a TWR of about 0.5, knock it over, prop it up with some wheels, add enough wing to make it flyable and then just abuse your excess of delta V to reach orbit without staging. I've done something similar with a skipper when testing how much of a craft to give over to air breathing engines. With the tiny Juno, on such a large craft, it's probably not worth adding any air breathers as you'd need so many. With the wheesley you'd have to test to see whether it was worth it. However you achieve it, without the Panther or better, these are going to be primarily rocket biased craft, using wings to permit excessively low TWR, and for re-entry control.
  10. Are there any mods which simulate the dark side of a planet while in the VAB? I find it hit or miss whether my spacecraft is suitably illuminated by the lights I've placed in the VAB. Sometimes it's ok, sometimes it's just spall spots and edges that show up. A mod to turn off the lighting in the VAB would be great. I think I read in one of the dev notes that some of the lighting is bult into the static scene, but making the ship dark should be possible.
  11. Tail backwards, wing sideways. This plane seems to have unreasonably agressive roll. Could probably get more crazy with some asymmetric thust.
  12. The Centre of Lift being above the Centre of Mass should result in a more stable aeroplane. Putting the CoL below the CoM can result in a more manoeuverable (or possibly unstable) plane. CoL being behind the CoM is usually trimmed out once in flight to result in no net pitch moment.
  13. Thought something like this might help people with some of the basic plane issues that repeatedly pop up. Tried to get as much as possible on one picture, rather than a long tutorial.
  14. I'm having trouble with low tech level planes. The landing gear doesn't seem robutst enough and causes a potentially fatal wobble on take off/landing. Here's my basic planes. A simple one and a rocket boosted one for surveys at altitude. When spawning the heavier plane, it may drop onto the front landing gear, boounce once, and then break the landing gear when the nose comes back down. Putting the landing gear nearer the CoM makes the initial bounce less and sometimes lands safely, although this ruins stability. During the takeoff run the plane rocks left to right in an increasing oscillation with speed. The landing gear never reads as stressed but at some point it gives up as "overstressed", especially at close to take off speed. When landing the tiny amount of force they take to break means even a perfect landing is liable to snap off landing gear with catastrophic consequences. This is with landing speed of between 50-60 m/s and vertical speed of less that 5 m/s. If it does land, OK it's still likely to destroy the landing gear while decellerating. Rough terrain landing is unlikely to be survivable. Settings are usually on default. Turning off suspension is ineffective at stopping the wobble. Biasing friction to the rear appears to delay the onset. Any advice?
  15. I've been having trouble making a rescue vehicle for early career mode. The general profile I'm trying to achieve is; Low tech - No R&D building upgrade, the less unlocks required, the better. Multiple crew return - Preferably 3 Kerbonauts, with a probe control for sending it up. Gliding re-entry - To come back without a heatshield, with some cross-range ability. Easy landing on wheels - Enough control authority and/or lift to land like a plane. Low cost - Intended to return Kerbonauts from LKO without costing more than mission payouts. It would be nice to return the final stage engine and tank aswell for better value, but not neccesary. Also, final touchdown on parachutes would be ok. I'm mostly having issues balancing the final stage craft in such a way that it remains controllable at low speeds. It often ends up with not enough control surface leverage, or it has excessive drag. I'm sure others have used similar profiles to this, so if you could post your crafts/experiences that would be great. Thanks
  16. The only reasons for 64 bit for most people seems to be to increase available memory to allow more mods before crashing, or to support constantly growing part counts. I was wondering whether it will also allow increased precision in object positioning in space, for things such as distant object enhancement. It would be great if this could remove the instability of objects. For example, when trying to catch something in interplanetary space that keeps shifting when you change time warp levels. Improving accuracy of multiple SOI changes for gravity assists would also be welcome. Would this happen with 64 bit in 1.1? Or would things have to be further updated?
  17. 1.25m utility bay on top of the capsule, with a docking port on top of that. Inside, a probe core with 3 parchutes attached. Set them to deploy at 0.4 pressure, make sure the bay is open and deploy before you run out of charge. Your pod is now automated and can carry tourists!
  18. One potential method of returning from this specific situation would be to wait until Minmus rotates to point you almost directly backwards in it's orbit. Then burn straight up. It's less effiecient to escape minmus SOI but every m/s spent will decrease your orbital speed round Kerbin, lowering your Periapsis. Also, it is a very simple technique. Escape velocity of Minmus: 242.61m/s Orbital speed of Minmus around Kerbin: 274.1m/s You should have enough dV to escape this way, make sure to quicksave though and work out a good aerobraking periapsis, it may be lower than you expect.
  19. [quote name='Octa'] Fuel consumption -> less mass -> higher TWR -> higher accelaration and speed -> more lift [/QUOTE] -> Less trim required, but not actually adjusted -> Pitch up due to trim
  20. [URL="http://forum.kerbalspaceprogram.com/members/71315-Geschosskopf"][B]Geschosskopf[/B][/URL], Regarding your second pass from a lower apoapsis to the same periapsis resulting in more braking. You would have a lower speed at periapsis, starting from a lower apoapsis, so the instantaneous drag at this point would be less. However, a lower apoapsis also means coming closer to Kerbin throughout your orbit, which means contacting the atmosphere sooner and for longer. This is apparently having a more signifigant effect than where you set the periapsis, probably due to this in the patch notes: "Physics: * Drag coefficient changes based on the same factors as turbulent convection (a Pseudo-Reynolds number). This means higher drag high up in the atmosphere, and slightly lower drag when going very fast very low."
  21. It looks to me that th epoint behind the payload where the rocket diameter goes from 1.25m to 2.5m is a weak point. This allows the fairing to go off center and develop drag on the tip of the rocket, whice at transonic speeds is enough to overcome the stabilising fins at the bottom. The Thrust to weight ratio of the mainsail is good to get the rocket off the pad but it will get too fast too low in the stmosphere to remain stable. Suggestions: 1. Strut between the main rocket and payload to prevent wobble 2. Reduce throttle when you are close to 300m/s and then gradually increase speed once you are above 10km. Once you get to 25km ish, you should be able to go full throttle again. I would also suggest switching to a 2 stage rocket. Not for any more dV, though that would likely result. A second stage would be much smaller and would mean your SAS and RCS systems could more easily rotate and adjust the rocket. You could even make that stage recoverable it you wanted.
  22. Maybe it depends on if you're on the ocean floor. I got out halfway up and it destroyed Kerbin but people seem to be ok when at the bottom. This probably needs repeating and bug reporting.
  23. Here's something I built while tring to figure out underwater travel This sub went 856m down, 3.6km along, crashed into the bottom and broke apart. Jeb got flung into the air in his cockpit and bob tried to get out of the crew cabin, causing Kerbin to disappear. From a bit of rough testing, neutrally bouyant is about 280kg/m^3 That's using the editor's 1.3m for width, which I think is rounded from 1.25m. That would make it 300kg/m^3 If you aim for this figure you should get very little force up or down when in the water, making it easier to travel. Remember to bring some lights though, I forgot and had difficulty seeing the bottom.
  24. You should be able to do this with KER. Seeing as you want to get your orbit equatorial, select surface mode and view the latitude/longitude. Wait for your ship to cross the equator and then burn to cancel your velocity in that plane.
  25. A workaround for anyone who finds this in a search: Attaching decouplers to the fuel tanks on the side of my lander means I can decouple the extra decouplers on launch, which reverts the rest of the parts to shielded.
×
×
  • Create New...