CorvusCorax

New challenge: Instead of "as fast as possible" - try with "as little deltaV usage as possible" (Timewarp allowed) Demo:

Also: Trajectory Preview:

New version 0.000014 has a frame and time counter - velocity is now independent of fps - unlike original ISS-SIM which no longer gives fast systems an unfair advantage in speed runs. https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9

I added a new feature to the userscript mod in v 0.000013 -- propellant utilisation is now monitored and displayed. That adds a new dimension to the speedrun. Try to do it with less propellant. We need some sort of formula to weigh propellant use against speed. I would suggest measuring the time and then add 1 second for every m/s of deltaV used. Would that be fair?

Confirmed. I fixed that bug in v 0.000009 of my CustomScript mod: https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9 Also, you can now chose to be placed in a 198 km circular orbit and need to phase and rendezvous with ISS manually before docking. Anyone wanna speedrun this? There is timewarp!

Check this out: With my mod, you can now fly Dragon from Dragon deployment - through phasing and ISS rendezvous - all the way to docking: If you select "CHALLENGE" to "RENDEZVOUS + DOCK" - you'll be placed in a 198 km Dragon deployment orbit and need to make your way to the ISS yourself. Without a map or maneuver node planner. But there's some helpful HUD info from Dragons navigation computer. You can figure it out on your own, or check the info on https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9

New version v 0.000004 of the Customization userscript adds time warp. https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9 In case you get bored during your speedrun. Also, proper orbital mechanics, so you can now change your orbit, re-enter, or try to re-sync to the ISS and display some orbital parameters on screen. No manouver nodes though >:>>>

I went full-on KERBAL-overboard on the mod and added support for proper orbital mechanics (single body for now) This means, yes, you can now make a proper retrograde de-orbit burn to re-enter: Also time warp, so the KSP-ers don't get bored :-) https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9

Docking on Zvezda - Aft port - NO HUD / docking guidance - User script: https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9 v 0.000003 Realistic docking constraints: Position deviation: offset max 10 cm Angular deviation: max 4° Velocity: max 0.1 m/s Angular rate: max 0.2°/s Time: 1:30 This was mostly to demo the extension. The time can certainly be improved

Now I dare you to speedrun to Zvezda (aft port) with realistic docking constraints (0.1 m/s 0.1m distance, 4 degrees deviation allowed) And then do it without HUD

I modded the sim and made a user script. You can now play with difficulty settings (including turning HUD off and fly by visuals alone) and dock to alternative docking ports (including Russian ones). More details here:

I added a new version of the ISS-SIM-Customizer: https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9 New features: 1. Realistic docking constraints based on NASA IDA specifications (allows up to 4 degrees more angular deviation, but requires more precision in position and velocity) 2. Select docking port to dock with. Available options: IDA-2 on PMA-2 Harmony Zenith Harmony Nadir PMA-3 (just squeeze in from underneath and push against that radiator) Zvezda Poisk Pirs Rassvet

This is too easy! Let's play this in HARD mode: Turn the HUD off. -- Simulate Sensor failure and dock like a pro Or turn collisions off, and look at the insides of the ISS (sadly no internal textures, but one can still pretend) Or make a deorbit burn - without getting warped back after 500 meters. Feel free to install this user script in Chrome Tampermonkey or Firefox Greasemonkey, and pimp your ISS-SIM https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9 (Note: No, docking to other nodes than harmony isn't implemented yet, that's a TODO. Feel free to do so, I need to sleep)

Just so I understood correctly, FAR uses the shape of the whole craft - including body - to calculate the translational static lift when the craft is moving through the air. But only "wing type" surfaces (including ailerons and similar control surfaces) are used to calculate dynamic lift that happens when parts move relative to each other, one part affects the airflow of another, etc... so FAR would not change the lift calculated by a craft body whether it's rotating around an axis or not (regardless of wether rotation is caused by robotics or control surface deflection or simply the whole craft is rotating) and in each timestep only the current orientation relative to the stationary air around the craft is taken into account, not localized differences in airspeed due to part or craft rotation. but for wing surfaces, including ailerons, this "local airflow" is taken into account both to calculate "dynamic lift" and effects like increased lift on the downwards moving wing during a roll manouver, as well as shadowing effects such as a deep stall in a T-elevator setup when the horizontal stabilizer ends up shadowed by main wings. if I got that right, then FAR is even more awesome than I thought If that's the case, I assume one probably could write a part-mod that just adds the "i am a wing" property to everything - in order to get full dynamic airflow calculation - at the cost of horrible performance impact. is that correct?

