king of nowhere

if you have 200 mods, perhaps there are issues. I am surprised your pc didn't explode already. that said - as a rule of thumb, the more you advance in the tech tree, the bigger the memories of the command modules and probe cores. however, modded stuff may not be recognized by kerbalism; in that case, it will get the lowest possible value, by default. this could be the source of your issues with memory - antennas are bugged by themselves. Like, I had a mothership with 6 RA100 antennas on the mun, and it was transmitting like crap because there was also a smaller antenna, and it was limiting everything. I got better speeds from jool, where the smaller antennas weren't working. I never bothered with trying to solve antennas problems because transmission time is not too important. So, antennas can have issues on their own. Add 200 other mods? no idea what could happen. I believe you should sacrifice a goat to the gods of information theory that the game starts at all, and count yourself very, very lucky that all your issues are easily solvable by some manual management (as in, just manually stop those redundant experiments). In my last grand tour I recorded no less than 47 bugs and glitches, and I only had kerbalism, rss and a few minor others.

when you have completed an experiment, it should not run the same experiment again. it never did for me. as for data transmission, why you're in such a hurry? it took over 3 years for the new horizon probe to downlink all the data it gathered from the pluto encounter; if you have similar issues, it's the mod working as intended. though if you "just started" a career, then early experiment generate only a few hundred kb of data, which can be downloaded in minutes. late experiments like gravioli readings take longer, but by then you have access to expanded memories and better transmitters

After starting my next grand tour, I realized I have to rework my mothership. the problem was a very cool solar array failing to work properly. I wanted to have a massive solar array of 100+ gigantors. It's completely unnecessary. However, this time I am not using kerbalism; as a result, I feel I have to carry around something stupid like that, else it would be too easy But I also want to be able to aerobrake hard, hence I want my solar panels to be retractable inside cargo bays. I initially devised the system shown the panels are mounted on trusses, which are mounted on hinges, which can fold and fit into some Mk3 cargo bays. The problem is that those trusses are long and heavy (to fit 8 gigantors lined up), so they wobble. Especially when using the engines. Time warping while using the engines is out of the question entirely. After a while, I noticed that the panels didn't look good anymore they are being bent. And the mission just started, if they look like that right now, I don't want to know how they'll look after I've landed on a bunch of planets. The worst part, though, was that even though they were supposed to fold and stay folded, they didn't Instead, this happened. And when I tried to aerobrake, all those solar panels went kaboom. Clearly not a viable project. They survived testing, but they didn't survive the wear and tear of space travel. So I devised a new system The solar panels are mounted on individual hinges. The cargo bay is now jutting out of the ship, and the panels are never too far from the center of the hinges. They deploy nicely, they look good, and I tested with full thrust at 4x time warp and there wasn't a bit of wobble. I was worried those Mk2 cargo bays would reduce aerobraking capacity, as they have a max temperature of 2500 °C - compared to 2700 °C for the nose cone cargo bays I'm using to shield the engines. but they hit the air laterally, so they heat less than the nose cones. The main problem now is that the ship is too aerodinamic and does not aerobrake much at all - I only lost 2 m/s from a 40 km periapsis on kerbin. I will have to taper some fuel tanks to create drag. Or maybe add a few inflatable thermal shields to use as parachutes. Anyway, before launching this new ship and restarting the grand tour, I want to do some more field testing with some of the shuttles

well, i can't help you with that. but now that you know all fuel tanks are equal, you have no reason to scale parts anymore

i'm not sure what dmr is, but i suppose it's the ratio between fuel content and dry mass. in which case, nearly all the fuel tanks have a 8:1 ratio; it's the same for all. some of them, like the Mk2 and Mk3 fuselages, have lower ratios - to compensate higher thermal resistance. the Mk0 fuselage has 9:1 ratio, but it's liquid fuel only. you can use it for LFOx if you have simple fuel switch installed.

Since there are a lot of worlds in this mod and it's hard to keep track, I made a map showing the general disposition of the planets and some general characteristics. I think it can be useful; could be included in the first page

there's an errata: thresomin is not in OPM, it's in whirligig world

