king of nowhere
-
Posts
2,398 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by king of nowhere
-
-
2 hours ago, strider3 said:
How is it possible to burn the Wolfhound when it is coupled to the top of the Mammoth stack? Won't firing the Wolfhound destroy the lower half of the central stack?
ok, i misunderstood the image. i thought the wolfhound was in the bottom of th ecentral stack, and the mammoth were all around it. my bad
in this case, if your station has enough fuel, you should refuel your mammoths, use them as first stage for moho orbital insertion, and drop them when exhausted. as i said, using many stages has advantages over a single stage. even if mammoths will be less fuel-efficient. but the moment you drop them, you still have the wolfhound fully fueled, and you'll be further along the way
-
36 minutes ago, Grogs said:
For the second situation I would choose a variation of c) for the same reason. Ideally, come in on the same plane as the station and set your Pe on its orbit. Then when you do your capture burn you could set your Ap so that you intercept the station the next time you swing back down to Pe. You don't really have to calculate to pull it off, just set the station as the target and burn until the two position markers come together. There's no reason you have to do it that way, but it feels like the most elegant solution.
yes, that would be not only most elegant, but also most efficient, because all the thrust you use is equalizing your speed to that of the station. doing it with a modified hohmann would require more deltaV to reach the same speed of the station.
i'm not convinced, however, that the saving from oberth effect is always inferior to what you'd spend to move around the orbit. consider for example a moho mission: it takes 2500 m/s for the capture burn. if oberth effect lets you save even just 10% of that, it would fully pay for periapsis raising.
i was considering also the case of the smaller moons, where you only spend very little deltaV to raise your orbit; but in those cases, you also gain less from oberth effect. so, perhaps scenarios b and d are cconvenient only for moho and eeloo.
maybe i will try one of the next days
-
ok, so we all know that if you want to insert in a low orbit to land somewhere, you're better off entering the body's SOI with a periapsis close to it, to use oberth effect. and also so your periapsis will already be low so you can circularize the orbit in one single burn.
but! assume we instead actually want to reach a high orbit. because we are placing a satellite contract, or because we want to rendez-vous with a space station in high orbit. we don't want to land or to move lower. so you have two options:
a) enter with high periapsis, then circularize. one single manuever, you're already there
b) enter with low periapsis, put your apoapsis on intended orbit, then raise your periapsis. it takes two manuever, but you get to use oberth effect to save fuel on the insertion.
things are even more complicated if you must rendez-vous with a space station: unless you timed your trip perfectly to circularize orbit already on intercept, you will need to get to a parking orbit first, and from there intercept the station.
so you can
c) enter with a high periapsis, don't circularize but stay in an elliptical orbit, just short of leaving the SoI. circularize when this would bring you on an intercept with the station. it's harder to do so on an elliptical orbit, but doable. you also can fix small errors to your inclination on a high orbit, where it's cheap to do so.
d) enter with a low periapsis, leave periapsis intercepting the space station. raise your periapsis when it's time.
again, the second option requires to move around the orbit more, as you need an additional manuever (technically you don't; but in high orbit raising/lowering orbit is very cheap, so case c lowering the ellipse to an intercept is going to be cheaper, and the deltaV for circularizing at intercept is also going to be cheaper). but again, option d saves fuel on intercept due to oberth effect. and orbit insertion is the most expensive manuever, so saving fuel there matters more.
what do you think, in the two case, would be the most efficient manuever?
i would assume it depends (higher speed of orbital insertion, it's more important to save on insertion with oberth effect. higher mass of the celestial body, changing orbit around it is more expensive, it is more important to save fuel on ohmann transfer), but in this case, what would be some useful parameters to go by? how much would be the difference anyway?
-
3 hours ago, strider3 said:
Putting a Wolfhound on the bottom of the central stack instead of a mammoth caused issues with getting to Kerbin orbit of 350km due to lack of thrust.
of course. engines have different efficiencies in vacuum and at sea level. that's why you also have to look for sea level isp. you want that high when launching from kerbin. the wolfhound is good for vacuum, but useless in atmosphere.
QuoteWhat I've done is split the central stack into 2 stages with a Mammoth at the bottom to help get me to 350km Kerbin orbit, and added several tanks and a Wolfhound to the top of the central stack, to get me to Moho.
yes, very good. that's an additional reason for making multiple stages in rockets: not only you shed dead weight, but you also can use different engines optimized for different conditions. that's true also in real life.
QuoteNow the question is...do I just jettison the lower stage with the Mammoth (which still has fuel) and go for Moho
or refuel at my station and burn the Mammoth then the Wolfhound for Moho?
neither.
you select your decoupler, and select "activate fuel transfer". then you activate the wolfhound, only the wolfhound, you shut down the mammoth, and you start your trajectory to moho. after you have burned some fuel, you transfer fuel from the lower stage to the upper stage, until the lower stage is dry. then you ditch the mammoth.
this way you can save every drop of fuel, but you also get to use the more efficient wolfhound. for an equal amount of fuel, the wolfhound can squeeze 20% more deltaV from it.
also, of course, you have to make sure your fuel shuttles contain as little dead weight as possible. this way, they transfer fuel more efficiently. my fuel transfer vehicle weights 180 tons full, uses two wolfhounds, and has a deltaV over 7000 m/s when full. you need 5000 m/s (EDIT: I misread the deltaV map, it's actually closer to 3000 if you get the right time. so, a return trip is also possible) to get to moho, so my vehicle could get to moho with a decent amount of fuel left (perhaps 15%; remember that fuel gives diminishing returns, and if you burn half your deltaV, you did not burn half your starting fuel, but more than that). my refueler has a couple tons of landing gear you don't need, so you can also save on that, and replace it with two tons of fuel.
but, since you don't need your refueler to be reusable (you don't have enough fuel to get back from moho anyway), you also could add more stages. a single stage for 5000 m/s is feasible, but inefficient. if you were to build your refueler with two stages, one to intercept moho, then you shed that stage and circularize orbit with the second stage, you coould save fuel. if you times things well, you also could get the first stage to return to kerbin (where it can save fuel by aerobraking), and reuse it.
anyway, sending fuel to moho is very expensive. it still costs 5000 m/s, on the most optimized trajectory - which i suspect you're not using, since you keep launching new refueling missions, are you waiting the launch windows?
it would really be less expensive to send a small, automated isru complex on moho. even if all it does it refuel your rover, and then you delete it. it's one mission, instead of 4.
-
13 hours ago, fizy45 said:
Also if they can make docking little bit easier (not rendezvous thats kinda easy) will be great. I dont know you guys but I am having trouble in that area luckly we have mechjeb.i am horribly conflicted here.
on one hand, i like this game specifically because it is gritty rocket science. you don't go around doing "cool" things while the science gets handwaved, you have to take care of orbital mechanics, fuel budget, and all the really complex stuff. that includes docking: it's hard, gritty rocket science, and it should not be handwaved.
on the other hand, after i run dozens upon dozens of them in only a few weeks of playing, it's mostly a bother.
so, perhaps something in-between. perhaps you have to do docking manually the first time, but you can get it automated eventually. perhaps it can be added to the manuevers that high level pilots can do. perhaps your ship will have a "manueverability" factor keeping into account how easily it can be turned around with reaction wheels, how large it is, stuff like that, and if the parameter is below a certain level (easy docking) the docking is done routinely, subtracting a smidgen of fuel. so the human would only have to do the challenging ones
-
i hope it has better tutorials and in-game references.
really. i had to join this forum to learn some basic aspects of the game. and i don't mean "learn this pro trick"; i am into rocket science and i already read a lot on the topic and was quite knowledgeable before starting the game. no, i mean "i want to do this easy thing, but i cannot figure out the commands". like, for example, the first time i tried to install a docking port, it didn't work because i installed it backwards. how would i know? they don't look so different, and the most similar parts (decouplers) work correctly on both faces.
-
ah, a rover with foldable wheels. i tried that kind of design. eventually i abandoned it once i got aerodinamic fairings big enough. turned out the downside of adding all those moving (and heavy) parts was not worth the benefit once i unlocked the pieces to launch the rover whole without it burning up on ascent.
also, most of my late rovers also double as fuel tankers for space mining operations, so they are quite big and heavy; hinges would not support them anymore
-
On 6/25/2020 at 10:38 AM, Spricigo said:
My suggestion is to not try to land it back (go ahead if you want but don't seem to be worth the trouble). If there is more than 600m/s left try to land it on the mun or let it in Mun orbit and wait for a "position Mun Satellite in a adjusted orbit" contract. A few tricks I use for satellite contracts:
- rename the satellite with the remaining deltaV at the end ("Mun Satellite" becomes "Mun Satellite 735") to know If there is enough juice left when the contact is offered.
- If you are launching the satellite to fulfill a single contract include the agency on the name (e.g Zaltonic Mun Satellite.) to identify it better.
- Add an HG-5 antenna to make it a "Gap Relay"
- Use a decoupler or docking port to drop any' Contractual Obligation Part' you don't need after completion.
- Unlock Propulsion System ASAP, and design a "Contractual Obligation Satellite" with the essentials and powered by a single ant engine (C.O.S. will pack over 2km/s deltaV with easy since it weight almost nothing)
i add an alternative path there:
- outfit your contractual obligation satellite as a deep space probe
- also add the best relay antenna you have
- pack a lot of deltaV
- send your satellite off to your target orbit
- as soon as the contract is fulfilled, manuever again and go on another planet to perform all the science.
- once you've carried out all the science you can, your probe is just another useful relay.
i advise only doing that late in the tech tree, though: the first probes i sent this way i had big plans, only to realize that they became obsolete very quickly as i unlocked new instruments
-
i ued to deploy parachutes when risky (yellow) all the time before i unlocked better pieces, i never had any malfunction.
i tried to deploy them on red a few times in bad situations, they always ripped immediately. they didn't even slow down the craft slightly, which was all i was hoping for.
-
there is nothing wrong with leaving a game after having done everything you could possibly conceive with it. it's why i leave most games eventually
-
i verified the voices i heard about kerbonauts helmets being indestructible.
i had a craft that was unstable for reentry. it kept reorienting itself nose first, so it was too aerodinamic and it crashed beforw slowing enough to deploy the parachute (even on "open when risky" setting).i decided i would leave the craft with my pilot and land with the pilot's parachute. too bad my pilot was still level 0, and didn't have a parachute available in EVA.
he lithobraked at 45 m/s head first. he survived. it wasn't even a glancing blow, he went down like a brick and barely bounced.
-
to get into mun intercept from low kerbal orbit you need some 850 m/s of deltaV. then, if you also want to orbit around mun instead of just doing a flyby, you need some more 150 m/s to enter orbit. from there you can come back to kerbin with only a small acceleration.
that's assuming you do all the manuevers perfectly, at the most convenient times, with the most optimized trajectories. i would want at least 1200 m/s to try that, to stay safe.
i assume your orbital stage uses a terrier, so the deltaV in vacuum should be about quadruple of that shown there. if i'm eyeballing this correctly, you should have around 1500 m/s left, which is enough for your purposes
-
15 hours ago, James M said:
The lower your periapsis when you arrive at your destination, the less fuel you'll need to circularize as your kinetic energy is at it's highest due to the planets' gravity increasing your ships velocity.
This post really delves into WHY that works and if you just take that little bit of extra time really reading and doing the calculations, it makes way more sense and I gotta say. It's really cool!
otoh, what always left me puzzled about that explanation is where the extra kinetic energy comes from. you are burning fuel, converting chemical energy into kinetic energy. the chemical energy of the rocket is always constant, but the ship is getting more energy, where is the extra energy coming from? i've never seen it explained well.
but thinking about it, i just realized the source is the exhaust kinetic energy. see, the fuel also has a kinetic energy, as part of the rocket. the faster the rocket goes, the higher the kinetic energy of the fuel. when you expel fuel, the fuel changes kinetic energy, and if you're going faster, the fuel will change its kinetic energy more.
regarding insertion orbit and circularization, another way of seeing it is that if you enter with a high periapsis, then you have to lower your apoapsis from escape to stay in orbit, then you are in a circular high orbit, and you have to lower the orbit at both ends. if you enter with a low periapsis, you have to lower apoapsis from escape to stay in orbit, which has the same cost as it would on the other case. but now you are in an elliptical orbit, so you only have to lower your apoapsis. so you save one manuever. and that without even counting oberth effect. so it means, by entering low you save fuel twice.
i never went to moho yet, but i've done a lot of mun insertions; without oberth effect, it is around 200 m/s to drop the other side of the orbit to low mun. with oberth effect, it's 150. and then i'm already in a low circular orbit, while if i enter at high periapsis, i am now in an elliptic orbit and have to run a new manuever to lower my apoapsis. which, depending on how high i was, would be another 50 to 100 m/s. so, by inserting low i can save up to 50% fuel for the insertion manuever
-
the first time i landed on mun, i didn't have the spark unlocked. afterwards, i always brought on some tourists, so bigger lander, so it needed a terrier.
the difference is minimal, though. as spricigo's calculation show, in most realistic cases it is within a few %. and then there is the engine cost, and both the terrier and the spark are cheap engines; maybe someone have some more efficient lander, but my mun missions tend to cost in the range of 40 to 60thousand
. saving 150 on the engine is also not a big difference.
ultimately, regarding the spark vs terrier debate for a mun lander, i wouldn't worry too much.
-
you can also attach lateral tanks to your lander to widen its base. of course, it will fly worse in the atmosphere.
regarding the terrier, it is bigger than the spark, but it is also much more efficient. what will give you greater savings will mostly depend on how big is your lander.
the terrier is also unlocked earlier. by the time you do your first mun landing, you are very likely to have the terrier, less so to have the spark.
-
to make it shorter: deltaV represents how much you can change your velocity.
a rocket has a total deltaV available which depends on its fuel, and it spends some of that deltaV every time it makes a manuever to change its trajectory.
for example, to move from a low orbit to a higher orbit you need to accelerate, to escape the planet's gravity. that acceleration is measured in deltaV, how much your rocket accelerated. and you expended fuel, so your available deltaV for future manuevers will be lower.
there are many different ways to get the same result in space, but some are more expensive than others. finding ways to get to the same place with less deltaV is of primary importance in a space program.
-
if you make your orbit higher than it needs to be and then circularize it, you are wasting fuel twice: once to raise your orbit, and once to lower it back. small corrections for a few tens of m/s are normal, but if you need more than that, you're being inefficient.
the gravity turn is by far the most efficient manuever to enter orbit: it's basically an hohmann transfer orbit from the ground to the orbit, and hohmann transfer orbits are the cheapest (or close enough; not sure if there is some complex manuever that would save a bit, but if real rocket scientist use hohmann transfer all the time, there's a good reason. i didn't believe it mattered that much, but after trying i discovered that on kerbin i could save approximately 1 km/s of deltaV by making a gravity turn rather than going straight up and then circolarize. the same goes for any other planet, except where there is no atmosphere it's even more convenient.
you can try for yourself: make a quicksave, get to orbit in the two different ways and write down how much deltaV you expended. you'll be surprised.
-
just tried it, it only recovered some fragments, none usable.
i will not rant about the stupidity of a system that overwrites all of my backups like that
-
before launching a vehicle that is ever slighly different from everything you have launched before, save the game. then use the cheat console to test your vehicle on all conditions that you may encounter during the mission, perform all the tasks you may want to perform. no matter how routine, perform them anyway. then launch the mission, and run it all the way to the end. don't worry about anything else, you're going to reload afterwards. only after you succesfully ended the mission, you can go back, reload the previous save, and do the mission for real.
i don't remember it ever happened that i didn't discover any fatal design flaw the first time i launched something new or tried a new mission. from a docking port installed backwards, to a rescue vehicle missing a parachute, to the thing not having enough reaction wheels, to an ore extractor capsizing upon attempting to pierce the ground because it wasn't properly secured. something will always go wrong at first. always.
-
14 minutes ago, AHHans said:
Do you have a backup of the KSP installation of the saves folder somewhere? Or do you use steam with the cloud-sync?
nope and nope.
i am old school. i come from the times when each saved game was a backup of its own, so saving the game multiple times was safe. now that i think about it, the far cry games also work in the same way, and i always thought it a terribly stupid way to manage saves.
but i'm thinking: the folder got overwritten, but the files in it were not. so the individual files must still be somewhere in my hard disk, and it should be possible to recover them using some specialized program. i will ask some of the pc experts i know
-
i decided to try running sandbox to see how it looks with the parts i'm still missing.
so i went to create new game, and i didn't bother to change the default name. it asked me if i wanted to overwrite the save, and i said ok, because i wasn't even using the default save, i keep lots of saved games anyway.
so i check what i wanted to check, then i come back. and i can't find any of my dozens of saved games anymore. nothing. i open the game data directory, look for the saved games, nothing there. i start a new career with a different name to check if i have the right directory, and indeed i see that a new folder pops up. and it's the only folder there.
does this truly mean that i accidentally deleted all my career? all the dozens of saved games that i specifically made as multiple backups, all the ships i ever crafter and saved, hundreds of hours of gameplay, everythingis beyond recovery? please tell me there is still hope
-
if you are looking for a challenge about reaching other planets, how about using gravity assists? when they sent a mercury orbiter they used 6 gravity assists between the earth and venus to slow down the ship, you could try something like that. even just an eve flyby with atmospheric braking should save a fair amount of deltaV
-
I am working on a multipurpose rover, it works magnificently at most of its tasks, yet it has a couple of weaknesses i could not manage to fix; i have to ask for advice
the rover has many functions:
1) fuel transfer between ISRU facilities and landed ships.
2) collects science
3) can land and take off under its own power on all planets without thick atmosphere (up to duna)
4) is fun to drive from a first person perspective (hence the cupola module oriented for better view of the ground)
5) survives capsizing at high speed
6) can operate in a wide range of environments
the rover has around 15 tons of dry weight, with capacity for 32 tons of fuel
it does those things quite well, but it has a few weaknesses
a) the rover has a hard time moving uphill. the slope limit depends on gravity and amount of fuel, but it's pretty low. fully loaded, on mun it can't take much more than 10 degrees. even on minmus tiny gravity it can't climb steeper than 30 degrees. this makes it almost useless for moho and duna.
unfortunately, the only ways to fix this that i see would be more wheels and/or bigger wheels. i already put as many wheels as i could fit on that design. as for bigger wheels, I'm already using the TR-2L model. the only model bigger than that is the XL3, but those things are super heavy. even if i swapped out 10 old wheels for 4 new ones, i'd still add 4 tons of weight. way too much. i guess i could use the hinges to angle my rockets backwards. i don't want to have to rely on consumable fuel just to move around a planet, though. and while i don't need it fully loaded, i'd like to be able to move around a planet with enough fuel to take off. which, in duna's case, means between one half and one third of full load.
b) the thrusters don't give uniform push.
this is harder to fix because the center of mass of the vehicle changes with fuel load, as evidenced by the image. however, the asymmetry of the push is small, and i was hoping the SAS system could compensate it. indeed, it can at low thrust. my previous version of this rover was able to achieve orbital manuevering, orbital rendez-vous and docking and a minmus landing, despite being more unbalanced than this one. however, taking off from mun is complex, the rover risk spiraling out of control. i managed after a couple of tries. i could not manage to take off from moho without losing control (i could land just fine from orbit). by the way, that was done at full load, when the center of mass and center of thrust align almost perfectly.
the problem is made worse by the hinges vibrating and further messing thrust direction: the rover is much more stable with the thrusters pointing upwards, but it needs to rotate the hinges downwards to take off (so the hinges are the most unstable right when i need more thrust). I need to explain why i made it like that. Originally, there was only one thruster, and its purpose was to right the rover in case it capsized. only later i realized that since i already has a rocket and a fuel tank, it would be easier and cheaper to strap on some additional engines and make the rover fly than it would be to design a whole cruise module and a landing module and adding them to launch mass. but i still need the rocket to work as anti-capsizing mechanism, so i still need them to be able to point upwards. also, the hinges allow the rockets to be safely retracted to be protected by the landing struts in case of capsizing.
the original plan called for intentionally capsizing the rover in order to take off (i know, it looks silly
). but the rover will just lean on the side, and it's quite hard to take off like that. so, i had to include the possibility to rotate the thrusters.
i could try to control the vibrations and asymmetrical thrust with a big reaction wheel. i could also use the stronger, heavier hinges. but i'm quite reluctant to add even more weight.
the push asymmetry could also be controlled by manually setting a thrust limit for some of the rockets, but it needs to be fine-tuned, and there is no way to do the tuning without firing the rockets and seeing if the push is uniform. if it's not, it's generally too late to fix things. and of course it must be continuously changed to accomodate shifts in the center of mass caused by fuel consumption. so, it's virtually impossible to make it work in practice
c) the rover still breaks for taking a bump at high speed
the safety struts work very well under normal conditions. i run many tests accelerating to 30 m/s (which is basically top speed with those wheels, and anyway it's top speed on most planets because low gravity will make the rover unstable; in fact, on mun it's hard to drive above 20 m/s for long without capsizing), and i never had any damage. directly slamming on the ground is another matter, though. in particular, taking a bump in the ground at high speed can break the front wheels, if the bump was steep enough. i tried putting the front low struts to try avoiding this problem, but turns out they also can't support a direct impact with the terrain at high speed. i may just have to drive more carefully around rough terrain, if there is nothing to be done about it.
any suggestion on fixing those issues without creating more problems somewhere else? is my dream of a rover fulfilling the 6 goals even feasible, or do i have to accept mediocrity somewhere?
-
i also have a similar problem. from what i can surmise, when coupling two ships the game makes some small correction to their position to fully align them. on the ground, this can cause some parts to go slightly below ground, or the wheels to become suddenly very compressed, and so the whole thing springs back. will try the advice of tampering spring values, otherwise the only solution i found is save scumming before coupling stuff on land.
. saving 150 
). but the rover will just lean on the side, and it's quite hard to take off like that. so, i had to include the possibility to rotate the thrusters.
orbital insertion economics 2: more complicated
in KSP1 Gameplay Questions and Tutorials
Posted
wow! it's very rare that i see someone making more math spreadsheet for a game than i do.
and it even turned out to be useful. i was expecting the differences to be small, since the two opposite effects mostly cancel each other, but picking the right insertion can save upwards to 20% deltaV for the trip.
could you put the calculation sheet available for download? i would like to try it for the various moons too.