eggrobin

1 Planck time. A better answer to this question depends on several things: What you call playable. If you want to be able to see where your burn leads you in real time in the map view (dynamic integration), you will have to wait for me to implement Saha & Tremaine, so that would be at the very least a month. If you only require application of thrust and if I were to set the refactoring aside (which I'm not likely to do, see next point), I could get that done before the end of the coming week. What I prioritise in my development process. I tend to like building up big structures for type-safety so I don't waste time tracking a missing xzy or mismatched units afterwards, but this takes time. I believe the "quick and dirty" niche is already successfully filled by HoneyFox's Orbit Manipulator Series, so that this approach makes sense. How much I get sidetracked by other things (I spent the second half of last week fixing and adding features to sarbian's SmokeScreen plugin and I implemented physical quantities in C++/CLI today). I think I'll use these physical quantities in Principia, I'll have to see whether I want to switch to C++/CLI altogether or somehow interface that with C#. I'm likely to switch to C++/CLI, since I intend to interface with native C++ eventually (I have established that mixed-mode is not possible, but having a codebase in C++/CLI and C++ seems saner than a mix of C#, C++/CLI and C++) and I needed C++/CLI in order to test the Geometry assembly anyway (you can look at the existing tests on the repository).

A wild guess: I actually have a practical reason for talking about these things, rather than saying "we are now going to talk about alternating multilinear maps on a finite-dimensional vector space over a field K with characteristic other than 2", which only really sounds exciting once you know why alternating maps are useful. It turns out a lot of this abstract nonsense and algebraic structures can be used in order to strongly type stuff. Physicists usually don't bother with that and say "it's a vector, but beware, it behaves weirdly under reflection". Good luck implementing that safely... Similar considerations apply to numerical integration: I found the numerical analysis course I took last year quite boring "let's make up another integrator by extrapolating an integrator we have; let's now look at ten different ways to do adaptive timestep; let's apply all of this to either a linear differential equation, the logistic equation or the two-body problem", but having an actual problem to solve is fun.