how are the forces on parts connected to a rotor calculated then? does FAR treat the rotating part as if it was non-rotating in every "frame" (ignoring local veolicty relative to vehicle root) and the "observed thrust" is an inherent property of the propeller blade part itself when its turning? I tried to confirm this with a few tests. Any surface of type "wing" does produce lift and drag when attached to a rotor hub or similar moving part. A similarly shaped body panel produces neither. This looks like "stock" behavior got adapted to produce "moving wing lift" but FAR ignores the part or at least its rotational motion. Is that correct? I tried to be "smart" and put the rotor on upside down, added the probe core to the "wing panels" and added a decoupler at the bottom of the motor, so I could detach and launch the "rotating probe" once it was spinning, (now with no more robotics parts involved) but again I did not get any lift with the rotating parts unless they were "wings" Is there a problem where FAR does only calculate lift for translational movement but not for rotational movement, reverting to stock lift calculation for rotational motion? (aka no body lift for lift generated by craft rotation)?) https://imgur.com/a/eGgqLYZ this is a detached probe core (with some empty tanks for stabilization) spun up, with wings attached. the rotating wings produce lift in far (can be seen both with the arrow visualization and the fact the "rocket" takes of) the very same craft, spun up and detached but with tilted body panels instead of dedicated "wings" - in FAR this shouldn't make a difference, yet... the rotating body panels produce neither lift nor rotational drag.

I have a question regarding FAR, 1.8.1 The Breaking Grounds extension pack and the recently added impellers: https://imgur.com/a/WPr3NFx Mods installed: BreakingGrounds Expansion, FAR, TweakScale, Deadlyreentry, MechJeb, Kerbal Engineer, MechJeb+Eng for everything Symptom: I can't reach more than Mach 0.8 with an impeller driven craft. Craft: https://pastebin.com/X58zcrUY The maximum speed is achievable with a blade pitch of 45° at maximum RPM of the available stock (Breaking Grounds) motor ( 4* EM-16S with 6 blades each) It's not possible to take of with that pitch, the blades stall, producing almost no thrust, to accelerate a variable pitch profile starting at more pitch (less blade AoA) and ramp it down from ~80° to 45°. At less than 45° (even steeper AoA) no further increase in airspeed seems to be achievable at any altitude. Note: I mapped Main Throttle to Engine Torque, leaving the RPM selection at max. As it turns out only minimal (5%) torque is needed to sustain Mach 0.8, resulting in quite long flight times with moderate battery sizes. The craft has a somewhat MACH optimized cross section. I did not see any effect on the curves by modifying initial blade pitch setting. This is the voxel visualization. Are the voxels too big to correctly work for these small parts? the arrow visualization has this ring of purple arrows rotate around the craft Questions: 1. How does FAR handle these rotating flight surfaces? Are Shock effects on individual blades and shock front interaction within the ducted fan modelled? What pitfalls do exist? 2. Does the inability to exceed Mach 0.8 have to do with local airspeed around the blades becoming supersonic? 3. Can supersonic flight potentially be achieved using appropriately shaped intakes or nozzles? (Aka, a shock cone built from a nosecone within a fan duct) Can FAR model these effects? Any insight on this? cheers Corvus Corax

it should be noted that the workaround needs another workaround. Any craft with the TR-28 d becomes almost unflyable with the workaround applied due to wobble. The fix: add struts around the TR-38 D's bottom (connecting to the auto-interstage / engine)

