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.

Well, first, everything is relative. So Lets have a think about patched conics, what are they like to calculate? Very easy. Patched conics are analytically solvable for the position with time. That means that given the starting position and velocity of the spacecraft at time 0, I can write the position and velocity at some future time t using a formula. For now I will use R to represent the canonical co-ordinates of the problem, it is a vector like (x,y,z,vx,vy,vz), so I can write: R = F(Rt=0,t) Where F can be found in advance and put into the code. This is great, because you can run the simulation at any speed with pretty good accuracy. If you want each time step to be 0.1 seconds (as I believe is the case at timewarp 1) then you take the R from the last iteration, use t=0.1 an do the calculation. It costs some number of operations, lets say N flops. If on the other hand the timewarp is set to 100,000, you do the same calculation but with t=10,000. It still costs N flops, and in both cases the solution is exact to up to machine precision. Strictly speaking this assumes no SOI changes. Change SOI and you need to change F to the one governing the new SOI. If you just change F for the first step after entering the new SOI, then there is no additional computational cost. I think that is what KSP does, and why it is sometimes inadvisable to cross SOI boundaries at speed. More accurate options, with a higher computational cost, are possible. Now, there is no such solution for an n-body equation. This is not a computational problem, it is a mathematical one. The mathematicians simply have not found a way of obtaining F for more than two bodies, and a few special cases with 3 bodies. So now you have to do the calculation in numerical steps. So the question is how many steps per in-simulation second are needed to be accurate? If you don't do enough, then small fast orbits get turned into short joined up straight lines, which don't really represent the orbit perfectly. Since each step epends on the one before, these errors add up to a real mess. My gut feeling is that 10 steps per in-game second will be required, and each one will require some number of operations N, probably not so different from the N above. So no change in computational load at 1x warp. But now, when you timewarp, you can't just change t. Every step depends on the output of the step before, and all must be done. So you have to do 100,000 times as many calcuations. This is where it starts to get messy. For some rough figures pulled out of thin air: Lets assume that there are 50 ships to track, each of which needs calculations for the nearest 3 bodies. All at max timewarp. That requires 50x3x100000=15M calculations per second, instead of 50 needed under patched conics. Is this impossible? well, maybe. It depends on the calculation being performed. My gut feeling is that it will be beyond most processors. If it is possible it will probably only really work well with some very well optimized code, making careful use of the processor's features. The lookup table you describe for example is probably not good, as it will be bigger than the processor's cache, and have to live in RAM. Fetching data from RAM takes time, direct calculations will probably be faster in this case. I think Orbiter does try to do n-body calculations in this way, but I think it has problems at high warp (I've never played it) Also, I don't think it would add to the game, as n-body systems don't usually have stable orbits. But this is a question in the science labs about computational complexity, so I won't go into that.

Something broadly similar has been suggested before: http://forum.kerbalspaceprogram.com/threads/43740-The-war-against-lag-Anti-lag-fairings and I like the idea. That thread went downhill rather fast though.

Your understanding of superconductors is close, but not quite right. In some superconductors (called type II) magnetic flux can be locked in by cooling through the transition temperature. This doesn't mean however that they will stay the same distance from a magnetic source. It means that it will try to move (and rotate) towards a position where the magnetic field is the same as when it was cooled. When you cool it close to a magnet, or even better an array of magnets, the trapped flux has quite a complicated shape. So the superconductor will only really find a similar pattern in the same place as it was when it was cooled. The earth's magnetic field however is quite uniform, so there would be little or no force pushing it back to where it was cooled down. There would be a small force trying to rotate the superconductor to the same orientation though, so you could use it instead of reaction wheels. A big enough slab of superconductor would be rather heavy, so it's easier to use little electromagnets instead, these are known as magnetorquers. There is a decent looking wikipedia article on magnetotorques, which might be interesting to you. There is also a wikipedia article on flux pinning, but it is very wrong. So don't read it.

Looks like someone's done this as a mod: http://forum.kerbalspaceprogram.com/threads/86691-0-24-DebRefund-v1-0-9

