king of nowhere
-
Posts
2,391 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by king of nowhere
-
-
2 hours ago, paul_c said:
I'm finding the same problems with a Laythe trip. Am I right in thinking, as a general principle:
* If you encounter a planet then (assuming you do a burn close to Pe, to get into a highly eccentric orbit just within ite SOI), if you have an encounter with a moon on the way out from the planet, you need to arrive behind that moon, as close as possible to it, to get the maximum gravitational assist but that will also go the right way ie slow you down and reduce the main planet's orbit?
* You can "choose which side" of a moon you encounter, making it a helpful/unhelpful in the grand scheme of what you're trying to do.
* It can also mess up your inclination (or improve it....but KSP doesn't show this numerically, only the graphic of the orbit)
* As well as any control you have on the effect of the encounter, you might just have a situation where the phase of the moon isn't right, so its gravitational effect is undesirable/best avoided?
I got into a situation where I encountered Laythe on the way back. My speed was about 4000m/s at Laythe Pe. Any retrograde burn resulted in splatting into Jool. So I was forced to burn about 1700 m/s to be fully captured but that meant I had enough to descend to Laythe, but not get back into its orbit. Any attempts to go below 50km at that speed resulted either in a fiery death or minimal effect (eg 49km didn't do much; 48km burnt me up).
it seems you are trying to dance the gravity assists among the moons of jool. that can be very rewarding indeed, or it can also lead to suicide thought.
but as a general rule of thumb, if you pass in front of a planet, you get slowed down, and if you pass behind, you get accelerated. this is the basics of gravity assist. so you don't need any expensive manuevers in reaching jool. pass in front of laythe duing your jool approach, and you'll be in jool orbit for free. however, you need to keep a high periapsis above jool when you enter, because this manuever will also lower your periapsis. indeed, a gravity assist will basically give you a prograde/retrograde burn (together with other components, but those are less easily predicted), and since you are neither at periapsis nor at apoapsis, the burn will lower/raise both your periapsis and apoapsis.
now you are in elliptic orbit around jool. from there, in my experience it is better to head for tylo. you can reach there with 200 m/s if you get the assists right. doing anything else is way more complicated; in theory you can use tylo to raise periapsis and laythe to lower apoapsis, but i never did much successfully without spending more in correction burns than i would gain otherwise. after you get captured into an elliptic tylo orbit, if you wait the right time you can get to laythe with a few hundred m/s anyway.
so i suggest: jool periapsis - gravity assist by laythe - possibly another assist by laythe to get the course right - captured by tylo - wait in elliptic orbit around tylo - transfer to laythe
-
8 minutes ago, mcwaffles2003 said:
It's right towards the top...
huh... i missed that
either that, or the way it was just below the dowload i assumed it was technical documents
-
3 minutes ago, mcwaffles2003 said:
Literally, in the original post....
your claim is patently misleading. there's no pointer called "docs and support" there - i may have recognized one as such.
there is the github link, indeed, as documentation. with a warning that it's outdated. the first time i installed the game i missed it (there are dozens of useful links, it's easy to miss something). after learning something by tinkering, i found the github. and it helped clear some things. for others, it was actually misleading, referring to something outdated.
then there is the "support". it was specifically labeled as bug report. Not "help". Not "support". Not "forum", "discussion" or anything. Bug. Report. As i didn't have bugs to report, i had no way to know those were also to ask questions.
Please don't resent me for not seeing that those things could actually refer to my problems. I do not resent you or anyone else for lack of clarity. In fact, I am a teacher, and doing this job i learned that there's no such thing as a good, working explanation on a complex topic. if it's clear, then it's leaving out all the details. if it tries to include the details, it gets too complicated and important stuff will be overlooked. The original post is well done. it is nonetheless confusing. the documentation is well done. it is nonetheless lacking.
-
15 minutes ago, Snark said:
I'm not saying "never do burns at high altitude". Some situations (like raising Pe) you have to, due to geometry. Other situations (like plane changes), it's better to do at high altitude because you have the option of "large burn low, or small burn high" and the small burn is better.
i know. i wasn't disagreeing with you. i was merely expanding a bit, in that there are some relatively expensive burns that are actually convenient in high orbit in some relatively rare situations.
by the way, i didn't have to make those burns there. the "standard" approach to reach a target in a different orbit would have been to match the plane, then change your orbit to intersect the target in one point, then keep burn at the intercept to change your orbital time and set up a rendez-vous in a future orbit. it's how the tutorial teches you. but in that situation, both nodes are very close to eve, resulting in a very expensive manuever. and then there's gilly's orbit being eccentric, and my orbit being eccentric with another angle, and this resulting in a high intercept speed. the radial manuever is a shortcut to go from an elliptic orbit to another, very different elliptic orbit without paying the crazy costs normally associated with that.
-
4 minutes ago, Snark said:
Statement still stands. Large burns at high altitude are inefficient.
Not sure what exactly you mean by "the angle of your trajectory"... do you mean your inclination? If so, then yes, it's better to make an inclination at high altitude... because then it's not a large burn.
Note that I didn't say that all low-altitude large burns are efficient-- just that high-altitude large burns are.
There are certainly cases (such as a large plane change) where it's more efficient to a high-altitude small burn instead of a low-altitude large burn, precisely because it's small.
all you say is true, of course. but no, what i'm talking about is burns such as those i used to reach gilly
part of that is plane change, but not all. i'm also changing the way the elliptic orbit is pointing. I don't know the proper names, i said the angle of your trajectory because in those burns, the ship is going in one direction, and that direction is changed. and they are 100-200 m/s, which is not particularly small
perhaps the best way to describe them would be radial/antiradial burns. though those trajectories make liberal use of all three directions, but ultimately it's the normal/antinormal and radial/antiradial that get benefitted from happening in high orbit, while the prograde/retrograde component is basically to ensure that I intercept gilly at the right time.
radial/antiradial manuevers, like plane changes, are cheaper when the ship is slower. they are, however, rarely mentioned, because they are rarely useful and rarely used. they are, however, excellent ways to intercept a moon in an irregular orbit when your own starting elliptic orbit is not pointing in the right direction.
-
wait a moment, since those things also exhist in kerbalism; what's the difference between TAC life support and kerbalism life support?
-
19 hours ago, Snark said:
In general, you want to avoid doing large burns while in high orbit around anything. It's very dV-inefficient.
unless you are making large changes in the angle of your trajectory, in which case high orbit is the only place to make them at a reasonable cost.
-
i take the chance to ask here a related question; I have a 1200 parts spaceship, and of course it lags hugely. but i noticed that the more i play, the more it lags. when i first open ksp and load the spaceship, it takes half a minute. after a while, loading it again takes a couple minutes. if i keep playing, it can take over 10 minutes to load the big spaceship. it lags while i control the spaceship, and it lags worse with time. the only way to revert that is to restart the pc. what would help to make the thing go more smoothly? CPU, RAM, what else?
-
I generally land on duna with large, complicated things with ISRU. but once i made a small rover as part of a challenge, and it's fitting to land almost everywhere, including duna
there is a terrier at the bottom, not very visible. it's enough to reach orbit with fuel to spare. the wheels work; the rover isn't particularly good, graceful, stable, fast or anything, but it's enough to move around some kilometers and get all the surface features. there is a parachute on the other side of the HECS, not visible from this perspective. it's some 20 parts total, and little more than 3 tons.
EDIT: forgot to mention: the parachute slows you down to 20/30 m/s; you need to use the rocket to slow down before impact. on going up, the thing is not aerodinamic at all - i made it as a universal lander, and a wide base helps stability; i'd only have to face an atmosphere once, so i didn't optimize for it. even in duna's thin atmosphere, this thing flies poorly. a gravity turn is not effective, too much drag. You should ascend vertically at a speed between 200 and 300 m/s until you get past 15 km of altitude, then you can turn. launching from the top of a mountain helps. even with the extra gravity and aerodinamic losses, though, you still have plenty of spare fuel
-
i'm not surprised that my questions would have been answered somewhere. good luck finding those answers, though. and I had no idea there was a dedicated discord server. i'm sure that information is also out there somewhere, buried among plenty of other useful informations. that's the problem with useful informations. also, for some reasons i am not comfortable with either github or discord.
by the way, i want to reiterate my appreciation for this mod and the people working on it (because i assume it's more than one). just because i argue about the minutiae it doesn't mean i'm not happy about it
-
20 hours ago, LadyAthena said:
Seriously? I didn't see anywhere it said this.
So the more I'm looking into it, the more Kerbalism just seems like a dead weight mod. All the good additional mods to make KSP awesome are no longer supported by Kerbalism, such as Remote Tech and others, and while I love the way the science works in Kerbalism, not worth the hassle when the mod itself barely functions half the time due to inconsistencies, and not even supporting base stock code in KSP like Field Research...
science is only the least part of kerbalism. frankly, 90% of the times it doesn't really make any difference, you just wait in orbit/EVA/landed a bit before getting the data.
kerbalism is good for all the thing it does with life support. I found myself at a point where i could do pretty much anything in the stock game, adding life support included a new level of complication to keep things interesting.
my main beef with it is the lack of explanation. including lack of people answering me when i ask stuff. the stock game is also very lacking in that regard, but at least i can spam questions in the dedicated subforum.
-
Additional question: is it intentional that getting nitrogen by mining is virtually impossible? i have a nitrogen drill, but it's barely producing enough to compensate losses. and i scouted every biome on duna and can't find any concentration higher than 2.5%
It would make sense to have it difficult to find, since it's quite rare in most planetary crusts. just trying to figure out if it was indeed supposed to be THAT rare
-
Also, if it's not too much of a hassle to add it, i would find it extremely useful to have additional power settings for automated vehicles; so far there is 80% battery and 20% battery, and i'm doing a lot with those, but I still need to manually follow my operations. having a 50% battery setting would be very convenient. 40% and 60% would be even better.
detailed explanation on automated power setting follows
SpoilerIdeally, my solar powered mining vehicles should drill by day, and rest by night.
unfortunately, setting the automation on day and night cycle does not work. because those automations only kick in at dawn and dusk. so, while my diggers can work by day, there will come a time when the sun is at the right angle that all the solar panels are shading each other. or perhaps an ike eclipses. anyway, they have a power shortage. I cannot, of course, let that happen, or i risk the crew dead for lack of life support. So I created an emergency routine to shut down mining work and activate fuel cells when power is low.
So, if I set my mining on day and night, what happens is that at the first power shortage everything is shut down. and then it's not restarted when power comes back, because day and night only kick in at dawn and dusk.
Incidentally, also triggering the day condition again every time the high batter is triggered would also be a way to tackle the problem, but perhaps less straightforward.
anyway, I had to set my mining on full and empty battery. so by day I mine with solar power. By night I keep mining until i reach 20% power. then everything shuts down and the fuel cells are activated. they slowly recharge the battery, until at 80% the mining starts again. this cycle goes on all night, but it's not a problem because i have plenty of oxygen and hydrogen.
this cycle, though, produces water, and dumps it. of course i must tell my fuel cells to dump water, i can't risk a life support failure because the water tank is full. anyway, i have the problem of remaking the hydrogen, and for that i use electrolysis. i tie it to high and low power, again. but electrolysis uses more electricity than my digger generates, so with it on i keep having power shortages. and after dumping water by night, now electrolysis risks draining all the remaining water and killing my crew by thirst.
So far, I am coping by controlling every digger every few days and manually performing electrolysis
ultimately, it would be much easier if i could set electrolysis to shut down at 50% power. also, if i could set fuel cells to shut down at 50% power, i wouldn't spend all night in the mine-drain battery-shut down-recharge cycle. the fuel cell would only work with battery power running from 50 to 20%, and it would provide life support and nothing else. this would drain much less hydrogen.
I also have an orbiter with insufficient battery to last through the night, unless i shut down the greenhouses, which i don't want to do for longer than necessary. and setting electrolysis to happen at high power creates this weird cycle of charge-discharge, which also creates problems at high time warp. again, if i could shut down the electrolysis at 50%, it would save me the hassle of doing it manually.
Furthermore, i would like to start the fuel cell at night and shut it down at day, but i cannot with the current setting; when the sun sets i have a full battery, so if i program my fuel cell to turn on there, in a few minutes the power level will reach 80%; then the fuel cell will shut down. similarly, as the orbiter reaches the new day with empty battery, if the battery was shut down by the new day, as soon as it hits 20% it would turn on again. at least, i assume so; i didn't try
EDIT: furthermore, it would be useful to be able, in the config window, to remove the message when batteries are at 20%, but keep it when they are at 0%. during the cycle i set up, it's perfectly normal that battery level will fall to 20% before activating fuel cells and recovering. i don't want a notification at every orbit. but if the level goes to 0%, then something definitely went wrong and i need to know it asap
-
5 hours ago, The wizard of me said:
Autostrut is kraken bait my friend
no more than anything else. and on a large ship, it is less troublesome than anything else
-
autostrut the payload, that's the apparent problem
-
this is very strange. the atmosphere should not matter if the capsule is aerodinamically stable. and personally i found that laythe's atmosphere is not bad, if you come equipped with thermal resistant stuff
try to post some pictures maybe?
-
try either with more or with less landing legs. those are usually the culprit when your craft bounces on the surface
-
55 minutes ago, MagicCuboid said:
The moderate radiation you're experiencing is from the "tail" and little bubble around Moho's magnetic field. If you squint you can see it. 0.088 rad/h isn't that much compared to if you were right in the belt.
As for stress, I have also noticed some discrepancy between what I am told in the planner and what my kerbals experience, but I haven't sent them on long enough missions to really test it.
what do you mean by tail and little bubble?
i am inside the magnetosphere and outside of the belt, i don't see any other zone.
anyway, it seems i get similar values anywhere inside moho's SoI. i tried to change the orbit a lot, but no way.
-
i'm not sure, but i think you have to go in the tracking station, select the unidentified object spotted, and manually click to track it
-
by the way, there's also something profundly wrong with the way the game counts stress. i have this luxury palace of a spaceship, with gravity rings, hitchhiker containers, greenhouses, cupolas, and twice as much living space as needed, and according to the VAB editor, stress should be under control for 20 years. yet after less than 1 year on mission, everyone in the crew is well above 50%.
after 200 days of mission i split a ship from that, and this second ship is nowhere near as luxurious as the first, though still decently comfortable. kerbonauts in that ship has been in space for just as long as the first crew. and yet they have stress between 20 and 30%. and that, they accumulated while they were in the first ship. it's clearly not how things are supposed to work
-
4 hours ago, paul_c said:
Made it with 22m/s dV left!
The burns were (approx):
1. 100 m/s to leave Ike for a wide Duna orbit
2. ~40m/s to adjust to not encounter Ike again
3. ~600m/s to do Duna > Kerbin. Due to my very wide Duna orbit, the planets didn't really align with my ejection angle, so I tried the 'first' one that looked about right - I might have been able to do a quicksave and try the 'next' orbit of Duna to see if it were better...but if it wasn't....
4. ~600m/s to insert into a Kerbin orbit, with an adjustment of inclination just as I entered its SOI to encounter Minmus on the way outThen the problem was, I was heading for Minmus with way much more than normal velocity. So the retrograde burn to insert into Minmus orbit was about 650m/s, then the rest was used for the de-orbit and landing.
ok, i did a quick trial. and by quick, i really mean "i can't be bothered to do things properly", and i spent much more than i could have. but i still needed 500 m/s less than your trajectory
this is my "probe", very simple. I deactivated commnet to not bother about antennas and planetary occultations. the important part is the vacuum deltaV, 3643 m, to judge how much i spent
start: i cheated the probe in ike orbit. from there, without too much hassle i find an intercept with kerbin for less than 700 m/s. that's cheaper than going to duna orbit first.
Do notice that it's year 1, day 259: i am well outside of an optimal transfer window. the graph underneath shows that i could save 500 m/s launching at a more favorable time. but i didn't want to wait two years; i had this old save that was mostly empty and had the right time, so i used it.
Anyway, I overdid the burn. now i will need a course correction
I am waiting until i am in kerbin's SoI to make the course correction, even though it would be better to make course corrections earlier. I spend 60 m/s for it, when i could have gotten away with less than 10. but it was easier doing it this way. I also fix my orbital plane to come in close to minmus plane. This far from a planet, plane changes should really be cheap
also notice my periapsis, 45 km. i eyeballed this as a good altitude for aerobraking. my intercept speed is 500 m/s, i will need to lose some of it. remember, if i had launched in a proper transfer window, i wouldn't have to spend so much for capture
At periapsis I almost burned up, which means my periapsis was quite good. I aerobraked some 100 m/s, i need to use the rocket to provide the rest
400 m/s of additional burn see me in an elliptic orbit
apoapsis is quite right for minmus intercept. i just need a small nudge to get away from kerbin's atmosphere
now, since i've done a good job picking my entry trajectory, i only need a very small burn to fix my plane. though you can get to minmus with a wrong orbital plane if needed.
minmus is on the opposite side of the orbit, i just need to wait some orbits to catch up
here i come close. actually i am a bit late, which is bad. I can delay my craft easily by raising my apoapsis, but i cannot speed it up. now, the proper thing to do would be wait another minmus orbit until i can get a better intercept. or go back one orbit, lower my apoapsis (when apoapsis is so high, you can easily increase/decrease your orbital time by one day with a few m/s), and increase it the next orbit. I didn't want to be bothered, but i could have saved fuel there too
So I make a radial burn. You normally want to avoid them, cause they are expensive, but when your orbit is so high and slow, they become quite cheap, and they are convenient ways to grab moons in eccentric orbits. 100 m/s for intercept, 250 for capture. then it's a normal landing
landed with 1943 m/s. i started with 3643, so i spend 1700 m/s exactly.
and that was on a hasty attempt, outside of an optimal launch window, and making course corrections in a very suboptimal way. I bet it would be possible to do it with less than 1000 m/s for a challenge.
I really have no idea what you did wrong to get such a high consumption
-
3 hours ago, paul_c said:
Made it with 22m/s dV left!
The burns were (approx):
1. 100 m/s to leave Ike for a wide Duna orbit
2. ~40m/s to adjust to not encounter Ike again
3. ~600m/s to do Duna > Kerbin. Due to my very wide Duna orbit, the planets didn't really align with my ejection angle, so I tried the 'first' one that looked about right - I might have been able to do a quicksave and try the 'next' orbit of Duna to see if it were better...but if it wasn't....
4. ~600m/s to insert into a Kerbin orbit, with an adjustment of inclination just as I entered its SOI to encounter Minmus on the way outThen the problem was, I was heading for Minmus with way much more than normal velocity. So the retrograde burn to insert into Minmus orbit was about 650m/s, then the rest was used for the de-orbit and landing.
you could have optimized much better
1-2 those burns made things a bit easier to plan, but they were absolutely not needed, and indeed they were even detrimental. you gain absolutely nothing on going from ike to high duna orbit, and in fact you lose some obert effect.
3 600 m/s looks just about right for a duna-kerbin intercept
4 huh? this looks completely wrong. you should need very few deltaV to get captured in orbit around kerbin, unless you were coming in from a bad transfer manuever.
5 again, this looks way too much.
i am reluctant to try it because the kerbalism mod makes a simple test like that much harder, but maybe i'll give it a try
-
Ok, so I have this big ship with over 1000 parts, and that may helping the problems. the thing is, it seems some fuel tanks are detached from the ship
Here is the ship, minus the docked shuttles
while huge, it's nothing particularly strange.. there is a central body, and 4 S4 tanks attached to it, and two of those have another S4 tank. the tanks are attached laterally to each other.
Here, though, you see that when you select the top tank, there is no fuel transfer option available. indeed, there is no fuel transfer between that and the rest of the ship. not even if i select the option to ignore crossfeed rules
Indeed, after fuel runs out in the top tank, the engines attached to it stop working (they are active and they had been working until a moment ago)
reloading back some saves, i discovered this bug was there since ship assembly (EDIT: but when i launched back the central body, it works. it was introduced sometimes during docking of the other subunits).any suggestion on how to fix this?
-
1) that's the best way to make long burns, because you take advantage of oberth effect. Duna to Kerbin, though, is only a small nudge, so you probably are better off not going for the assist
2) yes. aerobrake as much as you can, again, a duna-kerbin transfer shouldn't have a huge intercept. according to the launch planner, it would be 100 m/s to enter an elliptic orbit around kerbin
3) you can, but no real need. when minmus is generally in the right position, and you are in the high part of your ellipse, make a straight path to minmus. you will be going slowly in the high part of your orbit, so the manuever should be cheap.
your plan would still work fine, though
In general, you may even spend less than 1050.
[1.5 - 1.10] Kerbalism 3.11
in KSP1 Mod Releases
Posted
please, calm down. i recognize that a lot of stuff i asked is actually written in a way that's reasonably within reach (a lot of other stuff, though, isn't), and i apologize for spamming this thread.
but i'm putting much more effort in finding that content than you give me credit for. I did read the FAQ page, the wiki link (that's basically an intro, at the time i missed the additional pages), the readme, and a few pages that were linked to me. and everything i could find in the in-game tabs. and it was already enough information that a lot of it went over me. i still missed a lot of stuff, but i did try to read before asking. and, as i said, i'm uncomfortable with github. BY that i mean, i don't get github. i can't figure out how it's made, how to do stuff in it. I don't know why. it doesn't really seem that different from a forum, or a wiki. but i look at a page, and i go in confusion.
And just because something is written down in a manual, it's not a good reason not to ask. Look at the question section of the forum, 95% of the stuff that gets asked could easily be solved by pointing people to some tutorial. now, what kind of community would this be if every time some new guy full of enthusiasm went and asked something we were all "you clearly are making no effort at this, because in the front page there is the list of tutorials, and from there you'd eventually find your answer"? If "it's written in a book, go read it" was a good way to learn, my job wouldn't exhist. But then, perhaps I am a teacher specifically because I have the patience to tolerate people asking silly questions until eventually they arrive at the smart ones.
Anyway, sorry for being a bother and for my mild IT incompetence. I will try harder to look on github in the future, especially now that i've seen a bit better how to navigate it.