Search the Community

Showing results for tags '1.2'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website
  • KSP Pre-release
    • 1.2.9 Pre-release Branch
    • 1.2.9 Pre-release Modding Discussions
    • 1.2.9 Pre-release Bug Tracker


  • Developer Articles

Found 54 results

  1. This is reboot of @tseitsei89's economy challenge, which was for 1.1. Categories There is 4 categories each for Stock and Modded. I. DISPOSABLE LIFTERS - Recovery doesn't count IIa. REUSABLE ROCKETS - No airbreathers IIb. VERTICAL LAUNCHED VEHICLES - Vertical Launch with airbreathers III. GENERAL - Anything is allowed Score Score is given by {Expense for the Mission} / {Payload mass(t)}. Expense doesn't include the price of the payload. Recovery cost is excluded from the expense for categories IIa, IIb and III. Rules 1. No cheat menu, No clipping of fuel tank & engine. 2. For stock entries, the craft should work in the same way with stock installs. For modded entries, only balanced mods are allowed. 3. You must launch from launch pad or runway. 4. You must achieve a stable orbit. (Pe >70km) 5. Payload must be separated from the lifter once in orbit. Decoupler used for this can NOT be a part of the payload. 6. Payload can have 1 pod, cockpit or probe core but nothing else that contributes any thrust or control authority to your craft. Also no lifting surfaces in payload. 7. Payload mass count after it's decoupled. If you had fuel or something disposable on the payload, give enough proof that you didn't throw any of them away. (e.g. Show that initial payload mass and final payload mass are same) I. DISPOSABLE LIFTERS 1. Funds from recovery doesn't count. 2. You can use ANY parts you like. IIa. REUSABLE ROCKETS 1. You can use any parts except airbreathing engines. (This includes any kind of scooping) 2. You can recover any parts of your lifter that you can for a refund. 3. If you return parts of the lifter from orbit you don't have to land on runway or launchpad for 100% refund. Just land somewhere on kerbin and you can count 100% refund. This is because once you are in orbit it is trivial (but time consuming and boring/irritating) to land at KSC. 4. If you return parts of the lifter that are dropped while suborbital or in atmosphere you must land them somewhere in the KSC area (not necessarily on the launchpad/runway) for 100% refund (KSC must be within sight from your landing spot). This is because again precision landing is boring/irritating. If it is outside the KSC, recovery cost is calculated as default. IIb. VERTICAL LAUNCHED VEHICLES 1. You can use any parts, and at least one airbreather should be used in lifter. 2. You can recover any parts of your lifter that you can for a refund. 3. The craft should fly vertically to orbit - Pitch should be above 30 degrees under stratosphere(7km) 4. If you return parts of the lifter from orbit you don't have to land on runway or launchpad for 100% refund. Just land somewhere on kerbin and you can count 100% refund. This is because once you are in orbit it is trivial (but time consuming and boring/irritating) to land at KSC. 5. If you return parts of the lifter that are dropped while suborbital or in atmosphere you must land them somewhere in the KSC area (not necessarily on the launchpad/runway) for 100% refund (KSC must be within sight from your landing spot). This is because again precision landing is boring/irritating. If it is outside the KSC, recovery cost is calculated as default. III. GENERAL 1. You can use any parts. 2. You can recover any parts of your lifter that you can for a refund. 3. If you return parts of the lifter from orbit you don't have to land on runway or launchpad for 100% refund. Just land somewhere on kerbin and you can count 100% refund. This is because (IMO) once you are in orbit it is trivial (but time consuming and boring/irritating) to land at KSC. 4. If you return parts of the lifter that are dropped while suborbital or in atmosphere you must land them somewhere in the KSC area (not necessarily on the launchpad/runway) for 100% refund (KSC must be within sight from your landing spot). This is because again precision landing is boring/irritating. If it is outside the KSC, recovery cost is calculated as default. Submission - Submission should include enough screenshots or video to prove validity of the mission. - Username, brief explanation of the profile and characteristics will be listed. Craft file will be listed as well if it's given. Leaderboards Stock: I) 1. 589.8/t, @maccollo, with Skipper augmented with Kickbacks. IIa) 1. 378.32/t, @Abastro, with fully recoverable TSTO w/o boostback. (Poodle on the second stage, Skipper&ReliantsX2 on the first stage) 2. 394.99/t, @Nefrums, with Shuttle second stage on SpaceX style first stage. (Rhino on the second stage, Mammoths&Vectors on the first stage) 3. 484.231/t (Craft file), @Avo4Dayz, with simplistic recoverable rocket SSTO powered by single Twin-Boar. 4. 756.10/t, @Abastro, with fully recoverable TSTO with Nerv on the second stage. III) 1. 131.91/t (Craft file), @Wanderfound, with mk3 cargo bus powered by 6 R.A.P.I.E.Rs and 3 Shock Cone Intakes. with few wings - I guess, it's just not wingless 2. 159.29/t, @NightshineRecorralis, with mk2 spaceplane with 2 R.A.P.I.E.Rs supplied by single Shock Cone Intake. 3. 378.32/t, @Abastro, with fully recoverable TSTO w/o boostback. (Poodle on the second stage, Skipper&ReliantsX2 on the first stage) 4. 394.99/t, @Nefrums, with Shuttle second stage on SpaceX style first stage. (Rhino on the second stage, Mammoths&Vectors on the first stage) 5. 589.8/t, @maccollo, with Skipper augmented with Kickbacks. 6. 756.10/t, @Abastro, with fully recoverable TSTO with Nerv on the second stage. Modded:
  2. I'm starting a new career mode playthrough in 1.2 on YouTube, with the goal of making Kerbals a multiplanetary species! I'll be using a handful of mods, including Roverdude's USI Constellation. I'm hoping to post a few of these a week, so please check back on my channel!
  3. INTRODUCTION: The stock communications system in 1.2 is like a cross between RemoteTech and AntennaRange. It has (optional) control issues similar to RT but the network itself links up pretty much like AR. If you've never played with either of those mods, then hopefully this tutorial will demystify the whole communications network thing. It's really not that complicated. If you're used to playing with AR, then you'll find stock pretty much the same except for the new antennae and the different performances of the old ones. If you're used to playing with RT, then you'll probably welcome the vast reduction (to nearly zero) of the micromanagement, but might have to learn new habits depending on how you did RT. GENERAL STOCK NETWORK FACTOIDS: Stuff to understand before you get started. 1. No Perfect Networks There is no such thing as a network that allows 100% uninterrupted coverage to every square inch of every planetary surface. So don't lose any sleep over that. No matter what you do, something will always get in the way periodically. The best you can do is make something that works everywhere most of the time, and then time your activities to happen when you've got a link, waiting the minutes to hours when you sometimes don't. 2. You Don't Need Perfection You really only need the network in 2 situations: 1) when you're trying to control a ship/probe without a Kerbal pilot aboard (assuming you selected that option); and 2) when you're transmitting science. The rest of the time, the network doesn't matter. Thus, you only need to design the network to handle these situations. This means you need a network to allow landing on the far side of Mun/Minmus, to cover the mid-course tweaks of interplanetary trips, and to land on other planets. Once you're on the ground, you can wait a bit if necessary to transmit your science and take off again. That's all you really need, so don't sweat trying to do more unless you just want to. Also keep in mind the duration of the mission. Are you ever going back to this planet again, or is your main focus elsewhere and you're just here for some quick science? There's no point in getting too elaborate for a 1-and-done mission. 3. Getting Acceptable Coverage To do this, you have to minimize the impact of the 2 things that break links: 1) celestial bodies in the way; and 2) distance in excess of antenna range. You can pretty much eliminate the 1st problem with the network design described below. The distance thing is another matter. Right now, the biggest stock relay antennae barely work between Kerbin and Jool when they're on the same side of the sun, and only hit Eeloo when it's at or inside Jool's orbit. You can reduce this problem somewhat by using intermediate relays at Eve, Duna and/or Dres, although certain planetary alignments over time will still be problematic. And that's just with the stock solar system. If you use something like the Outer Planets Mod, where the closest new planet is twice as far from the sun as Jool (as in, just as bad a link from as from Kerbin to Jool) and the distances between the rest get worse from there on out,, the stock communications system just flat won't work much if at all. So for that you'll need a mod. Surely somebody will make a bigger mod relay antenna to work with OPM, or you can use a ModuleManager patch to change the stats of the stock antennae for longer range. Thus, this tutorial will just worry about the stock solar system, where distance isn't THAT much of a problem (except for Eeloo) most of the time. Then it's just a matter of avoiding blocking by celestial bodies, which is relatively easy. 4. Forget Geostationary Networks Kerbin now has a number of communications centers scattered all around its surface and your network can link back to any one of them, not just KSC. IOW, as in AR, your distant ships essentially talk to Kerbin as a whole, not just 1 spot on its surface. This also means that Kerbin by itself covers the near sides of both Mun and Minmus, plus anything within Kerbin's SOI not blocked by Mun or Minmus. The only reason anybody ever built a geostationary network before was because in RT, you could only talk to KSC itself, so you needed the geostationary constellation to handle the 50% of the time when KSC was facing away from your ship, which happened even in LKO. Because in the stock system you can talk to Kerbin regardless of which way KSC is facing, you don't need a geostationary network. You can build one if you want, but it's really just a waste of time and money. And FWIW, you can't build a geostationary network at most other planets and moons anyway because the required altitude is beyond their SOIs. So just ignore geostationary networks as the archaic "back in the day" things they are and move on. 5. Redundancy is Good It's a good idea to provide multiple possible link paths between any 2 points. That way, if one path is blocked, hopefully another will be open. It's easy to go overboard with this, but it can be done with a fairly minimalist approach. This tutorial will show how to do that. AVOIDING BLOCKING BY CELESTIAL BODIES: There are 3 types of blocking by celestial bodies. 1. Blocking by the Planet/Moon You're At This happens whether you're in orbit or landed. This is the most troublesome type of blocking because it will happen the most often (like 30-50% of the time), and you can't do much about it without going to a lot of trouble and expense. Often, this is more trouble than it's worth because, as mentioned above, it's actually pretty easy to make a simple network that provides coverage when you actually need it. Normally, there will be some time (minutes to hours, perhaps a few days even at very tiny moonlets) when you have to wait for a satellite to pass over before you have a link, but the wait shouldn't ever be long so long as to cause a real problem. Just warp through it. Going beyond a minimalist approach doesn't really gain you anything that's actually useful in real game terms, although you might want to for purely role-playing purposes. 2. Blocking by an Intervening Planet/Moon: Statistically, this happens quite infrequently. It's also the easiest type of blocking to overcome, to the point where it'll never be a factor. Just put your relays in highly eccentric polar orbits so they talk across interplanetary distances well above or below Kerbin's ecliptic and you're golden. That's the method recommended here (detailed below). 3. Blocking by the Sun: This is only a problem on interplanetary missions, but it is certain to happen during them at some point, usually between arrival and waiting for the return window. In purely game terms (ignoring the role-playing aspect of needing to phone home every day), this is only a problem if you're still wandering around in the system doing science when the sun gets in the way. And that's usually only an issue at Jool because the system is so large it takes months to explore it all. Problem is, the sun is too big to talk over/under with your highly elliptical relays, so you have to talk around it. You do that by creating relays at all planets except Moho. Eve is especially important because it's far enough from the sun usually to have an LOS from Kerbin to Eve to wherever, and it move faster than Kerbin so will provide these links more often. When Kerbin is opposite the sun from wherever your ship is, Eve is often placed to bounce a signal around the sun. This is especially important for communications with Jool . Anyway, as mentioned above, you need redundancy and multiple possible paths, and Eve is often a key step in that alternate path. Moho, not so much because it's so close to the sun that most of the time it can't provide a bank shot around it. Also, it's way expensive to get to Moho compared to Eve. NETWORK DESIGN: OK, so that's the underlying principles and realistic objectives. Now, how do you accomplish all this? Finally, we get into the nuts and bolts of the network. 1. Relay System: The basic unit of the system is a set of 2 long-range relay satellites in highly elliptical polar orbits around the central planet. One goes up, the other goes down, and they're 180^ out of phase with each other, so that when one of them is at Pe, the other is at Ap. Because their orbits are highly elliptical (like 2000m/s worth above low orbit), the relay satellites will spend the bulk of their time high enough above or below the ecliptic to be able to talk over or under any intervening body except the sun. Putting a pair like this at each planet (except Moho) will then provide a path around the sun to any other planet ALMOST all the time. These relays also cover nearly all the surface of the central planet most of the time. One will get most of the northern hemisphere, the other most of the southern. There will be a blind spot centered on the equator on the opposite side from where the satellites are (both orbit in the same direction so will both be on the same side of the polar axis most of the time), but central planets all rotate fast enough that a ship on the ground in the blind area will rotate into coverage soon enough. Every week or 2, there will be a few minutes when both satellites are over the same pole, one at Ap and the other at Pe, so that the whole opposite hemisphere is blind, but this won't last long because the one at Pe will be moving so fast, so don't sweat it. For most of the time, these relays will also cover much of any moons of the central planet. There will be a gap on the far side, however, wider than on the central planet, which you fill with other component of the network, the moonsat. The relay satellites should always have the biggest relay antennae you have. This is so they can provide alternate paths around the sun in as many ways as possible. As you unlock the bigger antennae, you might have to replace some of your early relays. Kerbin should definitely always have the biggest available. 2. Moonsats For each moon of the central planet, you'll need something in equatorial orbit. The purpose of a moonsat is to cover the gap on the far side of the moon left by the relay sats. The "moonsat" MAY be a dedicated commsat if you're doing something long-term on the far side, but for a 1-and-done mission, you can do things Apollo-style so that the ship left in orbit serves fills this role. The moonsat should orbit at a conveniently low orbit so that it passes over a ship landed on the far side often enough that blackouts aren't a bother, and for long enough that it can land while still in contact. But it also must be high enough that the relays can see over/under the moon to it most of the time. If being high enough for this makes the moonsat's orbital period (and thus blackouts for farside landers) longer than desired, you can use multiple moonsats spaced more or less evenly around the moon's equator. But most of the time you'll only need 1 for gameplay purposes. Munsats need an antenna big enough to reach the local relays at their Aps. 3. Modular System So, putting this together, for each planet, you have 2 relays satellites in highly elliptical polar orbits and for each moon you care about, you have (at least) 1 satellite in a relatively low equatorial orbit. It looks like this: CREATING THE NETWORK Setting up this sort of network is pretty simple. At Kerbin, you can launch each relay on a separate rocket but everywhere else, it's best to send them both out on the same carrier vehicle. If you want multiple moonsats somewhere, they should always go out on 1 ship. Using 1 ship to carry multiple satellites facilitates spacing them out evenly. Thus, this description will always use single ships even at Kerbin. The mechanics go like this: 1. The Kerbin Relays These have to be set up first because they're the essential link from other planets and the farside of Mun/Minus. Design a probe with the biggest relay antenna you have, enough juice to run it, and about 2000m/s dV in its own little tank. Save this as a subassembly. Then start the carrier vehicle. Make it so you can mount 2 of these relay probes under the same fairing and then add the subassembly probes. Launch into a polar orbit of about 150km. This will be the Pe altitude of the relays, high enough to avoid stuff in 80-100km parking orbits but low enough to whip by Pe in no time. Detach one of the probes and switch to it. Plot a maneuver node for when the probe is directly over one of Kerbin's poles, burning all or most of the probe's fuel to reach an Ap out near the edge of Kerbin's SOI, then do this burn. You should have a few hundred m/s left in the tank to tweak the orbit later if needed and to deorbit the relay when it needs replacing. Then you wait about a week for the 1st relay to reach its Ap. When it's starting to get close, switch back tot the carrier vehicle, detach the 2nd relay, and switch to it. Plot a similar burn for it, but located above the other pole so this relay will go in the opposite direction as the 1st. Adjust the number of orbits into the future when you actually do this burn as needed until it's as close as possible to when the 1st relay reaches Ap. It doesn't have to be exact, just close enough. Do this burn, then switch back to the carrier vehicle and de-orbit it. NOTE: It could be that the 1st relay won't have its own link back to Kerbin's surface when it's time for it to burn. This could require putting a "0th" relay in equatorial orbit first, if nothing you already have in Kerbin orbit can do this. 2. Munsats and Minmussats Until you have the Kerbin relays up, you'll need at least 2, unevenly spaced (or 3 evenly spaced) commsats in Munar orbit to talk to the farside. Minmus isn't tidelocked but rotates slowly, and orbital velocity is pretty slow, too, so you might want the same there to avoid long blackouts. By unevenly spaced, I mean 120^ apart, like a formation of 3 with a missing satellite. Having 2 spaced like this will give farside coverage 2/3 of the time---3 will give full-time coverage. But remember, you'll be putting relays up, at which point you only need 1 moonsat to give farside coverage 50% of the time, so don't spend money you don't need to. The basic technique is the same whether you drop 2 or 3 moonsats off the same carrier vehicle. The basic method for spacing multiple moonsats is as follows: First, decide on the altitude you want the moonsat to be so it can usually talk over/under the moon to one of the relays. Use math to determine what the orbital period is for a circular orbit at that altitude at that moon. Send the carrier vehicle to the moon and capture into an elliptical orbit with this altitude for the Pe. As for its Ap, again use the math to determine what altitude would give the carrier vehicle in an elliptical orbit an orbital period 1.33 (or some whole multiple of that number) times as long as for the circular orbit at Pe altitude. The idea is, every time the carrier vehicle reaches Pe, it will be 1/3 of a circular orbit behind any moonsat previously released. The carrier vehicle thus makes 1 elliptical orbit for every moonsat carried. Each time it reaches Ap, it releases a probe. You switch to the probe and plot a burn to circularize its orbit at its Pe. Tweak the probe's orbit as needed with RCS to fine-tune its orbital period to be within 1 second on the calculated circular period. Once all the moonsats are in position, de-orbit the carrier vehicle. NOTE: Generally, you'll need a mod like KER or MJ that will give you a display of your orbital period. As mentioned, using a tiny amount of RCS prograde or retrograde as required will allow for very fine control of your orbital period. 3. Expanding the Network Repeat the above process with the relays for every other planet. Send at least 1 moonsat to every moon you expect to visit regularly, but those can wait until you actually send out such expeditions. The relays are the important thing, to be able to talk around the sun and to give a better connection out to Jool, and should be set up as soon as you have the antenna to make them worthwhile. NOTE: Relays require a lot of EC/sec, but only when you're actually using them. Solar power is practically useless at Jool for any purpose other than slowly recharging batteries between widely separated uses. RTGs aren't any more powerful and are quite expensive, while fuel cells run out of fuel. Thus, relays for Jool, Eeloo, and even Dres should have rather huge battery capacity to cover their periods of infrequent activity. It might also be a good idea to have a fuel cell for emergency instances of prolonged or frequent use, remembering to turn them off as soon as possible afterwards.
  4. What is the current theoretical limit of the cost efficiency to orbit? For stock 1.2 without cheats, in terms of cost per ton, for these cases: 1. Without any recovery 2. Including recovery, without airplane flight path 3. Including recovery, with airplane flight path Practically, there was an orbiter capable of 600/t without any recovery a few versions ago (AFAIK). For the reusable case, I got 500/t with TSTO rocket in 1.1.3 and 1.2, and there should be better one. Here's a challenge to find the practical limit of the cost efficiency to orbit. Here's a spreadsheet with optimal cost efficiency for each engines
  5. Proton-M / Breeze-M A realistic and highly detailed parts pack for Kerbal Space Program. See more images of the Proton M with Breeze-M Proton Medium, Proton Light and 5 Meter Fairings for Proton M+ (included) See more images of the Proton Medium, Light and 5 Meter Fairings Proton launch pad (included) See more images of the Proton Launch Pad Features Proton-M booster Proton Medium Variant (new) Proton Light Variant (new) 5 Meter Fairings for Proton M+ Variant Breeze-M upper stage Proton launch pad Procedural and and fixed size fairings in different sizes and style Payload adapters for various TKS and DOS payloads Supported Mods Realplume Firespitter Core Realfuels stockalike Realism Overhaul OldscoolFairings Filter Extension Tantares (as Payloads) Fairing Logo Template Download the Template as a .psd file. Qestions and Answers Changes License Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)
  6. Colonists! for 1.2 Colonists! Introduces a new kind of Kerbals the (tadadadaaaa) colonist. (A mashup between Engineers and Scientists). The intention to create them was to have some kind of kerbal wich can be dropped off on a planet with a rover and do some science without mystery goo or materials bay getting useless after the first use and without them and their rover getting stuck because a wheel suddenly broke. Without coding it is just possible to decide wich abilities to copy from a kerbal and wich not. So the possibilities for me are limited. This is exactly what I took/left: Taken from Scientists: Ability to execute experiments in EVA and reset them. Difference to scientists: Scientists can process data in laboratories and provide a science bonus for recovered experiments/vessels. Taken from Engineers: Ability to repair stuff. Difference to Engineers: Engineers boost drilling/converting resources. Taken from Pilots: Ability to provide basic vessel control (activate stuff, steer, etc.) even without connection back to the KSC Difference to Pilots: Pilots provide SAS! Here is what he will learn in detail: Level 0 Reset experiments, Perform experiments in EVA, Full vessel Control Level 1 Repack parachutes Level 2 Repair lander legs Level 3 Repair wheels They will spwan like any other type of kerbal and you can recruit or rescue them. Here you see Jesvie and her description: Hope they come in handy for some of you! Published under MIT License, see source for details. Download (Spacedock): LINK Zip contains the "Colonists"-folder, just drop this in GameData Source (Github): LINK I do love it, but would appreciate some feedback. "Changelog": Deleted the pilot abilities because it was not possible to make the vessel uncontrollable if connection is lost. Without this drawback they would've been too overpowered! Added the "FullVesselControl" parameter to the colonists abilities. So no more pilot stuff but control of the vessel everywhere, hope that is more balanced!
  7. Sensible Tech Tree Version 1.0 Sensible Tech Tree is a mod similar to things like Historical Progression, and Unmanned before manned. The purpose of this mod is to completely rebuild the stock tech tree into something more sensible. Things such as planes from the start, probes before manned, and other such things that just flat make sense. Features - A whole new, more sensible tech tree has been built to replace the stock. - Most plane parts can be used from the start of a save, as before touching rocketry, we had planes for a long time. - Sounding rockets, are the first bit of rocketry you obtain, with probes as the only control option. - Survivability parts are unlocked, and tested before manned is even an option. - And many other re-arrangements of parts, and the tiers at which you unlock them. Supported Part Mods - None at the moment. Future Plans Past the first full release, I plan on working on support for mods such as KIS, KAS, Infernal Robotics, and many more, which will lead into the second version of the mod. After the Initial integration with some of the base mods that are planned, I plan to implement support for career's that require you to purchase parts from the unlocked nodes, though this is a lesser priority at the moment. Further down the line than even the part buying, is a contract pack. I plan on putting something together for contracts that will fit this mod better than stock in the future. Download Module Manager IS required for this mod to work. Version 1.0 - Spacedock Change Log License CC-BY-NC-SA ( Special Thanks @Pap1723, for helping with the initial bugs that i ran into CSA Community, for helping my motivation to complete the mod.
  8. Release - IFI Life Support. 10-2-2016 : Release VER 3,21 for 1.2 (on Curse of Github) (ModuleManager no longer required for this Mod) or Project Page on curse Source Code available at GitHub Released Under GPL3 License. Author : Stavell Bugs can be submitted in this thread or at GitHub. If plug-in seems not to be working right you can enable Debugging log entries via the right click menu on any pod (recommended to be left off unless you are experiencing problems.) Released Under GPL3 License. I know that there are a few Life support mods in development. They are too intense for my tastes. SO I designed my own. GOALS I have for my plug-in: Tracks life support use even when ships are not loaded into scene. Based on Realistic Life Support values on use and weight. based on information from Life Support Systems at Low overhead and play-ability with KSP. Life support tracked and used on EVA. Use only one new resource to simulate O2-Food-CO2 Scrubbers and recyclers, and emergency power ( LS resource use figures in Waste recycling based on Tech tree advances) Currently the MOD is working with no game breaking bugs found yet. therealcrow999 - Thank you for contributing the nice Logo and Flag for Interstellar Flight Inc. Universal Storage - Has Created a wedge that holds Interstellar Flight Life Support Resource more info can be found here spiritplumber - Has created a Part cfg for using a greenhouse part for use with the system Can be found here Sandworm - Created Modmanager file for HGR Parts -Thread is here Akinesis - Created more tanks for use with the mod Thread is here maxrsp - Has made a video featuring IFILS, thank you. Video Here Current Working Features: Kerbal going on Eva takes Life Support from pod/vessel. Boarding a pod returns unused Life support to pod/vessel. Running out of Life Support can kill crew All pods have LS Resource and plug-in installed using Module Manager. 2 Custom parts a radial and a inline tank for Life-support resource storage. Universal Storage has created a wedge to hold Life-support giving you 3 options for extra LS storage. Plug-in Operation Info: Currently there are several Status LS system can be in: Pod Standby - No demand for LS and no resources consumed. Life Support tag for days / hours of LS remaining is hidden. Active - Demand for LS and resources consumed. Life Support tag for days / hours of LS remaining will read how long LS will last for whole vessel. Visor - Kerbal on EVA breathing outside air decreased Resource consumption. Life Support tag for days / hours of LS remaining will read how much LS remains once active again (fixing). Intake Air - Pod using air intakes to provide O2 to crew - decreased Resource consumption. Life Support tag for days / hours of LS remaining will read how much LS remains once active again. CAUTION - Less than 2 days pod or 1 hour EVA of LS remaining. Life Support tag for days / hours of LS remaining will read how long LS will last for whole vessel. Warning! - LS at 0. Kerbals will start dying if immediate action not taken. Life Support tag for days / hours of LS remaining will read 0. Each unit of Life-Support should provide 1 Kerbin Day (6 hours) of Life support for 1 Kerbal. In Career and Scince game modes this goes up and down based on Tech tree. Mod uses the time as set in settings menu so it will track 6 or 24 hour days depending on setting in main menu. Days remaining on RT click menu are accurate based on this setting. Only change in mod is that if not using kerbin time each Kerbal requires 4 units of LS per day. Screen Shots Crew Pod Life Support Eva Life Support: Parts for system
  9. Hello. Today I installed Kerbal Space Program 1.2, but I immediately realised something was wrong. The game was really laggy, especially when building in the VAB. I've never had any lag issues in previous versions of KSP. Worth to note is that the same problem occurred while testing out the Pre-Release. General Info OS X El Capitan 10.11.6 Steam Client on Fresh Install No add-ons Kerbal Space Program 1.2.0 2560 x 1440 Resolution, Full Screen Specifications iMac OS X El Capitan 10.11.6 3,4 GHz Intel Core i7 16 GB 1600 MHz DDR3 NVIDIA GeForce GTX 675MX 1024 MB Are you missing something, please let me know. Thanks in advance.
  10. Internal antennas aren't combinable and can't be used for transmitting science (or relaying signals) - their only purpose is to provide short-range control to unmanned craft. It makes sense that probe cores would include an internal antenna, but why command pods? If you have a command pod with a kerbal inside, then the kerbal provides control and the pod's antenna provides no benefit. If you have a command pod without a kerbal inside, then you're not going to have control even though you have an internal antenna - unless you have a probe core as well, in which case you can just use the probe core's internal antenna. Either way, the pod's antenna still provides no benefit. So why include the antenna module in command pods at all? Is there any circumstance in which it would have any meaningful functionality?
  11. I'm cross-posting this here to give this mod a bit more visibility again. The main thread to discuss this unofficial build remains the "Unofficial Development Thread" linked below. I've recompiled and fixed up @N3h3mia's excellent collection of Science Mods for KSP 1.x as he is currently not able to update his mods. THIS IS AN UNOFFICIAL AND EXPERIMENTAL BUILD Do NOT raise bug reports for this build directly to @N3h3mia, nor to his official threads! NB: This release is (probably) NOT backwards-compatible with existing OMS saves! Official Thread (out-of-date)- overview and tutorial videos Unofficial Development Thread- unofficial revision history, source code, bug reports, feature requests, help and support, ... The Mod is available via Github (please do NOT request to have this added to CKAN or hosted elsewhere; remember, this is an unofficial build). Link to Latest Version (KSP1.2) Link to last KSP1.1.x Version Overview This set of mods consists of 4 main components: Kemini - early-game orbital science experiments in the Mk1 pod requires ModuleManager KEES - later early-game orbital science experiments for basic orbital stations. requires KIS recommends K2 / Corvus or similar 2-Kerbal pods OMS/KLS - full-station experiments, requiring heavy lifters and significant station infrastructure. The basic premise is that experiments are run in "Labs". Labs, Lab Equipment, and Experiments are launched separately. Equipment must be installed into the correct lab, and Experiments can only be run on certain Equipment. KEES and Kemini are simpler variants with some/all of the equipment/labs pre-integrated. Once an Experiment has been installed, it can be "Run", which will take some time. The idea is not to time-warp to completion, but to run other missions in the meantime. When done, an Experiment can be "Finalized" and must then be returned to Kerbin. Quick Tutorials Kemini KEES OMS / KLS
  12. Enjoy! Pics: Download: Fighting Falcon.craft?dl=0
  13. I discovered this when trying to build rotor bearing and the rotor just fell on the ground. Basicaly the fairings dont colide with ground, buildings or other spacecraft until the fairings themselfs are decoupled (staged), olny then they start to colide. Separated fairing segments also seem to ignore gravity as (when staged on the ground) they endlessly spin and float up after bouncing of the ground.
  14. Hey, there's a launch window for Duna coming up fairly soon and I'm looking for inspiration for my first ever Duna Base. Looking around on line there are lots of nice looking configurations, but they mostly make use of mods. As I play on an aging laptop, I like to keep things stock (apart from Better Burn Time) to keep performance up. I'd be grateful if you could post some pics of your stock missions to Duna, especially those including a base, so I can steal get some new ideas. Cheers, Clipper.
  15. The Linux install of KSP 1.2 appears to react badly to some configuration data that may be stored elsewhere by earlier versions of KSP. If you get a blank screen rather than the initial menu, this may be a cause 1: The data involved is stored in one or more subfolders of ~/.config/unity3d/ (This is on an Ubuntu-derived Linux, but I would expect it to be universal. This is a hidden folder and you might need to change a setting to be able to see it.) 2: On my system I found ~/.config/unity3d/SQUAD/ and ~/.config/unity3d/Squad/ , timestamped about three weeks apart in June 2016. They contained different sets of files. I made archives of both and deleted them. Both were related to Kerbal Space Program. 3: Deleting these files led to a normal startup of KSP, in a window rather than full-screen. 4: If you have an in-progress career or science game from an earlier version of KSP, I would not be at all surprised if you need to restore from the archives you made so as to run the earlier KSP version. 5: I am told Steam does things differently. I don't even know whether or not Steam supports Linux.
  16. Hi everyone, I've got some, i think, problem. I see in every screenshot or video of 1.2 version this "part" of HUD and those green lines (the connections between relays) But in my game I got none. My version of KSP is updated but i do not have that part of HUD. Am i doing something wrong? EDIT: I already launched some relays in orbit around Duna and Kerbin to test it, even the stock Relay. The Surface scanner btw works well.
  17. I understand the two types and what they do. But I have a question about combining them. For the sake of clarity, lets say we have two made-up antennas with these properties: Antenna 1 Type: Direct Range: 99999999km Antenna 2 Type: Relay Range: 5 meters My question would be, if I put both onto a satellite, would I then be able to Relay at 99999999km? Or would my relay capabilities still be 5 meters, irregardless of the direct antenna? TLDR: If I have both relay and direct antennas and the direct antenna has a greater range, will the relay antenna adopt the direct antennas range? Or they are both totally separate?
  18. Ever since I updated to version 1.2, KSP seems to be a bit more laggy than before... Using a vanilla install (64 bit) I hardly ever get above the 30 FPS. This is kinda annoying. Are any of you guys experiencing the same issue? Is there a way to solve this? My set-up is: CPU: I5 4690 (3.5 GHz) RAM: 16gb DDR3 GPU GTX 970 OS: Win 10 Storage: SSHD
  19. Is there a way to make fine adjustments to a maneuvere node?
  20. So I have a couple of questions about fuel lines in 1.2. Its my understanding that with the new fuel flow system, you dont really need fuel lines at all anymore? Or whats the purpose of them now that apparently, you can just set up asparagus staging without actually running lines? Or what am I missing? Discuss.
  21. I've built a station around the Mun and I can't seem to transfer the fuel from one module to another. I do know how to transfer fuel (Alt + Right click) as i've done it before. It is a possible bug for ksp 1.2?
  22. Hello, since today i have a strange issue with KSP. I subscribed to the 1.2 Beta and then later switched back to the 1.1.3-Version. Now, everytime i start KSP it opens at the wrong display (i have two). When i try to unset fullscreen it doesn't react. I have to force it with alt+enter to exit fullscreen-mode. Now the fullscreen-setting reacts but also fullscreens at the wrong display, regardless of where i place the window with fullscreen switched off. I changed nothing in the system, just switched to 1.2 beta and back and now this occurs. I'm using steam and started it there and with CKAN, same Problem. Every other game starts normal. Is there any known help? Thanks. I tried the launcher-settings, the start-settings of steam, switched which display is the main, i deleted and reinstalled the game and worked inb the config-sfc... nothing works. switching again to the beta the game opens at the right display, switching back to 1.1.3 its the same issue...
  23. As you can see in the screen shots, fuel transfer works within the same vessel but not through the Advance Grabbing Unit.
  24. Edit - It's a video diary. I'm curious how far I can get before all the wheels fall off.