Kermunist

It is a little difficult to make good recommendations without you giving us a little more information about your current knowledge and maths skill. You might also say if there are any particular areas in physics that interest you. The old Feynman book you mention was probably The Feynman Lectures on Physics, which comes in three volumes. It was published in the sixties, and they are showing their age a little, but I would still recommend them for a reader with a moderate level of physics. Landau and Lifshitz, as recommended by K^2, is also excellent, though as he says it is very maths intensive. I would think of them as a more advanced text, because of that. If you have sufficient maths knowledge I would recommend them. The earlier volumes are even older than the Feynman lectures, and the later volumes are younger, but in some ways they have aged better. It's also a very theoretical text, with less emphasis on applications of physics that I personally find interesting. In first year at my university we used Fundamentals of Physics by Halliday, Resnick and Walker. It's more up to date than the other two, both in content (not that there's much to update at that level) but also in pedagogical approach. If you really want to learn to do physics, as well as learn about physics, the sample problems will be useful. It's a less advanced text than the other two. I actually found A brief history of time quite interesting when I read it as a teenager. I think I was in a minority there, though, and it's not really a textbook. It also limits itself to astrophysics and cosmology, where the other books I've mentioned are broader.

Soo... I was actually thinking of writing a mod to do this. I was going to call it the orbital correction device, or OCD for short. I don't have time to do it now, or anytime in the near future, I don't even have a C# environment on my computer at the moment. But I don't think it should be too complicated. I don't feel any ownership of it and most certainly would not object to someone else making it based on the approach below. KSP stores orbital information as Semi-Major axis, eccentricity, inclination, longitude of PE, longitude of ascending node, mean anomaly at epoch and epoch. Of these, only the semi-major axis has any affect on orbital period. Vessels with the same orbital period maintain station relative to each other, and this is represented accurately by the patched conics used in KSP. There is no need to maintain a list of other satellites in the constellation or fix phase angles, it is sufficient to give them all the same SMA. The code would execute every time a vessel is unloaded, and would look like this: a = semi major axis of orbit of the vessel being unloaded Make a list of other vessels orbiting the same body For each vessel in the list b = semi major axis of orbit of the vessel from the list if |a-b|/a<0.0001 then a=b Break from loop There are probably a few other useful features, like syncing SMA with that of celestial bodies as well as vessels (this would make stable quasi-lagrange points at L3, L4 and L5). It might also make sense to tune the 0.001 threshold above to different celestial bodies and altitudes to make sure it is always neither trivial nor impossible to achieve. A simple GUI indicating what changes would be made on unloading might also be good.

RP-0 is a complex mod, and it builds upon and requires several other mods to work. It may not be the best place to start. Mods consist of several different bits. Generally: 1) Parts. You can create a new engine or fuel tank without any real programming, you just draw it in special software, write a config file for it and drop it into the appropriate folder. 2) Plugins. These are changes or additions to the KSP program itself, and are written in a programming language. Since SQUAD use a language called c# to write KSP, most plugins are also written in c#. RP-0 contains both parts and plugins. When writing a plugin (or indeed any program) you start with source code, which is desired to make sense to a human then a special program called a compiler translates your source code to a binary, which makes sense to a computer. When writing a mod or any not-tiny project, you end up making many changes to the source code. When you have many people working on the project, they all make changes. To keep track of all the changes, many people use a tool called source control. Git is an example of source control. A repository contains all the source code for a particular project. A commit is when you add your changes to the source code in a particular repository.

Much of what is now in GameData used to be in these folders. In order to add (for example) a part through a mod, you had to put it in these folders along with the parts provided by Squad, and if you wanted to remove a mod you had to sort through and find all the parts that came with it. This was a pain in the neck, so Squad changed over to using GameData and subfolders therein. I think they also changed the format of certain key files at the same time. The old folders, along with the code to load things from them, were left in so that mods which hadn't been updated would still work. They've probably outlived their usefulness now though.

