jd284

I made a MM patch for that purpose some time ago, it worked in 1.1, haven't tried in 1.2 since I switched to USI-LS. It adds a hexcan using TAC converters. The conversion rates might also be off now. But you can use it as a start.

Try some of the other systems in the top post then, listed under "Alternate size solar systems".

Yes, that function would give him the time elapsed until the body has rotated under the orbit, which means the next closest approach would be either then, or up to one orbital period before or after. Presumably he knows the orbital period (or it's easy enough to find out anyway setting a manoeuvre node ), and can put that in the timer advance value. And if none of these are close enough, he can set an alarm for the next possibility using the same function. Now, asking for automatically doing that on all future revolutions until the end of time isn't really useful. He'll not be very happy to learn that the actual closest approach is 574 years in the future... so at the very least that would need a proximity tolerance, because there's either "close enough" or "not close enough". It doesn't really matter if he could get a little closer 2 years from now. And in any case, computing that would get quite complex for little added benefit. I'm not saying that you need to change the orbit or anything, and with an equatorial orbit it wouldn't work in any case unless the navigation point is on the equator. So all that needs to be done is to use the existing function in a new way and you can give bpiltz the information he needs, or at least something close enough.

KAC basically already does this, but in the opposite way - as launch timer. It would just need to swap "from ground location to target orbit" with "from orbit to target location". Instead of "mind-bogglingly complex" this should be nearly trivial. Adding a UI interface for it is likely going to be more work than computing the timer.

Do you have enough mulch, and do you have room for the supplies being created? That load could be just right for the supply consumption of your kerbals, maybe supplies are full, or there's no mulch?

[edit] Seems like the check for this option happens in DrawGUI(), but the code won't even get there when the game is paused because there's another check in the function that calls it, which doesn't account for the setting.

Is it just me or does the "Hide alarm clock when paused" option not do anything? Regardless of whether it's enabled or disabled, the alarm clock always hides when paused. I don't know what's even the point of hiding the window at all...

Please be advised, this post contains spoilers about anomalies. Don't read if you don't want spoilers.

I'm not very good with either the contract system or github PR's either, but as far as I can tell it would be just checking whether contractData.GetValue("type") != "RecoverAsset". At least that what it looks like in the savegame.

I think there's a bit of a problem with the handling of the new contract type. Since I updated to 1.0.0.5, I've been getting several contracts where I'm supposed to rescue a Kerbal and his/her craft. However when I accept the contract, they are on EVA and there is no craft in sight, so it becomes impossible to complete the contract without the cheat menu. I think the problem is the underscores in the RESCUE_POD_TYPES list. Internally KSP replaces them with a dot instead for some reason. And the problematic contracts all had parts with underscores, such as mk2Cockpit_Standard. Changing the name to mk2Cockpit.Standard made the contract work correctly, when I accepted it the kerbal spawned inside the part and not on EVA. So you definitely have to change the default cfg file and replace underscores with dots. Probably it would be best to also validate the list of part names after loading, to make sure you don't set part names that don't exist into contracts, when people accidentally make a typo in the list or just copy them from the part cfg with underscores. (Looking at the source, it'd probably also be good to check the contract type and make sure it's a RecoverAsset contract, since so far you only look at the fields and assume that if they're present then it must be the right contract type...)

Sorry for the missing images, I made new links for them. Most experiments are not biome-specific in most situations, that's why there's the "global" row for them. Only when landed/splashed are all experiments biome-specific. For everything else the situation row at the top indicates which experiments you can do in each biome. How I keep track of these multiple experiments is basically explained on the first page. Just label your science expeditions with numbers or letters, and put those in the box to know which experiments you've brought already.

If you see these parts, then you've started your savegame with an older version of USI-LS that had them as "official" parts. They've now been deprecated, which means that in new savegames you won't see them, and for now ships using them won't break yet, but you should replace them when you can because they'll be gone soon.

@tsaven, I've reported it in #176. You can tell by the supplies consumption being negative that you have a recycler running at >100% load. Remove some machinery from it until it's not above 100%.

Well, that doesn't help me much since I've never used Smokescreen. And the problem persists even if the only things in my GameData are Kopernicus, ModularFlightIntegrator, RealSolarSystem, RSS-Textures, Squad and ModuleManager.2.7.5.dll. So it's something related to RSS and its textures, or Kopernicus and its dependency MFI. If I remove the PQS block from the RSS Moon.cfg (to make the Moon flat), the problem is still there but less noticable because there are no slopes anymore. Now the ground contact error is only between 0.2m and 0.4m. Not sure what that tells me about the source of the problem. If it helps, here's a zip file with logs and savegame to reproduce it: Moon_jumping_base.zip Mainly I want to find out whether I should make a ticket for RSS or Kopernicus... or on the Squad bug tracker. [edit] Can't reproduce it on a stock game on the Mun, regardless of how steep a slope the ground contact error is less than 0.05m.

