Capital_Asterisk

Overview This guide is for people who make KSP videos that involve a high part count, lots of explosions, decoupling, or rockets igniting. Requires external software: FFmpeg This means a bit of command line keyboard smashing is also required. Problems to deal with: The game almost always runs slow regardless of hardware Long stutters: a few exploding parts can freeze the game for a few seconds or minutes. Inconsistent time difference between rendered frames: time in-game will not match the real world or recorded time. Skipped physics frames: at low frame rates, many physics frames are skipped and won't be rendered. The normal way of dealing with this is to just speed up gameplay footage fast enough so that all this is unnoticeable. However, things like explosions will still stutter the footage, and the game speed will still vary throughout recordings. The solution: Edit settings.cfg to make time between each rendered frame consistent Remove duplicate frames from recorded footage. The consequences of using this method: The game will be limited to 25 fps. This is probably okay as it almost never goes this high anyways. Extra video processing step takes time and video quality might be affected Audio is not preserved Results: Correctly processed but slightly boring video: About 30 seconds of in-game time, but >1 hour of irl recording. Audio was manually added in, and the method wasn't finalized here making it run too fast during the collapse. How to Step 1: Edit settings.cfg This file is located in the root of the KSP folder ( Kerbal Space Program/settings.cfg ). It is normally modified by the title screen settings. Editing it manually will allow using values that aren't in the settings. KSP physics runs at a fixed 50 FPS internally, or in 0.02s steps. If display framerate is greater than 50, then physics frames will be interpolated between frames. If the drawing framerate is lower, then the game will skip frames. The number of frames KSP is allowed to skip is mostly determined by "Max delta time per frame" in the settings, or the maximum allowed physics time between rendered frames. Setting this to a small number will mean that KSP will not skip frames at all; however, this is wrong. Even when it's set to 0.01, KSP will still skip at least one frame when running slow, which means 25 FPS is the max guaranteed-consistent stock frame rate. The frame rate has to be limited to 25, which there's an option for. V-sync should also be disabled to make this work. Find the following values and set them accordingly: PHYSICS_FRAME_DT_LIMIT = 0.01 SYNC_VBL = 0 FRAMERATE_LIMIT = 25 Step 2: Recording and removing duplicate frames Record at a framerate a little higher than 25 FPS, such as 30 just to assure that no frames are missed. Any common video format should work. Do not record your cursor, as it can move while KSP is frozen, messing up duplicate frame detection. Install FFmpeg, this is a very powerful command line tool you should always have lying around when dealing with video files. If you're on Linux then you know what to do; if not, then make sure to download an executable, not the source code. For windows, I'd recommend using an ffmpeg-...-win64-gpl-shared.zip from here. There's a few guides on the first results of google on how to "install" it. I reccomend this guide for Windows. Now open your favourite command line terminal, every OS should have one installed, such as cmd on Windows. First off, check if ffmpeg is working by running the ffmpeg command. It should output something like this: >ffmpeg ffmpeg version n4.3.1 Copyright (c) 2000-2020 the FFmpeg developers .... lots of stuff go here Set current directory to where your recordings are using the cd command. You can drag files into the terminal window to automatically type their full path. cd path/to/recordings/folder Now time to actually remove duplicate frames. We'll be using FFmpeg's mpdecimate filter to drop duplicates, and setpts to set duration of these duplicates and also set the output framerate. Here's the minimal example of the command used to do this. Replace bold and underlined fields with your own values. Ignore FRAME_RATE and N. ffmpeg -i InputFile -an -vf mpdecimate,setpts=N/FRAME_RATE/TB*InputFPS/OutputFPS,fps=OutputFPS OutputFile InputFile - Path to your recorded game footage InputFPS - Framerate InputFile was recorded in OutputFile - Name of output file that will be created OutputFPS - Output frame rate. use 25 in this case. -i is for input -an removes audio -vf is for video filter For example, a recording at 48FPS: ffmpeg -i 'MyRecording.mp4' -an -vf mpdecimate,setpts=N/FRAME_RATE/TB*48/25,fps=25 'MySmoothRecording.mp4' This might take a while to process. Preserving quality (for h.264 mp4) FFmpeg has to re-encode the entire video, and by default, sets quality to a crf 'constant rate factor' of 23. Lower CRF numbers are better, and 23 has noticable compression artifacts. Add the `-crf 10` or something to avoid getting jpegged. ffmpeg -i 'MyRecording.mp4' -an -vf mpdecimate,setpts=N/FRAME_RATE/TB*48/25,fps=25 -crf 10 'MySmoothRecordingHD.mp4' I'll admit that video codecs and stuff is not at the best of my knowledge. This just works. Some extra notes and details This method is not the best way to record smooth KSP footage. The best way is probably to write a mod that records the game, or sets constant frame rates.

