FleshJeb

Ever wanted to use a cosmic string as a planet-blender? Invent intelligent biological nanomachines that multiply in such quantities that they can alter the universe by observing it? Or just have mysterious planet-sized space clouds that travel through the galaxy in waves and annihilate anything that looks like a civilization?

When 6000 hours you reach, feel this way, you may not.

Looks like a waste of RAM and processor cycles to me. Make the physics engine bulletproof and it could be wireframe for all I care. (Still holding out for Borderlands-style cel-shading though.)

Nope. That's another problem. Control surfaces will flop direction depending on whether the axis of the surface is pointing ahead or behind the COM of the craft. I think I saw in your other post that you were using the angled elevons--That might be the problem. Try different ones.

The fuel cells will automatically turn off when your batteries hit 95%, so it's better to bring too much than too little. Power consumption is complex because it depends on the ore concentration, and what level of engineer you have on-board, if any. Here's a thorough guide. I believe they cut the drill elec consumption in half since this, but that's easy enough to check and plug in to the equations:

Look at the difference in max torques. I believe they're identical, except for the shaft diameter. Of course this might make your prop radius smaller, and the S has less volume, so it will be less buoyant. There's an issue with deploying control surfaces, where if you edit your craft at all, the deployment can invert when you load the craft to the flight scene. It's weird and it sucks. The solution is to just hit the "invert deploy" button on the relevant surfaces in the flight scene. I hope this is what you're running into, anyway.

I agree with @18Wattwith a couple of additions: I find anything less than 4 blades can be a bit jerky. I don't know if that's the physics engine or what. It's somewhat reflective of real life. The goal is to maintain maximum RPM possible because that results in a blade angle that's more perpendicular to the direction of the craft. The steeper the blade, the more thrust they waste pushing sideways, and the less they push backwards. Of course, you'll need a minimum amount of thrust to break the water "stickiness", so that may require more blades. General submarine advice: A submarine is just an airplane in a medium that's 1000 times denser.

They’re both pilots, but Val has mods and a much higher G tolerance. Also, she respawns after 2 hours.

@Isidro22 That's a very workable solution. For testing, I'd put torque, RPM, and AoA on 3 separate KALs and control them with the onscreen sliders, so that I can see the interrelationships. Or you can use the throttle and the RCS keys to control the KAL positions. Once you've got some data points you like, you can put all three on the same KAL and control that with the throttle. There are a lot of good ways of doing it, so pick whatever scheme works for you. Remember also that you can reverse the rotors independently with action groups, as well as toggle the deployment or reverse the deployment of the props. Good for rapid stops and tight turning. I would definitely ballast it more (good pun). Of note, water impacts don't get calculated until the attachment point of the part passes between air and water. For control surfaces, I think that's the midpoint of the fat edge of the part, so if you've got the topmost one just over half submerged, you won't have to worry about it any more.

Do you happen to know how this works with the cargo bay, etc parts? I know we should occupy the internal nodes, and I always assumed that one should use the next size down. What about heatshields? They have three nodes, so which do you have to occupy? (I actually never use heatshields and just pull heat out of normal parts heat with high-heat transfer parts.)

The aero parts function with the same parameters in water as they do in air. Max lift at 25 degrees AoA, max lift-to-drag at 5-7 for supersonic, 3 degrees for subsonic. It sounds like your props are sticking partially out of the water to start, and then getting destroyed on impact? KSP has some funny stuff going on with water impact. For a perfect zero-AoA entry they should be able to take 3x their impact rating (15m/s for control surfaces?). I believe this impact resistance gets reduced with the sin of the angle. (I could be wrong, so folks can correct me.) What I would do is build it with the surfaces flat to the disk, and have them set on deploy at 0 degrees. Start with a fairly low RPM, and slowly increase the deploy angle and RPM until you're moving. (What's the "unstick" speed of KSP water? 0.4m/s?) If you didn't know, optimal deploy angle depends on the speed the craft is moving. The prop blades are drawing a corkscrew through the air/water, and that corkscrew gets stretched out the faster the craft goes. You want the blades to have an AoA relative to that corkscrew (say 3deg). Generally speaking, aim for the maximum RPM at all times, and adjust your deploy angle to preserve that. I haven't done an electric sub yet (I just know entirely too much about KSP physics), so I'd love to see the eventual results.

Some of the information on this is a bit out of date, but this should help you calibrate your instincts: The gist of it is that for most vacuum worlds and LFO engines, an initial local TWR of 2-3 is most efficient. Places with higher dV requirements favor the higher ISP engines and lower TWRs.

Off-topic: I like to joke about KSP still being in Beta, but I may have to revise that to Alpha. To play effectively, one has to maintain a robust knowledge of the outstanding bugs and their workarounds, if any.

"Neigh!"

https://pacificcoastairmuseum.org/ Pima looks amazing--Certainly much nicer than PCAM. I've chatted (online) with one of the volunteers at Pima--Former F-15 pilot and a fun dude. http://pwoodford.net/blog/?p=25353 --- @kerbiloid Go look at western Nebraska and Kansas, northern Texas, eastern Colorado, and the flatter parts of Idaho, Washington, and Oregon. Thousands of circles.

Interesting thoughts. Robert Forward's plan was 20 years of pushing to 0.2c, then coasting for 20 years, then braking by detaching the outer ring of the sail. Short version: https://en.wikipedia.org/wiki/Rocheworld#Forward's_light_sail_propulsion_system More detailed explanation: https://www.centauri-dreams.org/2013/08/20/key-issues-for-interstellar-sails/ First page of the actual paper: https://arc.aiaa.org/doi/10.2514/3.8632 Looks like @MatterBeam also covered it at some point:

Had some time to myself on Sunday, so I parked outside the fence of an air museum. See if you can name the aircraft. I always forget how absolutely huge these things are in person. Teaser pic, the rest spoilered below: EDIT: High res here: https://imgur.com/a/12kS0m5

If you're riding a laser sail, you could regularly displace from your path (or close the sail), and let the laser cannon(s) in home system clear the way. That should accelerate any small particles in your direction of travel, although I doubt it would vaporize them outright. Any overspill around the sail during regular travel might even be enough to intercept most things crossing your path. You'd certainly know by the reflections if you were going to run into a dust cloud. You could even find the relative velocity by reading the frequency shift from the bounced light. It pays to have your propulsion system also work as a sensor. I imagine mitigating impacts is more about the total rate of impacts and magnitude thereof, rather than avoiding them entirely. The question is: Does the laser cannon in home system put out enough power for this to be an effective mitigation strategy. Is the acceleration of the incident matter significant? What power level is required to also ionize the incident matter? It would require A LOT more than having it onboard, but what a mass-savings. If anyone feels like doing the math for that one. ;-)

@richfilesSomehow I missed the notification. I don't disagree with anything you said about Autodesk. I live within driving distance of their headquarters, and the number of times I've wanted to throw a brick through their window is uncountable. I've seen some REALLY impressive modeling done in SketchUp, but it doesn't suit my needs, so I haven't played with it. I took a look at the FreeCAD manual and I found a couple of things that might help you along. For snapping to the endpoints of lines and such: https://wiki.freecadweb.org/Draft_Snap How to input relative coordinates (press R to toggle): https://wiki.freecadweb.org/Draft_Coordinates If there's anything I can help you with, free to hit me up here or in a PM. Since I have a decent understanding of the CAD paradigm, I might be able to point you in the right direction. The last time I did what AutoCAD calls "solid modeling" was 1994, but I remember the basic concepts.

I wish it was all shunted off to a separate crew-management interface, accessed by a single button on the PAW, and/or one of the mod buttons on the right. The whole inventory system is not a level of granularity I want to manage AT ALL, and I think adding it to stock was a mistake.

Median home price in my area is $700k+ I could actually afford to buy a $250k rocket engine and live in the bell. The HVAC system might be a bit over-specced though.

The ridiculously small size of the solar system and celestial bodies in KSP doesn't provide a good use case for orbital fuel stations. In the majority of cases it's cheap enough to travel to and land at mining station nearby. This also reduces the amount of player time and shuffling of craft. Kerbin options that I've used and enjoyed: Launch to LKO and use the onboard fuel to go to a mining operation on Minmus flats. Launch fuel from Kerbin on reusable boosters to an orbital station, then land the booster. It's very convenient from an operational perspective. Catching asteroids and bringing them back to Kerbin orbit to be mined is also an amazing amount of fun, and a good challenge. Low Kerbin Orbit is relatively expensive to rendezvous around, unless you get into aerobraking, so it's not really worth mining and bringing fuel back from the Mun or Minmus. Places where I might put an orbital station: Low Eve orbit, if I'm returning from the surface: Fuel would come from Gilly. Keep in mind it doesn't necessarily have to be a permanent station. Many times I'll just use a space tug that hangs out for the duration of the surface mission, and then drags them both back somewhere to refuel. Laythe orbit: Refueled from Pol or Vall mining. Pol is slightly cheaper to run fuel from, Val is more convenient. Temporary tugs can hang out over Tylo. There's also a good use case for mining Laythe surface and refueling an orbital station with airbreathers. Dres orbit: Grab some asteroids. (I actually haven't been to Dres since version 0.25) Moho orbit, refueling from Moho: If I were going to do more than one mission to and from Kerbin to the surface, it makes sense to break up the massive delta V cost of that mission there. Places where I would just surface mine: Duna: It's cheap to get to and from. MAYBE mine Ike and refuel on the surface. Don't bother repacking chutes, the air is too thin to bother. Just land propulsively. Mun: Same reason as Duna. Eeloo: Unless you're going to build a full colony there, don't bother. In any case, I hope you have a lot of fun, and you should do whatever inspires you. The small size of the system ALSO means very few solutions are actually terrible, so experiment as much as you want.

In addition to J's excellent advice: Don't look at your ship, look at the navball. The stock one has all the information you need except for distance to target and rotation, and for most docking, you can ignore rotation.

That's a trifle reductive. The core benefits of AutoCAD in the professional setting are sustained drafting speed, dimensional accuracy, as well as ensuring that the accuracy of what you're modeling is maintained. Command-line input is EXTREMELY fast (and RSI-friendly), as well as being explicit--Everything executed is intentional. This comes at the cost of memorizing approximately 300 shorthand commands, and benefits from autocomplete. AutoCAD is so fast and precise that I actually prototype my Factorio builds in it prior to rebuilding them in-game. (Even considering the instant-build sandbox mode.) For me, what defines "professional" is not being able to produce a product, it's being able to spot when things are going wrong, knowing what to do about it, and figuring out how to avoid it in the future. This means creating and adhering to best practices and workflows, and modifying them as necessary. If you want to see what unprofessional modeling looks like, I refer you to the multiple rocket engines in KSP that were modeled with the thrust axis off-center and published without that being spotted and corrected. Things you can't do in Blender or Sketchup: Below is a model of a boat ramp and the grading necessary to tie it into a model of existing terrain (not shown). There are a couple of minor flaws in the model (I didn't build it), but it's good enough at this stage to do the necessary volume calculations with. Every dimension and slope meets strict engineering standards and will be located in the real world and built to a very high degree of accuracy with minimal field revisions or modifications. (Those cost time and money.) Plan view of 3-dimensional model of about a mile of city streets, with utilities, and property boundaries, in real-world coordinates. Plan view of a 3-dimensional model of a large park, with real-world coordinates.