Search the Community

I agree, they talk too much! They should simply shut down all communications and focus on making the game, dropping patches and updates when they’re ready. The only communication they need are release notes. Later on if they want to solicit actionable feedback on game balance or mechanics that they can’t get via telemetry then maybe ask about that. But all these announcements, AMAs, dev blogs, bug status updates etc are doing more harm than good. They only add fuel to the fire!

I feel like at this point in my life I have a basic understanding of how corporate culture works and can read between the lines. Obviously anyone working for a company isn't going to bad mouth their product, or their management, or their peers. It seems kind of weird to me that anyone would expect them to. Within those constraints there's so much people can say. I work for a 6-person firm and those rules are true for us too. Everyone came into the KSP2 EA with expectations about that would look like and it's pretty clear the product in that moment way underperformed. All you have to do is look at the Steam rating to see that. I'm honestly surprised it's as high as it is. And to me thats the entire problem: the game is much buggier than an EA release should be. No amount of corporate happy talk or axe-grinding public flagellation will change the fundamental fact of the matter, so I find all the backseat complaining about Intercept's PR misplaced, pointless, and tedious. When we see Nate or Chris or Dakota or anyone from the actual dev team chiming in they're being good soldiers, trying to maintain a hopeful, positive attitude for the game and Im sure to a certain degree for themselves. Obviously they know what the reality is and that folks aren't happy so I see no utility in rubbing it in. But yeah, you're gonna have to take everything you read with a grain of salt, understand statements in the spirit they're meant, and not let yourself confuse subjective interpretations and unfulfilled expectations with malintent. The actual headline, main assertions--no microtransactions, none of the roadmap content on the way to 1.0 will cost extra, etc. are all pretty firm commitments and aren't just subjective interpretations about what "soon" means. I have no reason to believe they'd go back on actual promises. The actual people making this game are trying as hard as they can to push this game uphill so that it can be something really great. I feel like its okay to see them as people and let them do their jobs.

