sgt_flyer

https://www.reddit.com/r/Arianespace/comments/7siadj/rarianespace_ariane_flight_va241_ses14_al_yah_3/ 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 https://instacalc.com/42882 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

@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)

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.

Well, as much as i like problem solving, i don't have enough concentration left for me after the end of a work day to get back into ksp at that kind of level atm - it'll get better once i'm more settled in my new job but don't worry, i still lurk on the forums, and i'm still avaible if you need to bounce ideas / concepts on someone

@Martian Emigrant it seems Krakensbane code is still in the game basically, squad put some code that kicks in above roughly 700m/s to prevent 'Kraken attacks' Below 700 m/s, krakendrives only goes to 3 / 5 m/s vertical speed - above 700, gives insane accelerations - so, beware when crossing the treshold with the drive active - especially when using it for a retrograde burn - it's like dropping an anchor attached to the wheels of a dragster going full speed happenned to me pre 1.0 - i was testing a spaceplane equipped with a krakendrive, and the thing kept on either breaking apart, or having the krakendrive just vanish from the craft each time i got below the treshold when trying to circularise with the drive around mün

Have you already tested how it reacts from the ground ? (At least, to check if Krakensbane got modified a bit :p)

@Majorjim! you should check out the MK1 diverterless supersonic intake well placed, with a few small radiator panels, it can make a really cool looking OMS pod

Farewell, Rosetta your legacy now rests in the scientists hands

'Catching' those balls with electromagnets is going to cancel the momentum - because your magnetic field comes from the ship. The ship magnets will 'attract' it towards the balls at the same time the balls are attracted towards it. You could put a metal plate for catching those balls, it would have the same effect. Take one magnet and an iron piece, and move them closer to each other - both will want to move closer to each other. magnetism isn't magical momentum conservation laws applys the same way. If you 'accelerate' a ball then slow it down to a stop within the same machine, net momentum = 0. No matter if it's mechanically accelerated and stopped, magnetically, or a combination of both.

You know, you should explain a bit on this forum what you are making , instead of simply giving a link without explanation besides, we are not able to see the images hosted on this forum unless we are logged in (so we basically need to register on another forum) if you wish to share those images, you should upload them on sites like imgur

@Columbia thanks i used those myself to make a few custom turbofans too if you wish though, i made a new 1.25m animated turbofan, built upon this bearing discovery by @Avera9eJoe here's a prototype animated turbofan built upon this suprisingly smooth operation (same method operations as my old animated turbofans - trim roll, then decouple the animated parts to get them turning - don't forget to reset the trim afterwards though ^^) and here's an animated view of the internals http://i.imgur.com/UHCe9di.gifv the album shows a bit more the mechanism http://imgur.com/a/jJMaI

@Sharpy - you share interesting designs, but it would be even better if you shared the design techniques you used (for example, a step by step album) - after all, this thread is more for showcasing construction techniques more than just sharing images of the .crafts . maybe you could write some description of why you created this design and how you balanced it

can you show us a picture of before decoupling ? I think what happens is that two of your docking ports are connected together node to node in the vab, and you decouple this. Leave the 'external' body docking port free (node avaible), and mount the future rotating part on a lateral decoupler.

it's Kerbal Engineer Redux it gives a lot of technical infos (TWR, burn times, delta-v per stage) - a nice tool when it works (it has a few problems with some designs however). can work without adding anything to a rocket (so they stay stock - someone who doesn't have KER don't need it to open a .craft built upon these infos