The workaround indeed makes the segfault disappear. I also noticed that the game does not crash if I decouple the payload from the upper stage before I activate the TR-38-D (it's a docking port sr, so it can be reattached to the upper stage for circularisation on a trajectory thats lofted enough) It seems to be one of those rare segfault conditions that are hard to reproduce, changing anything makes it vanish as its delicate conditions are no longer met. I hate those when they happen in my own code That makes me wonder though if this segfault could be used with a carefully generated craft file to execute arbitrary machinecode on the client - might be mean when sharing crafts on the net or with dark multiplayer and similar mods would likely be better to get it fixed in the next version before anyone finds out if its exploitable that way

Hi, I built a craft for use with dark multiplayer, but every time I hit space to engage the 3rd stage, the game segfaults. The craft was created and edited in the VAB only, using subassemblies that had previously flown on other craft without issues. To rule out the dmp mod as the culprit, I copied the craft file over to a stock game, stock also segfaults. I was running KSP_linux.x86_64 on a gentoo linux with Kernel 3.17.7 I then started the x86 version of the game instead of x86_64 and it also segfaults Game reports as version v1.1.3.1289 Here's the craft file: link to craft file I tried to backtrace the segfault with gdb, but its not very useful: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fbd740 (LWP 5934)] 0x00000000401a62bf in ?? () (gdb) bt #0 0x00000000401a62bf in ?? () #1 0x00007ffeff342800 in ?? () #2 0x00000000401a61e3 in ?? () #3 0x00007fff10fee0b8 in ?? () #4 0x00007ffefe052000 in ?? () #5 0x00007ffeff342800 in ?? () #6 0x00007fff0e297800 in ?? () #7 0x0000000016bb5dc0 in ?? () #8 0x00000000401a613f in ?? () #9 0x0000000000000000 in ?? () how to reproduce: copy craft file into savegame on stock KSP 1.1.3 start the game and load the craft unto the launchpad engage the TR-38-D decoupler between core booster and 3rd stage - either by right-click -> decouple or by going through the staging sequence game segfaults without writing any messages in KSP.log - instead of separating the stages as it should

This is an important for both FAR and stock aerodynamics: You have 4 force centers on a space - or airplane: 1. Center of mass/gravity (COM, COG) - this is the virtual point where if the craft was hinged on it would be in perfect balance - also usually the rotation center when turning in vacuum 2. Center of lift - this is the virtual point where all the lifting forces applying to an airplane appear to be combined. (Lift= force perpendicular to flight direction) 3. Center of drag - this is the virtual point where all the dragging forces applying to an airplane appear to be combined. (Drag= force opposed to flight direction) 4. Center of all aerodynamic forces (2+3 combined) Most tutorials don't distinguish between 2 and 3 and just use 4 named as either of them. KSP afaik displays 4 in both SPH and VAB Depending on shape and angle of attack, a structural part can have low drag and high lift as well as high lift and low drag, so 2 and 3 are NOT identical. However these conditions are both dependent on angle of attack. Which means if you change the angle of attack, points 2, 3 and 4 all shift around. Everybody is being taught that if you have your center of mass (1) in front of the center of aerodynamic forces (4), your craft will be stable. This is not wrong, but it's only half the truth. In theory, the crafts mass wants to keep its momentum pulling on point 1, while the aerodynamic forces push against it seemingly in spot 4. These forces against each other will rotate the craft. Usually center of drag behind center of mass will turn the nose into flight direction. Center of lift behind center of mass will push the nose down (which is good for autonomous stall recovery. In fact, you counteract that with elevator trim creating a down force at the tail which effectively makes the center of lift identical with center of mass while center of drag is still behind center of mass. As such the craft will remain flying level in a stable craft, a faster speed will lead to increased lift in the front, center of lift moving forward - pushing nose up, while slower speed will shift the center of lift back pushing the nose back down making it glide nicely) If you deviate your orientation ever so slightly, this arrangement will force the nose back into flight direction and everything is fine. Now if you steer extreme angle of attacks, 30° or more, then your aerodynamic shape changes drastically. Some surfaces might stall (increasing drag a lot, while reducing lift) while others - for example the fuselage itself when experiencing airflow from the side - might suddenly become a "lifting surface" (creating unwanted sideways lift) You can test that in KSP by rotating the entire craft around. The calculation for "center of lift" always assumes that the craft is flying towards the hangar door (in the SPH) or up (in the VAB). If you turn the craft nose up in the SPH, KSP will show you where your center of aerodynamic forces shifts to at 90° angle of attack. If your craft is stable, it will still be more or less at the same spot behind the COG. If so, then the forces would turn your craft back into a nose first position. However with such a wide-bodied craft as you have, the fuselage will create much more drag when flying at 90° AoA than when flying nose first - especially in the forward section. (Those nosecones really have crappy drag coefficients when flying sideways) This is almost guaranteed to move your COL towards the nose, above the COG. And that causes your craft to turn tail first. (That doesn't mean that it's actually stable with its tail first. The new COL with tail forward might again be somewhere else, leading to a craft spinning around oddly and never settling in any useful orientation) To have a really stable plane that you can trust during reentry manouvers and high AoA, you need to have the COG in front (as in closer to the nose of the craft) of COL not only when in its default orientation - nose forward, but also when turned 45° and even 90° sideways, up or down. If that is the case, you won't enter stuff like irrecoverable spins and such. (This is a real world issue even with some existing operational airplanes: A so called "flat spin" is exactly that: In a stalled high AoA configuration, the COD shifted so far forward, that the craft remains, spinning, in that configuration and its impossible to move the nose back down, even though the craft flies stable with a nose first orientation) With FAR, this is made further complicated. At high supersonic speeds, the center of drag shifts as well. With delta wings and a pointy nose, it COD usually shifts to the back, but with a blunt shaped nose it might even move forward (detached bow shock and the like forming up)

Problem 1. RSS & Realism Overhaul (at least FAR+ deadly reentry) installed - game version 1.0+ (tested in 1.1.3) 2. You got an airplane (anything landing horizontally) into low earth orbit 3. You want to get it back down without burning up. Usual outcome: Let's assume, you finally got a craft flying in FAR at both subsonic and high Mach speeds and even have thing not spinning out of control during reentry attempt. As soon as you try to reenter at LEO entry speeds (~8000m/s ish) stuff simply overheats and explodes :-( Howto do it anyway: a) Procedure: You can't use ablative heat shields, so you'll want a very shallow lifted reentry with as low an initial speed as possible, so the heat load can dissipate. You really need to fly the craft all the way down from orbit using a steep AoA to get a detached bow shock and limit overheating. 1. Get Apogee of your orbit to under 200 km above earth (propulsively or with very careful >100 km perigee atmospheric breaking if you dare) Otherwise your reentry speed will be too high and you will overheat before you even get enough lift to fly. 2. Get your perigee at 70 km or below (very shallow reentry) 3. Make sure the reentry shock front is detached. If your plane is pointy in flight direction (MK2 cockpit - good for supersonic performance on ascent but too pointy for nose first reentry) then you need to fly with high angle of attack to form the shock front on the bottom of your plane (20°-30° AoA or even more!) 4. At 80-90 km altitude you will start to get significant lift (at speeds exceeding Mach 20) keep pitched up to control vertical speed. Try to sink as slowly as possible, don't exceed 100 m/s vertical. 5. Keep flying with high AoA (blunt shockfront, high drag, lots of lift) and low vertical speed. If you can force a shallow climb, do it. It will bleed speed even faster. You will likely end up between 60km and 70km for seemingly ever. The reentry corridor might span 1/3 of a whole orbit from initial reentry until you are slow enough to fly circles or change direction. 6. Once you are below 3000 m/s you basically made it. You can trim down the AoA and descent more aggressively and maneuver around. b) Craft Design: 1. All "exposed" components should be able to sustain 2500K surface heating. WARNING: Most RCS thruster pods are not, might have to be placed in the back of the craft, above wings or similar to be shielded from reentry bowshock. Most engines also can't survive that much heat and need shielding from front and bottom (like the Shuttle's SSME) -- Hint: Small Landing gear pods can only sustain 1500 K, you'l likely need medium or large unless you reenter bottom up to shield them. 2. The plane must be aerodynamically stable at subsonic (for landing), supersonic, and hypersonic speeds in rarified atmosphere. You can test that with suborbital flights not exceeding 3000 m/s going up to 60-80 km. Many MK-2 fuselage planes tend to enter a flat-spin in thin upper atmosphere even though they are stable further down. I solved that with "SpaceShip 1" style tail-booms, with SR-71 style tail fins on them ... even though they aren't foldable, they gave me both enough tail stability and enough control authority for #3: 3. You need to find a way to trim the plane for extreme AoA flight aerodynamically, so you need quite a lot of control authority. If the airstream at Mach 20 wants to bring the nose down, you can't fight it with RCS for long. Even in this configuration the plane needs to be semi stable (stable enough that SAS can keep it from spinning out of control) - in a nutshell that means you need forgiving stall behaviour (since you basically reenter high-speed-stalled) Example: Flight with large AoA (22°) and level flight - at this point already descended to 65km and 6100 m/s: (At this point also my bow and mid section RCS thrusters had all but vaporised, only the three at the tail remained. FAR and deadly reentry have a habit of overriding your decision where to place RCS thrusters in a very convincing way ) This shuttle can sustain flight at +20° AoA thanks to setting of max control deflection (40°) and AoA setting -200 on the tail boom rudders. SAS is only used to keep roll and yaw centered. Tail rudder trim reset to zero AoA and 15° max deflection once speed below 2000 m/s, SAS no longer needed (self stable) In this flight I overshot my landing site by more than half a continent and ended up in the middle of the Indian ocean. I managed to ditch the craft with onlyminor damage (ripped one of the tail fins off, but the fuselage and wings held, Jeb was fine )