do you need an autopilot to keep a steady course? For my laythe circumnavigation, I just pointed my "boat" east and alt-tabbed out. For speed limit, speed is set by propeller angle; it kept 53.2 m/s (just below the speed that plane needed to take off from water) without any other input. As for direction, it would steer north or south with time, but I only had to check every few minutes. and I would find in those minutes the "boat" had started pointing 20 degrees north or south, it's ok, it's still going mostly east. So I point it back east, and alt-tab again. no need for any autopilot. As an alternative, you can make a boat that has a lot of lateral control, but no up/down control, and set as target a planet. Choose it so that a boat pointing at it will point roughly east (or west, if you prefer). sure, it will be a bit below or above the horizon, and the boat will try to sink its head underwater, but since you have no up/down control, it won't be able to. and it will keep the east/west direction. as a fancier version of this, you could set up a satellite constellation to use as targets to keep pointing east. You'd have to change target every once in a while, but you may still be able to go a couple hours without inputs. P.S. @18Watt I see my thresomin circumnavigation hasn't been added to the leaderboard yet

from a purely effectiveness perspective, that's the best option. if we were rover racing, we'd all do it. you can steer and use the reaction wheels to stabilize simultaneously, that's a huge advantage. on the other hand, keeping the same controls and turning the reaction wheels on and off has the advantage of being easier to learn and perform, and to require only one hand - leaving the other free to turn around the camera with the mouse. it's a more "touristic" approach

I do, but i deactivate reaction wheels before pushing W. in fact, it's got nothing to do with pitch control, because the rover pitches up, not down. in a realistic simulation, I surmise it's because the wheels are spinning in a sense, and conservation of angolar momentum imposes an opposite rotation on the rover, and in low enough gravity that's enough to pitch up. I don't know how realistic ksp is - as I tried to learn better planes, I was flabbergasted at how much stuff doesn't work realistically - but either way, I've done several tiny worlds with different rovers, and always my rover pitch up. I'm surprised you didn't experience the same on Gilly. then again, from what I understand your gilly circumnavigation was done at orbital speed with rockets pointing downwards, so it was an entirely different experience.

Thresomin is a very, very small world in the whirligig world planetary pack. It's only got a radius of 2 km, plus, some 700 m of terrain elevation. Less than 20 km to circumnavigate. So, as I landed there, I decided to circumnavigate it. Whirligig world offers a couple of very interesting challenges. The starting world, Mesbin, is a giant planet that rotates super fast. One day lasts 15 minutes. there are 11 g on the poles, but only 1 g on the equator due to centriphugal force (yes, I know, it's not a perfectly accurate explanation, let's just be short). It would be a unique challenge to make a polar circumnavigation of Mesbin; a rover would have to resist 11 g, and be able to move uphill. I tried a bit, but there was nothing I could build that would survive the poles. Statmun is the inner moon of Mesbin, floating in geostationary orbit, very close to the surface. it's very small (3 km) and it rotates fast, so on the equator you cannot stand still; centriphugal force is higher than gravity, so you just fly away. to make an equatorial circumnavigation of Statmun one could make a rover with rockets pointing downwards (boring). Or, one could make a robot with ground anchors on the leg, to take one step at a time while staying anchored to the terrain (super cool!). Would be a nice challenge, but I don't want to learn robot making from scratch. However, maybe someone else will pick those challenges

I am about to start another grand tour, I only miss the last step: giving names to everything. Hence I'm asking for ideas on a few of those vessels this is the mothership - with already a few things already attached. it weights 2800 tons. in my normal kerbalism missions it would hold all the life support, but kerbalism is incompatible with this planetary pack; to simulate the added mass of life support, I added a bunch of additional living space. the engine pack. the nose cones can be closed to protect the ship for harder aerobraking similarily, the solar array also can be retracted and stored inside cargo bays. Here's a better look at the vessels already attached to it. from the left: yet-unnamed unmanned probe with a scanner, Arrowhead Stock spaceplane, yet-unnamed modular taxi, Ice Cream refueling vehicle, Cigar small lander, another unmanned probe. this weird-looking plane is both a mobile base, an exploration vehicle and an ascent vehicle for large eve-like planets. the back part is habitation modules, hence the mobile base. when it's time to leave, the habitation module is ditched, the ascent vehicle flies up on propellers, then it jettisons the wings and it's a small, but powerful rocket - necessary for planets bigger than Eve. here while it's docking to the mothership, with its thermal shields attached to survive reentry. the taxi. in my mission architecture, "taxi" is the vehicle that ferries a lander from the mothership to low orbit. without the taxi, one would have to either use the mothership to move around the landers - horribly expensive, given how big a mothership is - or include the extra fuel in the lander, which would make the lander a lot less efficient. here the taxi has an additional fuel tank, for when it has a greater payload (basic configuration is for carrying around the lightweight lander Cigar, extra tank for Arrowhead). finally, the small probe. it's got a scanner to find ore, and a rovemate core to detect anomalies. some science instruments too. it's purely fluff, since i can't read a resource scan anyway, and nothing it does is necessary. but i like having it. So, I don't know how to call the mothership, plane-habitation thing, taxi, and small probe. I am open to suggestions. thanks