and here's the video of my entry : ) (warning, i use a lot of clipping when making replicas ;)) fully stock soyuz - Flies like a breeze (it doesn't even need SAS during the gravity turn after the pitchover ! ) added a few subtitles with the various events (staging, etc) - bonus, a launch escape system sequence at the end of the video (bonus timestamp : https://youtu.be/iw2j0_qOJQQ?t=779) gimbals : on the boosters and the core stage, only the 24-77s 'twitch' can gimbal (used as verniers) (gimbals are disabled on the MK-55s 'thuds') on the upper stage, it's also the same setup - the thuds are gimbal locked, and the LV1-R spiders act as verniers a few infos on how the RCS is set up on the spacecraft : the 2x4 angled RCS on the end of the service module control pitch, yaw and forward / backward translation. the rcs on the 'belt' of the spacecraft, control roll and lateral / vertical translation. (this allowed me to roughly center the translations around the COM of the spacecraft) finally - here's the craft files : soyuz + the launch pad - 798 parts. (not as bad as it sounds - after initial liftoff, as the discarded pad is loaded in separate threads, it's not that much a strain on multicore CPUs :)) https://www.dropbox.com/s/7dixrr0frn89jys/Soyuz launch pad.craft?dl=0 soyuz without launch pad - 383 parts. https://www.dropbox.com/s/m2i3quyk2auv7k5/Soyuz.craft?dl=0

I've written it in the post 383 parts rocket + spacecraft, 69 parts for the spacecraft alone. i also have a version with a stock launch pad, around 700 parts (launch pad, + rocket) (which is the one i've put in the video ;))

@InfiniteAtom No,there's no mods it's full stock on KSPs current version, stock aero parameters too (i even didn't need any editor's extensions ;))