It already is isn't it? Objects more than 2.5km (I think) away are treated as a single point mass following an orbit calculated using patched conics. This is colloquially referred to as being "on rails". In normal timewarp, the same applies to the active craft (and anything else inside the 2.5km limit) - it is put on rails. Physics timewarp keeps doing physics calculations, and is limited to 4x by lag and accuracy issues. As currently implemented, rotation is lost. It might be better if it was kept, and I think it's on the todo list. It's certainly been suggested a fair few times.

Look like this is an accidental partial copy of http://forum.kerbalspaceprogram.com/threads/76865-Make-A-Base-at-the-Meteor-Crater%21

For a senior project, you might as well settle for "negative pressures are impossible". You are also correct with your above point that if any vapor is formed, it cannot have a negative pressure, so any hypothetical negative pressure in the liquid will be relieved by vapor formation. That said, I don't think negative pressure is outright impossible. In a solid, negative uniaxial pressure is easy to achieve: just stretch your sample with a piezo. The amount of negative pressure you can achieve is very small, because the sample will break. Negative hydrostatic/multiaxial pressure is more difficult, but by no means impossible, just use more piezos. In a liquid, in theory the same thing is possible. But void formation would kick in even sooner, because liquids are usually held together by weaker forces. To allow negative pressure you would need the energy of 'stretching' the liquid to be less than the energy of the void formation (whether that is a vacuum void or a void containing vapor). The former depends on the compressability and is going to be a large. The only energy cost I can think of for the void is surface tension, which is normally a much weaker thing. Worse, the compressability energy scales as the whole volume of the liquid (l^3), whilst the surface tension scales as the surface area of the void necessary to relieve the stretching (l^2). I don't know of any theoretical upper limits on the energies of surface tension, nor any lower limits on the compressability of a liquid, and I would be surprised if no such liquid was possible. Edit: further thought. I rather doubt that any macroscopic-sized equilibrium system can show negative pressure in a liquid, as it will always be unstable to formation of a single large void. I do think that a non-equilibrium state might be metastable, with no void formation unless nucleated. Because of the scaling laws above, it should be possible to achieve a system where small voids are unstable, and decay, but voids over a critical size grow rapidly and release the negative pressure. If the critical size can be made large enough, voids will not occur unless nucleated by an external peturbation (such as a high energy particle strike). The above mentioned paper by Hahn indicates that this is certainly possible in a quasi-1D system, where the scaling laws will be different: l^1 and l^0 probably. I bet a literature search would show up 3D theoretical work at least. But it's too late at night in my timezone to start looking.

2034T to stable orbit. 168 parts, so should run on most people's machines. SSTO (do I get extra points for that?). IMO ARM parts are a bit overpowered...

A phased-array antenna running round the 'equator' of your rotating vessel would be able to act like a dish pointed in any direction. Phased array systems already exist, the technology is fairly mature and they are replacing steerable dishes in some cases because they can be more reliable. Some examples off the top of my head: RAF Fylindales radar, SatCom systems on aircraft. As for propulsion, putting the main engines to thrust along the direction of rotation is probably wise. When you attempt to change the heading of the craft prior to doing a burn, the gyroscopic effect might cause a bit of a headache, but nothing you can't work around with simple mechanics. You will need to apply torque (using reaction wheels or thrusters) at a different angle from what you would with a non rotating ship. Check out "Torque induced gyroscopic precession" for the details and the maths.

Also, localisation is usually done near the end of the development cycle. Usually the translators are not the devs, so as the devs make changes they can only update the English text, and maybe one or two others. Then the translators have to come back and do some more translating. With paid translators, it becomes expensive to keep making changes, with volunteer translators stuff gets out of date and misleading. Much better to wait for the project to be complete, then make the translations. This of course is for a conventional dev cycle. The elephant in the room is the possibility that KSP is going to continue to see minor releases for a loooooong time, and thus waiting for near 1.0 release to do translation becomes a bit of a pain.