Kertherina

How are you supposed to land on Venus? I made a successful entry just yesterday and even successfully landed in previous versions of KSP / RO, but now once i reach 4000kPa pressure everything just explodes. Since as far as i know there are simply no parts that can withstand more than that (i've looked through most of the tech tree), how can you make things not explode before reaching the ground? Should you simply not use the option where pressure can destroy parts?

I occasionally have the same problem and also KSP crashing when trying to load crafts, although i wasn't connecting them before. Also using RO and RP-0.

Thank you very much, one of the mods i really missed with how impatient i am, especially during reentries

I don't use CKAN so here's a screenshot of the GameData folder: http://i.imgur.com/oC3koi2.jpg (The Mainz_EngineAttachRules.cfg allows for surface attachment of all engines, not sure if relevant but just so you know what that does. Also, i think i added KJR afterwards)

I also have a problem with engines specifically breaking way more often than they should. I basically haven't had a craft where nothing fails for a while now. What really got me suspicious now was a Duna lander with twelve 24-77s, where eight ( ! ) broke after just a short deorbit burn, landing assist burn to help the chutes, and attempt to hop a few hundred meters so in the span of being active for maybe a minute and a couple restarts (not sure if relevant). Age also shows ridiculous values like 40000 which is about the total mission time if this is in hours, and MTBF of 0.16 despite the fact that engines are supposed to only age while being active. Not sure if there's a problem with mod interactions, i do have a lot of other mods installed too, but don't really have the energy to figure this out at the moment so i'm just gonna uninstall it for now, but i wanted to let you know. Cheers for an otherwise great mod that enhances the atmosphere a lot.

Works for me, also for already existing crafts (or well the one i tried just now which did not work before). Thanks

I don't suppose there's a way to make a part a root part during active flight? I did select "control from here" for the probe core but that also did not help after undocking from the space station.

I have the same problem and do use SETIctt. One addition to this bug: I managed to launch a 3 man pod with 3 tourists with a OKTO2 probe core to my space station, only when trying to undock and fly back did i get this problem.

I am new to all of this and learning as i go, so thanks again, you are really, really helpful and this cleared things up yet again What i wanted to say was i need to think about what exactly the real part of the quaternion would stand for since that would be the roll information i currently store with the separate starboard vector. So basically, how is the craft rolled when the real part is zero since that would be the basis for everything and i need to know how to initialize it at the beginning of the simulation. I just don't have a (visual) grasp of it just yet. As for errors, there is so much stuff going on that i can easily just normalize each tick, it really makes no noticeable difference.

Thank you, that sounds all very helpful. Now i just need to think about how exactly to store the ship's orientation in a quaternion.

Science is a method and a way of thinking. By making observations, formulating hypotheses and testing those (by seeing if predictions from the hypothesis are true), it is the only tool to find out what reality is like. As for some of your secondary questions: What will it allow us to do in the future? That's impossible to say. It's hard enough predicting what we will find out in ten years, let alone in the distant future (at least that is what your question sounds like to me). I am convinced of one thing though, if humanity lives long enough it will discover many exciting and strange new things beyond our wildest dreams. Think something like quantum mechanics, or the theory of relativity, only one step further still. Are we using it properly? "We" as in humanity...not completely. You just have to look at all the misuse of science in the form of weapons. Really not a surprise if you look at humanity today though, maybe one day we will grow up and only use science for good. What is it's potential? Pure speculation, but science may one day fully explain our universe and maybe even beyond that. If we as humans are intelligent enough to understand it and get this far is another question.

I'm using quaternions. And since i'm still pretty new to programming (this is my first project bigger than "calculate some prime numbers"), low level coding does indeed sound scary. Besides, if performance were a problem i could just reorthonormalize only every 100 or 1000 rotations. The error shouldn't be noticeable then either, the only reason i am doing it every 10 rotations is because there is no noticeable difference in total simulation performance. And branching...well, again, as long as i don't notice a drop in performance it should be fine.

Just wanted to let you know, it works like a charm. I can easily afford to reorthonormalize with Gram-Schmidt every couple rotations (perks of having a very computation heavy simulation ^^), doing it every 10 rotations atm, where the floating point errors are obviously pretty much nonexistent.

@PB666: I don't have much to say about all this since i have yet to dig into this topic, but thank you so much for writing that out, that was really helpful. @K^2: Currently i have set the origin of the coordinate system to the starting point of the Sun. I don't see how this leads to problems though, i have a fixed frame of reference and calculate everything from there. That shouldn't be a problem, or is it?

@PB666: I can't follow you completely, but i plan to consider every major body for n-body physics for now. If the performance gets too low i can still change that, Pluto is a good example for a body that won't have a significant impact most of the time. Here's how i currently plan to deal with n-body gravity: I have only started to look into this (so many things to learn for a simulation like this...) so this is all subject to change, but so far Encke's method seems to be still relatively simple, yet pretty accurate. Basically you predict the unperturbed orbit which you can do exactly, and then introduce the perturbations that change the orbit. The error being proportional to the perturbations means it will also be small since perturbations are small in general so it sounds pretty neat so far.

If i can add more digits (what i can actually do thanks to the MPFR library, although it is quite the effort compared to using a double), why should i stop at one extra? If i do this i will use something like 25 digits, if only because that is already the precision i use for position vectors and it's easiest to use one precision for all arbitrary-precision variables. First i will try fixing the orientation with some cross products now and then though, that would be the best solution in terms of computation power needed.

No, that doesn't work because you don't have those digits to be able to round. That's the thing, the numbers are only exact up to so many digits / Bits, after which they just stop. If you had the additional digits to round, then you could just use those in the first place.

N-body physics isn't really an advantage for this, neither is it a disadvantage. A more critical question is how i want to deal with gravity torque, if i cut that off once it is weak then i could maintain the orientation vectors over long periods of time without any rotations and thus without error. Can't be any more precise because i yet have to look into that topic, and i will not do that any time soon. The error is floating point errors. It has nothing to do with the code or the equations, it is how the computer handles floating point numbers. Maximum precision for a double is around 15 digits. Beyond that, anything can and will happen. Also, the last digit isn't even rounded, everything beyond that is just cut off. Add to that a large number of ticks (10^9 - 10^10), and the error starts to become noticeable. I do use GNU MPFR for arbitrary precision arithmetic so i can just use a higher precision variable, but i was asking because i wasn't sure there are other / better / more elegant methods of dealing with this since i am pretty new to programming an this is my first big project (the first "bigger than calculating prime numbers" project even). EDIT: @K^2: Thank you, i wasn't aware of either and will look into those links tomorrow. As for the cross products, sounds like a great idea too. I don't care about the exact roll value anyway, much more important is the orientation of the vector and that it doesn't mess up transformations. I will definitely implement that. And yes, i plan to improve upon the n-body gravity anyway, currently i just have Cowell's method and i plan to use Encke

No, i have full n-body physics. Not yet gravity torque, but that will be implemented later too. Anyway, tick times may go up to the order of seconds for no thrust, but that will still be a lot of ticks over decades. As for the errors, it would cause an error in the value for roll (which would be negligible), but more importantly a changing port vector would mean a different orientation too - which has implications for everything, because it is used for transformations, and you have to transform everything for thrust and lift forces, so it can have an effect on both translation and rotation of the craft, which can be fatal if the errors become big enough. And as for the order of magnitude of the error, if you assume something like 14-15 significant digits for a double and 1s ticks and saying that an error greater than 1E-6 is significant, it would only be a matter of single digit years. EDIT: First part is what seems to be the consensus. There's seemingly no other way. And not caring about roll is not an option, while it is possible in theory it would be very limiting and i definitely don't want that since it is also supposed to become a game, besides a realistic as possible simulation.

Getting the axes initially is not really a problem, as i am saying you can set up the port vector in the beginning and then rotate it with the craft. What worries me is the error that accumulates over time, because if you rotate the port vector every tick the craft rotates you do get floating point errors. For long missions talking dozens of years there will be a lot of ticks and these errors will accumulate, both changing the value for roll and making the port vector not perpendicular to the forward vector any more. Which is where i asked myself if there is not a better way. Which vector exactly you take and how exactly the axes are oriented doesn't matter, because this problem is from the rotation of the extra vector so it's always there if you take the "initialize vector and then rotate it with the craft" approach.

That would not work. The way this system works is that engine and wing positions and orientations are in the frame of reference where port is x, up is y and forward is z. If i choose different starting axes then the starting positions of the engines and wings would be different again, and i would not have gained anything because i get the same exact problem with a slightly different coordinate system and different part coordinates. Different numbers, same problem. Also, by now i am guessing this is just how it works, you take the port vector at the beginning and rotate it and live with the error. At least i am sure enough that tomorrow i will try that and see if it works.

1. Space contracts as in it gets shorter in the direction you are travelling (Lorentz contraction). This is closely related to time dilation, which is the phenomenon that time goes slower the faster you go. Why both of these things? They are direct logical consequences required for consistency with c being constant in every frame of reference. If something like a train is moving near the speed of light, and it emits a beam of light, then it has to travel with the speed of light for both observers outside standing still, and for observers on the train. If time and space would not change, then from the observer on the train the beam of light would travel at c but for an outside observer it would be faster than c. This can't happen. So, time goes slower the faster you go, or in other words an outside observer will see time pass more slowly for the train. Now, since time passes more slowly, that means the light is travelling more slowly too and thus not faster than light any more. As for the lorentz contractions, someone less tired than me can probably explain that. 2. That is a good question. Historically, it was acknowledged that c has to be constant in all frames of reference for maxwell's equations to not break down. Special relativity is then a direct consequence of this, accessible via thought experiments only. As for why exactly is c always c in every frame of reference - why is any physical law just the way it is? It's a question that has no answer. 3. Well they are not exactly the same (otherwise why would we have different names?), but they are part of the same: space-time. Every bending of space results in a bending of time and vice versa, they interact like one entity. This also has implications for velocities. In fact, you are always moving at the speed of light - but through space-time. If you don't move in space, you move in time with c. It's a 4D-velocity vector in space-time. This also explains why the faster you move through space, the slower time passes because a larger portion of c is going in spacial velocity, rather than in time. 4. What do you mean "it"? And in fact, gravity also has effects on time (and obviously space). This is the field of general relativity though, whereas until now it was all special relativity. Special relativity is the "easy" part, concerning itself with non-accelerating objects not in gravitational fields that is accessible via thought experiments alone. General relativity is, as the name suggests, more general, and much much more complicated.

You again save the weight of a launch escape system though, which is really heavy. Also, generally the weight of parachutes is underestimated. I don't remember any numbers, but i read that thrusters are in fact lighter than parachutes for a Dragon like capsule.

For me active (thruster) landing for capsules, without question. - Rocket technology is mature as you said, you can add redundancy for extra security like SpaceX does. - It doesn't need much mass - Abort capability straight up to orbit - Soft pinpoint landings - Edit: and launch abort system is also included! It's just a combination of security and versatility, plus it allows reusability (no landings in salt water) and even rapid reusability, that makes it superior in my opinion. A backup parachute for redundancy doesn't hurt either, giving you two very different landing options (different again means more secure because not everything that destroys a chute destroys engines and vice versa) for earth at least. I can't wait until the first Dragon V2s land actively, i think it is the future. EDIT: For boosters, since you already have an engine why not reuse it? Additional parachutes or something else would add way more dead weight than a bit extra fuel, see SpaceX again. For probes, parachutes can be super handy, but that obviously depends on the target. On a planet with atmosphere you should use it, without atmosphere you have no other option than active landing, and on Mars you could in theory to both (only parachute is not an option), but then pure active landing might just be the way to go because it is simpler than having two different systems to land.

Not sure if i understand that correctly. If i make the local coordinate system fixed and the axes all parallel to the global fixed plane, that would mean i could just stay in the global coordinate system. The point of the transformation is to have something in a local frame of reference because the positions and directions of engines and wings are all relative to the rocket, so this coordinate system has to constantly rotate with the rocket too. And generally, i need the local coordinate axes in forward, port and up direction to have a consistent coordinate system. Aligning them with the global axes is counter productive.