floating over statmun (whirligig world planetary pack) with a comet in background

to change orientation, there are some parts that you can choose as "forward". those are probe cores, crew modules, and docking ports. right click on them, "control from here", now that part is pointing forward. Some of them even have the option of pointing forward or backwards. however, what you are experiencing is not normal. are you still launching rockets from the launchpad? if you're launching from the spaceplane hangar, it may make a difference. do your rockets have unusual features? I suppose not, since even the ones that used to work now have this problem. if manually fixing orientation does not work, you may try to reinstall the game

Part 14: You must be this Tal to move forward Dancing Porcupine travels to Tal, the sub-moon of Wal, to complete the circumnavigation of the moons of Urlum Tal, in all its glossy charm

I think I'm going to redesign the thing entirely, without any kind of fairing.

oooh! once more, the responsible is a glitch in how the game handles aerodinamics. I tried changing place on that fairing. indeed, the situation improved significantly, though the rocket still flipped. now that I understand the problem, I can go back improving on my own. I do not doubt your analysis, but the thing is, there is an aerodinamic fairing that should cover the back there, and a vector engine attached on the back node, and I checked that the vector also has 0 drag while the back fairing is there.

I am trying to build a mobile base that doubles as ascent vehicle for an eve-like planet. basically, it's a big plane with a large living space, it then drops the living space, flies up with propellers above the atmosphere, drops the propellers and wings and ascends as a rocket. unfortunately, even though the shape looks fine, it keep trying to flip. this is the full plane with the base part. not really relevant here. this thing flies passably, has some issues, but i'll improve it after I can get the orbiter to work. to start orbiting, I drop the living space and this part flies up on propellers. it flies well, it is very stable. However, if I steer too much away from prograde, this thing flips and cannot be recovered. it appears to be aerodinamically unstable. I would blame the wings being that much forward, but the center of lift is in the right place. doesn't look right at all. Anyway, if I don't do any sudden turn, I can fly up nicely. The flat part behind looks ugly and drags heavily, but it doesn't create any real issues. The really bad part starts when i ditch the wings This is the rocket that ensues. I removed the fairing to see it better. Well, this thing flips immediately. The flaps in the back are a latest addition to try and prevent that, but they do no good. Ok, I can see that the center of mass is shifted in the back of the rocket, which can create problems. on the other hand, I have a large flat surface, which should make drag. the front is very aerodinamic. and I have just added a bunch of flaps. I also have a powerful engine (it needs to be, the planet has 2.2 g) with a lot of gimbaling. I suppose I could try to fix the center of mass, but it's chancy. The upper stages are meant to be discarded from the top, so I can keep the engine (a necessity to get the high deltaV and thrust required to leave Derbin); but they are used in vacuum. The first stage, with the vector, is dropped while still within a significant atmosphere; I'd really not have to tilt the rocket and discard a tank from the front in that condition - plus, I'd lose the aerodinamic tip. Aside from that, I have done what I can to minimize the center of mass issue. No good; I have launched a lot of horrible payloads without fairings, and this looks to be the most unstable of all. At some point I discovered that the fairing wasn't working properly and the things inside were still causing drag. I fixed the issue - the screenshot below shows, I am selecting a bunch of stuff inside the fairing to check that their drag is 0. still no good. that rockomax tank in the back has an abnormally high drag; it's the same drag of the backwards fairing, which has an open node in the back. so it's like that tank has an open back. which it hasn't. I can't understand what's causing this, but it's drag behind the center of mass, so it should actually help with not flipping. this final shot shows the moment I release the wings. the rocket flips upwards immediately. resistance is still 0 inside the fairing, staging didn't mess with it. yet there is one big red line starting inside the fairing, as if there was something actually messing up that could be responsible. however, I selected each and every part inside that fairing, and couldn't find anything with any drag. I suppose I could try to move the CoM forward, though - as I explained - it would cause a lot of other problems. I'd rather not have those problems. This rocket really should not flip

since you problems specifically pertain a mod, you may have more chances finding help in the specific mod thread, rather than in general questions. I doubt many people are familiar enough with that mod to try and answer

I called those things "cocoonators". basically, a small probe with a claw and a heat shield to attack to the frail component and shield it. you probably don't have the 10 m inflatable shield, but you also have a much smaller part to shield.

