Stevie The Crusher

Topaz is done, and I've started my Nanocrystalline Diamond WIP with slightly different settings than Physics Student, in order to force good comm-sat coverage. It is very slow, like others have found, but I think it will pick up a bit when I unlock survivability and gain access to drogue chutes. That will let me deal with the common sub-orbital tourism contracts, even though I'd prefer to just hammer away at surface part testing. I don't think I'll be able to afford Aviation before finishing KSC Tours with Baro and Mat Bay, so I'll probably end up just rolling around the craft itself until it's time to start voltron assembly projects. I've found using an alternate sandbox save for prototyping is useful to keep your kerbals alive, and impatience is very bad for them. Generally using smaller and more stages allows more in-flight flexibility, at least until you can use liquid engines and throttle. My general strategy is to make enough credits and science to put together two docked craft, one for the runway and one for the water, that have all the parts that can be tested docked on them. Switching focus to one of these craft completes testing for any already-tested parts that are present (repeat contracts), as was discovered by players in one of the previous caveman iterations. Once I have that kind of steady income, I'm probably going to go setup the overkill comm-sat constellation, and start building temperature survey satellites for Mun (orbiting at 12km and 8km for high and low). With relays fully covering Mun and Minmus, I'll be free to start landing. I'm still debating my surface science strategy, but I think it will be necessary to figure out a kerbal cage and send Bob with a big refuel-able lander in order to get enough. If that isn't enough for full completion, I'm probably gonna do the math on long range relays (they will be big) and then go interplanetary.

Here's my progress update for my Topaz WIP. Complete! This is my next iteration on my rocket, though the staging still failed. I did solve the instability between booster core and payload by setting all parts involved in that custom tri-coupler to rigid attachment mode and with auto-struts (I think you need advanced tweakables turned on for this). With that problem solved I can make the core more complex and finally add the proper radial decouplers in, though they'll have to have crossfeed activated. I'm still learning new things about lawn construction, but I'm getting a bit impatient. After topaz I'll probably skip right to nano-diamond. With most of the settings the same across those, they'll have a very similar feel. I've found that in my current game I need a relay network at Minmus to continue exploration (sun and Kerbin opposite each-other), and I've decided I'll be better served just dropping a lander on Mun. Most games I start with Mun for the sake of travel time, and I now have the construction techniques to support that with basic facilities. I was kinda hoping for the 'complete everything' badge, but I'll settle for nano-diamond if I finish that. Out of curiosity, what's the "This level coming soon" after nano-diamond about? Just a placeholder? It would feel silly to start nano if there is something more challenging. Edit: Topaz complete!

Yeah the explosions happened on my end when I was still trying to dock crawlers underneath things, and the landing gear caused it to bounce up when unfolded (see apatite album). As for alignment, if the standardized "this many parts high" system doesn't work for you, I've found "merging" in a ghost of your crawler inside the editor load menu to your core stack gives you some idea where it will end up. For LY-10 gear under ~10 tons load, you would sink the ghost into the floor until just the top of the wheel is showing, to account for compressing the suspension. You could also make a mock-up connection on the runway, then calibrate your core stack to that new height. On my end of things I'm finally getting comfortable not having reloads. Means designing abort functionality into craft, and so far that has kept me from multi-mission flights. Part count and weight budgets mean more when you have to survive something going wrong. I've also had to do profit contracts for the first time, to have buffer funds in case of relaunch. I'm probably gonna see how far I can get without lawn assembly, before trying to optimize the rocket from vanadium.

Vanadium complete: https://imgur.com/a/T2l0V I managed to build a rocket as described in my last post; assembly pics are in with this run. I ran into staging troubles, but still made it to orbit fine. I guess we'll see how far I'll go up the difficulty ladder before getting bored.

Ahh I never got around to trying this before, but this time I will. I've been trying to optimize my early game career play and trying this has already provided some interesting insights. I'm starting at the bottom (Talc) and working my way up, so here are my first two: Talc: https://imgur.com/a/N6SfI Apatite: https://imgur.com/a/zrEKc I'm working on Vanadium right now, and the lessons on efficient science gathering from the others is making things go fairly smoothly. For assembly, I have an idea that I think might work better than the one I tried in my Apatite playthrough: Build a mobile support tower on the lawn that can hold up the rocket parts vertically, and add them to each other's sides with a crawler. Doing it this way removes and launch clamp mass concerns, and could allow 6-way symmetry on the booster core, if you start construction with one of the side boosters. It would also free up the launchpad, making delivery trips shorter, or maximum part size bigger. I'll probably have something like that in my Vanadium submission when I complete it.

I was kind of surprised these still worked. They even managed to kill the landed magnet drive, yet not multi-entity pushing stuff. I'm glad you don't need to have a blob of panels like I did last time, makes for much more manageable systems. Why did you choose the service bay? In my past experience they tend to be fragile when using part clipping. (I guess you added struts to compensate?)

