Jump to content

Loren Pechtel

Members
  • Posts

    1,199
  • Joined

  • Last visited

Posts posted by Loren Pechtel

  1. 14 minutes ago, KocLobster said:


    @smjjames
    Oh I hadn't realized that, it just seemed like that would logically be necessary.

     

    Can someone tell me if I'm doing this right? I think I calculated that I am producing enough electriccharge, and in the map it shows the scanner constantly beaming down the green thing, signifying it should be working. The planetary mapping box though is just a ton of static, it doesn't seem right. Also, the multi spectral sensor doesn't show if it's working optimally when I right click, just shows "start scan". Is it actually lacking power? Also, attempting to analyze either nets 0 science. It LOOKS like I have no electric charge, but I believe it's accumulating it as fast as it's using it, so I believe that I actually have enough. I don't really know though.

    http://imgur.com/C1FGK85

    The few of them that I flew seemed to need to do the "Start Scan" before they produced any data and strangely enough never produced any data below about the tropic of Capricorn even though the satellite certainly went there.

  2. 5 minutes ago, bewing said:

    That's what happens when the ladder is too close to being overhead. There is a large artificial torque in trying to grab a ladder at that angle, and if the grab fails your kerbonaut gets flung away.

    I wasn't even near the hatch (I've found that ladders at least in the vertical position were a hindrance, not a help--I omitted them from this launch.  Next bird I'll try some sideways ones and see if they will let me crawl around to the hatch better) when I bumped the rocket.  The messed-up perspective made me goof, I actually touched a fuel tank on the booster.  (Did my Kerbal freeze? :) )

  3. It's simply walking the shortest path between the nodes--this can way overstate the dV needed.  I just tried Mun surface to Minmus surface and it wants over 3000 m/s when in reality I think it could be done for half that.  The problem is that it has no concept of how far up a gravity well something is.  My impression is that this could be solved with arrows between all the "intercept" points within a gravity well.

  4. 5 hours ago, katateochi said:

    I find EVA spinouts are best resolved by switching off the jetpack and letting go of controls, then firing the jetpack back up again and hitting space. That will generally get you back in control. 
    Also you can change your roll by changing camera mode, which is a bit odd, but switching between orbital and free camera modes lets you roll by 90 degrees, and can make the difference when trying to grab a ladder.  

    The pack switched off when this happened and wouldn't switch on again.  Maybe he would have recovered in time but by then I would have been marginal on fuel even if he had (not being able to point at the rocket had wasted a lot of fuel already) so I simply reverted the flight.

  5. A Kerbal died today in the orbit of Mun because of a defective jetpack.

    <Space> is supposed to orient the Kerbal towards where it's facing--but for some orientations this does not work.  After many failed attempts to grab the hatch because of this (why can't capsules be outfitted with bars all the way around?  Ladders don't work, Kerbals refuse to move sideways on them) he was finally flung away at about 40 m/s and no longer would respond.

  6. 4 minutes ago, cicatrix said:

    Can you post pics of your hopper? I think this might not have anything to do with MJ. This may happen if you have asymmetric thrust and your center of mass shifts when you burn up your fuel. The lighter your craft is the greater the effect. Up to the point when your reaction wheels or RCS cannot handle it. Perhaps the picture of your hopper may help to see what's wrong.

    Sorry, I don't have a save around anymore.

    When I did it manually, just press Z and zoom into the sky it flew perfectly.  Furthermore, it flipped without the engine even being lit--this was clearly commanded.

  7. 28 minutes ago, Tex_NL said:

    When was I talking about a negative altitude? I never did.
    Minmus has many locations that are several kilometres above 0. The highest peak goes all the way up to 5750m. If you're landed on a spot that's 4 km high and set the ascent guidance for 3 km your rocket will immediately flip and crash.

    But my target was my tanker.  It should have taken the altitude of the tanker.  IIRC it was something like 100km.

  8. 11 minutes ago, Tex_NL said:

    Pretty sure I know what happened.
    You launched your rocket with the ascent guidance autopilot but forgot to check the altitude. The intended ascent guidance altitude was lower than your altitude before launch. As soon as you launched the ascent guidance assumed it had already finished the gravity turn and tried to circularize the orbit. Normally this would mean MechJeb points the rocket at the orbital prograde, warps to Ap and ignite the engine. Since you were already at your' highest point' it immediately flipped your rocket and ignited.
    I can't imagine any other behaviour that could cause the crash. MechJeb did exactly what you told it to do. You can not hold MechJeb responsible for wonky results when you give it the wrong info or target.

    PEBCAK and not a MechJeb error!

    I was launching to rendezvous  with my tanker.  How would I enter a negative altitude?

    This does give me an idea, though--I recall someone else having Mechjeb fly their rocket into the planet because they were using ion engines and the burn time was so long that the burn started far around the orbit but Mechjeb aimed without considering this.

    Now, it appears that Mechjeb is only looking at the best time to launch within the orbit and is not considering that the ground track can vary between orbits.  (Mechjeb's approach would be fine when aiming for something equatorial.  My tanker was in a polar orbit as I wanted to hit every biome and that would have cost a lot more in plane changes if my tanker was equatorial.)  Perhaps it was trying something like that--trying to match the tanker's orbit when it should have waited for it to rotate around instead.

    Unfortunately I don't have a save (I waited for a better alignment and then took it up manually) and now I'm on a new game where I'm not to the point of building such craft yet.  When I get there I'll see if I can reproduce it, though--I want to do some experimenting with it and see if I can write something that will let it handle a "land here" command while sitting on the ground rather than in orbit.

  9. 5 hours ago, cicatrix said:

    I think the problem was in the orientation of your control part (probe core). Did you detach anything from your lander? Was there a tug vehicle in orbit?

    Your control part (probe core) should be oriented 'upwards' (facing in the opposite direction of your thrust vector). If you have it upside down MJ would try to orient your PROBE CORE onto the 'correct' vector and if your engines happen to point in the wrong direction after this - well, that's just too bad.

    This was a hopper, IIRC on it's third launch from Minmus after the last refueling.  The rocket flew properly on the previous flights.

  10. 1 minute ago, Zhetaan said:

    The only other thing I can think of is that you somehow accidentally put the navigation into target mode, and MechJeb is trying to thrust according to your velocity relative to your tanker.  If that isn't it, then I'd have to call it a Kraken attack; MechJeb shouldn't be doing this on its own.  After all, the whole point of using an autopilot is that it knows which way is up as well or better than you do.

    It was targeted on the tanker because I was launching to it--but I had done that before and it worked, albeit not very well.  It messes up enough that I've about decided to simply launch into an orbit under it and use the rendezvous to actually catch it.

  11. 5 minutes ago, wasml said:

    What Zhetaan said. If the probe core was on upside down I could see this happening - easy way to check is look at the nav ball before launch. If the probe core is upside down the orange side of the nav ball will be visible - if not the nav ball will be on the blue side.

    Except this was a lander that had already been hopping around Minmus.  I have no idea of how to rearrange a rocket in flight and the only Kerbel on the scene was a scientist anyway.  Also, I was able to fly it up manually.  It flew as expected and MechJeb had no problem guiding it to the tanker.  (At least until it ran out of monopropellant.  Why couldn't the Kerbel use a tow rope to haul it in?  They were that close.)

  12. 8 minutes ago, Zhetaan said:

    Did you, perhaps, set your MechJeb module to 'Control from Here'?  Did you dock with your fueler using a radial port and set it to 'Control from Here' for docking?  Is your Kerbal in a non-command pod, or is your command pod in a weird orientation?  If your point of control is in a weird orientation (which can happen if you forget to transfer control away from a radial docking port, for example), MechJeb doesn't know the difference and will try to orient the ship according to that control point.  In the case of a radially attached port or the MechJeb pod itself, it means that the rocket tries to orient sideways.  The engine's thrust is perpendicular to that, and the end result is a cartwheel.  It's worse if your point of control is on the bottom and MechJeb thinks you're upside down.

    Pretty hard to select a docking target while you're still on the ground.  it's hard enough in space!  (And why can't it default if you have only one!)

    I have yet to build a rocket with a radial docking port.  The lander was a can, a fuel tank, a RCS tank and jets, an engine, a probe core, a docking port, one of every science instrument, legs and a ladder.  Next time it will also have lights.

  13. 4 minutes ago, Yemo said:

    @Loren Pechtel: Different case, same principle I guess. It seems to follow a strict rule (like if apo 10m below threshould, start burn) regardless of the actual effect of that action.

    However mech jeb is a really big project and the circumstances changed a lot recently (atmo, heating) and 1.1 will nearly certainly break stuff again. So it is very understandable that putting effort to optimize it now has small rewards considering it does not last very long until it needs to be touched again.

    Under those circumstances mech jeb dev is really great!

    And after 1.1 hits, offering support by feedback, suggestions and contributions (in code or otherwise) will make it great again.

    Fixing it's propensity for flying into the planet and it's poor choice of orbits when targeting something in a polar orbit shouldn't be broken by whatever is in the 1.1 update.  If it goes bonkers again on me I'm going to see if I can figure out why.

  14. 17 minutes ago, Yemo said:

    If you have SETIrebalance installed, that prevents your scientist from collecting goo and science jr (except if you also have UnmannedBeforeManned installed, in that case this rebalancing feature is deactivated).

    @Loren Pechtel

    edit: Oh, and on topic, yes mech jeb ascendence has great difficulties at the moment. It burns until apo is above the threshold and then totally stops thrusting even if that results in a loss of control, so it most likely flips without ridiculous (stock) RCS. If that flip lowers your apo below the threshold even by 10 meters, mech jeb burns again regardless where the rocket is pointing, essentially failing the ascent...

    Try an acceleration limit of 20 instead of 40 and adjust the ascent path to 55. And activate corrections or something. Not pretty but less horrible.

    No, I don't have that mod installed.  He could collect from the goo, just not from the science jr.  I couldn't interact with the science jr in any fashion.

    Despite the failings I brought home enough science from that mission to complete the tree (even after a docking calamity that left my lander damaged) and so I decided to start again with the difficulty bumped up.

    This wasn't a case of burning until apo was above the threshold--my rocket was tipping over on the ground before the rockets were even lit.  It flipped it and lit the booster heading into the ground.

    I downloaded the MechJeb source and had a look to see if I could see why it's very badly behaved when I try to land while not in orbit.  It's going to take a more careful perusal to understand but I can see it's blindly doing steps without seeing if that's appropriate.  I really wish I could say "land here" while sitting on the ground and have it understand I want a parabolic hop.  Scansats will show you the biomes--but only on the big map and you can't land with that.  Hand flying there's no reasonable way to target a desired biome other than with the cheat menu.

  15. 5 minutes ago, Frybert said:

    Really the only way we're going to know for sure whats happening is if you can get some video for us. I can 95% guarantee you that if you can show a video of whats happening someone can tell you whats going wrong in a heartbeat.

    I'll see if I still have a save around.

    The rocket works (except the materials bay--my scientist can't do anything with it)--this was the second trip up to the tanker with multiple hops per landing.

  16. 4 minutes ago, nobodyhasthis2 said:

    @Frybert is absolutely correct on RCS. It will restrict to reaction wheels alone otherwise. 

    Also need to point out that it likes to land a maneuver node and hold nice and steady. It does through a feedback loop that requires good control authority. If your RCS is not balanced or there is also a problem. Weak or modded saturated reaction wheels will also lead to delays in finding the node quickly. Plus if there is low RCS fuel anyway for manual maneuvers that is not going to help either. This can cause trouble on launch because it would normally just miss the burn time. However in a launch it has already committed to finding the node. In atmosphere the control surfaces can make up for the other two systems but not here obviously.  

    The automatic pilot is running a selection of modular scripted functions. So if it does not get into the right plane. It will correct by running the plane change script for it after the launch. This is where you might want to take it off autopilot and assess the situation briefly. Another rendezvous scripts or tiny manual tweak might help. It can also generate the launch guidance node to help as well so you can see where wants to go. It is not a fan of direct approach to rendezvous without orbing a few times. 

    It will fly a very generic curve to orbit (which can also be tweaked) that does not take into account the handling characteristics of an individual rocket. By default it also goes for 0.1 m/s accuracy and that a little too low in some situations. Minmus is very forgiving and that is something you could take advantage of in ways Mechjeb can't. 

    That is not say it does not work. It will do the job of several mods and is very useful. It just needs to be watched very carefully and needs a bit of extra fuel now and again. 

     

    Nobody has explained why Mechjeb would choose to flip over my rocket while it was sitting on the ground, though.  I was a few seconds from ignition when it tried to turn a cartwheel.  No visible exhaust so it could only have been the reaction wheel.  It was like it was trying to head through Minmus to get where it wanted to go.

  17. I'm on Minmus, trying to launch to meet up with my tanker in orbit.

    I launch, kaboom.

    I reload and watch the launch from the close up view.  Mechjeb uses the reaction wheel (it didn't light the engine or RCS) to flip my rocket over and then lights the engine when it's pointed about 120 degrees from the vertical.  Of course it goes boom.

    It's also doing some pretty horrible orbital matches when I do a launch to rendezvous.  My fueler is in a 89 degree orbit, there should not be a major plane change burn needed!

    Even with manually waiting until the target orbit passed overhead but then with a manual launch burn of about 80 m/s I used over 500 m/s to do the rendezvous.  (And, major curses, I ran out of RCS fuel.  I have to send up a resupply rocket to recover my Kerbel and the boatload of science up there.)

  18. 18 minutes ago, FancyMouse said:

    I believe OP's problem is just the problem that happens when you try to stick tiny-sized part to a huge-sized part - editor isn't so happy with it and need a special view angle/mouse positioning to make the tiny part green and attachable.

    And as OP said, the other way - attaching huge part to tiny one - has no problem.

    There's not that much difference in size--I'm using the one-man can, not the two-man can.

×
×
  • Create New...