Not sure if anybody else has done this yet, but enabling/disabling same vessel interaction can make for some very responsive mechanisms. Here's a video of a piston that enables SVI on girders to extend. It's also possible to make rotating joints, but it seems to be a little harder. I've tried using this mechanism to build an ornithopter; I haven't had much success so far for a bunch of unrelated reasons.

Sorry for the confusion; It works anywhere in the GameData folder.

yep

got lazy, or i forgot

yep, it's very simple and doesn't rely on anything.

So I just released a new version. This new version actually decreases induced drag, check it out.

That's done now. Lift multiplier can be changed for a part by adding a ModuleGroundEffect to it. MODULE { name = ModuleGroundEffect groundEffectMultiplier = 200 } New version with the induced drag reduction and stuff is released on the github page.

So far, it seems I found another way to modify lift force without changing lift coefficients and without using ModularFlightIntergrator. The mod now applies forces directly to the wing parts, as well as modify the blue lift arrows. The normal FlightIntergrator puts the calculated lift force into ModuleLiftingSurface.liftForce, and KSP has a TimingManager that can be used to run an update function after the ModularFlightIntergrator has done its magic. liftForce is useful for calculations, and doing something like applying negative of this value using part.Rigidbody.AddForce cancels the force entirely. Using a bunch of vector math, I was able to calculate induced drag and other excrements for a more realistic ground-effect effect. This boi is too heavy to leave ground effect. Lift multipliers has been set really high for testing purposes, and the lift vectors are more vertical because of induced drag reduction. I find KSP mod development very stressful due to slow performance, loading time, variables that have no description, and having to dig through the source code of existing mods to maybe find some useful techniques. There's a bunch of other projects that I enjoy working on, so this is kind of a low priority. I'll get the custom multiplier configs done in maybe a week for a new release.

Seems like something worth adding after not touching this mod for more than a year. It's definitely possible by just multiplying the calculated lift value with a coefficient from a config. I think all I have to do is add a new PartModule that does nothing but store that coefficient, and a bunch of other stuff to deal with it. This should make it possible to have a wing part that has a very low base lift, but goes really high in ground effect. Another quick and easy way is to just clip wings into each other so there's more lift, but it would end up flying instead of staying on the ground. One of the big problems with this mod, is that it can't decrease the induced drag, which increases with lift. The thing where the lift vectors become more vertical in ground effect doesn't seem to be possible with stock KSP wings. The lift force is stuck perpendicular to the wing or I just didn't try hard enough. I seem to be in the mood for working on random projects, so I might make some updates to this mod very soon. Using ModularFlightIntergrator seems promising, just hoping I don't have to completely rewrite the aero model. nope. If I ever get the kerbal ejector working slightly better, it will be called Eject-A-Kerbal because the kerbals become ejecta. I might actually work on the decoupler particles one, just that the new way Unity and KSP deal with particle systems is hard to work with and is undocumented last time I checked.

