MrHappyFace

Hi

Not a feature, I tried fixing it several time, but it's still broken.

Oh, no, I'm not dead yet. And while its not prohibited by the license, releasing another version under a new name just causes more confusion, considering I'm still here. I'm still in the process of updating. 1.1.3 only released a few weeks ago, and I have 2 other mods I've been working on on top of personal stuff.

Done! That was way easier than expected. Download: https://www.github.com/HappyFaceIndustries/KerbalAnimationSuite/releases/latest Changelog: Updated to KSP 1.1.3 Remade animation player window, allowing custom binding of animations to number keys Reduced download size by 11kb by deleting those pesky thumbs.db files Added other things to increase the size of the changelog Here's a screenshot of the new animation player window:

Oh crap, has it? At least the rest of the game is more stable.

Now that 1.1.3 is out, I feel comfortable updating. Update will include a better animation manager. BTW, almost all of the kerbal's animation system uses legacy animations, so it makes no sense to use non-legacy.

If I did that, then I'd have to seperate all the other PQSMods I have planned as well, and if I separated everything out based on their purpose, I'd have several plugins instead of just one, which would be hugely inconvenient for me. Also, the way KopernicusExpansion is structured, it has very little overhead unless one of it's features is in use. plus the mod is currently just a 2mb dll and a ~1mb config file, so overall it's a very small mod overall. I might want to do so in the future for some of the larger features, but not now.

I have no idea what could be causing the bouncing. Maybe it's got something to do with some parts still falling while others have already settled on the surface. Does this happen with 1-part (non-EVA) vessels?

Why not do this: public float impulseSpeed = 0.01; //... var gravityVector = FlightGlobals.getGeeForceAtPosition (vessel.GetWorldPos3D ()); var impulseVector = gravityVector.normalized * (gravityVector.magnitude * -(1 + impulseSpeed)); vessel.parts.ForEach( part -> { if (part.GroundContact) { part.rigidBody.AddForce(impulseVector, ForceMode.VelocityChange); } }); The function getGeeForceAtPosition is the standard way to calculate gravity, used by stock code and all the mods I've seen, and it's probably more optimized than yours is. Math.Pow function calls are relatively expensive too. Also, I'm pretty sure the EVA thing was because EVA kerbals don't take kindly to odd forces. I've had a kerbal fly into to the air at 100m/s for hitting the ground in ragdoll mode. Yup, you're right. I was in the mindset of KSP where everything is listed as kilonewtons and tonnes. I meant m/s as in that's how much the velocity was increased in that frame. It doesn't make much sense to use m/s2 when we're dealing with instantaneous impulses. Impulses last one frame, and frames are of variable length, although meters per frame squared might work.

Impulse is not v * m. (Note that acceleration is change in velocity and velocity is change in position.) In unity, you pass a vector into the AddForce function, which is used as a force when it's in Force or Impulse mode, and an acceleration when it's in Acceleration or VelocityChange mode. That means that the resulting change in velocity (acceleration), in Force and Impulse mode can be calculated easily by solving for A in the equation F = MA. F = MA (input of AddForce function) = (mass of rigidbody) * A (input of AddForce function) / (mass of rigidbody) = A Now, assuming you input a force of 1kN with a mass of 10kg, you get this acceleration: F = MA 1kN = 10kg * A 1kN / 10kg = A A = 1/10m/s or 0.1m/s If you add a 10kN force to a mass of 1kg, you get this: F = MA 10kN = 1kg * A 10kN / 1kg = A A = 10m/s From this, we can see that (in force or impuse mode) it requires a greater force to accelerate more massive objects by the same amount, so we increase the force by multiplying it by the mass, NOT dividing it by the mass like (I think) you were doing. Of course you can bypass masses and forces entirely by just using Acceleration or VelocityChange modes, and just pass the desired acceleration in directly. EDIT: I reread your first post, and now I'm not entirely sure I know what the problem is. I though it was that the AddForce was behaving differently in different conditions, but that doesn't seem logical. Are you applying the force upwards as in (0, 1, 0), or upwards as in negative gravity. The gravity in KSP isn't always down, or even consistent for different positions, so you need to use the function getGeeForceAtPosition I explained in my first post. Also, are you using AddForce or AddRelativeForce, because if you're using AddRelativeForce, then the force would be applied in different directions based on the orientation of the rigidbody. Some source code would be immensely helpful.

You multiply by mass. Newtons 2nd law states F = MA You want to increase your upwards velocity by 0.01 + g m/s, which is an acceleration of 0.01 + g. To get the correct Force, you multiply Mass by Acceleration. F = MA. Alternatively you could use the VelocityChange ForceMode, and just use 0.01 + g as the magnitude, without mucking about with masses. Side note: The difference between the ForceModes are as follows: Force - A regular force. Applying a force of 1kN for 1 second on a 1kg object speeds it up to 1m/s. Acceleration - An acceleration. Applying an acceleration of 1kN for 1 second speeds the object up to 1m/s regardless of mass. Impulse - An impulse force. Applying an impulse of 1kN for 1 frame on a 1kg object speeds it up to 1m/s. VelocityChange - A change in velocity. Applying a velocity change of 1kN for 1 frame speeds the object up to 1m/s regardless of mass. Side note 2: You can get the vector for gravity (gravity is not always down because of round planets) by using the following code: var gravityVector = FlightGlobals.getGeeForceAtPosition (vessel.GetWorldPos3D ()); The vessel.GetWorldPos3D() function gets the worldspace position of the vessel. For your purposes, you'd do this to apply an upwards impulse of 0.01m/s: var impulseVector = gravityVector.normalized * (gravityVector.magnitude * -(1 + impulseSpeed)); //impulseSpeed is 0.01m/s in this case You'd take the impulseVector and use it in the rigidbody.AddForce function.

