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.