What could be the reason that some of my Moon bases spawn several meters in the air when I switch to them and then teleport back down to the surface? I'm using the 8192 textures v10.4 released on Mar 15 together with RSS v12.0, Kopernicus 1.2.2.1, and running the KSP 1.2.2.1622 64-bit version on Linux. The debug log has a message "[Materials]: ground contact! - error: -4.920m" when this happens. It wouldn't be a big deal but it causes drills to briefly lose ground contact, so I need to restart all drills every time I switch to the base, which is terribly annoying. Any suggestions for things I could try? Screenshot: left side before teleport, right side after teleport. The location in this case is 2.1088956°S 80.683676°E. [edited with more digits since I found out that it depends a lot on the exact location] [edit] I've now experimented with hacking the savefile and playing with the position of the vessel, and it seems it spawns at the height that belongs to one corner of the height map "tile" it's sitting on. The closer I move it to the corner the less ground error there is, until gets to the next tile. So basically, instead of a smooth incline it spawns as if the height map was a staircase, and then teleports to the real surface just before physics kicks in. So is it possible that the surface normal vector is wrong somehow? I've tried clearing the Kopernicus cache and it didn't help. A surface normal vectors stored in the textures? Does Kopernicus calculate them? Or is this a stock bug after all?. One more reason to stick with flat areas for bases... but this was the only location with Lowlands, Midlands and Lunar Seas biomes close together near the equator...

I just created a ticket about this but then I figured the discussion might be better placed here. The information window showing remaining supplies, EC and hab time etc. is currently very cluttered. I'll be happy to help with the implementation if you like, just let me know if my ideas are good and should be changed as proposed or not. I don't want to waste time on a pull request that would just be rejected. In my opinion, the main point this window should answer is whether things are going well or whether I need to intervene somewhere, i.e.: is there any vessel in danger of running out of supplies or hab time soon? how long is the active vessel good to go on unattended? (only if the hab time is running out:) which kerbal(s) need attention? Therefore it would be very helpful if the following points could be improved: supplies and EC remaining are the same for all occupants, therefore showing it repeatedly is redundant, just show it once per vessel at the top (maybe optional) show times with only two significant units (if KSP can format them like that?), I don't need to see the times down to the second for multi-year timers sort by the kerbal's remaining hab time (either vessel time or home time, whichever is shorter) so that the shortest remaining hab time is on top allow collapsing the list of the individual hab times, and only show the shortest hab time of all vessel occupants (this could be a button to collapse it, a checkbox to select the type of view, etc.) sort the list of vessels by shortest time remaining (supplies or hab, disregard EC for this), but put the active vessel on top of the list (maybe optional) show the remaining supplies and hab time in green without factoring in the grace period (like is done in the VAB), switch to orange and display the grace period only after supplies or hab run out (currently I have to subtract the 15 days to find out how long the supplies are actually going to last; I don't want to consistently starve my kerbals near the end of every transfer) Regarding the things I proposed as optional, let me know if it'd be better to put them in the general setup window, or as controls in the status window.

I found a green monolith on the Moon (playing RSS), about 100km east of the northern "standard" one. But it didn't do anything. Is the tech-unlocking feature a random effect? Or does it just not work in RSS?

Those of you having issues with the efficiencies, such as recyclers not worked in the background and kerbals becoming tourists and then going back to work, make sure you have the latest USITools (0.8.6). RoverDude fixed the efficiency issues there but didn't make a new USI-LS release yet with the updated USITools. So just update it manually and things should work better.

You'll have to obey the original license, of course, but I don't care if you want to include the DLL. Don't put my name there though or people will start expecting me to fix bugs too... all I'm good for is pressing F8 to compile it and hope nothing breaks...

I have recompiled KSCSwitcher for 1.2.1, seems to work fine for me but no guarantees whatsoever. Feel free to try at your own discretion though. Download - only has the DLL which you need to replace in the Plugins folder. Keep the rest of the files.

I'm trying to add the "3D printing" functionality to the MKS Workshop, but getting IndexOutOfRangeException when clicking "Open Workbench" and the window doesn't open. The recycler opens fine though. Am I forgetting to set something else? (Also, is "MaxPartVolume" still a valid option?) MM code: Log: Let me know if there's any other info that would help. [edit] Turns out I also need to add all the categories individually. Seems a little verbose, but OK. And no, I guess MaxPartVolume no longer exists.

OK, I made a ticket. Thanks for looking into it.

Well I can't have regular fins below because they'd mess up the landing (going engine first). What I wanted is something like this: Falcon 9 grid fins You see them there at the top of the first stage. Retracted during launch, deployed for the landing engine-first. Here's a simple example of what I have: There's no control input from me. The grid fins are retracted so I hoped they'd have no lift, but you can see the huge yellow arrows coming from them anyway, and in a really weird direction too. Also red drag arrows. So it looks like the only way this will work is by hiding them in a fairing.

OK, so there's no way to deactivate them so they don't mess up the launch? I have to hide them in a fairing or something?

Grid Fins - How do they work? Is there any guide on how to use grid fins? I tried to use them like on the Falcon 9, to allow a supersonic first stage to land safely. However regardless of how I placed them, the rocket didn't even launch right, as soon as it picked up some speed, even without control input and the grid fins still retracted, they generated large control forces (the yellow arrows with F12). Am I doing it wrong? How do I do it right? I expected it to work like this: 1. Launch rocket with grid fins retracted, so they don't generate lift. 2. Extend grid fins after separation, use them to steer the rocket while supersonic/transonic. 3. Land