LN400

FINALLY... got the Mun double scan satelite sent off to Minmus after 15 days mapping the surface, docked the fuel depot to one of the Mun space stations that is off to Minmus next where it will meet up with another fuel depot to become a permanent orbital lab/base there. The Mun depot is going to 20km orbit where it will be the permanent Mun fuel station.

To avoid the rover flipping over, the 1.25m reaction wheel is plentyful on a medium sized rover on Mun. A tiny rover can get away with a smaller reaction wheel. Alternatively you can use RSC but this is less than optimal as you need to spend fuel and once that is depleted you have a problem on your hand. Set the brakes on the rear wheels. You can do this in the VAB (possible in the field but I don't remember). If you are going at more than say 5 m/s on Mun on flat terrain, engaging the SAS and brakes are usually enough. Downhill you might use the reaction wheel to raise the front wheels while stepping on the brakes on the rear wheels. Don't turn and brake when going fast or downhill. Be careful that both rear wheels touch the ground. If only one wheel touches the ground then the rover can easily tumble out of control. Use uphill to help slowing down, if available. Even a small hill can do the trick. Keep an eye out for these and watch the speed closely.

First question I have is, why can't you have permanent RCS thrusters on the module? If the problem is you don't want them to fire up when you use RCS on the rest of the station, then you can always disable the thrusters you don't use at any time. For approaching the target for docking, some sort of propulsion is of course necessary. No way around that. It can be a separate motor/tank with RSC that is jettisoned after docking, or you could install the infernal robotics mod to build a robotic arm for the final docking/assembly but this is a bit hairy if the module is massive and it involves getting the robotic arm installed so it may be a catch-22 depending One last alternative I can think of is using the KAS/KIS mods that will give you a winch for pulling the module in and into place but the structure will most likely be less rigid and a lot weaker than if you use docking ports and one of the other methods.

A few things to consider when building a rover: How are you going to get it to the destination? This sounds like Captain Obvious speaking but it is easy to build a cool looking rover only to find it's a nightmare to send anywhere. Low gravity planets vs high gravity ones vs tractions. A rover that works wonders on Mun might be too light weight for Minmus so it keeps sliding around or it gets airborne after hitting a bump, breaking on landing. That Minmus rover might break down under its own weight elsewhere. Consider which wheels you can use on the destination planet/moon. A rover with a mass of 1 ton weights 9.81 kN on Kerbin but only 0.490 kN on Minmus. If you want a 9.81 kN weight on the rover on Minmus then the rover would need a mass of 20 tons and a weight of more than 196 kN on Kerbin. How to place the command module? If you plan on having only 1 command module on the entire rocket+rover then having the module upright works for the rocket but is less optimal for the rover, where flipping it 90* makes navigation a lot easier. Just remember to test it on Kerbin first to make sure you flipped the module the right way. Or, have 2 modules, one for the rocket and one for the rover.

I have noticed but never really thought about why. Could it be to use the CoM/thrust offset for a less fuel hungry g-turn? With the shuttle hanging underneath the tank, the drag and mass will allow for less thrust from the shuttle's engines than if it rode on top, kind of thing?

It totally depends. If I need a first-in-a-series design, then a lot of time goes into building, or if I need a one off design. Most of my designs are in series/mass production with only minor adjustments though and once I have 10-15 of those scooting all over the place then most of the time goes to seeing that the burns happen in time, not to mention collect science and planning future burns. When things get busy in space I can easily spend a day or two in real time doing nothing other than flying.

The Cirrus SR22 has a parachute system (CAPS) as standard.

That is pretty darn sweet. Nice job!

I hope this is some initiation rite. Where can I pick up my membership card? Biggest mistake though: I got the demo and though "ok, this is neat". A buddy said I should sign up on Steam and he would gift me the full version. I did.... Big mistake. Where did the time go?

Continuing my quest for the kOS script that will perform magnificent g-turns time and time again. It's a long way to the top if you want to automate things.

If I'm not mistaking, Scott Manley did a ridiculous 500 G launch in one of his vids. The ship exploded 1000 meters up but the Kerbal survived the launch itself.

Found a few more that weren't too bad as well as plenty that were real bad so I'll skip the latter. This one turned out as some kind of Marty Feldman lookalike. Old man #1 Old man # 2 who is really the native American in my first post, with beard and no braids after me looking at what else he could be. And finally Frankenstein's creature with a nosejob, the final version I did and the one that I like the most.

Thanks guys. I must confess I do struggle with the documentation the way it's laid out. Some things aren't that obvious until you already know so thanks heaps for the explainations given.

Adding to the post above by Empress Neptune. For each design, just like in real life, learn how the plane behaves at different speeds. Find the lowest speed where you can maintain control and not lose altitude. Remember that speed. Typically that will be near your minimum take off speed so remember which speed you took off at. Before take off, memorize the pitch angle of the nose (look at the nav ball). That is the angle where you will land on all wheels. A couple of degrees up from that is where the drag helps you slow down while letting you land on the main wheels. In flight, play with speed, controllability and descent. Find the speed where you can control the airplane while slowly losing altitude. That will be (near) your landing speed during finals. A plane needs time to adjust so plan well ahead. Like in real life, make a plan for the phases before touchdown, especially the finals which is the stretch you START losing altitude for landing. This needs to be started straight out from the runway, Don't do sharp turns during finals. It also needs a considerable distance. 5km out is not unheard of. Might very well be more. Standardise your initial altitude and speed for finals. Start the finals at the same altitude each time, at the same speed. This makes it easier to find what needs to be corrected in future flights. Allow a shallow descent. A straight sloped line is perfect at an angle of only a few degrees. You might have to wing it but if you pay attention to your speed and your descent rate then it can give you the ballpark figure you need. Just above the treshold, just a few meters off the ground, cut the throttle and let the plane settle down (unless you are flying a grand piano tied to an anvil in which case you might need the throttle). Keep practicing all the above and in particular the finals. Keep it standard.

Thank you. I have however read it and I'm still reading it but here is one of the problems I come across: I get the list of parts and in my case, at the launch pad, the part (the 2.5Mm omni antenna) is number 22 with the tag "ant25". Now the thing is, when the antenna is to be deployed, I may or may not have shedded off a number of parts, depending on how soon/at what altitude I decouple the lifter. The antenna may or may not be part number 22 when that happens. So I want to use partstagged. I have tried set antlist to ship:partstagged("ant25"). set ant to antlist:getmodule("ModuleRTAntenna"). ant:doevent("activate"). This gives me an error: "GET Suffix 'GETMODULE' not found on object LIST of 1 items: [0] = "PART(longAntenna, tag = ant25). Now, another part in the documentation1 states that the partstagged syntax is partstagged(tag_name) without quotation marks so I have tried both with and without quotation marks. No luck. However, this code set antlist to ship:partstagged("ant25"). set ant to antlist[0]. set ant2_5 to ant:getmodule("ModuleRTAntenna"). ant2_5:doevent("activate"). works but the syntax is different from the one in the documentation. This is very confusing and I would appreciate some help to wrap my head around this. 1 https://ksp-kos.github.io/KOS/general/parts_and_partmodules.html?highlight=partstagged

I am trying to activate an antenna via kOS but I need help with this one as I can't seem to find in the documentation the exact code that allows activation/deactivation/toggle/. Could someone please post a snippet of code in its exact form that will do this, or point me to the section in the documentation that has the exact syntax?

I'd say all engines have their uses. That being said, some engines are more widely used than others and niche engines will appear to be more useless than wide-range engines. I think I have used every single engine in the game at some point. One fairly large rocket didn't have enough thrust to get anywhere, putting in the only larger engine was a more expensive option than strapping 2 Thuds on the rocket. Only one rocket but the Thuds saved me some cash. I have had rockets and landers where CoL did not line up with CoM but putting on one or a few Twitch engines solved the balancing issues. The Ant gave some of my micro probes far better range than any other engine could offer, and so on and so forth. I am not a huge user of stock SRBs but even they have found a place more than once. The keys are "niche" and your style of playing/designing.

First thing I would check when updating a mod is the change log. Most (or all) mods have a change log either on their front page here, in the zip archive or on the download site. Any removing of parts should be mentioned there.

I did build a "reusable" rover. Chassis was basically all fuel tanks, reaction wheel and command module + docking port for refueling in orbit. Used it a lot for exploring Mun for landing sites suitable for manned landers. I say "reusable" since this one didn't have enough dv to leave the Kerbin system in any meaningful way, but it had enough to make it to Minmus for refueling before being used there.

I gather then that there is no standard but here's a request to all who reads this topic, that everyone reporting on dv also mention which dv they are talking about since it can mean several hundreds of m/s difference.

First question: The only part I am aware of that allows decoupling and recoupling later, is the docking port (in stock game that is). Another thing is that rovers are rarely (if ever), designed for a return trip. Most rovers, I would think, are designed for a one way ticket. A link to posts about return-ticket-rovers would be interesting.

Nearly absolutely nothing at all as time wouldn't allow it but I did, for the first time ever, because I'm that slow, some preliminary experiments with SRBs and staging for a better TWR profile.

One question: When there is talk about dv, is there a standard as reference? I mean, is it all amt, or all vac, or a specific combination? This question really goes out to all who use dv benchmarks of any kind but it would be relevant to know what is being used here..

In all honesty, considering the lack of quality to the actual plan and assuming they are not plain mad, a more plausible scenario than in the books/movies would be the one in Bored Of The Rings: "But fear not, dear boggie," continued Orlon, "you shall not go alone." "Good old Gimlet will go with you," said Legolam. "And fearless Legolam," said Gimlet. "And noble King Arrowroot," said Bromosel. "And faithful Bromosel," said Arrowroot. "And Moxie, Pepsi, and Spam," said Dildo. "And Goodgulf Grayteeth," added Orlon. "Indeed," said Goodgulf, glaring at Orlon, and if looks could maim, the old elf would have left in a basket.

These are very interesting findings but something that should be looked at, imo, is the spread in results for multiple launches for each condition, to get more solid statistics. This isn't something I would ask of one person but if we could have a community "research" group where everyone are testing in the same conditions, with the same ships, same mods etc, each doing a small portion of the tests needed, then it could very well be doable. The data then being collected and compared.