This last update was just about the technicalities of how I will implement strongly typed reference frames (in KSP, sometimes the universe rotates around you, sometime it moves with you, sometimes the y and z coordinates are flipped, i.e. you get mirrored positions; moreover I also render things in weird reference frames), so you want to be sure that when you combine things from different bits of KSP you do it in a consistent way (for instance, you don't want to apply a mirrored velocity in a non-mirrored reference frame otherwise you will go up instead of sideways). The right way to do that involves some interesting algebra, but this only is relevant to modders who have to deal with the reference frame weirdness of KSP. Well, the above post is just a lot of abstract nonsense, but yes, the point of the whole mod is to have realistic gravitation, so there will be Lagrange points, sun-synchronous orbits when I implement quadrupole moment, etc. You can actually look at the kind of trajectories you will be dealing with once this becomes playable in the imgur album in the OP (note that some pictures are in rotating reference frames).

Just install the new SmokeScreen and the regularly dotted smoke issue will disappear. If you want collision or buoyancy you will have to wait for Nazari as something has to be changed in his .mu file in order for that to look good. If you just want the smoke to be denser increase the emission in the cfg. Well, I really want to get back to Principia and I am completely incompetent as far as Unity stuff is concerned, but most of the issues you described (star-shaped exhaust, weird bouncing at an angle of À/4) should be fixed by the latest build. Make a good-looking .mu file with no damping (damping set to 1), no forces and no weird angle (I don't know what Nazari1382 did, but his smoke comes out of the SRBs at an angle; don't do that). In your cfg, use the following settings: grow 1.0 0.0 // No exponential growth. energy 1.0 5.0 // or something higher, you want the smoke to last a while. // Set the speed to something high enough, bearing in mind that it will drastically slow down on collision and due to drag. collide = true // collision. collideRatio = 0.0 // For smoke at least 0.0 is the only thing that will look good. // New parameters: physical = true // buoyancy, drag. stickiness = 0.85 // Smoke should be very sticky (at least 0.75, or as high as 0.95), otherwise a lot of // smoke will come out of the trench vertically. Stickiness slows smoke down on collision // with a perpendicular surface. logarithmicGrowth = 5.0 // This is what I used in the screenshots, you might want to use something significantly higher. // The formula for logarithmic growth is Log(logarithmicGrowth * t + 1) + 1), where t is // in seconds and 1 is the initial size in the result, so you can [url=http://www.wolframalpha.com/input/?i=Plot%5B%7BLog%5B5+*+t+%2B+1%5D+%2B+1%2C+Log%5B50+*+t+%2B+1%5D+%2B+1%2C+Log%5B0.5+*+t+%2B+1%5D+%2B+1%7D%2C+%7Bt%2C+0%2C+10%7D%5D]try that out[/url] in // Wolfram|Alpha to see how things will grow with time (the linked plot shows you the growth over // 10 seconds for logarithmicGrowth = 50, 5 and 0.5). This should really be a user-definable // density-dependent curve, but I'll let [b]sarbian[/b] do that. sizeClamp = 10000 // You don't need size clamping with logarithmic growth, set this to something high so it doesn't bother you. // I (or [b]sarbian[/b]) should make a 'noClamping' setting someday. initialDensity = 0.6 // Atmospheric density is about 1.2, set this to something lower for lighter, hotter stuff (e.g. smoke, flames) // and something higher for cold, heavy stuff (e.g. cryogenic venting; note that you should remember to use low velocities // and low energy (short lifetime) for cryogenic venting). // For reference, 0.6 is about the density of air at 300 °C, 1 atm. dragCoefficient = 0.1 // Fool with this until smoke slows down the way you want. This should get you started, then fool with the settings until you get something that looks good. EDIT: PSA: I found out where the pyramidal shape mentioned before on this thread was coming from. This is because using a Random Velocity in Unity will generate a random velocity offset as a product of uniform distributions, i.e. a uniform distribution on a square. Sarbian or myself will have to code something to enable better initial velocity distributions of particles (uniform on a disk should do the trick for most purposes).

You're welcome! Feel free to point out any errors in my explanatory post or ask for clarifications. After some pretty fruitful forays into the nebulous realm of particle effects, it's time for a Status update: The Geometry assembly seems to be mostly feature complete, so I'll start writing tests tomorrow (Saturday) after changing a few access modifiers, replacing the ugly switch statements in Permutation by something nicer, and a few optimisations. Here is an overview of its features; things are made rather more formal than is usual in physics (there are even a few categories, SSR Kermit will be happy) because the point is type-safety and convertibility between reference frames (some direct, some indirect). All types are generic with parameters deriving from ISpace. The parameters are tags indicating which reference frame the object belongs to or between which reference frames the transformation acts. Examples would be Local, World, MirroredWorld, Integrator, etc. I currently only support orthogonal transformations, so it cannot be scaled space. This might change in the future. From a mathematical standpoint, the tag A represents an affine space A on a three dimensional real inner product space V. The types are immutable except for R3Element. The assembly is CLS-compliant. Scalar.cs: Scalars (double precision floating point) are wrapped in the type Scalar so as not to risk accidental operations with stock weakly-typed quantities or single-precision floating point numbers. [*]Sign.cs: A sign. We don't care about 0 since this is used for determinants of orthogonal matrices, so 0 is not specially treated (I think it's seen as negative). [*]R3Element.cs: R3Element is basically my equivalent of KSP's Vector3d, a weakly typed three dimensional real vector, on which all sorts of operations (including dot and cross product) are allowed without any regard for their invariance under transformations. It is the underlying data type for all other vectors, which have a readonly R3Element Coordinates field containing their coordinates. [*]AffineSpace.cs: Point<A> is an element of the affine space A -- think of it as a position. You can't add them or scale them, but you can take the vector Vector<A>.ToFrom(p, q) from q to p, you can compute barycenters as Point<A>.Barycenter(q1, λ1, q2, λ2,), etc. [*]Grassmann.cs: Vector<A> is a vector in the vector space V acting on A. The operations of an inner product space are available. Bivector<A> is a bivector in V ∧ V. Physicists call that a pseudovector. Examples include angular velocity. The operations of an inner product space are available. Trivector<A> is a trivector in V ∧ V ∧ V. Physicists call that a pseudoscalar. Examples include the magnetic flux. I probably don't need this, so you can't do anything with it at the moment. The syntax for the inner products is Vector<A>.Inner(v, w), resp. Bivector<A>.Inner(v, w), etc. In addition to the inner product space operations, the wedge product of the Grassmann algebra, ∧: V × V → V∧V, ∧: V × V∧V → V∧V∧V, ∧: V∧V × V → V∧V∧V, is available. The syntax is v.Wedge(w). The wedge product of vectors is like cross product of vectors, except that by keeping the result in the Grassmann algebra things behave nicely through the looking-glass. Moreover, since in an inner product space, V∧V is canonically isomorphic to the Lie algebra so(3, V), bivectors can act as antisymmetric matrices on the left and on the right, B.ActOn(v), resp. v.ActedUponBy(. This corresponds to the cross product of a vector with a pseudovector. They can also be exponentiated, yielding an element of the Lie group SO(3) of rotations of V, which is the type Rotation<A, A>. This is how you get a rotation from an angular velocity times a duration. The syntax for that, for instance, would be Bivector<A>.Exp(É * t). Finally you can take their Lie bracket, the commutator of matrices, which corresponds to the cross product of pseudovectors. [*]OrthogonalMaps.cs: These are maps between vector spaces and their Grassmann algebras. The maps on the Grassmann algebras are uniquely defined by their action on the base spaces, so we'll look at them as maps between vector spaces. OrthogonalMap<A, B> is a map between A and B (or rather between the vector spaces acting on the affine spaces A and in the category of inner product spaces. Rotation<A, B> is a map in the category of oriented inner product spaces. Permutation<A, B> is a map in the category of inner product spaces equipped with an unordered basis (it's a coordinate permutation). Since these are not implemented as matrices and have distinct representations (the rotation is a quaternion, the orthogonal map is a rotoinversion (sign and quaternion), and the permutation actually permutes the coordinates), converting a Permutation P to an OrthogonalTransformation is a nontrivial operation. This is done by evaluating P.Forget(), the forgetful functor to the category of inner product spaces. [*]EuclideanMaps.cs: Similarly, this file contains the types for transformations between affine spaces on oriented inner product spaces (RigidTransformation) and between affine spaces on inner product spaces (EuclideanTransformation), with a forgetful functor from the first to the second. [*]Maps.cs This class contains the composition between maps. The syntax is Maps.Compose<A, B, C>(f, g) for the composition fâ—‹g of two maps of the same type (i.e. in the same category, forgetful functors are not implicit) f: B→C and g: A→B.

Well, the sprite is just for demonstration purposes (I couldn't use the HotRockets! model as it was angled and had damping), it's up to you (or nothke or Nazari or anyone else with Unity and artistic skills) to make something pretty out of these features. Note that the dotted smoke fix will apply to HotRockets! just fine (the emission is a bit low, so things will still be somewhat discontinuous, but the blobs will be randomly distributed, denser and fast-moving rather than regularly spaced and fixed with respect to the rocket). As HotRockets! uses damping and seems to apply some sort of rotation to its particles, another .mu file is needed if you want to use collide or physical, otherwise things will look weird.

PSA: I have submitted a pull request on the SmokeScreen repo containing a fix for this issue as well as a few new features.

I have just pushed a commit that fixes this issue to my pull request. The issue is fixed by distributing the newly emitted particles uniformly at random along the emitter's trajectory during the frame. Bear in mind that you still have to make the emission high enough, otherwise there just aren't enough particles to make a continuous plume. I would recommend against using this bug for shock diamonds, as their appearance would then depend on the performance of the machine displaying them. Other features introduced include better collision, buoyancy and logarithmic growth (which I would strongly recommend instead of exponential growth, as it looks more natural and removes the need for clamping). Avoid using damping with physical=true, it looks awkward. Set the dragCoefficient instead. The new options are as follows: // Initial density of the particle seen as sphere of radius size of perfect // gas. We then assume (only true for ideally expanded exhaust) that the // expansion is isobaric (by mixing with the atmosphere) in order to compute // the density afterwards. Units (SI): kg / m^3. [Persistent] public double initialDensity = .6; // Whether to apply Archimedes' force, gravity and other things to the particle. [Persistent] public bool physical = false; // How much the particles stick to objects they collide with. [Persistent] public double stickiness = 0.9; [Persistent] public double dragCoefficient = 0.1; // Logarithmic growth applied to to the particle. // The size at time t after emission will be approximately // (Log(logarithmicGrowth * t + 1) + 1) * initialSize, assuming growth = 0. // TODO(sarbian): make this a cfg-configurable curve (as a function of density). [Persistent] public double logarithmicGrowth = 0.0; Here are a few illustrative screenshots a before/after for dotted smoke, and two launch pictures. I didn't do anything fancy in Unity (just an emitter with one of the HotRockets! SRB textures) so the particles themselves are ugly.

Note that the costly thing here is collision: buoyancy etc. should not slow things down significantly. Trying to hack collision-like behaviour for the pad would be complicated, would probably lead to a lot of troublesome edge cases, and would only look good when launching (smoke would still disappear into the ground during powered landings, etc.). Sadly we can't easily run collision detection on another thread (that would require writing our own raycast). Perhaps we could run the raycast every x frames though (and apply buoyancy etc. every x frames, otherwise things will behave weirdly). We could even make x a setting.

I've managed to get some nicer results out of buoyant smoke (more on the pull request page). I think this could also be used (with high initialDensity) for cryogenic condensation.

I have submitted a pull request that alleviates this (by changing the behaviour on collision). It also includes other highly experimental stuff (buoyancy/weight, and some kind of handwavy drag for the particles), so caveat compilator. The highly experimental stuff can be turned off by setting physical = false. I have no experience with Unity, so the screenshot looks really ugly (as explained in the pull request, I needed to make my own .mu with no damping for the experimental features).

This will be the first thing on the list after the current refactoring. For the moment I need to write tests for the Geometry assembly, then wrap the things I need in Orbit, CelestialBody, Vessel, etc. so I have strongly-typed reference frames to work with. This will make it easier for me to understand what I'm writing, spending two hours tracking a missing rotation or xzy is no fun. EDIT: I don't think I have mentioned it, but I think the jitter I was experiencing was due to the planets not quite being where they should be (inaccuracies in the Orbit code). If this is indeed the case, I can ignore it while in space (all vessels will twitch together), and at lower altitudes I can leave Unity in charge of the physics. Some of the things I was observing also came from confusion between reference frames, hence the current refactoring.

I'm completely clueless as far as graphics are concerned so I don't know how relevant this is, but rbray89 seems to use shaders he writes in GLSL, which none of the aforementioned mods do (actually, most of his code is GLSL).

Note that Starwaster is maintaining a plugin based on Razcheck's work, whose source is available (Razchek's original post is now full of dead links).

I had the same sort of experience with reference frames (planets have a tendency to go crazy when you forget a .xzy), hence the ~500 lines of reference frame management (+tests, this needs tests). For the moment I'm mostly dealing with distances and velocities, all in SI units. When I get to fuel and thrust management I guess I'll want strongly-typed physical quantities; writing things in C++/CLI seems cleaner than doing runtime checks.

You're right of course. Edited my post so as not to confuse people. QFT, which stands neither for Quantum Fourier Transform nor for Quadratic Frobenius Test in this context.

Runtime checks are not very useful, especially given the time it takes to start KSP; a wrapper and testing will alleviate that, but I fundamentally like things to be sound at compile time. Compile-time checks for quantities are a pain to code in C# though, so I'll probably do quantity checking in the future refactoring that involves rewriting stuff in C++/CLI. For the moment, reference frames are the greatest source of confusion (it's full of xzy and rotations and rotations conjugated by xzy), so I'll be compile-time checking those. See Geometry.cs for the current incomplete implementation. Forgetful functors are missing, I just coded them but I didn't push them, and I still need to write the left actions of most transformations. EDIT: I didn't push permutations either. I'm not sure about that, I'm still trying to make the core features work properly. You mean the 'c' coefficients, right? This value is the time. ComputeRightHandSide computes any RHS, it just turns out the one we're dealing with here is autonomous. So it's not for future use, it's for generality. It was something I quickly hacked together for memory usage when running long-term simulations of Alternis Kerbol; I only store the state every samplingPeriod steps (and samplingPhase just tells me how long it's been since I sampled). At the moment I'm using that to plot the trajectories, but I really need to find a smarter way to sample.

An alternative would be to use a uniform distribution on a disk: pick Æuniformly at random in [0, 2À], r u.a.r. in [0, (λz)²], the position is (√r cos Æ, √r sin Æ, z)---assuming z is the exhaust direction and z=0 is the apex of the cone, where λ is the slope of the cone. This might look better than a Gaussian (and it is slightly less computationally intensive).

sarbian: Great plugin! One remark however: I'm not sure whether it's too late to change the identifiers (there shouldn't be too many compatibility problems right now), but I think 'persistant' should be replaced by 'persistent' (unless you intended to name the classes in French). I'll report it as a bug on GitHub. nothke: These screenshots look great!

I have mostly seen category theory in algebraic topology (which of course has applications, such as proving that you can cut a ham sandwich in half or that you cannot comb a hairy sphere ), so I wasn't aware of that. Well, if ad T and ad V commute, their exponentials commute (because you can apply the binomial theorem to the terms of the series), exp(Ä ad H) = exp(Ä ad T) exp(Ä ad V) so (8) in [Yoshida 1992] is exact. Another way to see that is that as the exponentials commute, (16) is just ( ÃŽÂ [sub]i[/sub] exp(c[sub]i[/sub]Ä ad T) ) ( ÃŽÂ [sub]i[/sub] exp(d[sub]i[/sub] Ä ad V) ) = exp(Σ[sub]i[/sub] c[sub]i[/sub] Ä ad T) exp(Σ[sub]i[/sub] d[sub]i[/sub] Ä ad V) The integrator has first order if and only if Σici = 1 and Σidi = 1 (this is because they are actually the nodes of the underlying Runge-Kutta integrators, see my introduction), so any integrator that has 1st order has the highest order possible. As [Yoshida 1990] proves that you can have arbitrarily high orders, the 1st order integrator has arbitrarily high order, i.e., it is exact. Note that this never actually happens; writing H = H0 + H1 in the general case as pointed out by Wisdom, ad H0 and ad H1 commute if and only if {H0, H1} = 0. This implies H[sub]0[/sub]' = {H[sub]0[/sub], H} = {H[sub]0[/sub], H[sub]0[/sub] + H[sub]1[/sub]} = {H[sub]0[/sub], H[sub]0[/sub]} + {H[sub]0[/sub], H[sub]1[/sub]} = {H[sub]0[/sub], H[sub]1[/sub]} = 0 and similarly for H1, so H0 and H1 are first integrals; in other words we are pretty much dealing with two separate Hamiltonian systems. In the usual case T(p) + V(q), we get that the forces are identically 0.

I didn't know this was a possibility. I'm confused. ad x is indeed a derivation (it's actually by definition an inner derivation), but where do you see a module that's not a vector space? If T and V commuted life would be simpler; in particular the first order integrator would be exact. Also, I edited my post slightly since you replied in order to explain the actual of role Baker-Campbell-Hausdorff here and in order to link to Yoshida. Wisdom makes some really good points in the discussion in [Yoshida 1992]. EDIT answering the edit above : Equations 24-26 only say that for the integrators constructed by Yoshida for his proof, which, as pointed out by Wisdom, are suboptimal (see [Atela & McLachlan 1992] for optimal integrators; see also the Mathematica documentation on SPRK methods for sources for their coefficients---up to order 10. I have not been able to find the Sofroniou & Spaletta paper outside a paywall). Equation 17 on the other hand pretty much defines SPRKs, so you won't be able to parallelise too much. GPGPU might still be beneficial from a vectorisation standpoint (I'm not familiar with it though; just writing native code will already give you a nice speedup due to SSE).

If the date of birth in your profile is accurate, I would be rather surprised if you understood the above post. I would however wholeheartedly recommend reading the bits of Feynman linked in the OP, I first learned calculus there when I was about your age. His style is very pleasant and his explanations are quite intuitive.

We'll have asteroids to deal with in 0.24, so that's not completely out of scope. "leapfrog in higher orders" is pretty much what SPRKs are about, though a stricter generalisation of leapfrog is an FSAL SPRK. They give some really nice explanations for the idea behind the SPRKs in this book though, rather than expressing them all as a bunch of coefficients. I think I'll add it to the recommended reading section, it looks pretty accessible. You'll have a hard time doing that, since papers about symplectic integrators assume you know what this is all about and general treatments of the Baker-Campbell-Hausdorff formula fail to mention the relation to Hamiltonian mechanics. Here's a rough outline, you should be able to fill in the blanks from Wikipedia. -- Notations: M is the phase space, in this case â„Â3N×(â„Â3N)*; { . , . } : C∞(M)2 → C∞(M) is the Poisson bracket; {f, . } := g ↦ {f, g}, i.e., {f, . } g = {f, g}, so that {f, . } is a linear endomorphism of the space C∞(M) of smooth functions of the phase space. We want the solution z to z' = -{H, z} (Hamilton's equations, where z = (q, p) are the generalised coordinates). It is of course given by the exponential of the linear operator applied to the initial conditions, z = exp(-t {H, . }) z0, so that z(Ä) = exp(-{Ä H, . }) z0, where Ä is the timestep. We take smooth functions f(q, p) and g(q, p) in C∞(M) (H, z = id, L, p, the Lagrangian â„’, T, V, are examples of such functions) and look at the commutator of the linear operators {f, . } and {g, . }: [{f, . }, {g, . }] = {f, . } {g, . } - {g, . } {f, . } = {f, {g, . }} - {g, {f, . }} = {f, {g, . }} + {g, { . , f}} -- As the Poisson bracket is antisymmetric, = - { . , {f, g}} -- As the Poisson bracket satisfies the Jacobi identity, = {{f, g}, . } -- Antisymmetry. It follows that the commutator on the operators of the form {f, . } works essentially like the Poisson bracket, so it will satisfy the Jacobi identity too. It is bilinear and alternating, and the {f, . }s form a vector space, so it is a Lie algebra. Note that we actually started with the Lie algebra (C∞(M), { . , . }), whose the Lie bracket was the Poisson bracket (a Poisson algebra, mathematicians have creative naming conventions), what we just did was taking the adjoint representation (see the relevant Wikipedia article), thus getting a subalgebra of End(C∞(M)). The usual notation for the adjoint representation is ad f := {f, . }; I'll use this notation from now on, the brackets are getting rather cumbersome. Back to the problem at hand, finding exp(Ä ad H). We have H = T + V (or some other partition of the Hamiltonian). We want to know how to write exp(Ä ad(T + V)) = exp(Ä ad T + Ä ad V) as a function of exp(Ä ad T) and exp(Ä ad V), the separate evolutions. ad T and ad V don't commute, so it's not just the product. The Baker-Campbell-Hausdorff formula tells you just that: it says log(exp(Ä ad T) exp(Ä ad V)) = Ä ad T + Ä ad V + 1/2 [Ä ad T, Ä ad V] + 1/12 [Ä ad T, [Ä ad T, Ä ad V]] - 1/12 [Ä ad V, [Ä ad T, Ä ad V]] + ... I think this should enable you to read Yoshida's works. I would recommend starting with Yoshida's Symplectic Integrators for Hamiltonian Systems: Basic Theory [Yoshida 1992] in order to see the general definitions and ideas, his 1990 paper Construction of higher order symplectic integrators focuses only on proving that such integrators exist, with no concern for efficiency, and only talks about even-order integrators. See the discussion with Wisdom at the end of [Yoshida 1992]. The main idea is the same as for Runge-Kutta (see my introduction linked in the OP) except instead of trying to match terms in the Taylor expansion of the solution, you try to match terms in the Baker-Campbell-Hausdorff formula: the convergence rate is for the Hamiltonian here. Of course you do that by composing symplectic maps so that you don't have an energy drift. We'll always have Mordac. Which f's? Unrelated: while investigating formalisations of physical quantities and reference frames, I found this fascinating post by Terence Tao. It turns out that deep down formalising them works similarly. The post is pretty enlightening: it give a clue as to how to formalise the fact an average of temperatures makes sense, a difference of temperatures makes sense, a sum of temperature differences makes sense, but a sum of temperatures doesn't (or similarly, why a barycenter makes sense while a sum of positions doesn't).

For KSP, where you have about 20 massive bodies, FMM is probably not worth it. Realtime is completely trivial, it's the 100_000_000x that you need for dynamic trajectory predictions that might be an issue. I don't intend to do GPGPU. I'm not familiar with Hermite integrators; what is the idea behind those? Note that you can write plugins for KSP entirely in F# if you want (or in C++/CLI; you need wrappers in one of the other three languages for VB.NET because of case insensitivity). It seems people aren't quite aware of that, I'll probably write a PSA about it at some point. While testing that I discovered that asmi was right when conjecturing that Unity doesn't support mixed-mode DLLs, so if I want to use native code (which would be really nice since you lose vectorisation when using CLR) I'll have to use DllImports and mess with marshalling by hand. On the upside with this approach you know where the thunks are. Welcome to the nineties! Admittedly some languages lagged behind, like Ada which only had Unicode identifiers in Ada 2005, but it compensates by having the following in Ada.Numerics: À : constant := Pi; EDIT Also, it's been a while since I've done a Status update: I have started doing some refactoring since the sphaghettiness of the code was getting on my nerves. I have written strongly typed wrappers for the numerous reference frames spawned by KSP (direct vs. indirect, rotating vs. inertial, world vs. body-centric, etc.) as I have had numerous bugs due to a misplaced xzy, rotation, translation, scaling, inertial force etc. Of course, since KSP has the brilliant idea of using both direct and indirect reference frames, I needed distinct types for vectors, bivectors and trivectors (basically I had to strongly type Grassmann algebras; there can be no cross product, only wedge products, commutators and left and right actions of alternating forms---where is identified with through the inner product, and is identified with ). I do not think I will implement strong typing for physical quantities yet (though I'd like to), since C# generics are not powerful enough for that; I would need C++ templates. I'll do that when I rewrite things in C++/CLI. The next step is to implement my own versor, since Unity's Quaternion is in single-precision float and KSP's QuaternionD is broken. The rest should be more straightforward refactoring.

If you want to work with the names of the attach nodes, fewer exemptions is better, ceterum censeo this is a better a better approach; expecting future modders to properly pick correctly between "connect" and "attach" seems like a bad idea (neither of those explicitly refers to blunt body drag) and the same question of renaming and breaking saves vs. adding an exemption would arise every time someone gets it wrong. A KSPField that explicitly says what it does seems both more elegant and safer. This is technically true, but should be negligible. I do not think it is enough to warrant going with the more obscure "connect" vs. "attach" approach.