sgt_flyer

@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

@cubinator extremely good idea that rubik's cube a few ideas for you to improve it. you should be able to translate your docking ports so their docking section just barely shows above the surface of the structural panels (they will still be able to dock), then you should be able to shrink the seams as a result. (this way, the sections should be able to glide more smoothly, the sunken docking ports should create less jams (as their geometry would be mostly covered by the structural panel geometry.) now, for the bearings like Majorjim, i worked too on bearings , i had to build a few extremely tight bearings, for use on the stock ISS (notably in the canadarm selfish_meme and myself are making , here's a variation of one of the bearings i made for that : (the bearing itself is the decoupler and everything above it) if you need it for your rubik's cube - it can still bend a bit, but it goes back to flat on it's own (under gravity or not) for making those bearings, i tested the various parts that makes the bearings to know where the collision layers are exactly, and translated the elements to be in contact with the geometry (one possibility, is to 'drop' them on each other - and see the separation (the actual collision layer being smaller than the 3d model) the following pictures i moved some elements around to show how it's built the two reaction wheels are directly attached one to the other. the 3 ox-stats visible between the two small reaction wheels are attached to the decoupler - they keep the lower reaction wheel 'pressed' against the decoupler, and prevents bending (as they are sandwiched within the slight gap that exists between the collision layer of the two reaction wheels. those bearings work very well for keeping parts with low RPM things 'flat', centered and contained (even if you give them a nudge in yaw or pitch, it'll stabilize itself) keep in mind though, this bearing is made in 1.1 - the physical collision layers have changed a bit between 1.0x and 1.1, when squad had to reexport the models for unity 5, so what you see here might end up needing a different amount of translation in 1.0x and unity 4 here's the subassembly of the 1.1 bearing, if you want to test it (for your subassembly directory) (it's not backwards compatible though) https://www.dropbox.com/s/zcdsnatef8jeyun/flat hinge.craft?dl=0

yeah, ended up facing similar issues with the stock canadarm i made for the stock iss @selfish_meme and me are working on. as the stock canadarm has even more limitations than the real one, in some cases, i ended up changing the canadarm's targets / payload position for having an easier time

@cubinatorfrom here, now that you built your own bearing, you'll see it's a lot of the following to make it work smoothly : slights adjustment in vab -> test -> back to VAB for new adjustment and so on a slight thing to help stabilise your bearing's tilt with 1 or 2 parts - you can attach an OX-stat to the cage, and position it with the translation tool so it ends up between the two small reaction wheels of the rolling part (of course, there has to be nothing else there ^^) the result is that if the gap between the two RWs is finetuned just to the ox-stat's thickness, if the bearing tries to tilt it'll be stopped by the solar panel. keep in mind though (especially in 1.05) - the physical colliders don't exactly match the visible 3d model. (the colliders are generally slightly smaller) - so don't be afraid to experiment

for lots of undocking, as long as there's no major force trying to push the bearing out of his roll cage during docking events, you should be fine. for controlling it's turn from the center part, if it's meant to turn in only 1 direction, mmh - maybe you can make two sets of landing legs (or landing gearts) - alternating between the two sets of legs/gears to push the other part (ex : legs set 1 deploy and push against a panel) - then retracts, not yet in range of it's second panel). set 2 deploy and push against it's own panel, then retracts) - legs set 1 has now a new panel accessible for pushing then retracting) . jet / rocket engines exhaust pushing against the other part could work too.

for making open ended fairings : place your fairing base, don't make a shape. place a part (or several, to make clearance) on the payload side of the fairing, including a part large enough to close the fairing around it with the needed opening. shape the fairing to your liking, close it around the last part. remove that last part, the fairing disappears. from there, use the Undo command (ctrl+z), the part reappears, but not the fairing. then use the Redo command, the part disappears, and the fairing's shape you made reappears, open ended note, if you pick up directly the fairing base (and not the part before it) and replace it after having built the fairing shape, you will have to use again the undo / redo command to restore the fairing's shape. for copying a fairing shape, you need to save the original as a subassembly, and use the subassembly each time you want a new copy (symmetry don't work on keeping fairing shapes either) works exactly the same in 1.05 or 1.1 note, 1.1 open ended (or interstage) fairings are made of a lot of colliders - these can negatively affect the game (and it's colliders multiplied by the number of placed segments in addition to the rest !) besides, 1.1 1.25m fairings are not really round inside - they have 8 colliders per vertical slice in x2 mode (so, octogonal), 9 colliders in x3, 8 in x4, and x12 in x6 (so that would be the most round). @JZ6 bearing in 1.1 would end up being made of 7 vertical slices, in x6 for most interior roundness, so you end up with 42 individual colliders for this bearing alone - creating a dry bearing instead would drastically reduce the number of colliders afterwards, for smooth low rotation speeds in microgravity, dry bearings can work very well (and can be made really compact ! - ex, a 0.625m part with x6 solar panels around it). just be sure there's no straining on the bearing during docking events . create some test rigs if you want to check the smoothness of parts - place an I-beam or another flat parts, and mount the part you want to test on a decoupler (with additional probe cores, reaction wheels and RTG's attached to the part) above that flat part - then decouple it, switch to it, and observe how it 'rolls' to determine it's shape. in any case (wheeled or dry bearing),to ensure smooth operation, it's important to have the center of mass of the rotated part in the middle of a single bearing (or in the middle of two bearings if you use two)

the R7 booster visibility is also stated on wikipedia further down the sputnik 1 article they explain that too (in the launch and mission section) some info though - you can use a square cage around a rounded part to create a joint (or a structural girder inside a structural fuselage should work too) to limit partcount - you don't need to have both elements of the joint rounded - counterweights can also work too instead of separatrons (the physics engine is accurate enough for that)

a note on the Sputnik history it's not the satellite that was visible from the ground it was the much bigger R7 Core stage that was visible from the ground, which was also in orbit (as sputnik had no propulsion, the core stage had to accelerate to orbital speeds before separation ) - they even installed deployable reflective panels on the stage to help tracking it

mmh. Be careful on physical collider count - the game performance in Unity 5 is affected by the number of colliders more than the number of parts now. (the more colliders present, the longer the 'freezes' will happen upon vessel loading) so even welding parts won't help much in those cases - parts with complex physical collider shapes (like the hollow structural fuselage) are made of lots of simple colliders instead of 1 complex. (that's one of unity 5 changes) still, good luck with the modded ISS

texture remap on the fairings of the soyuz booster? nice

the version assembled in editor then hyperedited into orbit is not meant for anything else than pictures it's very shaky - even with SAS disabled ! I Don't really know if it's because of cpu usage or something else though - the version assembled up to P6 is not shaky at all, even under SAS, so it's hard to compare

sorry there's going to be some delays for the follow up started an IT learning course, and it's taking quite a big chunk of my time at the moment (for the next 9 months !) so i won't be able to push up so many vids like i did before i started the course.