here's a preview for my entry (full Stock) (note, i built it a few months ago - however, i made the video for the challenge ;)) i have to do a few video edits before uploading the video, but here's a preview image - i used the numbers from the soyuz blueprints, but roughly scaled down to kerbal size (tried to get dimensions to roughly 64% of the real size) - thanks for the Fairings 383 parts (rocket + spacecraft), 31.8m long, 5.9m wide, 156 tons fueled. (boosters included) - it flies like a dream (with wide fuel margins in the upper stage when launched on an equatorial orbit) the spacecraft itself is 69 parts, 5.9 tons (Veeeery cramped, clipped multiple MK1's ^^) video to follow for all those who want to attempt building it, here's a link to a blueprint avaible online (warning, 3000x4000 resolution image ^^) - russian language, however, the dimension numbers written on it use the metric system (afterwards, feel free to scale it down or not - 'ksp' size is roughly scaled down to 64% of real size. (when comparing the MK1-2 command pod to the real apollo command pod) http://www.slavinskas.com/scifi-photo/stash/soyuz-rocket-blueprint-3000x4000.jpg

@Claw thanks for the additional explanations

they are not interacting with each other - they are effectively grouped as a rigid body - but the physics engine still has to process them on scene loading - simply to at least get the parameters (size, position, and at what it is attached) of each convex into memory (they are procedural afterwards, difficult to process in advance) - and it seems it has to retest them at each staging event to check if nothing changed / they didn't collide with anything. (which is why we were sometimes getting very long freezes at scene loading, and then at various staging events)

for physics calculations it is. it's one of the things squad had to deal with when they switched to unity 5 - Unity 5 can only handle convex shapes for the collisions, concave shapes are not supported. creating a filled cylinder (fuel tank) is an easy convex shape - creating a tube or a half-fairing require to build the physical collision model out of several convex parts, which are then grouped together to create one entity - but when doing physics calculations, it has roughly the same impact than if you built a tube out of wing parts. it's why when the 1.1 beta test was released, that complex / huge fairings created long freezes on scene loading. the fix squad did for this was to make 'closed' nose fairings out of simple primitives (half cylinders , cones - per vertical segment) - so you have much less 'physical' parts. (try decoupling something inside a closed fairing ^^) those switch to their full multi-convexes physical shapes only when you stage the fairings. open ended fairings / interstage fairings however are hollow - thus made of a variable amount of convexes. (multiplied by the number of vertical segments). it is still possible to adversely affect the game performance if you create a complex interstage / open ended fairing current 'open ended' fairing / or ejected fairing halves physical 'mesh' generation is roughly this (from infos gathered from @Claw and the patchnotes during the beta test of 1.1) : each 'size' of fairing baseplate has a 'minimal' amount of internal 'sides' hardcoded. (something like 8 for the 1,25m fairing, 9 for the 2.5 and 12 for the 3,75m one) when you modify the number of panels (fairing to split in 2,3,4 or 6 sections) the game recalculates the amount of 'convex' needed per section (distributed evenly), to always be equal or above the minimal. so if a 1,25m fairing is set to split into 2, you can have 4 convexes per section (2x4, = 8 convexes ). when switching to a 3-way split, you get 3 convexes per section (total 9 convexs) - 4-way split, you get 2 convex per section (8 convexes total) and in 6-way split, again 2convex per section (so 12 convexes - because if it only had 1 convex per section, 6 convex would be below the hardcoded limit) all that multiplied by the number of vertical slices ! even something like my custom 1,8m space shuttle SRBs were resource hogs when built solely out of open ended / interstage fairings, so i rebuilt them to have one huge closed fairing on top of a interstage fairing made only out of 3 vertical slices in 2-way split, to have a minimal performance impact.

beware, 1.1+ Open ended / interstage fairings use a lot of resources, and are slightly less round than pre 1.1 ones (especially less round if you use 2 sided 1.25m fairing, as it's an octogon shape inside) A 6 sided 1.25m open ended fairing would be more rounded, with a 12 sided polygon as a roll cage - but for ingame calculation, the fairing would count as 12 individual physical parts - per vertical slice ! So if you clicked 5 times when making the fairing, that's like having 60 individual parts for the physical calculations !

@Avera9eJoe my current test platform is much more down to earth (or down to kerbin ^^), so i didn't really tested it in saving / reloading searched for something to replace the small wheels i used in this kind of bearing before 1.1 your finds on magnetic bearings just came neatly ^^ i'll send you a link to the bare bearing for testing for g-loading, when manoeuvering this plane (5.4g's when pulling out of a sea level dive with the test plane) they only slowed down a bit due to friction (once the G-forces lowered, they started spinning back to their old speed, without noticeable wobbling ) edit : - mmh checking on the disassembled thing, i have a slightly shorter gap on the side where the ox-stats are touching the reaction wheel - so the other docking port is pulling harder, pulling the reaction wheels onto the ox-stats (which i guess is one of the things that helps on stability)

ok, did some tests with those magnetic bearings under gravity / g forces seems a small dry bearing cage does wonders to stabilize the wobbling (doesn't even need high part count cage - i only used 3 ox-stats to stabilize the thing, without adding much friction (though when g-forces kick in, friction increase, but stability is kept) the spinning part's docking port is attached to the small 0.625m decoupler, when the part is decoupled, all docking ports magnetize the 3 ox-stats are attached to the outer structural fuselage, they serve as the stabilisator (they are just wide enough to leave a little clearance to the RTG's collision layer) - the solar panels also 'press' against the reaction wheel (blocks back & forth movement) animated gif - click the image to get to the .gif

i never tested them in 1.1 the extensive rework of how fairings physical collision layers that came from the switch to unity 5 pretty much killed the original versions . for example : a 2 sided 1,25m fairing will have only 4 physical collision boxes per side ! an octogon is not really a great way to make wheels roll (using x6 sided 1,25m fairing will end up with 2 collision box per side, so you get a 12 sided polygon for the inside. now multiply those 12 polygons by the number of placed points of the fairings (can be 6 to 10 segments depending on the diameter) and you end up with up to 120 physical polys per engine hull - not counting the mechanism itself. unity 5 physical geometry can quickly become a resource hog (as it's convexes only) additionnaly, 1.1 landing gears are not really meant for that a well made dry bearing might be much more reliable the new 3d models for the jet engines didn't help either besides, we now have the goliath for a large animated turbofan i'll try to upload an alternate version this week end based around the structural fuselage and retractable ladders for a 1,25m @Majorjim you should ask more in Azimech's thread about this kind of things