voicey99

The K-Prize is still going, @boolybooly occasionally checks back to judge submissions (I can't say the wait though, it could be weeks). As for the craft, I'm assuming you put a cubic strut or something on the end of the horizontal bicoupler and then offset the vertical adaptor/bicoupler into the craft. Also, what are the ARIs for? The two SCIs should provide enough air the four RAPIERs, and at the speeds where you need all the air you can get the ARIs are next to useless.

Since version 1.3 came out, I see it is known that the Kerbal Standard sticker is always the default sticker now, but the custom sticker also seems to be overriding whatever texture you set it to for the flags, as whenever it is moved in the VAB or the vessel is launched it reverts back whatever custom sticker it has been set to regardless of whether it was set to a flag or not. All the existing vessels in flight have reverted to the Kerbal Standard sticker as well.

Currently the only means to transmit science is from a vessel to the KSC-but what if you could transmit it from vessel to vessel? I see two main uses for this-if a vessel had a relay antenna and an RGU on it (a probe control point, manned or not), other craft could transmit to that vessel (storing the experiments in the RGU) even when it is in the comm shadow of whatever body it is orbiting, to be (automatically or manually) forwarded to the KSC when the relay comes back into contact. This would be very useful for landed craft with geostationary satellites that frequently lose connection, even more so when they are on large bodies. This is especially so in the case of gas giant atmodiver probes, since they can't wait for the planet to orient itself favourably so their relay has LOS during the transmission window. The other would be when a kerbal is on EVA. If an EVA kerbal had a tiny, short-range antenna built into their spacesuit that treated all antennas within physics range as relay antennas and could transmit science to them (esp. EVA reports) for relaying back (though the direct transmission mentioned above could only be done after transferring the data to a vessel), draining EC from the relaying vessel as normal (this is why the range should be <2.4km) to prevent exploitation. This would allow the transmission of science without having to walk back to a vessel every time and sift through the potentially hundreds of science reports stored in it to pick out the ones you collected while on EVA to transmit. I'm guessing this in't covered by the "common suggestions" this time? if it is, please berate me .

I don't think that one will count because all parts that go up must come back down too, and you lost the tail on re-entry (and crashed it) so you're going to have to try again without losing any bits or crashing for this to be a non-gatecrasher entry.

One Kerbin year is 426 days long, so this is wrong. Logging on the bugtracker.

When I was doing some LS calculations, I noticed a small oddity in the habitation values-I think LS defines a Kerbin year as 425 days, not 426. I tested it by adding a 2.5m kerbitat on common mode onto the end of a Mk3 pax module and the calculation should have given me 18*0.25*3.35=15.075k-m habtime for one kerbal, which equates to 452.25 days, which is (ignoring the 32.5 minutes on the end of the year) 1 year, 26 days, 1 hour and 30mins. However, in the VAB LS window it gave that as 1y, 27d, 1h and 30m. Is this due to LS defining a year wrong, or has my maths gone wrong instead somewhere?

it lives in the ModuleAnimation section of the USITools DLL, so unless you know how to compile C#, don't mess with it.

You will also need CRP and the KolonyTools DLL *might* also be needed, without it you will get some errors but the LS part of the habring will probably still be functional. ...What do you mean by the last bit?

It isn't hardcoded, it is remappable in BOSS.cfg (but not unmappable). I just mapped it to my bin key of #.

However, I did notice a small oddity in the LS calculations-I think LS defines a Kerbin year as 425 days, not 426. I tested it by adding a 2.5m kerbitat on common mode onto the end of a Mk3 pax module and the calculation should have given me 18*0.25*3.35=15.075k-m habtime for one kerbal, which equates to (ignoring the 30 minutes on the end of the year) 425.25 days, which is 1 year, 26 days, 1 hour and 30mins. However, in the VAB LS window it gave that as 1y, 27d, 1h and 30m. Strange much? ...or has my maths gone wrong somewhere?

Would you like to be stuck in a 1.25m x 1m capsule for a week? I think not. It's not really different though, since the 15 days of no supplies before grumpout can be considered as the grace period if you didn't add any supplies, and you could also see the 7.5d of hab per seat as your grace period if you didn't add any specific hab modules. Scenario 1. Catchup doesn't happen until the vessel is simulated on being loaded or passing into physrange. Also @TheRagingIrishman GJ cleaning up the hundreds of inactive tickets on the bugtracker!

KSC++ does not come in this pack, I don't believe linux adopted that alongside SXT.

This is more a USI-LS thing, but habitation is distinct from supplies time. Habitation is supposed to represent how much time a kerbal can sit in a cramped pod for before they go nuts, and supplies time is how long they have a food supply for. When they run out of hab time, they grump out but when they run out of supplies they have a 15-day grace period before they grump out. By default, hab time is calculated by kerbalmonths of hab*hab mult/kerbs on vessel, and each additional seat on a vessel grants one additional kerbal-month of hab time (30 days), with the default multiplier of 0.25, giving you 7.5 days of hab per seat per kerbal. To extend this add additional empty seats to the vessel or use parts with ModuleHabitation (that is to say, the PPD-10 and an assortment of parts from MKS and other USI mods-they also require power). The LS window in the VAB will tell you more-note values are given in kerbalmonths.

If you are running an old version of MKS (from 0.50.9 to 0.50.17) then the option to hire the MKS kerbal types should be under the Hire Kolonists tab of the Kolonisation Dashboard applet.

Also, I guess the fact that you're on 1.2.9 also means pretty much guaranteed mod-free since almost no mods are out for 1.2.9 yet. I find putting chutes on the back end of a craft greatly reduces its stopping distance in case you don't nail the runway exactly straight-on or land in some other place where a short stopping distance or being able to slow down prior to landing is crucial.

I like what you've done with the offsetting and the embedding of Mk2 parts. Very nice, although it does look like a bit of a jumble at the back.

Have you considered that you might be using more substrate than your outpust is producing? A stock behaviour is also that the outpost will not do anything while it is unloaded, you will have to periodically check in on it to trigger the resource catchup and make it push its backdated production to PL (note: kontainers will only push to PL when they fill up, and then only push half at a time). You also need storage for at least a day's worth of production as not to lose resources in the catchup. EDIT: Get @DStaal with the ninjapost

Use the buttons above the symmetry display to make sure your centre of lift is in line with or behind the centre of mass if that's not possible, else it will be very unstable and possibly flip and go into a death spiral. Check how the CoM moves as the fuel drains or you could be in for a nasty surprise come re-entry. I find it useful to leave a marker on the plane where the CoL is so you can move fuel around to re-centre it (the CoM is the camera focus point) while on-orbit before re-entry.

I can't find any mention of the MPL in the LS page on the kspedia, and all the numbers for the other recyclers are correct-unless you are using exclusively USI-LS, in which case the kspedia entry might be different? Anyway, this would probably be one for the USI-LS thread. If it's definitely broken, make a ticket.

How long did you wait for it to unfreeze? The Salamander pod is typically the last part to be loaded, and the hang is the game going onto the next stage of loading. It's quite possible that you are trying to run KSP on a potato and it just takes some time to finish the loading process, else it's run out of memory (check the last few lines of ksp.log, it should be pretty obvious).

When making an SSTO for the K-Prize in Sandbox (outside my usual Career), I did notice something else-none of the LLL Jool V stuff is visible in Career. It's all there in Sandbox, but in Career it is not visible in the tech tree and therefore unusable. Are these parts deliberately hidden in the tree, or is something not working?

Specify?

No, you have to visit them every so often. Planetary Logistics should build up quite a buffer though, provided you have a production surplus.

It happens after you load the vessels and the resource catchup is processed. This means you will have to periodically check in on your outposts (and also need at least six hours worth of production storage to accommodate the catchup).

They went and found the wiki page after asking.