I got around to uploading the camera code I was talking about earlier. https://gist.github.com/HappyFaceIndustries/d997e268d38bd638881e4033606216f9 The rendering takes place in the RenderCameras method, you can change the Render function to RenderToCubemap to get Cubemaps instead of RenderTextures. The skybox exposure stuff is just to dim the skybox because this was a telescope mod, and the skybox is really bright if you zoom in too far, but I can't imagine reflections would zoom in, so it's not really needed. The UpdateVisibleObjects function is also not needed because it just makes far-away planets visible to the camera. I haven't tested this in 1.1.x yet, but I don't see any reason it wouldn't work with little to no modification. You may need to reference Assembly-CSharp-firstpass.dll for it to work.

What exactly confuses you? Installing them? Using them?

It would be easy enough to supress ragdolls, or replace the behaviour that triggers ragdolls. It would require modifying the kerbal's FSM, see the source code for my mod Kerbal Animation Suite for some information on how to do that (hint: look in the EditableAnimationClip.cs file), but yeah you'd need a custom plugin to do it.

Mods that reparent kerbin (set it's parent body to something other than the sun) are inherently glitchy because of the way KSP's planets work internally. It seems this bug doesn't adversely affect gameplay and it's just a visual glitch, so I wouldn't worry about it.

Well given the complexity of KSP's flight scene, I'm not sure there's any other way to get it to look good without using a custom reflection cubemap or reflection probe. You can set a custom reflection map by setting RenderSettings.customReflection to a cubemap composited from the method I posted above so that the standard shader can react to something other than the default skybox or the inaccurate results of reflection probes. Edit: Alternatively, use a custom shader and have your own cubemap property in the shader so you can assign the reflection cubemap per part instead of globally to the whole scene.

As far as I know, there are actually 4 cameras, all of which are composited onto the screen to get the final output: Local scenery camera which can see the terrain and ships. The KSC and easter eggs are on the same layer as the terrain, so they are also seen by this camera. Another local scenery camera. Not sure what the difference between the two local cameras is, but they're both essential. Both local cameras usually orbit the ship's center of mass, and move around the scene. Scaledspace camera, which can see atmospheres, far-away bodies and the sun. This camera is not tied to the local camera at all, but instead moves around in scaled space. Galaxy camera, which can see the skybox. This camera is stationary and is surrounded by a hollow cube with the skybox painted on. Most mods I've seen that add their own cameras (BDArmory, Cacteye, Tarsier) just make carbon-copies of these cameras and slap them together into a working camera setup. I'm not exactly sure on how the reflection probe works, but it seems to just be a single camera rendering a cubemap and passing that cubemap to all renderers within it's bounds. Perhaps you could replicate this effect by rendering 4 cubemaps from your own camera setup, compositing that into one cubemap, then passing it manually to every part's material within the bounds of the fake probe. I have some code sitting around from an old project where I tried to make a telescope mod, it creates the cameras from scratch and composites them into the single RenderTexture, but it also does some trickery to allow it to support lens flares, atmospheres viewed from custom angles (atmospheres look glitchy otherwise), and some other things I can't remember that otherwise wouldn't be possible with a custom camera. I'll see if I can upload some of that later tonight.

@nli2work, the terrain is on layer 15, the atmosphere is on layer 9, the scaled planets (bodies viewed from afar, such as the mun in the sky) are on layer 10, and the skybox is on layer 18, and is a hollow sphere at the origin with a camera in the center for rendering the skybox. There's also layers 19, 23, and 30 which are for disconnected parts, the sun, and SurfaceFX (liftoff/landing particles, etc.) respectively. I'm not sure if reflection probes would world with the skybox, but they'd probably work with the atmosphere/scaled/sun layers, and they'd definitely work with the terrain/surfaceFX/disconnected-parts layers. Edit: I'm getting my information from this post: I haven't updated it for 1.1 yet, but there isn't any reason I can think of that any of the layers I've listed would have changed. I also see that you apparently already have the skybox working, which confuses me, but I guess it works.

The main reason I haven't updated yet is because I've been lacking in free time lately, but hopefully I'll find some time to update SoonTM

It'd work, but it wouldn't be emissive, so the sun would be dark.

It's always been possible, Unity 5 or not. There's an atmospheric heat ripple effect in my mod Kopernicus Expansion, but I don't think there's an engine heat refraction mod yet, though it'd be pretty trivial to make one.

It's not updated for 1.1 yet. If for some reason you're using it on 1.0.5, try reinstalling it manually or using CKAN.

It's been less than a week, calm down. 1.1 was quite literally the biggest update in KSP history, and I didn't have access to the prerelease.

Ask how to use custom vessels for asteroids in the kopernicus thread. Not sure if there's a way to hide them on the map though.

You can already do that with the latest version of Kopernicus using the new asteroid spawning.