SSR Kermit

Dodging phantom transients ended in accidents.

I'd say that if you can get a rocket into space in the game, it is for you Halfway to anywhere!

You're quite right about multipole not being worth it for stock KSP; not only are we dealing with low N but the system is very flat and the rotational aspect completely dominates phase space. On that note, 2D/4D clustering using volumetric 3D space partitioning (octrees) is just silly. If we define a system of say 5 gas giants in the 0.5 < M_Jup < 6 range and put more than an Earth-mass of moons in orbit around each, plus trojans and spartans at the L-points and add a considerable sphere of scattered objects, well then FMM might be good (one can dream, right) Most sane people would not intend to do that. However, in my case, I think I have strong reasons to; but that's what all crazies say. If I can realise the very simple Yoshida scheme, a 6th order integrator using seven force computations, and parallelize it to the (time) performance of a 3 force computation scheme, it will definitely be worth it. yo6 is essentially the leapfrog called in a pre-3,1,3-corr pattern, which hints at a parallel model . This is what I'm currently working on, but I'm worried about portability despite (or perhaps due to) the grandiose claims by Apple, AMD and nVidia regarding OpenCL. A good explanation is here: in volume 2, chapter 11 of a lengthy tutorial on the n-body problem that Hut and Makino wrote. The book was never finished, which is a shame because it's awesome as an introduction for people from other disciplines. In short, it's a generalization of the leapfrog with nice properties (such as 4th order behaviour). I'm not sure on this one, but I believe there is a way to describe all these "leapfrog in higher orders" algorithms in terms of partitioned RK schemes, although they quite elegantly escape dependencies on the vectorized representation. Again, that might hint at interesting things -- perhaps a general concurrency scheme for a class of partitioned RK algorithms, which would be pretty awesome. It's interesting to note how symplectic schemes could arise from a separate branch of reasoning that doesn't use a Hamiltonian; Aarseth has more on the history in his seminal 2003 work. I've seen Yoshida referenced everywhere in the litterature, so I guess I better read up on Lie algebras and Baker–Campbell–Hausdorff in order to understand his work .... I think you'd be surprised at how many companies enforce strict C89 lexical standards in 2014, even if you're coding something like C# in a fully utf-8 environment. I've even seen source control systems that reject check-ins if you don't use strictly alphanumeric US ASCII extended by only precisely a set of characters from the host language (operators etc). And this in Europe! Inconceivable! EDIT: To elaborate a bit for the forum and give some praise to Hut and Makino; I really do recommend anyone seriously interested in implementing n-body systems to read (and code along) with the narrative. I'm a computer scientist and amateur astronomer and as such I found everything they had to say about software and development to be rather retro, even for 2007, but skipping those parts gave me a surprisingly detailed understanding of both the physics and math involved in stellar dynamics. I had a layman conceptual understanding and I'd seen animations of such simulations, but after a week of reading/math/coding I was able to move on to Aarseth's rather compact style and managed to read some more recent papers on the subject, where I have to take the theoretical physics on good faith but can check the numerical bits with general mathematical tools (such as Taylor series and recurrence relations). If you do read the tutorial, do note that I'm one of those who really think there should be hats on those f's! Otherwise you are proving structural equality between E an v! Check it out (like eggrobin said: welcome to the nineties!): http://www.artcompsci.org/kali/

Hey! I'm working on something similar, but more from a computational point of view than providing new gameplay. I'm using a Hermite integrator (pumped by a 6th order Yoshida), and I'm using octrees and their duals to cluster distant sources (ie, FMM)-- getting that to run in realtime on a beefy graphics card should be possible albeit not trivial... I'm working with OpenCL and F#, but I'd be very interested in any kind of visualization features in-game if/when you are ready to share the source. If you haven't read it, this book is awesome; Gravitational N-Body Simulations, Sverre J Aarseth, Cambridge University Press (2003) Aarseth is something of a legend among stellar dynamicists and has devoted a long career to the N-body problem. EDIT; Found the source on github, good stuff! I applaud your "daring" use of unicode!

I've been using it for a couple of days, no issues beyond those present in .22; in rare cases (haven't been able to nail it down, might be a mod-part etc) the rebuilt vessel becomes grabbed but unplaceable since there isn't a root in the build space. Adding a second leads to very bad things.

