dnbattley

The topic of zompi- (it's perhaps a shame they couldn't have been "fish"-) drives is going more mainstream, with SWDennis' recent video on the topic. I should probably also highlight my own YT efforts to explain the drives, from a few weeks back:

Good spot. And this was even earlier https://kerbalx.com/Fishanator/Test-Phantom-Drive. I suppose it goes to show that PR really does count for something... Nice! It certainly does make for very satisfying aircraft for flying. I probably had the most fun flying my Enterprise craft (https://kerbalx.com/dnbattley/USS-Enterprise-NCC-1701-A) as I have had flying anything in KSP ever...

It turns out Blender offers really good green screening where you can match the colour you are keying out very precisely, and then tweak to e.g. feather in the edges, so it was quite simple to avoid cutting off the face.

Yes, it's just a simple custom flag I created

Behind the scenes:

It does, but it's not without some issues. Ideally, the docking force would be modified by being bound to an action group, but that isn't possible, and varying the force by moving on a piston is both non-linear, so far as I can tell, and surprisingly difficult to "turn off" hence my preference to use the inflatable dock. It's also a good force for small vessels, is ok for medium-sized planes, but it doesn't scale particularly well, especially if you factor in the control mechanisms. That said, it's a great addition to the portfolio

The excitement started here: Quickly, a few people began to work on this and develop a number of craft of varying complexity: My own additions to the pile-on were two fold, an initial test craft: https://kerbalx.com/dnbattley/zK-Drive-2 Followed then a more developed vehicle: Which is now slightly further refined (though not yet released) as a fully functional VTOL:

Just point me in the direction of the flags! In the meantime, I created a catalogue page for the army stencil font decal set I generated to use recently:

I've found it quite useful to create "catalogue pages" of decals which are then easily shared via Imgur (e.g https://imgur.com/AgJXcIw ), but a side effect of this process is to automatically resize decals to the preferred size of 512x256, if you want me to assist you on that.

Thank you! I put the model together in as modular a way as I could, which was necessary for the times the KAL bugs out and forgets all its instructions... The way to dissect it is, 1: offset the large servos outward, 2: move the octagonal piece upwards (this exposes the "fixed" supports that the sides rest on when static), and then 3: look for the side of the motors that selects all three axes and offset this motor - this will separate out one of the moveable cubes (either edge or face), and all sets of 3 axes motors were deliberately oriented the same way. Provided you keep the offset on grid mode everything can be offset back into position, and it was this precision that allowed the gimbals to work. I now have a save game crammed with subassemblies for all of these parts I put together...

Thanks! And sure thing: I've posted the craft file on Kerbalx https://kerbalx.com/dnbattley/Rubiks-Kube, if you want to take a look. It is fully stock (plus DLC, naturally). The version there is slightly upgraded from this with control added via action groups. In terms of operation, it abuses the self interaction toggle functionality to make this a single craft (no docking ports/decouplers) using tiny servos (the most "cubic" pieces in the game) as the fulcrum, which rotate each piece (these in turn are each attached via three unmotorised rotors to give full 3-axis movement), with further guide parts fixed to the core, and also to each side servo, becoming "active" in turn depending on whether the piece is moving or not moving at the time. I originally tried making a version based on the real design of a cube, but this approach had significant benefits in terms of part count and controllability.

For your predilection:

Those interested in acquiring KSP on sale might be interested in this site.

Landing on Tylo from 70km unpowered is, unless I've missed something, going to need some form of physics exploit to achieve successfully. My first thought would be Kraken tech, but frankly that would make the challenge too easy, and it's not clear to me whether that sort of exploit is going to be legal per the terms of the challenge. My second thought is to exploit the infamous wolfhound impact tolerance. Was that the intent of this comment?

Neither, really: the surface scanners rotate with a relatively high torque but no electricity usage, so I've contained them within two plates with self interaction and then use gears to step up the rotation speed, which directly powers a "wheel" of friction plates. It's conventional physics, so not what I'd call Kraken tech.

+1 for finding a way of dealing with the easy sharing of files here. I've seen similar discussion on the reddit channel too, and have had some thoughts that I hope might help: 1. The most effective way of dealing with decals seems to be to treat them like a mod (and this in turn may imply that CKAN should be involved here), i.e. store them in a subfolder (of any name) within GameData, in a further folder named "Flags", to allow them to be more easily filed. This allows some separation of flags into groups, but we may not necessarily wish to encourage a new folder for every set of flags as this might rapidly become unmanageable. Nomenclature of the decals is important when selecting them in game, and to ease categorisation and avoid overlap so we should probably seek to encourage people to use a "category_name.png" nomenclature in their designs, e.g. USAirForceFont_A.png - and we may even have a way of controlling/enforcing this (see later). 2. All decals are required to be identically sized (512*256 RGBA-encoded PNGs): this is helpful to us. 3. It is relatively straightforward to "mosaic" these decals automatically using, for example, imagemagick ls *.png >> names.txt montage *.png -geometry 512x256 -tile 4x -alpha on -background transparent combined.png (there is no particular need to tile them, but it does make the file look more attractive to me, particularly if people will be reviewing these, like a catalogue - and this may be the best use case for the KerbalX site) To uncombine them: convert combined.png -crop 512x256 +repage +adjoin temp_image_%d.png awk -F, '{ system("mv -v temp_image_" FNR-1 ".png " $1) }' names.txt (noting that the above command does destroy EDIT: now restores filenames - see #5) 4. A single image may be simpler to view/share/store, provided there is an easy facility for users to split: again is this a role for CKAN (or some other meta-mod), or could the montage/conversion be done on the KerbalX server side? 5. A secondary text file could be used to store the names of original filenames and this could be referenced in the splitting process. This is the point whereby we can also enforce a nomenclature standard, if we wish. Depending on the number of people sharing flags, this may be more or less important. I hope some of these musings are helpful.

A slightly silly entry: with a top speed of only 4 m/s or so, it will take some time to reach any given destination, but the main attraction is an infinite range due to the lack of any actual fuel requirement: a somewhat unnecessarily complicated gearing system enables independent 4 wheel drive, powered by surface scanners, and an aileron enables steering.

I think you are over-thinking this. Is there a specific exploit/technique you wish to use to compete in this challenge that you want to discuss?

When you do this:

This isn't my challenge, but I'd suggest: yes; yes; yes; no. Stratzenblitz and Brad Whistance both know (and usually say) when they are exploiting the aero engine (usually by, e.g., stacking components in an odd order and then offsetting back into a "normal" position). My hypothesis is that you can't really "accidentally" do that sort of thing, though would admit there could be greyer areas (e.g. physically attaching fins to the back, rather then the sides, of a rocket to try and gain an advantage) that may be hard to police: hence recommending an "honour" system... EDIT TO ADD: therefore, the "non-grey" rule might be this: no <mod>-offsetting?

@Pds314 This is some great research, and thanks for sharing! In my earlier ship I had to put tiny grip pads at the bottom for the collision, so it may be that some but not all flags have border collision: but conversely that factor worked well for the flame effect in the video...

If it was ever considered feasible in real life, even if not ultimately used, then I think most would consider that to be a "conventional" rocket, but if you still don't feel comfortable with the challenge then I would politely suggest it may be preferable to avoid it rather than aggressively questioning a newer member of the community.

I think the intent of OP is reasonably clear, and perhaps the simple solution here is to require kerbal g-force limits to be enabled to preclude decoupler/kraken drive forces, with an honour principle not to deliberately exploit the aero physics engine?

Also, perhaps, due to their life ending potential if activated near any living beings...