Jump to content

Loren Pechtel

Members
  • Posts

    1,198
  • Joined

  • Last visited

Posts posted by Loren Pechtel

  1. 9 hours ago, AHHans said:

    If all parts with a command point - i.e. command capsules, probe cores etc. - get destroyed then the remaining parts are "just" debris. Did you check if there is debris at the crash site?

    I couldn't check, the box that tells you about the crash blocked everything and couldn't be dragged.

    However, I got the deorbit point dialed in right, put it in the ocean within sight of KSC at about .2 m/s (chutes plus the rocket) so it didn't bobble at all (the usual cause of water breakups I've seen is the rocket going too deep and being destroyed after the rebound), it looked perfect.  Then it slowly tipped over and every bit of the rocket that mattered was obliterated, I was left with a pile of engines and fuel tanks.

    It seems completely insane but I think the only way this design will fly is if I put decouplers on it and blow off the boosters at touchdown.

  2. I decided to try something.  I took the wheel off and put the very same wheel back on the outer part (so now there are multiple wheels)--I never picked up a different part.  Now it steers properly.  The only thing I can think of is roundoff--maybe the wheel's rotation is being rounded to zero.

    It does turn out I need more power for some reason, though--the battery drained while doing nothing in orbit.  I guess those tourists had too many lights on.

    And now I'm really confused!!  It didn't come down exactly where I planned but I thought I was doing ok.  I put it in the ocean as intended at about 3.5 m/s.  I hit recover and walked away to deal with a problem.  I come back to find it blown to bits by a hard landing.  How do I have a hard landing after I've already landed??  I've seen rockets damaged by tipping over in the water but I've never seen one annihilated.

  3. I do have a much heavier vehicle with the same wheel but this is not a case of being out of power!  That was my first thought, but I looked, the battery is nearly fully charged.  I expect it to turn slowly but it's got 7 minutes to turn maybe 10 degrees for the circularization burn.  I do not believe I need panels--the battery will be used to orient for circularization, but then recharged by the circularization burn.  It will be used again to reorient, partially charged by the deorbit burn and then probably fully charged when I burn to get it down to opening velocity (aerobraking alone won't slow this beast anywhere near enough.)  Once the chutes come out there's no more need for SAS anyway.

  4. (Note:  I've been away from the game for a while, maybe something has changed that's messing with me.)

    I have a probe core--the OKTO2, tweakscaled up to fit.

    I also stuck Jeb on board after the first flight got stuck.

    I have power (although no way to generate it--this is a tourist hop, it's only staying up a fraction of an orbit.)  Note that the engines gymbal if I attempt to turn the rocket.

    I have a reaction wheel.

    Furthermore, I have two designs.  The first is the core of the rocket--chute, core, wheel, passengers, fuel, engine.  This flies fine and has successfully completed a mission other than coming down in the mountains.  The second design adds a ring of chute/passengers/fuel/engine, all exactly the same as the core--I'm simply scaling it up to carry more tourists.  Mechjeb takes this up but won't circularize.

    The only thing unusual here is the lack of decouplers--I'm bringing the whole thing back and trying to drop it in ocean (no way it's not going to fall over on land) off KSC.

  5. 6 hours ago, RoverDude said:

    It's also unbalancing.  Saying this as the fellow who wrote the original MPL code for stock ;)

    Note that I said the extra should be a buffer, it shouldn't participate in the yield calculations.  I realize that if it did it would certainly be unbalancing.

    I don't see any balance issues in having an infinite holding capacity for output.  That's simply a matter of not having to tend it as often.

  6. 11 hours ago, Terwin said:

    To be fair, the 2.5m science lab is already more than capable of finishing off the tech tree in short order from just the Kerbin system, so what would be the point of a lab with 3x the efficiency if 3 labs is already over-kill for the tech-tree?

    Also, with those (relativly) new science storage modules, it is pretty easy to collect science for several labs to process in parallel if you want a huge collected science total after finishing the tech tree...

    Yup.  Some time ago I tried the science lab route to massive science.  I had already grabbed all the science from the Kerbin system so I went to Duna (or was it one of the moons?  I forget.)  I had a rover with all the science instruments and Bon Voyage to guide it.  A separate mission landed a science lab.  Gather all the science, upload to the lab, launch another copy of the science lab rocket, unmanned.  When the lab was done the scientist goes next door to the next lab, repeat the cycle.

    Then I discovered the mod that allowed you to use the extra science to improve parts was incompatible with Tweakscale.

    The one thing I did note about the science labs that I didn't like is they have limited capacity.  There would be less management involved if their capacity was infinite.  Since their yield is tied to how much science they have the extra input should be a buffer that keeps them full rather than simply increasing their working capacity.

    Note that in career mode once you have progressed far enough you can fund your whole program this way and not take another mission if you don't want to.

  7. 40 minutes ago, vossiewulf said:

    I'm not sure I would call a centrifugal hab "smaller", but I admit I didn't know some of those parts had that high a hab time or multiplier. I thought I had looked over the MKS parts carefully. Thanks, those will help.

    But I'll probably also take on the challenge of building a modular hometime-setting station where I can control how much hab time it has by undocking modules, because it will be complicated and another reason to build a giant overbuilt space station.

    Yeah, I had no idea there were hab time multipliers there, either.  The only way I knew to get high hab time was something like that earlier rocket studded with observation portals, or else a bunch of the big rings.

  8. 1 hour ago, RoverDude said:

    So a few points and I apologize for the brevity as i am on mobile.

    Fourth.  You are using a combination of quarters and hab multiplier parts right?  Making a vessel with hab times in decades is not hard.  But it's going to have a realistic relative size   if you are failing to use multiplier parts that's your problem.  Add a few cupolas and play with the math in the VAB 

     

    I ultimately just don't agree with your position above, and believe your issue is a vessel design one, coupled with unrealistic expectations regarding the psychological effects of groups squished in small quarters or subjected to isolation.  There is a reason NASA pays volunteers to study this.  Though I think vessel design is the more likely culprit given how Hardy Kerbals are configured to be.

    I do have a problem with how hab time works--we need some bigger parts.  Look at your example of a 5-year ship.  There are a lot of parts on there to get that 5 years.  I'd like to see some bigger things that provide the same benefits for similar cost & weight but using a lot fewer pieces.  If crew capacity and bonuses were altered by TweakScale that would probably do the job, although I would like to see an in-line module with bonuses.

  9. 35 minutes ago, silvermistshadow said:

    So, I'm trying to set up a Karibou rover. I've read some info about rovers and that their center of mass should be low. I definitely need to figure that out, as all of my Karibou rover designs so far have a tendency to flip over if I brake a bit too much on Kerbin. I've heard it's a lot worse on anything with lower gravity. Thing is, while I can figure out how to move COG forward/back on most things, I have no idea how to move it 'up' or 'down'. I don't really think that strapping things to the underside of the rover sounds like a great idea either. Of course, the easiest option would be to borrow someone else's designs, but I always have difficulty finding things. Another thing would be making sure it can recover itself when/if it does flip over. The inline RCS modules it can have, perhaps?

    On a mostly unrelated note, I'm off to go find something to help me with the whole 'vtol' thing, because Mechjeb doesn't seem to have a 'hover' mode. 

    It's not actually your center of gravity that matters, but rather the angle between the ground and the center of gravity.  The smaller the angle the more stable the rover.  Putting your mass low helps but it also helps to make your rover big.  It will be a pain to haul to orbit but it's a lot less likely to crash.

    Also, if you're willing to spare the mass & power, use reaction wheels.  Bring along a pilot or probe core capable of running SAS.  With SAS on it will use the reaction wheels to try to keep the rover from flipping.  I've taken rovers with big reaction wheels over terrain where you end up sliding down a hill--when sliding you can't hope to be careful and thus any ordinary rover will most likely crash.

  10. 9 hours ago, Starwaster said:

    Your second and third sentences contradict each other ;)

    Leaving your burn as late as possible is the opposite of a gravity turn in reverse. Apollo's lunar landers did the latter. Typically  starting with 115 x 15km orbits and braking at the low point. Pitching up just enough to manage their descent so that both vertical and horizontal are mostly canceled as they approach their landing sites. (keep in mind that their orbital velocity was starting at ~2km/s while doing this)

    The difference between the two (shallow vs steep) is that shallow landings have lower gravity losses. 

    But I guess for most KSP stock landings it's not usually an issue since our landers don't usually have to worry about delta-v that much or conserving any of it for the final approach. 

    Nevertheless, it is more efficient to do a shallow rather than steep landing. 

    I'm not contradicting myself.  On launch a rocket goes straight up, then soon tips with the rotation of the body and accelerates to orbit.  This is the lowest energy trajectory, you want to do the exact reverse to land with the least fuel.  The first burn puts your periapsis a bit above the point where you want to have killed your horizontal velocity (the reverse of your circularization burn.)  You then come in, lighting your rocket at the point it will kill your horizontal velocity over your target.  This of course means you end up lower than the orbit you were in, hence the reason your periapsis is higher than your objective.  As you approach your target you tip more vertical as you can't just suddenly turn vertical when you complete your burn.  (Now, if you have a small rocket with the vastly-overpowered rotation capability of many such rockets in KSP you would be better off not rotating until you're over your target.)  You still have substantial vertical velocity at this point, optimum is you shed it in a suicide burn.

    This isn't what Apollo did because they took the safe route.  Their approach burned considerably more fuel, though.

  11. 59 minutes ago, Starwaster said:

    Current landing AP is pretty wrong. Landing should be a continuous burn with no course corrections. Instead, if there is error then it needs to compute how much corrective burn it needs but then spread it out over the remaining burn time. And the current targeted system IS capable of that but only within the final stage of the burn and if the burn is interrupted for any portion of time it will want to do another course correction before moving on to the final burn stage.

    The landing AP also has no real concept of vertical velocity management which is why landing from too low an altitude tends to result in crashes. It spends too much time cancelling the horizontal velocity and unless its gravity turn orients downwards enough to cancel out the vertical before the suicide timer goes negative then it will probably crash.

    I've been sitting on some code for the AP that takes that into account and pitches up just enough to keep its downwards momentum under control. It works pretty well in scaled systems but not so much in stock so I never made a pull request on it. And it doesn't work for targeted landings at all. 

    I don't think keeping the downward momentum under control is what you want.  You want to leave the burn for as late as possible.  The ideal landing is a gravity turn in reverse.  Without knowing exactly how the rocket will perform you can't do that precisely, though, so you're going to need to allow some margin.

  12. 1 hour ago, HebaruSan said:

    There are, they just happen every 30 minutes or so. A trip to Minmus is just as much a Hohmann transfer within Kerbin's SOI as a trip to Duna is within solar SOI.

    A "transfer window" normally refers to a situation where you have three bodies involved.  The math is imprecise and much more complex than what you are thinking of with a Hohmann transfer.

    For a Hohmann transfer you simply need to find when you're at a point directly opposite where your target will be in half an orbit.  (If that gives a negative solution you missed it, look for the next such point.)

    Things like Transfer Window Planner and the similar functionality in MechJeb, however, are looking at a more complex problem.

    1)  Your target is in another SOI.  The simple math of a Hohmann calculation won't give the burn you need.

    2)  As there are three bodies involved (the ship, the starting planet, the arrival planet) there almost certainly isn't a perfect solution.  At the point your planets are lined up perfectly it's almost certain your ship is not.  Thus, rather than a simple equation that spits out one answer you have a much more complex equation that must be tested over a whole range of values in order to find acceptable missions.

    For a Hohmann burn the fuel use for a non-optimal burn goes up very rapidly as you get away from the optimum, you're going to want to do such burns as close to perfect as you can.  For an interplanetary burn the penalty goes up much slower, in general waiting around for your spacecraft to reach the correct point in it's orbit for the burn is going to have a very minor penalty.  (However, if you're orbiting near the edge of Eeloo's SOI and try to burn for Moho the error is so big you might as well forget about it--exit Eeloo's SOI on the inward side and then do it as a Hohmann maneuver.)  You can even send a fleet doing it one spacecraft per orbit without a big penalty.  (Just make sure their arrival times are also staggered as you can only fly one craft at once!)

  13. 3 hours ago, invultri said:

    Oddly enough, it seems to work when the stage would go below the 20km line and I am focussed on a craft in the Mun SOI. If I am in the tracking station, main ksp view or focussed on a craft in Kerbin SOI the stage is not recovered.

    Stages are only recovered when they go below the IIRC 22km line.  A stage that doesn't go that low will simply remain in "space" (even if it is actually orbiting entirely in the atmosphere!) and not be recovered.

  14. 27 minutes ago, LadyAthena said:

    I'm wondering if there is a way to remove the "habitation" requirements, or adjust them at all, as even flying 2 kerbals to Minmus requires a monster spaceship just to deal with the habitation alone. a 2man pod + 4 man living quarters for just 2 kerbals, which should allow them to live comfortably for a good time. Yet they get "home sick" before the mission ends, and that's just touching down for less than an hour on minmus, so its almost a complete non stop flight, which seems just ridiculous to me. I've lived in cramped quarters for months before out at sea, which ultimately is the same thing this system is trying to simulate. Yes its uncomfortable, yes it isn't very pleasant, but to think I'd just up and "stop working" especially when that work brings me back home, is paying the bills, and is what I signed up for is ludicrous to a retarded level..

    I get the "home sick" bit too, I actually like it, because it means you gotta either have a full fledged functioning "home" like base with everything, and or rotate kerbals out, which is realitsic, but that should take a year minimum, not days. Again you're an astronaut, you signed up for this.. Don't start complaining now... Otherwise I like everything else this mod does, and how it does it, but the balance seems to be geared more towards "lets make this challenging to a ludicrously unrealistic level". Are there anyplaces to mod, alter, or adjust the stats?

     

    To put things into perspective, a Submarine can and will stay submerged sometimes for up to 90 days. 3+ months, and I've heard of submarines staying submerged for longer during practices. These are EXTREMELY cramped and tight quarters which hundreds of men are sharing for over 3 months sometimes.. So again the "habitation" and "homesickness" thing is just... ridiculous to me..

    I would like to see a few changes:

    1)  The higher the Kerbal's level the longer they should be willing to be on a mission.

    2)  The submarine has a lot of people--I think that matters.  The more Kerbals around the longer they should accept the situation.

  15. 3 hours ago, alien_wind said:

    I'm not sure if it was mentioned here before already but does the eva canister supposed to be infinite?
    because it says on it that it has 10 eva-propellant but if I do the "refuel" action it does not decrease the amount..
    I can get a kerbal to orbit with this no problem on mun or minmus

    I can't address whether the propellant goes down or not but your evidence doesn't prove it.  The jetpack contains a ridiculous amount of fuel in stock.

    You can get to orbit on Minmus with your jetpack alone, no need to refuel.  One refueling (and note that a canister is supposed to provide enough for two) will get you to orbit on the Mun.  (Note that the Basic Orbit mod will make it much easier to do this, it lets you see your orbital parameters in the close-up view.)  In versions past I have done orbit-Minmus-orbit with one fuel tank and orbit-Mun-orbit with two.  Admittedly, I'm not good enough to accomplish the landings without a reload or two.

  16. 3 hours ago, octeris said:

    KSP Version: 1.7 (04/10/2019)

    Mods installed:
    [x] Science! - 5.17
    000_ClickThroughBlocker - 0.1.7.1
    001_ToolbarControl - 0.1.6.20
    CustomBarnKit - 1.1.19.0
    DistantObject - 1.9.1.1
    EnvironmentalVisualEnhancements - 1.4.2.2
    KerbalAlarmClock - 3.10.0.0
    Kopernicus - 1.7.0-1
    ModularFlightIntegrator - 1.2.6.0
    ModuleManager - 4.0.2
    OPM/CTTP - 2.2.2
    PlanetShine - 0.2.6.1
    Scatterer - 0.0540
    StageRecovery - 1.9.1
    StockVisualEnhancements - 1.4.1

    https://www.dropbox.com/sh/ajgf3qq6zkhigak/AABFbGRUYnIhAf52KVm4AfcBa?dl=0 contains the craft, the Career Mode save with contract active, and output_log.txt.

    The mission profile is relatively straightforward. Load up all 6 tourists + 1 pilot into the command pods and head to the launchpad. SAS on, throttle to max, and launch. I wait for 100-150m/s before pitching over about 10° East (hdg. 90°). Climb to around 10km altitude before pitching over slightly more (~20-30°). We're using 4x Terriers and 1x Reliant in the second stage, so we need all the altitude we can get from the first stage so that the Terriers in the second stage are as effective as possible.

    Once the first stage runs out of fuel there are 3 separate staging events (2x side, 1x center) to drop the 4 fuel tanks out from underneath the upper stage safely. Be sure you're dropping the correct side tanks first, based on the craft's roll, or you risk the fuel tanks colliding with the unseparated tanks.

    Engage the second stage and burn prograde. Depending on the ascent profile of the first stage you may or may not need to pause throttle to wait for the craft to get closer to apogee for the orbital burn. Generally speaking I've been burning prograde again immediately without waiting, as the Terriers' low TWR means they have to burn for a long time to get us enough dV to circularize. If we don't burn soon enough we risk either an extremely elliptical orbit or not reaching orbit at all. In any case, circularize/burn to a stable ~70-90km orbit.

    I then wait for or time-warp to the new apoapsis (previously our periapsis) before burning retrograde until our periapsis is around ~50km or slightly lower. I remain pointed retrograde (pilot SAS) for the remainder of the mission.

    Once we are just about in the atmosphere at ~50km I separate the 4 parallel pods from the top of their fuel stacks. Stage again to drop the remaining fuel/engines and you're left with a 3-stack of command pods, containing the two remaining tourists and the pilot. Fall to around ~30km or so, or until you're worried about too much atmospheric drag, and stage again to separate the remaining 3 pods. By the time you're at this point SR has usually recovered the 4 other pods. You can timewarp the remainder of the missions and everything should land safely.

    Please let me know how I can help assist further. I was thinking it might be worthwhile for me to attempt to reproduce the issue on a clean install of KSP with just Stage Recovery installed, in case the mods I have installed are potentially causing the issue. I noticed that was recommended in the "Get Support" thread stickied in this forum.

    Later messages seem to indicate you solved your problem (there's a reason it's recommended to uninstall old versions of mods before installing the latest!) I do have a comment about your mission profile.

    This sounds like you're just hauling tourists to orbit.  It also sounds like you have decouplers.  Assuming you have radial parachutes may I suggest an alternative design that would provoke outrage at NASA but it will fly:  Put your pilot in a capsule, put your tourists in the crew module (meant for aircraft but it works in space), take a heat shield and invert it and stick it on the nose of your rocket.  Then attach a decoupler and a nose cone.

    Simply putting a capsule on top of crew modules is very prone to lawn-darting a heat shield on the front will create enough drag that it will slow anyway so long as it's not too long.

    If that's not enough you can provoke even more howls from NASA by radially mounting more crew capsules--each needs the shield/decoupler/nosecone setup but you can fly it with only one command pod (although if it gets big enough adding a reaction wheel is a good idea.)

    I have flown suborbital tourist contracts with a slab of 5 stacks of IIRC 3 capsules as one rocket.  (Note:  I modified the number of available contracts, with the stock game you can't have enough tourist contracts active to fill such a bird.)

  17. 4 hours ago, Jumberlack said:

    Hi, I'm trying to understand how this mod works, what is the reason behind the limited number of different resource channels and why must they be input in the cfg accompanied by a power of 2 up to 32? 

    When you see things set up in powers of 2 like this you should automatically think bit flags--you can add together any combination of them and yet tell exactly what numbers were added together.  It's the most efficient method of packing such information and given that the author used it pretty much implies there was a lot of data to keep track of.

    The storage units that such things get stored in have standard sizes of 8, 16, 32 or 64 flags, each of which uses twice as much memory as the next smaller size.  Also, KSP mods are written in C# and while it supports 64 bit unsigned values they can be a hassle to work with because the compiler is so strict about not allowing anything it thinks could possibly be wrong.

  18. 11 hours ago, DaveLChgo said:

    Oddly enough now its working again for me.  Weird.

    Are you sure the stage isn't still up there?  KSP's destruction threshold is well below the top of the atmosphere and objects on rails do not experience drag even in atmosphere.  If your periapsis is above I believe 22km the stage will remain in orbit--even if that entire orbit is within the atmosphere!  (Careful--remember that you can't switch away from an object in atmospheric flight.  Switch to such a booster and you have to stay with it until it burns or goes splat.)

  19. 14 hours ago, HebaruSan said:

    A personal PSA: In the next 24 hours, I will be going on a vacation during which I expect to have no internet access, including this forum, GitHub, Discord, email, etc. (It's possible that I'll check in from a hotel computer, but I may not.)

    I will be back online on April 10. If you reply here, PM me, or submit an issue or pull request, I won't see it until then.

    See ya!

    A decent vacation on The Mun or a quickie on Minmus? :)

  20. 1 hour ago, boomboomtime said:

    I am using KSP version 1.6.1 and i installed KIA and KAS. KIS works but KAS does'nt attach to the hooks. It also wont let me use it in EVA. It would be great if you updated this mod to the current version, as there may be multiple people with the same, annoying issue. Glad to hear from you, great sir!

     

    Have a great day.

    Well, if you want to install a car into a spaceship you need the SpaceY mod! :)

×
×
  • Create New...