Jump to content

schlosrat

Members
  • Posts

    100
  • Joined

  • Last visited

Reputation

23 Excellent

Profile Information

  • About me
    Spam in a Can
  • Location
    USA, Florida, Space Coast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, Is there's a setting somewhere that can control when/if the rendezvous autopilot does a match planes maneuver? I find that when there's some infinitesimal difference between two orbits it forces me to do this - which wastes a lot of time getting around to the AN/DN point. If I go into the rendezvous planner I can can skip this step for orbits I know to be "close enough" and go strait to planing a Hohmann transfer. Once on that transfer orbit I can enable the rendezvous autopilot and it will take things from there. That's my workaround, which is a bit tedious and eats up screen real estate with both the rendezvous planner and autopilot open. Is there a way to set the tolerance for the rendezvous autopilot so that it will skip the align planes step when the planes are within some tolerance, say a degree or two? It's really not a big deal if the match velocities step fixes the plane difference. If this isn't a setting somewhere could it be made a setting? FYI, I'm using MJ2 2.12 and KSP 1.11 if that matters. Thanks!
  2. Thanks @VoidSquid. That sounds like just what I've been observing - and it even includes a handy work around!
  3. Thanks @RoverDude. I made a Karimute like yours and was able to EVA from both ends just like you did, so I went back to my Karibou and discovered that the issue was being caused by the fact I had an OP-E Large Scanning Arm attached to the cab. The scanning arm was attached to the top in the black area between the headlights - so not particularly close to where kerbals appear when on an EVA. When I removed it entirely from the cab I was able to EVA. I also tried attaching it in other locations. I found that no matter where I attached it, the part it was attached to would report it's hatch was blocked. This also happened on a Karibou Crew Cab, so it's not limited to the Expedition Rover or the Malamute Cab. It also happened with a CRSY Light Scanning Arm and an SPRT Medium Scanning Arm, but it doesn't happen when I attach a ChemCam. Since even the CSRY Light Arm is more massive than a ChemCam (0,06 > 0.05), I tried attaching an SC-07 SC-9001 Science Jr (0.2 tons) up between the headlights. That did not prevent EVA the way each of the scanning arms does, so it has nothing to do with mass or the size of the attached part. Maybe it has something to do with the articulation of the scanning arms? This effectively gets me un-stuck as I can attach the scanning arm to an un-crewed part where EVA will never be an issue. FYI - I tried attaching a CRSY Light Scanning Arm to a Mk 1 Command Pod and I got the same result - hatch blocked and unable to EVA, so the problem is apparently with the scanning arms - or perhaps with some mod I've got that's messing with these arms (not sure what that would be...) As a follow-up clue, though possibly unrelated, the cab lights don't work quite right. Turning the lights on produces light cones falling where you'd expect them, but the windows and lights themselves remain unlit. Thanks!
  4. Is anyone else having an issue with the exit hatches on the Malamute and Karibou cabs being blocked in KSP 1.11? I believe in past versions I've been able to EVA kerbals from these caps and they show up dangling off the front of the cab. Now I can't get them to EVA from the cabs and need to transfer them to another part and EVA from there. Is this the intended behavior now? If so, bummer - kind of tedious to shuffle kerbals around just to be able to EVA and get a soil sample or whatnot.
  5. Thanks @taniwha! If there's some lingering edge of the window still hiding out there I've not been able to find it. Must be my poor eyesight to blame.
  6. @taniwhaI'll be happy to try to help with that. I have a hunch I'll follow up on. I was running without Click Through Blocker until recently so it may be that with the EL window open I clicked on something over it and then inadvertently moved the EL window as well or instead or something like that, but one simple test would be to open the EL window in the VAB and simply attempt to move it off screen. If you can do that, then any fool (myself particularly) can also do that and live to regret it. @kspnerd122 Have you tried using EL in 1.11? I've been using it for a while now and not seen any issue. Give it a shot.
  7. Hey sorry to be a pest, but can we get a fix to prevent the EL build resources window from being movable off the screen in the VAB/SPH? It may not come up often for you, but it comes up ridiculously often for me - even when I'm being careful. Yes, I can go in and edit the save game file, but this seems like a pretty poor approach. I see where the MJ window in the VAB literally won't let you move it off the screen. There is apparently some guard code that checks if the window's new position would be off the screen and prevents it. Something like that would be great! Never have to deal with the problem again. Barring that a button or some way to reset the position would be nice. Thanks!
  8. I just wanted to follow up and say that the fix works fine in 6.8.3 as well. Sure the button looks funny, but it works just fine. Thanks again!
  9. OK, I was being stupid and resetting the BuildWindow rect when I should have been resetting the ShipInfo rect. Oops, my bad! Rolling back to 6.8.2 does fix the button appearance, but I suspect all that nonsense I posted above about the button not working is incorrect. I'm going to try it again in 6.8.3 - but basically it was me resetting the wrong window rect and not getting why the window didn't reset... Oops.
  10. Hi, Once again I've managed to moved the EL dialog window off the screen in the VAB. Curiously, this time I thought I was being very careful not to do that since I recall it was a hassle to fix last time - requiring manual edit of a save game file. I know you answered how to fix this back in May: I updated to the latest EPL 6.8.3 (I managed to move my build window off screen before I'd updated and I was previously using 6.8.2). I also followed the instructions previously posted to edit a quicksave to set rect to 0,0,0,0 for the BuildWindow in the SCENARIO block. Unfortunately now I can't get the EL window to come up at all in the VAB (outside the VAB it's fine). With or without a craft loaded the EL button now has a black background (unlike the gray background other buttons have), and pressing it does nothing. I've also tried putting the rect numbers for BuildWindow back to what they were pre-edit (1471.79688,252.960938,695,582), but that didn't help. I tried starting a new game since this could be save file related, and in a completely fresh sandbox game I'm also unable to get the build resources window to come up in the VAB with a stock craft loaded. I think a clue here may be that the EL button looks different than it has in the past and different than all the other buttons - where if you move the mouse over other buttons they "highlight", and their button background gets darker while you press them, but the EL button background is oddly very dark all the time (much darker than a pressed button background). I suspect there's something wrong with how the button itself is operating and so no window ever comes up no matter how hard you press it. So I'm stuck and not really sure what's going on here. The old fix doesn't seem to be working, but that may just be a side effect of my upgrading to 6.8.3? Not sure what to do.
  11. Thanks @RoverDude. I don't think I've got MKS installed - so perhaps that's part of the problem? The USI tools I've got are Akita, FTT, FX, Karibou, Konstruction, Kontainers (which brings in these parts obviously), Malemute, ReactorPack, and WarpDrive. I've avoided MKS mainly because I prefer the simpler EPL build process. I'll go have a look at what I can find about this over there.
  12. Hi Just curious where I can find more info on how to use the planetary and local warehouse capabilities. Not sure when those got added, but they seem to be breaking my use of the parts. Really, I just want to be able to configure a Kontainer to hold RocketParts for use with EPL, but in 1.10.1 they're all setup for use as either Local Warehouse or Planetary Warehouse, with no apparent way I've found to actually put something useful inside them. They're really pretty - and as parts I really like the look of them. I've used them tons in the past; but now they're just wasted mass. No way to actually put anything in them I can find. So... pretty, but useless, making them ultimately pretty useless. Short of writing a MM script to gut this capability and put it back the way it was I'm not sure what to do with them. I suspect I'm missing the whole point of them. Sure, I'd love to have nearby vessels be able to share resources - but if you can't put anything in them, then what am I sharing? Vacuum? Thanks!
  13. Hi does anyone know how to turn off the tooltips? They get stuck on and then get in the way of other information I need on my screen, particularly in map view. Thanks!
  14. Hi Guys, I ran into a problem in my career game that might possibly be related to this mod,. though I tolerated the problem for so long that I have no way to say "do this and that will happen". I'm really kind of guessing about what caused the problem, however I suspect it might be possible to also fix this sort of problem with this mod, so I'm sharing here to. The problem I observed was that at some point in my career if I went into the Astronaut Complex, I was not going to be able to get back out. This led to my creating a bunch of kerbals using Ship Manifest since I couldn't hire any - though I believe I had already created a few using this mod by that time. The problem I was experiencing in the Astronaut Complex was that I would get exceptions generated in the console any time I pressed the button in the upper right to leave that building. I basically couldn't find any way out other than quitting the game. The exceptions that were being generated were this: [KerbalRoster.ValidateAssignments] NullReferenceException: Object reference not set to an instance of an object: at KerbalRoster.ValidateAssignments (Game st) (at <48dcb08e2e1542e2af1286b02d2eb072>:0) Looking up KerbalRoster.ValidateAssignments I found here that this class "Validates all assigned crews against being on non-existing vessels. May never happen, but it was a bug once so it might still be a thing now." There are also references scattered around the web that this bug was fixed in 1.4.5, but that later versions forked off of 1.4.2 and so the bug may have found it's way back in. Ultimately this led to me examining each Kerbal in my persistent.sfs where I found this: Three kerbas had a type of Applicant, but also had a state of Assigned (how can that be possible?) One kerbal had a type of Unknown and a state of Assigned (Seems pretty likely this was the cause or at least a contributing cause) All other kerbals had type of either Crew or Applicant All other Applicants had a state of Available All Crew had a state of either Available or Assigned Upon changing the type to Crew for all the Assigned kerbals I was able to enter the Astronaut Complex, hire some more kerbals, and get back out! I'm wondering if Ship Manifest might be able to help automate cleaning up something like this?
  15. Opps, I posted on the old thread. Sorry. I've moved my post to the new thread.
×
×
  • Create New...