@IkranMakto @linuxgurugamer @JadeOfMaar Going a bit technical here, the mod cares about both ModuleLiftingSurface and ModuleControlSurface parts. Just for reassurance, the debug console should say something like "ControlSurfaces counted for [vessel name]: 16." It's not expected to work (that well) for single-vessel helicopters, like in Breaking Ground, Infernal Robotics maybe, exploited claw gimbals, any mod or technique that moves the parts in a single vessel. This is because of the way it calculates wing span. Oversimplified, it is the distance to the furthest sideways-moving wing from the COM. If you sit near the center of an airliner, and look out the left or right window, you'll see that air is moving fast across the main wings, horizontally from your vision. This approximation works great on fixed-wing aircraft and stock rotors, ignoring the positions of the stabilizers. You can make a craft that is just one big propeller, and it would work. For single-vessel helicopters, there's no good way to to measure the span. The calculated wingspan will be much lower, as the diameter is measured from the COM, instead of the center of the rotor. The effect might be noticeable if the rotor is larger, and closer to the COM vertically. The only good way I can think of is to have a separate wing span value for each moving section of the craft. This needs more thinking but it seems to be the right direction.

Just confirmed it still works in 1.8 without any recompilation, at least on Linux. The mod is too simple to break easily, being only a bit of vector math with no dependencies. There isn't really anything to add, besides supporting ground-effecting off of 90 degree surfaces, like sides of cliffs or buildings, which isn't really necessary.

Make hitting the ground a challenge A runway is a death trap designed to kill pilots who do not understand the concept of Ground Effect, a phenomenon created by communists to allow ships to fly with tiny wings. This simple mod adds Ground Effect to the stock aerodynamics, by applying extra forces over existing wings. It allows ground effect vehicles (GEV) to work properly. Features Increased lift over terrain and ocean Reduction in Induced Drag Up to 200% more lift at closest proximity Custom Lift multiplier can be set per-part config Ground effect scales based on an approximation of wing span Some GEV designs can stay stable without SAS No significant performance loss Works on stock rotors Installation No dependencies, and works on almost every KSP version, just put it anywhere in GameData (yes it's just a single DLL). CKAN and Spacedock links coming soon? [Latest Github Release] Is it working? Check the developer console, and it should say "CraftName has entered Ground Effect." Notes Wing span is roughly calculated by getting the largest value of a lifting surface's distance from the COM, scaled by how perpendicular the wing's position is with it's velocity. It's pretty complicated to understand, it's better explained in the source, but I put this in because it allows rotating vessels to work, such as non-DLC stock propellers. This mechanic can be abused for very slow aircraft There may be a few problems with Breaking Ground rotors, or any mod that has moving parts on the same vessel, as wing span calculations are done per-vessel. Tested to work with the following aerodynamics-related mods: Procedural Wings Bulleted List Extender Continued May unknowingly clash with other installed mods. No FAR compatibility planned; I was working on it for a while but it was really messy, and why make an aerodynamics mod for an aerodynamics mod? Development Thread Media

Again, I found another bug that causes small vessels landed in water to explode violently. Wings get a huge increase of lift when they have a negative depth (underwater). I'll fix this soon. I don't know whether to trust myself or not when I say something is ready for release. Sorry, but I decided to discontinue FAR support for a couple of reasons: Solution would be like writing a separate mod, as FAR completely replaces stock aerodynamics. Rewriting and replacing parts of FAR is hacky and inelegant An aerodynamics mod for an aerodynamics mod wouldn't be good FAR source code is slightly difficult to understand As I mentioned in a previous post, ground effect (the phenomenon) should instead be added as a feature to FAR itself.

There's a bug that causes vessels consisting of a single wing to enter the NaN dimension, breaking the game. So decoupling a wing from a stack separator, or having a wing explode off of a craft, would destroy everything. This has been fixed in the latest release. By now, I think it's time to post this on Add-on Releases. Sure!