• Content count

  • Joined

  • Last visited

Community Reputation

1,617 Excellent


About sgt_flyer

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @MR L A basically, it's because the wheel's position has to be extremely precise to prevent offset thrust (the dampener force is not exactly lined up with the wheel's visual model) - even then, when using maximum pressure, the part bend slightly worsening the offset. (And it's even worse with a center of gravity far away from the drive) the reaction wheels are basically there to compensate the resulting torque now, be careful on long range missions, you can basically only use the drive from lower orbits in planets SOI, as the wheel stress rises the further away you are from the planet you're orbiting. If stress reach 100% the dampener breaks and the drives stops working. (On kerbin near 7000 KM stress is near 100%, on duna it's 4000 km) so you need very precise transfers (or classic engines to do course corrections) :p it's doable though, managed to get my mk-2 version from kerbin's surface to duna's low orbit with only jet engines (for getting above krakensbane speed) and the mk-2 krakendrive for getting into orbit, make the transfer, and braking near duna
  2. Well, you can see it in action in the video in the first post As for the how, basically when the wheel dampeners try to extend after having been compressed, the force is only applied to the craft the wheel is a part of (instead of also applying to whatever the wheel is pressed on). Normally there's no problems (wheels usually press on a planet's or moon's surface), It's simp'y a computing simplification for limiting the resources used by the physics engine of the game. But here, when it's the same craft that press on the wheel, the wheel only impart force in one direction (instead of two), resulting in net thrust. Before the game swithed to unity 5, the wheels could interact with the same craft, so you never needed a separate part since unity 5, wheels can't interact with the same craft, so you need a separate intermediate part. Basically, you get : 1) Part A wheel's dampener is compressed by part B. 2) Part A wheel's dampener try to extend back, pushing part A away from part B (but imparting no force on B, while in real life it would impart force on both sides) 3) because the part A also pushes on B (but B get's no return force from the wheel), you get a net thrust. It's like that magnet troll physics meme Now, for the two modes of operation (hover mode vs thrust mode) it is thought it's because Krakensbane steps into action (Krakensbane is a piece of code added by the devs to prevent kraken attacks (which worsened the faster / farther you went), but this code only steps into action after you went faster than a specific speed Now for the pure mechanical in this craft (outside the troll physics), the objective was to have a reliable sliding mechanism with redocking for part B within part A. Using the airbrakes authority limiter allows to control the movement of part B, pressing it more or less on the wheel, controlling in return the amount of force applied by the wheel on the craft When the airbrakes retract, they pull part B to redocking range (in te 2.5m model)
  3. sgt_flyer

    Threads of the month: July.

    @Vanamonde well, i like to tinker around in the VAB more than i do missions so for me, the Krakendrive redesign was more an exercise in improving my knowledge of those, rebuilding those, and trying to improve the concept further Learned a few more vab tricks in the process which can help me in other cases
  4. ok, tested a few things with a rebuilt the mk2 version. (tightened the slides, rebalanced the wheel position to limit reaction wheels needs) (note : i play with max physics delta time per frame set to 0.03, guess it helps taming the kraken a bit :p - he has less time to try to wreak havoc on physics ^^) from those tests, seems the wheel stress changes based on distance from the orbited body, instead of the speed of the craft. from early measurements made from a 100x100 save, seems like at 6500 km above kerbin the wheel stress rises to 95% when the k-drive is operationnal. note : quicksaving and quickloading before engaging the drive reduce a bit the stress at a given altitude, but it's a bit random From 100x100 orbit around Kerbin, with various saves : (the last save and load is made at the previous altitude) - ko means the wheel stress broke the dampener Stress Altitude 1.9 400km 2.3 500km 4.8 1000km 12.8 2000km 24.5 3000km 40.1 4013km 100/ko 7000km 100/ko 8000km Here, there was a quicksave and a quickload just before engaging the k-drive. Stress Altitude 1.0 400km 0.8 500km 2.1 1000km 10.5 2000km 10.5 3000km 15.3 4013km 30.0 7000km 100/ko 8000km in this last table, all tests with the last save and loads made from a 100x100, the orbit was then extended to an orbit with a 100km periapsis and an apoapsis at the edge of the body's SOI. no save before each test. : Kerbin Duna altitude 60 2870km 40 100 4000km 59.1 5000km 82.2 6000km 95 6500km It seems the wheel stress increases faster on a body with a smaller SOI. The tests were all done with the prototype seen here, which did make the flight from Kerbin's Airstrip to duna, with no rocket engines nor RCS ! Propulsion : 2 whiplashes (for takeoff and accelerating up to transition speed), 1 MK2 KrakenDrive the transition is real smooth with jet engines to bring the kdrive above 100 m/s simply set the authority to 56 / 57. Take off on jet engine, and accelerate to 100 m/s, engage the k-drive, then shut down the jet engines, the K-Drives do the rest. (throttling down the k-drive a bit during high altitude acceleration phase helps not burning ^^) now, for the flight to duna, i managed to make my transfer with a 1000 km periapsis around duna directly from LKO, as i had no mean to correct the trajectory (because of the behaviour shown above). I guess a more complete prototype with small rocket engines for course corrections would make the best use of this KrakenDrive. i'll try to test various SOI's to get to know the safe operation altitudes for the engine
  5. it's kraken based technology it can be unpredictable by nature though, it's seems the further away from kerbin (or planet), the faster the wheel stress rises. when i tried braking after entering jool's orbit with low thrust, wheel stress rose instantly to 100% and broke the dampener. i guess it could still be used to send things on an interplanetary transfert, then you detach the drive and send it back to kerbin for the next payload
  6. sgt_flyer

    So, you have a plane on a conveyor belt...

    If you have the plane with it's propeller set to give it 50 kph forward motion, while the belt is set at 50 kph backwards, the plane will go forwards at 50 kph. (Well, could be slightly below 50kph forward because of the tiny amount of friction you could experience in the wheel's bearing) the wheels would simply free spin at two times the speed they would if there was only the plane rolling at 50 kph on runway Do the same with a classic car on a conveyor belt however, and it would appear stationary all because of the different mean of propulsion : a classic car uses the wheels to 'push' against the road to provide forward motion. A plane pushes against the air to provide forward motion,which is not affected by whatever would happen on the ground Now, if you mount an aircraft engine and propeller on your car instead of it's classic engine, and put the wheels in free spin, it would behave like the plane described before on a conveyor belt After that, most of the remaining arguing in this thread could be resumed around the scenario that the belt no longer tries to match the vehicle speed, but the wheel's rotation speed instead, which results in some kind of edge case which quickly get to either infinite speeds or mechanical failure ^^
  7. Added the video of the KrakenDrive in operation to the post
  8. Hello, i scratched my head for some time for rebuilding an effective stock KrakenDrive, within the current limitations of the game, notably that wheels don't collide with the same craft - you need a separate part for the landing gear to press upon for that. Second problem, is getting a mean to redock this separate plate after use, for warp time or for saving games. for that, i started playing around with Airbrakes to give the pressure plate enough spacing from the docking port, to get it to redock once the airbrakes retracts. So the basics is simply having a moving part applying various levels of pressure on the wheel, with rail guides to prevent the moving part from escaping. One incredible bonus in having this kind of setup, was that it was possible to change on the fly the amount of pressure applied on the landing gear, simply by varying the airbrakes authority slider. The result, is that it was now possible to control the KrakenDrive's thrust within both Hover and Thrust modes ! one thing i realised that changed though, was Krakensbane (pre 1.0, the transition speed was at roughly 700 m/s speed) During hover mode with High G manoeuvers, the thing sometimes transitionned on it's own from hover mode to thrust mode - within atmosphere ! once in thrust mode, it was easy to get the thing to orbit on it's own Tested various form factors for the engine, and i could miniaturize it enough (though, it's a bit less stable) to fit within a single CRG-08 MK2 bay ! Here's the video of the drive in operation : Here's the full mission album : Here's the .craft files (Dropbox) KAT 25 (2.5 m form factor) : 25.craft?dl=0 KAT MK2 (MK2 form factor) : MK2.craft?dl=0 mods / DLCs i had during this KrakenDrive's devellopment : Making History KER, RCS Buildaid, EVE and Planetshine. While i have Making History, i didn't used any part from MH within those two drives, so a stock install should be able to launch them. i didn't use any of the new decouplers either, though i don't know how it will react in other versions of the game Operations : Pin down the AIRBRAKES, and use the slider to change pressure. the KrakenDrive effect threshold is roughly around 54% slider. For the KAT 25, press AG 1 to toggle on and off the KrakenDrive. it will redock on it's own when turned off. For the KAT MK2, press AG 1 to turn on the KrakenDrive, and press AG 2 to turn it off (a reverse pair of AIRBRAKES will then push back the pressure plate to redocking range) note : if you incorporate the MK2 within a spaceplane, you'll need to keep the cargobay slightly opened (1% in clamped mode) else the airbrakes will not move within a fully closed cargo bay. In Hover mode, the speed can vary between slightly negative descend speed (between 0m/s and -1 m/s) (though you're really at minimum effect), and + 20m/s of vertical speed (the krakendrive can't get higher vertical speed in hover mode, once reached, it's not necessary to continue to increase the airbrakes authority further) Transition : seems the transition speed seems to be between 60 and 100 m/s, the krakendrives can achieve transition during High G manoeuvers in hover mode, (though, generally, you have a really high airbrake setting at this point, the thing will be nearly uncontrollable until you dial back the krakendrive to a lower thrust setting, generally by 57 / 58% of the AIRBRAKE slider) Thrust mode in air : within atmo, you will be limited by the Krakendrive's drag, don't expect to be able to break the sound barrier with it while under 10000 m. (throttle back the krakendrive to keep a steady speed near 300m/s while under 10000m) above 10000m, the acceleration of a given setting will gradually increase as atmospheric density decreases. feel free to throttle back further to get a steady ascent (plus, it will protect the KrakenDrive from atmospheric heating) once in orbit, you can circularize with classic Kdrive operations. (and with thrust control on the kdrive, it's easy to get into low G thrust, the deactivation of the kdrive is nearly instantaneous when you hit the button (in ship mode though ^^, actiongroups won't respond in map view) In thrust mode in space, i've seen the krakendrive go from roughly 0.5G of acceleration to above 35Gs ! thankfully the thing is built like a tank so, there's nearly nowhere you can't get with those ! Limitations from my test : The number 1 limit for these KrakenDrive seems to be the Wheel Stress. the faster you go, (above 20000/30000 m/s of speed) the faster the Wheel Stress rises during operation. (and it's hard to brake if you're too fast, the stress still increases while braking) once wheel stress reach 100%, the gear's damper breaks, and krakendrive stops working. Other Limitation : the krakendrives don't seem to like aerodynamics. aircrafts with active KrakenDrive onboard are very hard to control from the few tests i made, an open ended MK2 bay at the rear of a plane can be moderatly controlled. trying to place the KDrive near the COM seemed to help to if the Kdrive was embedded within the plane. Getting to hover mode while in space : not really recommanded possible (slow down to near 0 orbital speeds), but can have side effects (can break the Airbrakes), that said, managed to land the KAT 25 on Mun once, all on it's own Have Fun playing with it, i expect KrakenDrive researchers can get new ideas from it (at least, the few KDrive researchers that weren't lost in the Kraken's belly for abusing it's powers .... the Kraken's behind me isn't it ? ^^
  9. sgt_flyer

    Behemoth Development (STOCK)

    Hmmm. 1- how are the vectors configured ? You might want to limit the gimbal range, and even turn off gimbaling on most of them. With the COG so far away from the gimbals, lateral stresses must be simply insane 2- position of the root probe core can impact stability, leading to excessive overcorrection of SAS. you can check by trying to fly it without sas enabled and without touching the controls to see if it survives. If it survives, try placing the probe core near the engines. 3- check the first item that broke in the game's mission logs (F3) (likely one of the fuel tanks) - basically one part broke free within the clipping, leading to that RUD. 4- try to change the position of the tank onto which you applied the symmetric mk3 tanks. (Instead of on the bottom, place it on top, etc). 5- if nothing above works, it might simply be just too heavy check by using a single column of mk3 tanks of the correct height, with the corresponding number of vectors 6- finally, if the column itself is too heavy, try to switch to a shorter core stage with fewer engines, but add boosters around it with fuel crossfeed to keep the core topped off (you might want to use 1.25m SRBs for separatrons though ^^) one of my old projects of the kind : (It was able to put 1500t of oversized payload to lko ^^' before autostruts even existed thanks to a crisscrossing of struts meant to average the load) ^^ in any case, your twr might be a bit low, as your rocket is without both upperstage and payload
  10. sgt_flyer

    Favourite real world Rocket?

    It was never built, (N-1 was favored in it's place) : Chelomei's UR-700 rocket Was quite an advanced concept for it's time , even reusing some hardware from the proton rocket the side boosters were mated by pairs on this thing, one half of the pair carrying an extra oxydizer tank, the other half an extra fuel tank - those where meant to top off the central cores. It was meant to use crossfeed long before KSP besides, the 3rd stage (on top of the 3 boosters forming the core stage, was meant to be a modified first stage of the proton rocket ! (The modified proton stage was to only have 3 engines and 3 side tanks, instead of 6) that version was planned for 151 tons to LEO another version of this rocket would have replaced the 3rd stage with an NTR stage ^^ crazy concept which would feel just so KSP ^^
  11. sgt_flyer

    SPACE STATIONS! Post your pictures here

    @MaianTrey A small hint for a stock mobile base system : Since the wheels physics update, wheels work in space if you can 'press' a bit the wheels against a flat surface (I tested it when i designed the s1-s0-p1 truss sections ^^)
  12. sgt_flyer

    Arianespace launch thread Mmh - seems they released some orbital parameters, seems like they are ~17° off of their intended orbit : Target : i=3°, A×P=45000×250 km Current detected orbits (both sats, upper stage and Sylda - not necessarily in that order ) 43174 ( 18012A ) i=20.64°, A×P=43163.63×232.36 km 43175 ( 18012B ) i=20.64°, A×P=43198.26×231.64 km 43176 ( 18012C ) i=21.01°, A×P=42790.30×168.65 km 43177 ( 18012D ) i=20.64°, A×P=43152.68×234.75 km With no feedback from telemetry, seems like the upper stage could not correct it's trajectory... it's still going to cost the satellites quite some delta-v: Edit : Mmh - just for the inclination change, seems it'll cost the satellites roughly 450 dv (though i might have inputted the wrong numbers in the calc) - numbers used : r2 = 43174 r4 = ((6371*2)+232+43174)/2 r6 = 17 that's still going to reduce quite a bit the satellites service life in the end. still, the upperstage managed to take those satellites in orbit despite complete loss of telemetry and corrections - not a small feat either
  13. sgt_flyer

    [0.90] Sputnik 8K71PS

    @KerBlitz Kerman It's because the link was generated before mediafire was banned by ksp admins. Besides, it'll only work in ksp 0.90 Here's my latest, which worked with the new atmosphere It's available in the thread below but be warned the new shape of the puff monopropellant engine broke the craft a bit (there's 1 on top of each booster, which was used for separation - the new shape of the puff is way too big for that)
  14. sgt_flyer

    (1.1.x) Build a Kerbal scaled ISS

    Hello - i don't know if the canadarm and the soyouz still works correctly with the latest builds - the geometry of some parts (the mono RCS for example, which i used in the hinges), and the monoprop engine) has changed. For the soyuz for example, the monoprop engines were used at the tip of the side boosters during separation - the new model of the monoprop engine is way bigger than the old one, which makes separation quite risky.
  15. sgt_flyer

    KSP Weekly: The Arecibo Message

    The change makes sense because of the collider geometry of the nose fairings ('closed' nose fairings colliders are completely filled, only switching to the correct collider shape after decoupling to save on the requiered computing) it's this way since the unity port, because of the way colliders are handled (the current version of unity physic's engine now rely on convex colliders, instead of being able to use concave colliders like before) anything you decouple (or a kerbal leaving his capsule) within a nose fairing is going to be violently ejected because it will be within a solid geometry squad made it that way because on the initial fairing release, having hollow fairings was the root cause of the large delay (>1mn in several cases!) on scene loading of large rockets. For the large fairing, it was roughly 12 rectangular colliders per height segment of a nose fairing ! - so collider count grew up way too fast with large nose fairings) while when filled, for a nose fairing, they can use a single cylinder /conic collider for each height segment. Still, interstage style fairings (you can close it around a nose part (ex : an FL adapter) still retain the hollow style colliders when closed (so we can have f9 style interstages) if you want to make hollow habitats for kerbals, simply close the fairing around another part this is the case since the unity port (tested the hell out of those things during the beta of the unity port)