That thing, is incredibly sensitive to changes. Works, and I'll definitely be tinkering with it some more. With the multiple drives, are you attaching them together from the bottom? With the way you have the batteries setup it seems attaching them together from the back (having the drives on the front of the ship) would provide more output than if you did it from the top of the drive and had them behind.

Did some more testing, and with enough SAS to generally maintain control, my cube cage design seems to average out at about 4G. It can do 10G bursts, but I've yet to figure out how to make that consistent. Increasing the gear force on the cubes increases the needed SAS, which tends to just balance out to the same G-force afterwards. Loaded up an old craft file for the JD drive, still works. Did some tuning to get it working in orbit again, outputs 14.5G with my test rig. Adding any payload creates rather abrupt diminishing returns on the G-force and reliability, so only useful for personnel and data transport I think. JD Drive vs Mun JD Drive Craft I also tried to remember the old requirements for K-drives, and I think I got it back. You need three things: a suspension part (force), a clipping part (glitch activation), and a pushed part (counter-force). The old designs have a leg ghost through a panel and push against a panel/dock/adapter/SAS. If you apply too much force it can break the leg. If you overly reinforce the pushed part, it can break the leg. If you attach things to the pushed part, it can break the leg. The reason gear have trouble working with this layout is because of the lack of leeway in the suspension column to fit the clipping part. My cube apparently got around this by changing the clipping part from clipping into the suspension, to clipping into the pushed part. So technically my cage acts as the pusher plate, and I have confirmed attaching things to the bottom of my drive is an even worse idea than doing it with the leg drives. Small gear are durable, they are the last part on the ship to break when I did it. Boom. I tried to use this concept to reduce the part count of the clipping part to just a single plate, but you need more than that if you want it to clip, and also stay contained. Might be able to use a single plate if you stand it up and push against the edge, more testing required.

The first Kraken Drive development was super fun, but I mostly just tweaked what other people had going to get results. This time I went a little farther. I have revisited old styles, these are what I managed to cobble together: (Was building in 1.0.4, realized I needed to update. Re-did testing on these craft, still work the same.) Push Plate Functional and very stable in atmosphere, but no effect in orbit. If it stops working, reload client. Push Plate Atmos Push Plate Craft Scanner Research The narrow band scanner can indeed collide with things and spin them, though not for long with this quick setup. Needs work, and a way to convert that rotation into acceleration. Some potential for driving props on helicopters or planes. Scanner1 Scanner2 Scanner Craft Push Spinner Looking though the old K-Drive thread, I found a drive by sgt_flyer. Rebuilt a version of it, confirmed it still generates a small acceleration. Miniaturization efforts resulted in mixed results, typically with large G force happening when the rotor jams. (this version doesn't spin constantly, you need to add a slight depth offset to each drive gear until they all push on different plates. I added that in a later version) Spinner Spinner Craft Push Cube This is the one I created and have been working on. It takes the concept from sgt_flyer's rotor blades, and makes them work from any orientation. Kraken Cube Kraken Cube Sub-Assembly The resulting structure is highly sensitive to anything clipping inside it. Since it works from any direction, I don't need bearings, but can get away with a small cage. This is my current stable version: Push Cube Atmos1 Push Cube Atmos2 Push Cube Orbit1 I was trying to hit mun, but I missed. Steering this thing is difficult. Push Cube Orbit2 The properties I've found so far are interesting. It is perfectly reliable, in that it will always turn on when you lower the gear. It will never break, as the force the gear push into the cube with has been tuned so the G-force spikes are within the cage's tolerances. However, the force produced changes constantly, and aims in a wide arc. You need an absurd amount of reaction control to keep this thing pointing even vaguely in the right direction, and the more force you try to generate by squeezing the cube farther makes the problem worse. I've found that you can roll the vehicle while your SAS steers to allow something approaching control. Push Cube Atmos Craft Push Cube Orbit Craft Here is the next revision 'cage' I have been working on. Higher force output, but it very often tears itself free of the craft and goes on adventures without me. Push Cube2 Atmos Push Cube2 Blooper1 Push Cube2 Blooper2 Push Cube2 Atmos Craft Push Cube2 Orbit Craft I tried with only one gear at one point, but without the other random forces in play to average out the force direction to forward, you get a lot of lateral movement going on. Miniaturization is going to be difficult, this thing isn't exactly light on part count. The smaller you make the cage, the more focused the forces are towards where you're pointing, but also more likely that the cube escapes, and goes flying off somewhere. If you try to exceed the force limits of the cage, first the force spike will destroy every connection on your craft that is weaker than the cage, and then the cage will burst. Basically anything using this above 10G's is probably going to need special construction, rather than relying on part connection nodes. Even with struts, i'm pushing those regular connections to their limits already.