I only had this "can't activate while stowed" issue once so far. And I had nothing stowed at all. I went to orbit with an extension module of my space plane stowed in its MK3 cargo bay - docked to a docking port so it wouldnt bounce around. Once in orbit, I opened the cargo bay, decoupled, let the epansion module float free and directed it via its RCS to another docking port on the top of my space plane. The cargo bay closed again, the extension module was then to deploy its large solar arrays. I got the "can't deploy while stowed" error. It only went away after I 1. decoupled the extension module 2. armed a "docking" clamp that was also on the extension module 3. redocked the extension module (using docking ports, not the clamp) which made absolutely no sense. IMHO this whole "stowed" calculation is buggy as hell

I recently designed a fully controllable helicopter with FAR and infernal robotics however as I found out in a later flight (sadly I don't have video of it) when I parked the helicopter with running engines and tried to see if Bill could jump off the cockpit, walk around the heli and climb back in... with new innovations apparently also come new hazzards to kerbals - especially if a craft like this starts to wobble and tilt... ... can we add "helicopter blades" to the list?

being able to use TweakScale with robotics parts would solve all size problems forever I think that actually does work can anyone put the CKAN info up so it gets possible to ckan install the expansion packs with 1.0.5 please?

Hereby doing that. This happens with KCT in combo with TestFlight Reproduction: Have an engine fail (loss of thrust, engine failure or explosion) in flight (thanks to "TestFlight") Recover the vehicle into the VAB/SPH using KCT Either try to edit this vehicle or try to re-launch it (both leads to this nice error) I uploaded the logs and filed more detailed information at https://github.com/magico13/KCT/issues/114 (hope thats the right place) Edit: found the cause. The issue is that an engine or tank "exploded" thanks to TestFlight often removes one of several symmetric parts. This triggeres a known issue in KCT when symmetric parts are rendered "no-longer-symmetric" in flight (like clipped wings) but with higher incident-rate. Work around is to "Scrap" such vessels (or recover "old style") and then rebuild them from parts (takes longer though). Apparently there's a relatively easy fix for this, so it should likely be fixed very soon