Jump to content

king of nowhere

Members
  • Posts

    2,391
  • Joined

  • Last visited

Posts posted by king of nowhere

  1. 2 hours ago, Gotmachine said:

    Which, like the content of your other posts, tell me that your making zero effort in searching for answers before spamming this thread.

    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.

  2. 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

  3. 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.

  4. 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.

  5. 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

    YOt7j7k.png

    laIho0c.png

    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.

  6. 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?

  7. 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

    5K2GQod.jpg

    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

  8. 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

  9. 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.

  10. 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

  11. 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

    Spoiler

    Ideally, 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

  12. 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.

  13. 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

  14.  

    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 out

    Then 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

    HgbIK2a.png

    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

    JlU3pEx.png

    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.

    4KGgRNz.png

    Anyway, I overdid the burn. now i will need a course correction

    6m5fuuc.png

    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

    x3yg746.png

    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

    XWYYOjN.png

    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

    Ei9ZaFk.png

    400 m/s of additional burn see me in an elliptic orbit

    1E9sCBB.png

    apoapsis is quite right for minmus intercept. i just need a small nudge to get away from kerbin's atmosphere

    qlF6C9x.png

    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

    WsFgvfN.png

    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

    7JRSDnr.png

    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

    MYRElv6.png

    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

  15. 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 out

    Then 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

  16. 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

    gH0PCdw.png

    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.

    xP8bMoX.png

    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

    tn6yq2R.png

    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?

  17. 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.

×
×
  • Create New...