To be fair though, Voyager uses a massive dish to make that 20W into a very narrow beam. As a result it is 46dB stronger than it would be if it came from a simple dipole antenna. So if voyager was equipped with a simple dipole (which is what KSP's basic antenna looks like) then it would need 750kW or thereabouts to yield the same signal strength at earth - obviously impractical. So I think it is realistic to give the simple anteanna a range limit. The other two antennae look more directional, so it's reasonable to have them work at longer ranges with more moderate power requirements.

If you post up your save file (look for ksp/saves/YourGameName/persistent.sfs) someone might be able to fix it. Even if they can't posting said file in the support forum might help Squad fix the bug.

I think you'll find the pitch in the table called "pitch angles". It mostly increases, but does occasionally reduce. Angle of attack will have remained small throughout the flight. It's definitely not that. I think the graph you're looking at is called "space fixed flight path angle". I think that means it is the angle the velocity vector makes with the horizontal in the space-fixed frame of reference. So to start with, at time zero, the rocket is stationary on earth. In the space-fixed frame, the rocket is moving horizontally because the earth is rotating, and the angle is zero. Just after lift-off, the rocket is moving up as well as across at the speed the earth is rotating at, so it makes an increasing angle to the horizontal. As the rocket pitches over, it stops gaining vertical velocity and starts gaining more horizontal velocity, so the angle stops growing and starts to fall. Eventually it reaches orbit, and at that point it is travelling horizontally again, and the angle goes back to zero. Make sense? I know what I mean, but I'm not sure I managed to communicate it.

Well, here's a source for the first problem. Though perhaps it would have been better for the OP to provide it. http://answers.unity3d.com/questions/9999/procedural-mesh-leaks-memory-everytime-the-game-ob.html note who posted the most recent comment on the answer. Note also the dates, this may well be fixed in Unity now.

I think you've missed my point a bit tntristan12. It's not that the predictions would be very difficult in an improved aerodynamic model (though the outcome would depend a lot on how the ship's attitude changed during the maneuver, which might be hard to predict), it's that they would be different from the predictions for the current model. So there's no point adding this until the improved aero model is in. Otherwise the code, and the time and effort in writing it, would go to waste when the new model comes in.

As has been said, solder isn't very strong, and it might still break even if you're doing it right. That said, here's some tips on making a strong solder joint: Make sure the solder wets both parts well. It should run all over the contacts. If you only put a little solder on, it should run around and coat the contacts, not sit in a ball where you put it. If this isn't happening: - make sure both contacts are heated through (can be hard with big blocks of metal in plugs) - try cleaning the contacts first or - try using a small amount of flux to get things going. Clean any excess flux off afterwards. A harder solder would be better, but might be difficult to get hold of and need a hotter soldering iron. Unlike soldering a normal component, use loads of solder. Build up a big blob that completely covers both contacts and joins them together. The solder joint should be shiny and bright when it's done. No stringy bits or points where you took the iron away from. If it goes dull then either: - you took a long time to make the joint or - you moved the component as the solder was cooling But as I say, even if you do all this right, it still might not be that strong. The hot glue idea's a good one, I might use epoxy resin (because I don't have hot glue).

I think this has been considered and discounted for technical reasons. The current atmospheric model is very simple. A cylinder experiences the same drag going end on or sideways, there is no concept of streamlined or anything like that. This makes it easy to predict how the orbit of a craft changes as it flies through the atmosphere (unless it has wings). So as is, it's not too hard to do what you want, and the hard working folks behind mechjeb have done it. But the plan is (or was) to change the atmosphere model to a more accurate one. Squad never made it particularly clear how much more accurate (I'm hoping for something like NEAR), but better than the current one anyway. The side effect of this is that it will become much harder to predict the effects of aerobraking, because you'll have to consider the shape of the ship, and it will be different if it enters the atmosphere broadside on. Squad didn't want to write the code to do the prediction for the current model if they would have to rip it all out and start over when they improved the aerodynamics. Still, it's been a long time since I heard anything about improved aero. It may be that Squad have decided the current aero model, complimented by some excellent mods for those who want more, is enough. In which case it'd be nice to see a feature like this (with an easy API to turn it off for people using NEAR/FAR)

My guess? They want to build one of these http://en.wikipedia.org/wiki/VA-111_Shkval And somewhere between the scientists doing the work and the south china morning post publishing the story, someone decided to try and think of a nice, non-military use for the research. And this is what they came up with.

I have a feeling that we basically agree how this works, it's just I wasn't quite clear originally that my division when calculating the force was a vector division by scalar. We're both thinking of using the same operations, but I had considered the hard ones as part of the calculation of the force, and you considered them part of the vector addition. I edited my last post before seeing your latest, it might be a bit clearer now anyway. 3 divisions and a square root (which I had forgotten about) are the things that will take the most time. Still quicker than you will get with trig I think.

I was assuming that one would have the vector distance to the planet, use this to calculate the vector force, and then you just add the vector forces. In which case I think you only need three divisions per planet in total (though I haven't sketched it out completely, it might be four), all in calculating the vector force. If aiming for speed, you'd want to stay away from trig, as it's rather costly to evaluate. edit: I think I can get it with one square root, three divisions, ten multiplications and five additions per planet (to update V, another 3 multiplications and 3 additions or so for R) @JavaProphet I'm not sure I follow your post, I may have a closer look later. In reply to your note, the numbers I gave are the typical times it takes for the ALU to complete the requested operation. At the very least, there will be one extra cycle to read the instruction, fetch the operands and pass them to the ALU, and that assumes they are available in the processor. To avoid having any other overheads, and spend every cycle doing what you want, you have to program very carefully. Assembly would be best, compiled languages like C or FORTRAN may also let you get there. I would be amazed if you were anywhere near that efficient in Java (guessing from your name) or C# (which KSP uses). edit: here's a comparison of the time taken on some operations by different processors http://www.agner.org/optimize/instruction_tables.pdf

I think actually the vector addition is not too bad. It is after all just three addition operations. Depending on the processor design and my ability to dredge these things out of the back of my memory: - Addition costs about 1 cycle - Multiplication costs about 3 cycles - Division costs much more and can vary a lot, 10-30 cycles So it's probably going to be the division by distance squared which dominates the calculation. Still faster than hitting RAM though, I think.