Sorry to say, but your transfer is terrible. Judging from how little the trajectory is deviated by the gravity, it looks like 1-2 km/s of intercept speed. and of course you can't aerobrake; if you go too fast, you melt. so, learning to make better transfers will both reduce your insertion deltaV, and make it more likely that you could aerobrake. And the key to a low intercept is that your trajectory must be as similar as possible to that of the target body. the planet is moving very fast. your ship is moving very fast. when you intercept, you have to pay the difference in speed. but think if it was two cars instead. two cars moving at 100 km/h. if they are going in opposite direction, the speed of a frontal crash would be 200 km/h. that would also be the amount of deltaV needed for them to equalize their speed. if they are hitting at 90 degree instead, it means one car has to slow down by 100 km/h in the Y direction, and gain 100 km/h in the X direction; by pitagora's theorem, it's an intercept speed of 142 km/h. but if they are moving in the same direction, they are standing still compared to each other. the best way to transfer is called hohmann transfer. here you get an example you can see, the transfer orbit is an ellipse having earth(kerbin) on the closer point to the sun, and mars(duna) in the highest point. this way, when you reach duna, both the planet and your ship are moving in the exact same direction. duna is moving faster than you, and you have to compensate for that, but it doesn't take much. instead, if your solar apoapsis would extend way beyond, you're moving across duna's orbit, and you're going to have a horribly high intercept speed. which is your case. a transfer window is the time when the planets are aligned so that you can leave kerbin on a hohmann transfer orbit, and reach duna at apoapsis. orbital inclination makes things more difficult; for duna you can just make a plane change at a node, but if the difference in inclination is high, a plane change is hellishly expensive (can be as high as 2 km/s for moho) and there can be better strategies. but that's not a concern right now. at the moment, your objective is to get a hohmann transfer right. try one. another thing to consider is the Oberth effect; it basically means that a prograde/retrograde burn is more efficient if you make it closer to a source of gravity. so going from kerbin to duna is cheaper if you launch from low orbit than if you launch from a higher orbit. And a capture burn is cheaper if you perform it closer to the planet. try to plan the maneuver, you should see that your capture deltaV should lower considerably if you lower your apoapsis from 500 to 50 km. though not enough to salvage the mission, probably, in your case. if you have low thrust, and your capture burn lasts several minutes, you're going to get less benefits from oberth effect - because you're performing part of your burn far from the planet. oberth is bigger on bigger planets, so it's important to get close for a capture at duna, and even more at eve or kerbin, while on a minmus intercept it makes very little difference.

I'm not allowed to soften landings? You got me worried there for a minute, because on priax I've needed to do that occasionally. when falling down a crater, I sometimes have to point the rockets downward and slow down. I did say it clearly in the report a few times, for example here I may have done it a couple times on polta too, but I'm not sure. But I assume those small uses are ok, and what is actually forbidden is taking suborbital jumps - which is a very different things. actually, on gilly (and ovok and hale) you could use a quick rocket burst to accelerate while still touching the terrain, reach 10 m/s, that's enough to go all the way around the moonlet, but still slow enough to land on wheels. So one could circumnavigate it with a couple jumps while technically following the letter of the rules. Incidentally, I did manage quite a long suborbital jump on Ovok, where the terrain is very flat and you can pick up some speed despite the low gravity, but it was entirely wheel-powered. By the way Tal requires quite frequent rocket use, for a kinda weird reasons; it's full of boulders, and those boulders have collision enabled. and the rover frequently jumps (low gravity), and it may land just on top of such a boulder. the boulder then hits the fuel tank, which is rather fragile. so in this case I have to give a quick rocket nudge to avoid the boulders. I have to do this maneuver once every few kilometers. again, I assume "use the rockets to make the jump 30 meters longer and avoid those boulders" is not against the spirit of the rules, just like "I fell down this deep crater, I'll use the rockets to slow down the fall". I point the nose down and land within a few seconds, so those jumps are in the 30-100 meters long, no problem. I'll try to remember that if I do happen to jump down from a high, steep cliff.

I'd have no idea how to write a script in any case. what i do is point the nose down if I leave the ground. this way i land quickly.

uploaded the priax circumnavigation. there were a couple segments (of 8 and 3 km respectively) where I did take suborbital jumps to skip heavily bugged terrain, where my rover exploded without reason. technically against the rules, but it was a force majeure case.

Part 13: Ravines The circumnavigation of Priax is eventually completed. Next stop: Tal