swjr-swis

"Mark Watney... Space Pirate." <looks pointedly into camera>

Oh and a belated welcome to the forum.

It's basically a high eccentricity polar orbit around Ike, with an eccentricity of 0.001 too much. Result: a slight gap in the orbit right at the top, where it temporarily escapes Ike's SoI. Temporarily, because Duna, being the quintessential big brother, immediately catches the escaping relay and pulls it in towards itself, in the process slinging it back into Ike's SoI. The only reason it looks like it ends up escaping the dance is because the patched conics shows a limited number of patches... in reality it goes around and around a couple of revolutions more. Just a few. Ike: "Mooooooom! Duna keeps throwing the relay back at me!!" Duna: "No I don't!" <whisper> "Why are you hitting yourself with the relay?" Ike: "MOOOOOOOOOM!!" Kerbol: "Stop it! Don't make me turn this solar system around. I *will* turn this around!"

The thrust limiter is an artificial limitation imposed by the game editor, forcing fixed 0.5 steps. Nothing stops you from manually editing the craft file (or if you've already launched it, the save file) and lowering that limiter to say, 0.01%. Search for 'thrustPercentage = 0.5', since that's the value you have on it now. That should at least give you more time to react for the cut off. Not sure if it will help to show the maneuver time though - at some point the values become so small the in-game code simply shows zero regardless. For future reference, if you wish more accurate thrust for small probes, try using monoprop and either one of the small RCS thrusters - 0.1 Thruster power, 20x smaller than the Ant.

Nothing so nefarious. Just Duna and Ike playing a game of "Catch, it's yours! No, you! No, YOU!" with my poor dizzy relay.

Psst: double that. 2 π * 600 km radius. Actually 607 km, unless you plan to phase through mountains.

Playing around with relay orbitals, the following appeared: Go home, relay... you're drunk.

I imagine because a resource container that runs empty at one point doesn't necessarily stay empty from that point on, so it makes sense to allow continuous requests if at some point one could actually provide the resource again. An easy to picture example: Battery -> lights. Lights turn on, start requesting EC continuously at say 0.1 EC/sec. Battery sees those requests and tries to provide the asked-for EC, until the battery runs out. Lights keep asking EC but get 0. Now consider that this is a probe on the night side of a body, and there is a deployed solar panel on-board. Dawn arrives and the solar panel starts producing EC. If the lights are allowed to continue request EC, the EC can now automatically be provided again and the lights turn on again. Bad example maybe because in KSP1 engines and lights simply switch off entirely when the required resource flow stops, forcing us to re-activate them manually. But it works that way for probe cores and reaction wheels: both need EC to work, stop working when no EC is available, and automatically start working again when EC is generated again. I'm hoping they will consider allowing all resource using parts to work like cores and reaction wheels, and stay 'switched on' to start working again once the depleted resource is available again. Hmm. Forum playing tricks on me again. I thought I was responding to the just created post in the Devs insight about KSP2 bug thread. Apologies for the necro.

I would advise you to run a few simulations/trials, in a separate sandbox save if need be. You need to get a feel for how long it takes to slow down enough for a controlled landing, how long ahead of the intended landing spot you need to start your burn. On a low orbit around Moho, you'll be going around 800 m/s. That's horizontal speed you need to kill with the burn. You will also gain some vertical speed purely from gravity alone, which also needs to be countered - the longer you 'hover', the more you need to burn. Don't underestimate this: on three Ants this is likely to take a burn of 2-3 mins (!). That whole time you'll be falling, so don't start from too low an orbit or gravity will have you before you even had the chance to kill your orbital speed. Doing this with 840-870 m/s would require picking a flat area and executing a near to perfect suicide burn with a high TWR craft. I would not recommend it if you've never done it before; even the 950 m/s suggested is likely on the low side. I can't stress enough my first recommendation above - try it out a few times and you'll get a better idea of how much you may need. I would keep the landing legs; it's only 45 kg for the three, and they up your safety margin a good bit compared to landing on the engines. I do agree with not needing batteries. In fact, you can do without that 0.625m reaction wheel too - the HECS2 includes a strong reaction wheel as well. You will however need a good antenna, or a strong relay in high polar position to keep line of sight with both your probe and Kerbin, or you risk losing control at the wrong moment (assuming you play with CommNet and requiring connection for control).

Ok let's start you off with a lightweight entry, the MinCN-1885 The MinCN-1885. 16 parts, 1.885 t, single Juno, single seat. Jeb standing ready, all of 91 units of LF in the tanks. Cruising mach 2 @ 11.5 km. Halfway point. One full circumnavigation later, back at the KSC runway. Full album: https://imgur.com/a/bRtYrpu

Or.... and just throwing this out there... just bring all the pieces you find together to 'organically' grow your very first space station. A space station of lost and found spacecraft parts. The Lost and Found Space Hotel. Come stay a night at our growing collection of quaint abandoned pods of mysteriously stranded kerbals. <starts walking off talking to no one in particular> Some say, when you're really quiet -and space is really, really quiet- you can still hear the screams for help of the former occupants when they first realized they were marooned in space. <rubbing hands> Yes... yes I can make this work. They'll be lining up for tickets! Muhahaha! <stops and looks suspiciously over both shoulders, then scurries off>

Aliens. The ones that left all the anomalies for our current-day kerbals to find.

Big ship with lots of stuff going on, but I can't see anything that's a dead giveaway for phantom forces. So I figured I'd test launch, but I can't even get it to launch without exploding. I assume it's meant to be cheated somewhere into the ocean before launching. I tried that, but before it settles down enough to launch, it just topples over and explodes halfway down to the water - apparently because the reaction wheels drain all EC within seconds. The staging order also seems wrong - decoupling order that can only lead to explosions if it did manage to lift off. The craft description and the upload page give no launch instructions; not sure if I'm missing something crucial here. Since I can't get it to launch to test and don't understand the intended working, I have no idea which section of the ship even gets to the point where you mention having the issue. Can you check to make sure you have the upload correct, and/or add a little explanation of the intended launch sequence?

@jimmymcgoochie already offered alternative suggestions, worth noting. to still answer your questions directly: Yes, engines attached to rotors will keep running when or after rotating. No, no fuel line is needed - as long as a part doesn't explicitly mention 'no fuel crossfeed', KSP considers all parts to include invisible internal fuel conducts. Fuel lines stretch pretty far, usually more than is practical. They also don't care about stuff being in the way.

Hi there, welcome to the KSP forum. You're going to have to be a bit more specific, I'm afraid. KSP is notorious for having 1001 ways to generate phantom forces, intentional or not. An image is likely not going to be enough to diagnose this - it's hard to see if parts are placed/clipped/configured in just the kind of ways that might have this effect. Try uploading your craft file (kerbalx.com, dropbox, google drive, etc) and post the link to it here.

Cautiously confirming this. A change in the image host interface seems to have been the cause for that one. It doesn't retroactively solve the missing thumbnails of pages uploaded during the error window, so for those pages please try to manually refresh the thumbnail image (in edit page mode, click the tiny thumbnail image at the top beside the title and reselect the desired image). Or if you had no image on the page as a workaround, you can try adding one now. Thanks everyone for your patience so far. Agreed!

Not if you drain their ablator first. There's only one 'real' wing part lighter (basic fin) than a drained 0.625m heat shield, none of the control surfaces, and only the smallest of the prop and duct blades. Also makes it the cheapest and next-to-lightest separator/decoupler option, btw.

It's connected with the current issue. At least the craft pages with a missing thumbnail work and the craft file is downloadable; other craft pages just don't work at all and show the 404 error page. No news to report on this yet.

Barely. I think the regular drag force applies to the base of the blade or very near to it. At that point radial speed is minimal and so is the drag calculated for the blades = minimal torque required to get/keep them moving. Which is my point: The optimization is based on moving the drag point to get as close to zero blade drag as one dares so the readouts still show a minimal EC usage and the divide-by-near-zero flight range goes through the roof. But since it's a continuous sliding scale, a micron more and it's now in infini-land. Proof is in the pudding. I just exaggerated it to show the issue clearly, after you both stopped at the edge of it going into 'negative', while your previous series of entries show the range growing exponentially at the blades moving inwards.

@camacju explained it ealier in this thread: On regular lifting surfaces, all force vectors (drag/lift) act on the same point. On prop blades, the point of action for lift/thrust was moved somewhere far outside the tip of the blade to artificially enhance the generated thrust and make props more playable. In a default placement it works as expected, but when offsetting the blades inward the drag point moves to the opposite side while the lift point, being way out there, still stays in the 'correct' side. Instead of the airflow causing a drag that slows the props rotation, it's now accelerating the rotation, ie. magic torque that doesn't require rotor EC usage. Offset it enough and it becomes enough to not need any EC at all anymore, as long as there's an initial bit of airflow started.

@18Watt: did my last entry not meet the criteria?

I hate to be the party pooper, but yes, I would call this an exploit, because yes, there is absolutely free energy being created. Proof, with a plane with a relatively poor cabin drag-optimization compared to the other two entrants. The only improvements it introduces are the better choice of wing part and a system to almost nullify the vibrations that kill SAS, allowing me to simply use SAS on ORB PRG to let the plane fly itself: Two rotors set at max size/power and max RPM, with two of the smallest duct fan blades each, liberally offset inward from their default to clearly show what's happening. Used all my EC simply getting up to speed and in the air. This was hands-off, ZERO management of blade deployment, rotor torque, or RPM limit - all I did was release the brakes. 25 mins later, the plane is still at (over!) max RPM and climbing, 79.5 m/s at almost 9 km altitude. I didn't feel it necessary to wait a day to see if it will circumnavigate because obviously it will. And being completely stable in flight, it doesn't even need watching. Just to make sure, this time I went and LOCKED the battery just after take off. Same result. Plane will keep going as if nothing's up and will obviously do so indefinitely. I have literally done nothing but close the fore bay, set SAS to ORB PRG, and released the brakes, zero prop/rotor management or even flying. Let me be clear: I am a strong proponent of Applied Engineering in KSP, and I have zero issue with putting this to good use. But let's call it what it is: what we're seeing in this exchange is really just 'infini-props'. We can pretend it's not, but it's really just about how far we dare offset the prop blades inwards, allowing an arbitrarily low EC usage to keep up torque, passing through literal zero, and then even becoming 'negative' since now the blades are basically creating their own torque (once the craft gains a bit of speed). Craft file for anyone wishing to peer review: https://www.dropbox.com/s/eit1qdj09wf412c/SWiS TinyProp 3.craft?dl=0

Thank you but no. All I did was a refactor to make the craft comply with the stock part rule. If you're gonna put it on the leaderboard do it under @Poppa Wheelie's name, please. Maybe I'll make an entry of my own when I get time. Carry on.

To make up for compromising your entry, I redid your craft to meet the stock parts rule (octo 2 core, battery, and reaction wheel, stacked on the bottom node of the engine and clipped up into the tank), and improved a bit on it with a different tank size and staging strategy. The resulting craft now gets to orbit with 3087 m/s left in the tank.

This is from the KSP Community Fixes.