Jump to content

Search the Community

Showing results for tags '1.2'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. 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...
  2. 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?
  3. 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)
  4. 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, you get just as bad a link from Jool to Sarnus 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 (EDIT without jacking up the DSN range a LOT). 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.
  5. Mk-X Spaceplane Parts v1.0 (for KSP 1.2) (and none of the other versions of KSP don't ask for 1.1.3 support or I will riot) I don't really have time to manage any larger mods right now, so I've created this very small (4 parts!) mod pack that emulates the X-37b spaceplane in a very simplistic way. The parts are 1.875m wide and the cargo bay has space for 1.25m probes/payloads. Still needs some balance so all feedback welcome! Planned parts are winglets, adapters, an engine mount and possibly a dedicated engine and some crewed parts! SCREENSHOTS It goes into space! It deploys satellites! It re-enters! It lands on the ground! Includes four parts currently: drone core, RCS slice, cargo bay (in 1.2 only) (2 are stacked together here to make the X-37b) and an LFO tank. The integrated RCS currently only covers roll and pitch so you will need a few additional thrusters to fully balance it for docking. DOWNLOAD IT FROM THE GITHUB (I've never used GitHub before so tell me if I've done anything wrong) (please tell me) (don't let me suffer in silence) The cargo bay doesn't show up in 1.1.3 and I have no desire to add support for it so stop asking
  6. As you can see in the screen shots, fuel transfer works within the same vessel but not through the Advance Grabbing Unit.
  7. Until 1.2 whenever I was piloting anything in the regular view (not map mode), I could see a green box indicating anything within several km long before I could actually see the vessel. This box also included a little bit of text telling you your distance from this nearby object. Not sure how far away it would start to pick stuff up, but it was significant, at least 10-20km. Since I installed 1.2, I never see the little green target box indicator at any distance. This makes rendezvous in orbit a lot more difficult for me, since I usually guide myself to the encounter for about the last km with at least a little help from visuals. In orbit, however, especially in the dark, you can't see anything small (say just a basic capsule on a rescue-from-lko mission) until you're something like 25m from it. So you have this impossible task of flipping back and forth between map mode to check distances and back to the piloting screen so you can control the craft. I've been looking for a setting somewhere that turns this off and on but haven't found anything. So then I wondered if it might have something to do with the new com stuff? or maybe it has to do with something in career mode that I haven't upgraded/researched yet? Anyone else had this problem?
  8. I'm not really sure where to put this, so if this is the wrong forum, someone can move it. Beginning at 1.2s initial release, I have been plagued with issues preventing me from actually playing it. I'm on OSX and i haven't even gotten to the issues some people have has with it getting stuck at asset bundle definitions, i haven't even been able to open the game! To begin with, every time i tried to download KSP from the store it failed. Be it installer or no, the download has either failed directly, predicted a downloading time of over 2 days, downloaded at roughly 2 kb per second or shown a "server maintenance" screen. And this was just on the iMac. Then, i decided to try downloading it on my small laptop to see if it was an internet problem. The windows version downloaded on that computer in less than an hour and a half. That is, of course, no use to me as it isn't worth playing on that computer in the first place. Instead I devised a plan to download the OSX version on that computer, then transfer it with a USB to the iMac. Turns out when downloading the OSX version I had all the same problems as before. Something must be wrong with the OSX download, i thought. I then had a brilliant idea, since lots of people have evidently been able to download the OSX version elsewhere, i would get Ben to download it at his place, put it on a USB and give it to me. This worked. Ben managed to download it just fine (!!!) and he gave the USB to me today. Maybe half an hour ago, I sat down at the iMac, very excited as i would be able to play 1.2 for the first time. I transferred the file over to my Applications folder (like i always do), dragged the icon down to the dock to create a shortcut, clicked it and... ...It crashed almost immediately. I tried again and it did the same thing. And again. Even if i clicked the "don't reopen" button when the computer warned me that the application had crashed unexpectedly when i opened it last, it would still open... and crash immediately. I tried moving the KSP package out of the KSP directory and back in... didn't work. Then i tried moving KSP.exe out of the KSP package and back in... still didn't work. On thing i did notice however, is that the KSP package is now 1.41gb, instead of 1.98gb, but this is probably unrelated. The thing that confused me most about this is that every other version of KSP has downloaded and opened like a charm. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (me venting my frustration) -T
  9. I couldn't find the bug report thread. My two bases on the Mun were partially sunk into the surface of the Mun when I loaded into them in 1.4.3 with MH 1.2. Whatever patch of 1.4.3 was available for download about 10 minutes before I posted. Mac OS 10.13.4. Two mods: MechJeb and KerbalAlarm. Aside from Mechjeb the bases in question are completely stock. KerbalAlarm is just a timer or reminding me to pay attention to my vessels when they're coming up on maneuvers or whatever. All I did was go from the tracking station to two bases stationed on the Mun. When they loaded, the bases were half submerged in the surface of Mun, and were instantly propelled upwards. One of them has RCS jets so I was able to land it safely, but the other one is a mobile base with no RCS, and was smashed to pieces. In either case there was not time to get screenshots. I installed 1.4.3 using the Mac OSX installer. I don't know what is meant by a "clean install". As I had to restore 1.4.2 from my backup drive, the output files have been expunged from existence. I didn't load any other bases or vehicles because I didn't want them to be smashed. Does it matter that both these bases are within a kilometer of two different Mun arches, and not on level ground?
  10. 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 (http://creativecommons.org/licenses/by-nc-sa/4.0/) Special Thanks @Pap1723, for helping with the initial bugs that i ran into CSA Community, for helping my motivation to complete the mod.
  11. Colonists! for 1.4.X 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!
  12. 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!
  13. 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 wiki.org 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
  14. After the squad introduced us 1.2 with its new communication and relay system, we discovered many new possibilities. It was interesting to revive old probes, connecting kerbals that are separated by billions of kilometers from each other and making every meter on any planet or moon, a place, with great connection. But we often forget about relay, sometimes people don't even launch it, they simply use antennae attached to their craft. But what if we took the opportunity, and made a challenge out of it? I present you the “Butterflies and Hurricanes” challenge! Despite that you might think that it is an easy and boring challenge, you may face a lot of interesting situations, and discover something you didn't know about relay. I will start from rules because they will affect the whole challenge. 1.You have only 80 500 funds and If you will spend more, you basically fail the challenge (reusable rockets are allowed) 2.Using mechjeb and other calculative mods is allowed, though no cheat mod can be used in this challenge (Alt+f12 counts as a cheat). And if mod adds some kind of infinite propulsion it is also considered cheating. 3. If you made the whole challenge with some money left it means you are a cheater it means that you have completed the challenge, quite well. Back to the challenge itself. You have to put 6 satellites in 170 000 m orbit (a bit lower or higher also counts). Into orbits with different inclination of 30,-30,0,50,-50 and 90. They need to have the RA-2 antenna The final step is to put 2 satellites into a very high orbit of 7 000 000 m orbit (higher or lower also counts) You have to design these 2 satellites to have powerful antennae like RA-15. After you've set up all the satellites you have to perform a first task of your relay system- you need mark all anomalies and space centres (like baikenbanour and etc.) You will end up with a relay covering the whole kerbin surface. In case that you've already made a relay around kerbin try to do so with other planets/moons. In such case orbital altitudes may be random, but inclinations must be done according to the challenge. Send your screenshots! Have fun! Invent cool relay designs! Now to the scoring system: I made it different from many other challenges. Here is it: There is factors that will make up your challenge: Launcher design (reusable, SSTO, launch from water, launched via plane, lifted with air balloon) Relay design (more than 10 parts on the satellite, decorative use of other parts for looking good, a copy or an analog to the real relay) Perfectionism (ideal orbits, ideal inclination, ideal landmarks) Fund economy (lower than the certain amount given in the challenge, reusablilty) Perfect funding (the given fund amount is spent perfectly with 0 funds left) Other planets/moons ( add 2 to your score if you visited other planets, add 1 if it is Kerbin's in moons) Visited at least one landmark that you've made during the challenge (each visited location is a factor point) The more factor points you have, the better you did the challenge. Leaderboard itself 1. 2. 3. 4. 5. 6. 7. 8. ... This thread may be necroposted, but I think I edited enough of it to be clearly different to the previous one. If this is out of forum rules,I ask moderators such as @Vanamonde, messenge me, so I could edit it enough. Please don't lock this.
  15. Today's Squadcast with @NathanKell, @Arsonide and @KasperVld at last had an Experimentals build of 1.2 (1.1.99.1431 to be exact ). I won't describe the whole thing here, just a few comments and screenshots; resolution is mine, not KSP's. New loading screen: New option in the general settings: Ease In Gravity, which from what NathanKell briefly said, sounds like the physics-loading easing that KJR does. CommNet settings, if it is enabled from the Difficulty Options screen: Some of the new antennas, plus an example of the level of KerbNet functionality on a probe core: CommNet has changed, no longer is all of Kerbin an antenna (seriously? ), thanks to @Mu there are now three equidistant ground stations on Kerbin--actual objects too: Another new feature: Now you can focus the camera on any part via the right-click menu ("Aim Camera"), i.e. Camera Focus Changer is now stock This is an example of aiming the camera at the big dish antenna:
  16. Hey guys, I'm pretty new the forums as well as KSP. I have about 13 mods installed and have an aching suspicion that one of them is either out of date, or installed incorrectly: massive memory leak, when I go above the first layer of atmosphere, shadows and lighting get really buggy. What would be a suggestion from an experienced modder? Any advise would be appreciated. P.S. My apologies if this is not the correct place to post a topic such as this, as I said, I'm pretty new around here ...
  17. Continuation of economy challenge 1.2 with rules changed. Categories There are 3 categories each for Stock and Modded. I. DISPOSABLE LIFTERS - Reliable Disposables II. REUSABLE ROCKETS - Reusable Vertical Launch Vehicles III. SPACEPLANES - Cargo Planes got to orbit Scoring Score is given by {Expense} / {Payload mass} for the mission, for given Payload mass. - Expense doesn't include the price of the payload. Recovery cost is excluded from the expense for categories II and III. - All lifters listed will be the most efficient one among lifters with the same or lighter payload, in terms of the score given above. - i.e. a lifter won't be listed when it haul heavier payload than another lifter, and has worse score than that. 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 launchpad 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. II. REUSABLE ROCKETS 1. You should recover at least one part of your lifter. 2. The craft should fly vertically to orbit - Pitch should be above 30 degrees under stratosphere(7km) 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. III. SPACEPLANES 1. Feel free with recovery - you can either recover or dispose any parts. 2. The craft should fly horizontally to orbit. Perform horizontal flight (pitch < 30deg) at least once before reaching stratosphere(7km) 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. - Payload mass and cost should be presented clearly. - Username, brief explanation of the profile and characteristics will be listed. Craft file will be listed as well if it's given. Leaderboard Stock: I) - 1.77t in 1720/t (3046 funds), @WanderingKid, with Thumper on the first stage and Terrier on the second stage. 3.2km/s to orbit! - 61.87t in 589.8/t (36488 funds), @maccollo, with Skipper augmented with Kickbacks. II) - 1.770t in 811.86/t (1437 funds) , @WanderingKid, with recoverable rocket SSTO powered by Skipper. Protective Fairing Included to protect the payload. - 3.280t in 756.10/t (2480 funds), @Abastro, with fully recoverable TSTO with Nerv on the second stage. - 13.42t in 378.32/t (5077 funds), @Abastro, with fully recoverable TSTO w/o boostback. (Poodle on the second stage, Skipper&ReliantsX2 on the first stage) - 140.1t in 290.94/t (40761 funds), @Abastro,with fully recoverable TSTO w/o boostback. (Rhino&PoodlesX4 on the second stage, Mammoth&TwinboarsX4 on the first stage) III) - 7.000t in 159.29/t (1115 funds), @NightshineRecorralis, with mk2 spaceplane with 2 R.A.P.I.E.Rs supplied by single Shock Cone Intake. - 10.50t in 69.00/t (725 funds), @OHara, with mk1 spaceplane with the payload between docking ports. Powered by 1 R.A.P.I.E.R and Shock Cone Intake. Suboptimal Entries: Modded:
  18. This is a thing I'm working on. Long story short: 1. Exterminate the ability to transmitt science 2. Set the science transmission to always 100% 3. "Clear out" the large crewed lab (no converting science anymore) 4. Give the now useless lab the only transmitter wich can actually transmitt science I never used the lab. And when I gave it a shot it seemed to be highly overpowered. I also think not beeing able to transmitt science form wherever you want and get 100% is a good idea, but I thought having a "base" from wich you could transfer your science back home with no loss would be really nice too. So I came up with this idea. Probably needs some testing and balancing (especially the transmitter). Here is the code, not that much: //Disable Sciencetransmisson for EVERY antenna @PART[*]:HAS[@MODULE[ModuleDataTransmitter]] { @MODULE[ModuleDataTransmitter] { %packetInterval = 0 %packetSize = 0 %packetResourceCost = 0 } } //Delete ScienceLab and ScienceConverter, add Datatransmitter @PART[Large_Crewed_Lab]:FINAL { !MODULE[ModuleScienceConverter]{} !MODULE[ModuleScienceLab]{} %MODULE[ModuleDataTransmitter] { name = ModuleDataTransmitter antennaType = DIRECT packetInterval = 0.1 packetSize = 5 packetResourceCost = 40 requiredResource = ElectricCharge antennaPower = 500000 antennaCombinable = False } } //Set EVERY experiment to be 100% transmittable @PART[*]:HAS[@MODULE[ModuleScienceExperiment]]:Final { @MODULE[ModuleScienceExperiment] { @xmitDataScalar = 1.0 } } If you'd like to check it out, test it, improve it, nag about it, print it ... here is the LINK, it also needs ModuleManager of course
  19. 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, basically only stock-balanced mods are allowed. However, you can request adding new category for mods you want. It will be accepted if it's resonable for this challenge. 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. - Up to 5 entries will be listed on the leaderboard. 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. 88.46/t, @Wanderfound, with improved version of 'kerbotruck' - more boosters! (8 R.A.P.I.E.Rs and 4 Shock Cone Intakes) 2. 106.57/t, @OHara, with improved version of @NightshineRecorralis and giving it more cargo. 3. 109.02/t (Craft file), @Wanderfound, with mk3 cargo bus 'kerbotruck' powered by 6 R.A.P.I.E.Rs and 3 Shock Cone Intakes. with few wings - I guess, it's just not wingless 4. 113.69/t, @Clancy, with mk1-2 spaceplane powered by 2 RAPIERs supplied by and 1 NERV. (Just enough Oxidizer to push through the 30-40km, where the NERV can take its time getting to orbit.) 5. 159.29/t, @NightshineRecorralis, with mk2 spaceplane with 2 R.A.P.I.E.Rs supplied by single Shock Cone Intake. 6. 378.32/t, @Abastro, with fully recoverable TSTO w/o boostback. (Poodle on the second stage, Skipper&ReliantsX2 on the first stage) Modded: - Stock-Balanced - with FAR&AJE
  20. 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
  21. Hello, So the other day BeardyPenguin released his Fall of Kerbin mod list. I was really excited to give it a shot but when I found out it was 1.1.2 I thought I could just go into betas in steam properties and find 1.1.2 but I cannot I only see 1.0.5 and 1.1.3. Is there any way to get 1.1.2? Any help would be most appreciated.
  22. I need load time to go down because I'm having to go down to my basic must-have mods, such as SVE, NFT, SpaceY, RealPlume, and nothing helps. I have KSP 1.2.2 x64 while forcing DX11 using 52 mods. These include UKS, USI-LS, and Stockalke Station Parts Expansion. ATM, Dynamic texture loader, DDSloader, and load on demand are all incompatible or unavailable. I don't know what else i can do. Any ideas?
  23. Enjoy Pics: http://imgur.com/gallery/fJKmc Download: https://www.dropbox.com/s/14el9zwq8uf0arc/Mikoyan MiG-29.craft?dl=0 Max Speed: Mach 2.57, 882m/s at 8000m altitude Max Altitude: 25600m Can withstand 10> Gs, can maintain level flight in 5 Gs and is capable of 10> G turns
  24. 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.
×
×
  • Create New...