schlosrat

OK, so I buildt the first section on landing legs since EL is determined to start craft up high and then lower them into place (nice touch, great for vessels, but can we turn that off?) Now it's curious that my modular base craft are coming in oriented wrong. Surely the orientations on the micropads hasn't changed has it? That seems astonishingly unlikely, but I suppose it's possible. If the micropad orientations haven't changed, then why did the craft I've built (with the correct orientation in the VAB) come in rotated by 90 degrees on it's long axis? These craft never did this before, so something must have changed that affects this. FYI - All of my modular base parts have the root part as the part that should be attached where a micropad is, and in general they've got another micropad already attached with the correct orientation to keep on building. Here you can see one of the micropads on my modular base core with the cyan arrow up. Attached where the Branch 1 micropad was is my modular smelter, rotated incorrectly by 90 degrees... Confusing!

OK, so removing TweakScale solves my vessel loading issue and I can build things. Great! Now why are they coming in so dang high? My modular base sections have FASA launch clamps under then to hold them in place. I've built these before, and always in the past the first one I build comes in at the same height above the origin stake as it is off the floor of the VAB. Now they're coming in at a silly height that isn't especially useful as the built in ladders can't reach the ground now. I even tried adding a -Y Bounds stake (which I had been afraid would cram the thing right on the ground), but it still came in at the same silly height. Any clues why my build is coming in so high? Is it somehow related to the height above ground of the EL Survey Station in the lander? It almost looks like those might be related, but why?

On further investigation it seems to be something going wrong with the vessel load, and in particular it appears to be incompatibility with TweakScale. I've got a metric crap ton of mods, so it took some time to figure out, but I can successfully load craft in the EL UI and build them so long as I don't have TweakScale installed. I can apparently have KSP Recall (which TweakScale requires), but not TweakScale itself. If I have that I experience the odd behavior described above. I am, however, seeing occasional odd behavior in my tests where the survey stake explodes if I time warp during the build. I don't think this is related to the other show-stopper effect, and sometimes the build works fine while other times the stake explodes. The apparent TweakScale incompatibility is a bummer for sure - I like that mod! But if it's a choice between being able to build things or being able to tweak the scale of things, I'll go with building things and find other ways to get the part sizes I need.

Hi, Long time user back from a break. Love that EL has been updated for 1.12 and the look of the new UI! I'm at the point where I'm attempting to build a first base in my 1.12.3 game. I have a lander with ample rocket parts, electricity, an EL survey station and a command pod. When I pull up the new UI I see I've got my productivity above 1.0 depending on how I move my kerbals around. Jeb's my pilot with 2 stars, and I've got Bill (2 stars), plus three other Engineer kerbals (two at 2 stars and one with just 1 star). I sent Jeb out with a mallet and some stakes, and he placed a nice D-O stake not too far from my lander, then got back aboard. So far everything seems like it's going just fine. The UI shows my lander as the pad, but nothing comes up in sites. If I click into the sites field I can find the stake Jeb placed, but I can't seem to get it to show up in the field other than in the drop down menu you get when you click that field. If I attempt a select a craft to build under these circumstances (pad selected, site visible in drop down list, but not showing up in the Site field otherwise), then KABLAM! The selected craft I'm loading appears where the Survey Station is sending parts of my lander flying every which way. As much fun as explosions are, it's not my desired outcome and is kind of frustrating. I turned to the manual to see if there's any guidance there, but didn't see anything I was clearly doing wrong. Do I need to seat Jeb in the Survey Station, or can he sit in the command pod like a good pilot and let the 4 engineers take the survey station seats? Would that matter to this situation other than possibly lowering my productivity slightly? I suspect the problem I'm seeing is related to the apparent inability to select the survey site, though it's also strange that the moment I press Load the craft I want to build appears fully formed (though in the wrong position and orientation) without waiting for a progress bar or any amount of build time. Just press this button and watch your lander instantly explode... Update: I tried with Jeb in the Survey Station and still can't seem to select his survey stake - it's sort of like it shows up grayed out in the field, though you can rename it and see it in the drop down. This time, when I pressed load in the Select dialog the craft appeared just a little ways off (oriented wrong, floating unnaturally in space, not falling or anything) so that it didn't collide with my builder, but nonetheless I couldn't "build" it.

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!

Thanks @VoidSquid. That sounds like just what I've been observing - and it even includes a handy work around!

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!

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.

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.

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

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!

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!

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.

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.

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.

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!

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!

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?

Opps, I posted on the old thread. Sorry. I've moved my post to the new thread.

SOLVED! At least in may particular case under 1.9.1 While I'm not sure how this happened, I suspect it could somehow be related to my use of the Ship Manifest mod, which is how I create almost all of my kerbals; though that in part is also due to the very long span of time I've tolerated this issue which has previously meant that my only options for adding crew was to either rescue them or create them on the fly using that mod as entering the Astronaut Complex would always result in my being trapped there. It also might be related to my use of Custom Barn Kit, which allows you to set a fixed cost per Kerbal you hire (among other things); but I think I added that mod after I first observed this problem. In any case, what I found when digging through all the 114 Kerbas listed in my persistent.sfs file was this: Three kerbas who had a type of Applicant, but also had a state of Assigned (how can that be possible?) One kerbal who 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! So, bottom line, pretty easy to spot and fix in your save file if you know what to look for. As always, when editing your save file be sure to make a backup first! Cheers!

I'm having this same problem only for me it only seems to come up if I enter the Astronaut Complex. One in, there's no getting out. Observing the console reveals this error popping up each time I attempt to exit that building. The only way out is to force quit the game and go back to whatever is in the save. I've got no way to go back to a save prior to this since I've got no idea how far back this goes and from time to time I wipe out quick saves to save space. For me, the only option is to edit the persistent.sfs - but I've got no idea what I'm looking for. There are only 6 tourists in the save and none of them have names like any of my other kerbals. Any ideas what to look for in the save file? I'm running 1.9.1 BTW.

Thanks @taniwha! Finally got around to trying this and dang it was easy. Very quick, and I didn't even have to close the game to effect the fix. Thanks!

I've tried both ways. I normally use Kerbo Katz science automator to drop me out of warp and run things. It can be configured to either run or not run single run experiments, collect or not collect the sciance , and reset or not reset the experiments. I've tried having a kerbal on EVA run the experiments with that mod set to not collect or reset and I'm unable to get the parts to reset using a lvl 5 scientist close enough to get the PAW and operate the part So far the only fix I've found a to gut the module code that does the animation etc and drop in the module code from the stock parts. This gives me parts that are single run, not dual run, but they look good, weight the same, and will at least reset properly.

I've run into a curious annoyance in my career game that's not showing up in a sandbox save I've got in the same instal. I've somehow managed to get things set so that I can't see the el build resources window in the editor. I've tried setting the switch to show it in the editor before going into the vab and I've tried both with an without blizzys toolbar. Nothing I've tried will make it visible now in my career save, but in a sandbox game it's right there. I suspect I've somehow shifted it off screen so that when I toggle it off and on its appearing and disappearing off stage. Is there any way to reset the location of the window?

Is anyone else having an issue in 1.9.1 where the micro goo pod and the science micro will not allow reset even with a level 5 scientist on EVA? I'm currently unable to get them to clean up from a Science Lab, and sending a scientist on EVA is also not working. I can endlessly run the stock Squad parts using a scientist to reset them, but once I've taken two samples with either of these they are nothing but dead weight on my craft (pretty dead weight, but useless all the same).