Ah, the good ol (uhm, brand new) ModuleEnginesFX has thrown my custom hybrid-VTOLs for a spin (literally, the flat kind) already Looking at it again, I'd say there are two issues, one with the heat production but the other is a UI problem. Perhaps (probably?) a knock-on effect of the first. Cutting the heat production does restore the timing afaict, btw, and should be good enough; certainly for my purposes -- but the gauge is still decreasing and gives the impression of something glitching which might upset more sensitive users.... Thanks for the workaround!

Is there some issue with the new RAPIER engine? It's exploding due to "excessive g-forces" no matter how I try to use it. Does DR affect overheating in engines somehow? In trying to replicate the behaviour, I noticed that a very simple design-- a pod, the largest 1.25 m tank and the engine on the bottom-- would explode with this reason when the overheating would otherwise destroy it. Meanwhile, the overheating bar decreases with DR installed. So, I tried at reduced thrust, a TWR around 1.2, but with the exact same result. I'll try overheating an aerospike to see if it behaves the same way. EDIT: aerospikes heat up linearly and explode "due to overheating" as expected, although there's some unexpected fluctuations close to max overheating EDIT 2: Pictures and quicker way to replicate http://imgur.com/a/SwpYi#0

I just wanted to leave a big thank you to Ferram for creating and maintaining this mod -- it's become a must have for me; upon launching .23 stock I realized I couldn't go back! Credit to bac9 for creating parts that allow me to realize cool and pseudo-realistic aerodynamic designs (VTOL SSTO spaceplanes with anhedral wings that are stable from 0-5 mach!) It kind of boggles my mind how cool this modding community is and the amazing content its modders are adding. Thank you Ferram!

I'm realizing how important this mod is to me; now that FAR and DR are at .23 I'm getting ready to upgrade. For me, a missing FAR is a showstopper while DR is nice to have. However, I hadn't fully realized that B9 was the enabler for almost anything I do in KSP! I'm currently trying to decide whether to hold off updating, take a break from KSP (my sleep cycle would probably benefit) or try to weather any potential glitches by installing 4.0c to a .23 installation.... A BIG thanks to bac9 and Ferram without which I would likely have given the game up long ago....

I'm having a non-critical issue with this plugin and FAR on a spaceplane that was already strutted; I had a pair connecting every segment. With this plugin, the FAR flight assistance freaks out in the pitch axis, causing serious oscillations. EDIT: No I'm not, rather the plugin revealed a pair of unconnected struts by having them be the breaking point. The design I use is stable at high mach numbers but calls for some trimming or flight assist at lower speeds, but with the plugin it remains stable _unless_ I use the flight assistance even at lower speeds (SAS works like it usually does with FAR, btw, ie not-so-good at high lift). A bit odd that the FAR flight assistant did a worse job than either the stock SAS or even no assist-- never seen that before. Since its also a VTOL, I kinda need the flight assists to land, but fortunately the fix was simple: remove struts between attached segments. Or use the stock SAS, but that would retain the weirdly stable aerodynamics below mach 1. Here's what it looks like for reference:

Doesn't need to be a black hole-- this is true for any massive body. The distance at which a second body will lose structural integrity due to tidal forces is known as the Roche Limit -- wikipedia has a sufficient article on it. Rings are usually the result of that kind of event. As I understand it a semi ring generally requires additional interactions such as clumping or jets.

as a side note, despite this seemingly large constant the time a real space craft reaches Kerbin orbital speeds is about 1 minute 50 seconds. The recent spacex falcon launch took just under 8 minutes to LEO. On topic, if the constant of gravitation was an order of magnitude larger, even something like a building complex or worse yet-- a mountain-- would seriously screw with the local gravity field.... Perhaps not life-threatening, but definitely noticeable. I prefer to think it's some exotic interaction that provides extra 'virtual' mass and a bunch of kermions and anti-kermions

Hi! I've been playing for some time (since there was only the Mun and multi-layered booster towers were a serious thing) but only just joined the forums. I had some trouble joining because my username was invalid in some unspecified way. I think I figured that it was the word 'Kerman' that was disallowed, although there seem to be users with such names. I wanted some variation of Kermit Kerman. Hardly a major issue, but a suggestion is to list the restrictions somewhere on the registration form -- it gets a bit annoying typing captchas and passwords.... KSP is one of the highlights of my soon 30 years of gaming. These forums and the community of modders keep raising the bar, which is super awesome! See you in orbit, kerbs! Best Regards, Kermit Kerman Skerdinavian Space Research