This is very much how I feel (except I don't play ksp1 anymore). Game sucks, so be it. Don't really care anymore. When it's good enough to play (in my opinion, dont really care about version numbers or ea) I'll probably play it. For now, very much looking forward to cities skylines 2 (talk about a different path to release)

If they can achieve this I think they’ll change the sentiment not only on Reddit but also solidly get steam reviews back to mostly positive. And we’ll have tons to talk about on the forums. Yes this is how I would prefer as well. I thought they were solidly on this strategy after tweeting out the apology and timeline… and then they missed the one date they gave. Community trust is low, the reviews are more negative these days there’s no reason to give dates you can’t make 100%. Whatever happened in the past is the past, and I was ready to move on to their new developments but then those new developments were more “promise things” and then not deliver those things on time. Combined with communicating the delay on Twitter, and the update on the new “date” on the discord. So, from my perspective, they tried to start a clean slate with an apology (which I bought in on) and then proceeded to follow the SOP that got us into this mess. All that said, from the poll on Reddit it seems most responding to the poll (skewed by sample selection bias I’m sure) don’t expect science within 6 months. So, the good thing about low expectations from the community is that surpassing expectations is a sure fire way to regain good will (see no man’s sky.) Right now we’re all just guessing, but I hope it plays out the way you think it will. I just, 6 months ago, even with the buggy launch, was having fun (assuming the bugs to be short lived) and definitely thought we’d be in a better position by now.

its just disturbing how little i know about cars. you think learning to drive would be a right of passage. but how the hell can i be 42 and have the possibility of vehicle ownership turn into an existential crisis. im gonna have to talk to my shrink about that.

////////////////////MISSION UPDATE\\\\\\\\\\\\\\\\\\\\ - Finishing K.G.02 - Last Instillation of Methalox - Heavy Tug Drone leaving K.G.01 enroute to the Mun with 32t of Methalox. Foreword: The mission can finally continue as planned. This is the first chapter in the end of this mission. After fixing K.G.01, burning it into a 0° inclination and refueling it. I have finally gotten to the point were I could make a mission to refuel the heavy tug drone that didn't quite make it back to K.G.01, after its first mission to K.G.02. I can now finally fly it back to install the missing fuel tanks. All that is left is to instal the Methalox tanks, Burning K.G.02 into a 0° inclination, and dock escape vehicles and crew to the station. Once these small steps has been complete. The Kerbin - Mun fuel station mission will finally be over. Without further ado - let's get the last methalox load enroute to the Mun. Mission Tasks: A. Launch Methalox glider to K.G.01 and return 1st stage to KSC - Success B. Refuel glider at K.G.01 and rendezvous heavy tug drone - refuel and land at KSC. Success C. Rendezvous Heavy Tug drone with K.G.01 and load cargo - launch mission towards the mun - Success Lessons Learned; Lessons Identified: A. Glider right before stage separation and the return of Stage 1. I have been rather successful in founding a good formula for launching my methalox glider into space, without the rocket flipping and or expending to much fuel getting up into the mesosphere for the first stage to make it back to the ground again. Refueling K.G.01 - which took 3 missions - I tried to find a easy way to land the rocket in the vicinity of KSC. So far my approach is to burn back towards KSC - without getting a AP above 70km (as it can take quite a while to be able to maneuver again once you leave the exosphere). Once the rocket is enroute back towards KSC I keep it horizontal facing prograde. I will periodically burn, while in the thermosphere (~30km to 70km) gauging the rotation of Kerbin. I have found that aiming roughly here yields good results: As soon as the rocket hits the Mesospheres I follow the prograde down, and land sufficiently within KSC - I am calling it a success as long as i am landing on the flat terrain within the mountain range surrounding KSC. Now I had a bit of trouble finding out were on the map the landing pads actually are.. and so far the only fix I could think of was placing a tiny rover on one of the landing pads - I picked the middle one in the hopes that in the future, if i cant land on the middle one, maybe i can land on either ones that are adjacent to it. Speaking of rovers - can we have a talk about how janky rovers feel? My wheel base is pretty wide.. and even though it was I was still struggling keeping the vehicle on 4 wheels... and when it was time to stop at the landing pad.. the result was as follows: I thought it was kind of funny that the rover crashed into a tree, even if they are not collidable. Any way it works, Now I know were on the peninsula the landing pad actually is, which has made it a lot easier to "line" up KSC. Some times the pixelated icons dont help the game - I know it's the style they are going for.. but I think it hurts the UI more than it benefits it. Any way - the mission to K.G.01 was successful and the landing of the first stage - very succesful. See a detailed walkthrough in the spoiler section bellow: B. M.F.R.G. docked at K.G.01 and being topped op to bring as much fuel to the Heavy Tug Drone, as well as making sure it can make the journey there and back again. The journey to the heavy tug drone and back to KSC was pretty straight forward. For some reason the Δv bug - where it shows 0Δv when its a fuel line connecting the fuel to the engine plate - wasn't there after the undock from K.G.01. It meant that I could actually do maneuver nodes which immensely helped the rendezvous. The correction burn of almost 7° inclination was a bit tough for the terrier to perform - I would drift away from the intersection point before the inclination had been corrected, but the rest of the tour went easy enough. The drone was successfully refueled and the glider made it back to KSC - I even had to do a night landing. It's interesting when you only have the map, your speed and your distance to the ground to go from. I learned though that the glider can maintain speed at ÷10° - which means you can extend the glide a lot. For detailed walkthrough see spoiler section: C. Heavy Tug Drone - rendezvous with K.G.01 and being refueled before being loaded with cargo. Bugs, bugs and bugs: This part of the mission went relatively smooth too - I Identified further issues with the inline/shielded parts. Apparently they work fine as long as you don't load or quickload while docked to them. I had loaded half the methalox tanks to the heavy tug drone when i went to sleep, and the day after I found that all my saves were a Clamp-O-Tron was connected to a Clamp-O-Tron shielded they would be registered as docked, but not acting like they were docked, moving independently of each other. How ever I found a fix! The shielded/inline parts will not show the option to undock - the normal clamp-o-tron will. However I have experienced inline/shielded parts stop working if you undock with the functioning clamp-o-tron. This time I tried to make a costume undock action for the shielded port and it worked. I even tried to do the same with the clamp-o-tron shielded on top the Cockatoo on the K.G.01 habitation module, where i made an action group that forced it to undock, even if nothing was docked to it, and afterwards I was able to dock my probe to it. It made me happy to know that K.G.01 is not broken anymore! (relevant bug report has been updated) Synergy Issues: I found out that the station has another synergy issue. While the Heavy Tug Drone grew in size to be able to go to the Mun and back again, the fuel tanks did not. Right now K.G.01 has 64t methalox - How ever the heavy tug drone has 33t fuel in it. Right now K.G.01 Hydrogen capacity is 80t distributed in 4 tanks. It will take the Heavy Tug Drone 4 tours to move the 80t fuel to K.G.02 (which is half the K.G.02 capacity of 160t fuel) - and right now K.G.01 only has methalox for 2 tours. before needing to be refueled - 16 M.F.G.V launches. A part of me wants K.G.01 to have enough fuel to perform all 4 Hydrogen Launches without having to refuel - which means I have to double the Methalox capacity of K.G.01 - there are two solutions to this: Image of double docking port - and extended methalox tank. Solution A: Make double docking port adaptor for K.G.01 - This will double the fuel capacity without changing the fuel tank design. It will probably also look dope AF. But! Every adaptor is 10 parts - and every extra fuel tank is 7 parts. Which means I would be adding. 96 parts to K.G.01 - and it already has a pretty poor performance. Solution B: I make a new fuel tank with 16t instead of 8t - It will mean that K.G.01 and K.G.02 will not have the same tanks. - This could be resolved over time though. What do you guys think? Go crazy and hope for performance improvements - or be sensible and put on less parts/bigger tanks? Any way - detailed walkthrough of the mission in spoiler section bellow: Moving Forward: Now I will return to K.G.02 for the first time in a while. I hope my experience navigating the buggy waters of KSP2 will spare K.G.02 for any breaking. I will at least do my best for it not to happen. Next up will be the instillation of what ever solution I find to K.G.01 - as well as escape vehicles for K.G.02, a correction of inclination on K.G.02 and last but not least, crew. Stay tuned for more.

News of Deep-R has left my SPH design team quite crestfallen, I have to say. I have never seen so many of my engineers quite so distressingly crestfallen. Very, very crestfallen. As Chief of Engineering & Design, I had to give them a pep talk. Here's how it went.

i too was thinking about getting wheels. neighbors 2 doors down are moving and want to sell their minivan for five presidents, and i have the funds. its stirred up kind of an existential crisis. i can get it, but i dont really know if im up for this kind of big change. id talk to my shrink about it but the car might be sold before then.

Hi am new to this game

Its also important to note that around a month and a half ago a community member was fired from the team, while the planned slowdown in comms for summer started before this, this definitely played a role in the recent reduction of large scale communications. Anyways to actually talk about the tweet, a bit ago we got confirmation that the purple heating isnt necessarily what eve will look like. IMO the most interesting thing about these pictures is how it ties into something Nate said a while ago. I dont feel like digging up the quote but a while back nate said something along the lines of (iirc, actual wording was probably very different but this is just to get across the vibe of the comment) "Different atmospheric compositions make different heating visuals. While this isnt something we plan on implementing for version 1 of heating, its something that we want to do in future development". The fact that they're showing off multiple colors implies that they may be planning to release the different atmospheric reentry effects first go, which is neat. Its scope creep but in a way I dont really mind, its not like reentry vfx is top of peoples ksp2s wishlists right now and it seems nice from a development perspective to have stuff just be mostly done and you dont need to poke and prod at it much anymore.

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.

This AMA was extensive, in depth, but still weak, as that depth is on what I gauge are the wrong places: personal stuff, personal wants, personal dreams. Also for the next time, I'll make sure to submit my questions to Kavaeric or Spicat. There's the loaded question about the heat system, which is a simplification of the one we had yet it still comes loaded as "complex". From the thread on the heat system it became clear to me everyone is ready to answer to praise, but nobody was ready to answer genuine questions or respond to possible criticisms or player concerns. In the science question pitting KSP1 against KSP2, that the only answer is approachability... yeah, not happy with that answer. Whilst the answer on the modding questions were good, there's 0 compromise in them, which is a common theme by now, y'all talk about what you want, and not about what will be. Orbital construction: seems pretty basic, he does mention "hundred meter long ships"... is that in a couple giant parts or many normal parts? Colonies: "We are designing...". Bad. I prefer to think it's just a missed form of speech than really starting to design colonies now. Interstellar: Good, a second confirmation that FTL is not in the game. Heat on cold colonies: yet another missed opportunity for colonies to be anything more than set and forget.

No, you got impatient and posted early. I just made sure the pic you wanted to post was on the right number. It was done for you, so no talk of stolen please. TUBM is calm.

Agreed. But a binary fill (of the capped storage unit, possibly coming with an equivalent reduction in the amount of the resource at the mine, still thinking about my thoughts on depleteing material sources) means both play styles get equivalent access to resources. The player who wants to plan his missions based on what the next available transfer window is isn’t hampered in resources compared to the one who is ok warping through it all. Yup. The ideas are fun to talk about in the abstract, but the specifics of balancing it all will be quite tough. I was never one who wanted very complex life support in the game, but in late career saves I always felt guilty warping a great length of time and leaving several kerbals in tiny tin cans in orbits or on planetary surfaces. I would rather there be some incentive to not do that, but recognize I may be in the minority on it. A “this command pod is good for 6 years, then will be inoperable due to Kerbal death/hibernation” would imo lead to more intentional and planed gameplay decisions. I still don’t think that needs to be in the base game. However, for those who like to keep those considerations in mind binary fills would allow that style (even if just player limited) to not be hindered while, from my perspective, not taking anything away from the other side. They can still time warp as much as they want, there’s just no need for the more timeline methodical style to do so. Make the limiting factors the other ones here discussed, and I can approach advancing those limiting factors with a goal of minimizing Kerbal time in tin cans while others can disregard that.

I agree storage/colony VAB limitations (coupled with ways to expand those limits as you progress through the game) are the key to making the core gameplay loop fun and engaging. I guess whether or not the tanks are binary or gradual isn’t a huge issue, as I’m sure there will be mods to let you do whichever method the devs don’t chose. Balancing all of this is going to be one heck of a challenge tho with the many different ways people play KSP1. Hopefully they pull back the curtain on these systems soon, they’ll be more to talk about with a general idea of how this system will work.

Not sure where you were getting that idea from my posts. The launch cost for a basic rocket should be the same amount of funds, metals (or whatever material) and fuel regardless of where you launch it from. In the early game, metals and fuels would be unlimited, but funds would be tight. So you need all three for consistency but only funds matter. Mid-game, you're maybe launching from Duna. The funds cost of the rocket is now trivial because you have lots of funds, not because the cost changed. The metals and fuel costs now matter a lot, because you need to somehow get them on Duna, not because the amounts changed. I hope that's clear. So the focus of gameplay naturally changes from "I need cheap launches from KSP" to "I need ISRU". And later still you need lots of metal and fuel, so the gameplay evolves to "I need a colony that makes these resources at a scale where I no longer care about them." In the late game, none of the resources for basic rockets are scarce at all, you've finished that part of the game. Now it's all about whatever resource powers near-future tech, with exploration to find it and perhaps unique challenges in extracting it. And for the end game you need that, not just as simple ISRU, but as an automation/colony challenge to make vast amounts of it for the interstellar ship. OK, I'm utterly baffled by where the "grinding" comment came from. I assume you've ever played Factorio or some game in the genre it created, so you know it not about grinding. You simply can't progress the game that way, you have to embrace the new mechanics. And as you do the resource you worry about shifts over time. Yes, I totally a agree that "X or Y" can be more fun than "X or 10X", but that's much more dev work. Forgive me if I suggest that's not a useful direction, all things considered. (As a point of reference "451 games" (a kind of immersive sim) are all about "X or Y" to pass every challenge, and while I find them immensely fun they're so expensive to develop that only a few have ever been made.) That being said, Factorio is a whole lot of fun and it barely has any "X or Y" elements at all (coal liquefaction, and belts-or-bots are the only ones that comes to mind, and the game was a success before those). There's an amazing amount of player agency and choices to make in how you solve the problem, rather than which problem do you solve. You also talk about player choices that skip some steps, and while that can be fun for expert play, a lot of that doesn't have to be designed in. Expert players will find all sorts of skips you never designed in. But I don't think you should make content that, on a first playthrough, many players will skip (other than easter-egg type stuff), because again that's an expensive approach. Limited dev resources are usually better spent making content that all players will see. Of course, KSP does have replay value, so it wouldn't be a waste, but to me any sort of (designed-in) "alternate path" stuff should be added after the game is finished. It makes good DLC/expansion content, after all. But there is some "X or Y" in this approach and even a bit of "skip" choices, in that at each transition point between "how do I produce enough Resource A" and "how do I produce enough Resource B", there are interesting choices to make. E.g., as you start making a colony on Minmus, do you try to bootstrap that with lots of launched from Kerbin, or lean into colony ISRU and have it mostly build itself, or as an expert player decide "you know, I bet a colony on Gilly is a better long-term bet, and almost as easy" and skip Minmus altogether, There's no real problem with rocket parts and fuel being unlimited on Kerbin, any more than inexhaustible ore patches are necessarily a problem with automation games. You don't need to limit them on Kerbin, you just need something that makes launching resources from Kerbin at scale impractical. For the mid-game, when you're e.g. trying to build a colony on Duna, I would go with simply he funds cost. Lets assume you need really substantial amounts of metals (or whatever the construction resource is) to build and expand the colony. While the funds cost launching individual rockets might be a non-issue at this point in the game, the cost to launch 1000 is a different matter (or as Pthigrivi suggests, time could be the bottleneck.) As soon as you add automation to a game, the challenge becomes about scale, because the gameplay is about producing unlimited resources. Just because you have some unlimited source on Kerbin doesn't trivialize the game, but is rather the start of the chain. For building on Duna, you could try to launch everything from Kerbin, but as long as that doesn't scale well that's fine. As long as launching from e.g. a Minmus colony is a much easier approach, it's fine. Assuming here that a Minums colony would become much more efficient toolchain for launches to Duna than KSC launches, which wouldn't be very hard to design in.

The purpose of the paper is to assess Exxon's modeling with newer data. (This particular chart is from 1982). It shows strong correlation, which corroborates the validity of the modeling. The delta-temperature is zero-based. There's no benefit to charting the CO2 PPM to zero, because that's not a condition that's existed, and it would be discontinuous anyway, as soon as CO2 concentration ceased being the primary controlling variable in the physical system. The usual datum is 1850 for industrialization, and hundreds if not thousands of temperature stations existed worldwide by 1900. I've actually visited a science station that was built in 1897 and had a LONG conversation with the docent. They did some hardcore observations there. 1 deg C in that amount of time, over the entire Earth is a MASSIVE amount of energy--It's relevant. Particularly since we know that the ocean induces a LOT of thermal lag. So, a 1 deg change represents much more energy storage than a 1 deg surface temp change indicates. Independent models being corroborated. Possibly from the same or similar sources, so I'll give you that one. Originally published internally at Exxon for making business decisions about the effects of drilling a new field. Only obtained by the public in 2015. They weren't trying to impress anyone, and the conclusions drawn were contrary to the business interests. A manipulative chart would have wanted to downplay the effects. Extractive industries have higher profit margins, and it was already their expertise. Solar, wind, nuclear, hydro, and geothermal were already in use, but that required investment, and the risk of moving outside of their existing expertise. Short-term profits and risk aversion prevented them from moving sooner. Today, oil company investment in green R&D is about 1% of their budget. (i.e. meaningless). The source for that is a recent TED talk by Al Gore, which you may not respect as a source, but I'm comfortable with him getting basic company-provided numbers correct. See the above. My unsupported conspiracy theory involves oil as https://en.wikipedia.org/wiki/Hydraulic_empire Renewables are much easier to decentralize and don't provide the same opportunities for control. This is fair and possible, but not necessarily true. The argument is, "Can you get data that's more precise than the precision of the instruments, and is it fair to report it as such?" The answer is definitely yes. Many depleted traces, cross-correlated with each other. This is much more difficult to do, but we proved plate tectonics in a very similar way. Lots of geological and paleomagnetic observations, and I'm sure many of them were contradictory and confounding. And yet somehow we're not arguing about the validity of this: Long-term and short-term data. Those damn geologists and their AGENDA! They were all paid off by Big Dinosaur! It's a Silurian plot! Ours match pretty well now, and I live in a very weird area with crazy geography and lots of microclimates. That said, "Climate is not weather" We're looking at the global average over a long period of time, not the daily bumps and jumps that are highly influenced by local variations in terrain and vegetation.

That can work if there’s sufficient trust between the developers and the community. If there isn’t, it will just make things worse. A lack of trust is a vicious circle. Any event or communication will be interpreted against that background which will only add fuel to the fire. I think IG ought to have gone completely silent! Just release the patches with the patch notes. People would rage like they do now but they would be shouting into the void. And the patches would provide something positive to talk about. When the first roadmap update is ready, make sure it’s as solid as you can make it, and only then reboot communications. There are situations where “silence is golden” does apply and this I think would have been one of them. Putting developers in front of the community hoping that they’ll put the pitchforks down won’t work, it just drains time, effort, and morale that could be better spent on the game itself. Put another way, actions speak louder than words.

So I'm not sure if there's a thread about it, because I haven't seen one, but if there is feel free to merge/lock this one after posting a link to an existing thread. So I was lately thinking about replacing my old(ish) SONY Xperia L with something newer. What would be best is a phone with Android 5.0 and higher but with the same size of the screen. The problem is that doesn't leave me with much options, so I also thought about buying something like this. The phone cameras are kind of meh/10, but I don't think I'll be using it much anyway. I'm also considering buying a solar power bank. Because free energy! (not really though). So what do you think? Is it a good idea to buy a phone from a not-so-well-known company, or rather spend more money on something that is more "reliable". Are solar panels on a power bank worth it? Share your thoughts. And please, keep in mind I'm not an expert. Also don't turn this thread into iOS vs Android war thing. We're all mature enough not to do that, right?

I think I mentioned this in the grand EA discussion- there are many dormant threads on this forum that contain untainted discussion about the game, under the presumption that everything is fine and the game will eventually be completed. If that is what you want to talk about, why don’t you revive one of those many threads? I’ll stand corrected and be on your side if anyone starts bickering with you in a thread that’s actually about something substantive relating to the game that’s not a glaring current issue. Which thread do you wish you could post on?

They post a lot of development updates. There’s a lot to talk about there, or would be if the threads didn’t devolve into the usual bickering.

More personal comments removed. So we're all agreed that we hate each other and the other side is wrong. Now please talk about the game rather than each other. Meanwhile, overlapping threads have been merged.

I mean we literally have a whole new game with new UI and updated planets and all kinds of things, plus Science and colonies and interstellar are all on their way. Id love to talk about those things. We went years with much less in the past but still had tons of great conversations about how KSP could get better. Ive always had really lively conversations with folks I don’t agree with. Hearing new ideas is the only way we grow. Having different opinions is great. Repeating those opinions hundreds of times into most of the threads on a message board with the deliberate intent to clog all discussion and get attention from the devs is just run of the mill trolling. Its too bad. This place used to be fun.

I wonder if performative arguments have increased, or if there is simply less substantive stuff to talk about these days, because not much new has happened. Most topics have been worn out, so what is left on the forum is a low volume of posts about an issue that’s still salient, which is the fact that the game is currently a mess. Therefore it seems as if the forum has turned negative or unproductive. I’ll make a prediction: the tedium will become comparatively less impactful once a serious feature update is released in 5 years time. (okay the last bit was sarcastic, I couldn’t help myself)

Arr!