Jump to content

Eric S

Members
  • Posts

    1,589
  • Joined

  • Last visited

Everything posted by Eric S

  1. WARNING: Joke suggestion, not my real attitude: At 1/10th scale or so, I'm surprised noone's suggested "It's a Small World." Then again, those posters are probably playing with the RSS mod so that it doesn't bother them.
  2. This is a good idea, though to be honest, I'd like a timestamp of the saves in the alt-F9 popup, preferably both real world and in game timestamp.
  3. I'll agree with the idea, but I'm not sure science return should be what encourages that. Maybe budget, definitely reputation, should reward more "aggressive" exploration. Of course, that's getting back to the idea that we're playing an unfinished game.
  4. Correct, though you're in the dark for a longer period of time. Not much of an issue for docking, but if you're setting up an RT2 communications constellation, that might be an issue.
  5. I have no problems with it, if you don't think it's fair, don't do it. I usually revert, sometimes I don't because what went wrong was interesting in its own way (an excuse for a rescue mission, swapping out a module on a mothership, etc). And yes, the devs have expressed the opinion that they have no problems with revert as it applies to budgets and career mode, though it's possible that they might change their minds (or already have, for that matter). So I'd expect Revert flight and quicksaves to be as freely available as they are now, though I wouldn't be surprised if they added a knob to disable them (the flag is already there in the persistence file).
  6. I strongly agree with the first part of this. While discussing balance issues is reasonable, it's really too early for some of the absolute statements that get thrown around to be that reliable. About as reliable as I think we can get is the statement that the default game won't be that challenging for those that have played the game for years because it still needs to be playable by people that have just started the game. Also, I may have misremembered my typical Minmus lander, it may have been hitting 4-6 biomes instead of all 9, but it wasn't that much more expensive (at current cost balances, I expect that they'll rebalance the parts cost) than my minimal Minmus landers. I'll second this. At this time, the only non-RP reason to land a rover is to drive to different biomes, which means either landing close to a boundary between one or more biomes, or a lot of patience. I have, exactly once, created a craft capable of both driving and short orbital hops that managed to hit all 15 Munar biomes in a single trip. I never intend to spend that much time driving again.
  7. True, the most annoying part of playing Better Than Starting Manned is that it's been tuned to the point that you're just about required to get almost all the science along the way, leaving few real choices along the way. Or at least until you can start doing probes to other planets. I'll agree on both points, though I doubt a multi-biome mission to Duna is as practical as one to Minmus. However, with biomes in both places, it will probably be fairly easy to do a combined Duna/Ike mission that excedes the science return of a 9-biome Minmus mission. Not quite true, I hit all 9 surface biomes on Minmus as soon as I unlock fuel lines. Which is not a complaint, BTW, as I'm probably one of the more experienced KSP players.
  8. Nine biomes for Minmus, and 15 for the Mun. With fuel lines, it should be possible to create a manned lander that can hit all 9 Minmus biomes in a single trip (short hops between biomes, don't go back to orbit, that costs a lot more fuel), though at that level of tech, you most likely won't be taking enough Goo containers and Science Jr's for all the biomes. If you're looking for more science before you start going interplanetary, I strongly recommend looking up biome maps of Kerbin, Minmus, and the Mun, and remember which experiments are per-biome at which altitudes. The Negative Gravioli Detector is nice that way, as it is per-biome in both low and high orbit. EVA reports are per-biome on the surface and in low orbit.
  9. It has been suggested before, though I don't remember what the response was, if any. The devs seem to be either indecisive or have changed their minds on whether recovery will be affected by distance from KSC in regards to recycling parts (which isn't what you're talking about).
  10. Actually, I was thinking more in terms of the contradiction of "there is no one way to play" and "play in sandbox" though I didn't state that very well, or at all, really. Wasn't meant to be argumentative, which also came out wrong, so apologies for that. I absolutely agree that everyone should play the game the way that they find fun, be it sandbox vs career, stock vs modded, etc., and have no issues with giving opinions/suggestions to people that ask for them. The reasons I haven't done a full mission in sandbox since career mode came out don't necessarily apply to anyone else. The reasons you play sandbox, similarly, don't necessarily apply to anyone else.
  11. Isn't that a little self-contradictory? If anything, he should decide for himself how he wants to play, not take someone else's opinion.
  12. Not exactly sure what the question is. Since you've got unspent science, I'm assuming you just mean general direction, you're not actually stuck. My early targets in stock career mode are: Decouplers Batteries Fixed Solar panels Fuel lines Thermometer, Barometer Better solar panels Beeline for the Gravioli detector EDIT: You'll notice that I pretty much ignore 2.5m parts. That may not be the best decision for you, it really depends on your skill level and such. I've done manned round trips to Duna and Ike's surface without a single 2.5m part, as well as Eve orbit and Gilly's surface, and just about any other planet with probes. Basically, I don't need 2.5 meter parts to finish the tree, so I don't prioritize them. Science parts on the other hand, help a lot towards that goal. On the other hand, the last time I played a stock tech tree was before 0.23.5, and the changes to the 2.5 meter part placement in the tree has changed, so those parts may be more viable now that the poodle isn't the first and only 2.5m engine you get at the first node with 2.5m engines. You've got the first three items on that list. I'd definitely spend your remaining science points on Fuel Systems and Space Exploration, that gets you fuel lines and the thermometer. Fuel lines let you more easily create multi-hop landers if you want to go back to the Mun or Minmus (Minmus is a fantastic place for science if you don't get bored of it, 9 biomes and low enough gravity that almost any craft that can land there should be able to hit multiple biomes) or cross-feeding fuel boosters for larger launchers if you want to start going interplanetary. The thermometer gets you a good bit of science. Beyond that, I think we'd have to ask what you want to do? Would you enjoy more trips to the Mun or Minmus (yes, Minmus is easier to land on, even takes less delta-v including the transfer)? Or do you think it might start feeling repetitive? Do you think you'd want more science parts before you head out to other planets? Or will more science parts want you to go back to the Mun and Minmus to get it all before you go on (yes, I can be a completist, so I speak from experience here). If you're more of a completist, I'd probably recommend getting the rest of your science parts via Mun/Minmus science before going to Duna/Eve/etc., as going back to the Mun to finish up science with new parts is a lot easier than "oh, a new science part, let's redo that huge mission to Jool that visited all its moons."
  13. I'll third KurtJMac in a round about manner. Aaron Williams linked to a KurtJMac KSP video in one of his link dumps, I followed the link and bought the game less than three hours later, with about two of those hours spent in the KSP Demo (0.13.? at the time). First thing I did in game was to create the ship that quickly earned the name "death rattler." Kid you not, that thing, even when it wasn't exploding, was swaying, shifting, shaking like something out of an old black and white cartoon. The second thing I did was discover struts. That's when I started making it to orbital altitude, though orbit came a bit later because I wasn't being remotely close to aggressive enough with my gravity turn. Made it over half way to the Mun before I managed an orbit. A little practice with my gravity turn, and I was reaching orbit, though my first orbiting craft didn't arrive with enough delta-v to deorbit. Once I actually made it to orbit and returned, I hit up the KSP store to buy the game. The next day, I had my first munar landing (using someone elses design) on my first attempt, though due to hitting the space bar to launch (a staging step that shouldn't have happened until reentry), it didn't return. The next few landings were definitely more impact than landing, and I think it was my fourth attempt that actually returned. Then I started designing my own craft. We won't discuss the fact that my first self-designed munar flyby had landing gear, but I did manage to land and return a craft of my own design on the next mission. I had to overengineer everything back then as landing on the Mun was 1km/s (or more) of delta-v rather than the 650ish it should be (piloting issues, not game changes), transfers were never accurate enough to avoid major corrections once I hit the target's SoI (and I didn't know efficient ways to make those corrections), etc.
  14. While I'm a good spaceship designer, planner, and navigator, my actual piloting skills leave something to be desired. I can't remember the last time anyone but Jeb got off the ground in any of my career saves. I run a one-astronaut space program, it seems. Which isn't to say that I've never killed Jeb. That's what F9 is for. It does, however, mean that I've never stranded him (except by crashing, which also gets an F9). I can build spaceplanes that can reach orbit and return, some have even done flybys of the Mun, but not one has ever successfully taken cargo to LKO. Oh, I airhog a bit too, but not to extremes. I can get there without it, it just doesn't feel as fun. My first trip to Eeloo, back in 0.18.2, less than a month after I started playing, took something over 60 years AFTER I reached the right orbital height because I botched my transfer, and while I was able to find an intercept, it was several very long orbits later. Only my OCD managed to keep me going through 6 hours of max timewarp looking for a potential encounter. I started playing KSP just about when maneuver nodes were added, so I have no excuse, I can't claim to have been doing it the way I already knew how, but I still didn't use them for the first two or three months I played. Oh, that Eeloo mission would have gone so much smoother if I had taken the time to figure out maneuver nodes. Once while working on a more efficient method to rendezvous than the "kill relative velocity/thrust towards target/repeat until there" method, I managed to slam into the craft I was trying to dock with at somewhere over 100 m/s because I was paying more attention to my target-relative prograde vector than my distance to the target. A few of the other confessions here sound very familiar as well. Asparagus staging (at least I've stopped doing the two, three, and even sometimes four layer deep monstrosities), forgetting solar panels, etc. :-)
  15. Sounds like me, for short hops, I tend to use the main engine to counter most of the weight and then use RCS to more precisely control the surface velocity and altitude. Hopping four story colony stacks on Minmus using that technique can be interesting but works. :-)
  16. Was about to say that that's true of a lot of programmers in general as well, but really, you can substitute "people" for "modders" there. So not a flaw specific to modders :-)
  17. Depends on whether you want to balance against stock or reality, and there are a few other factors in the latter that might affect the scaling as well. Stock scales fuel capacity, mass, and cost linearly based on volume. The really small parts don't fit on the scale, and the SLS parts have their own scale, however. Reality isn't so clear cut. If you're wanting to scale the cost/mass directly linearly to the surface area, then you're assuming that the tank has the same thickness at any scale. At some point on the high end, the same thickness won't even be able to support its own weight. If you double the dimensions of the tank, you've increased the mass that the tank can hold by 8 times, but haven't noticeably increased the tanks ability to constrain the fuel within. That's not going to end well if anything goes wrong. The more mass per surface area, the less lateral force it would take to rupture the tank. Things don't even have to go wrong, really, because a large tank is probably going to have more mass on top of it than a small tank. The slightest sheer force would make the tank collapse for a sufficiently large tank. This is similar to the arguments against giant ants, or giants in general. Double the height and maintain the same proportions, and you've increased the mass by 8 times, but only increased the creature's ability to survive the stress of the mass by 4 times. I like Kasuha's approach, and if we were aiming for that level of accuracy, that would be a good start. All things said, I'm fine with the linear scaling that stock KSP tanks use, reality would be far too complex to try to model here.
  18. Thanks, mhoram, this time I've bookmarked that thread :-) The best non-math description I've read is to think of it as a reverse of an optimal launch on an airless body, which is to say, a gravity turn as aggressive as possible that still manages to avoid colliding with the terrain. On bodies that aren't airless, that description breaks down, but this landing method is strictly for airless bodies. Both landing methods have the main benefit of a suicide burn in common, that once they start burning, they're full throttle until most or all of the velocity is killed, minimizing gravity losses, which is why the suicide burn is efficient. On most bodies, I wind up doing a less than perfect horizontal landing method, killing my orbital velocity 500m-2Km above the ground (depending on terrain), which probably isn't more efficient than a suicide burn, but is close and is a good bit safer. That said, it doesn't change the fact that that's a very good write up on getting to the moon, and that's what this thread is about.
  19. I'm sure they'll do a lot of polishing when the game gets closer to release. Right now, much of the work going on is involving career mode.
  20. Did you not actually watch those streams? In several of the streams I watched, the player either hit a bug, or explained that he was doing something in a way that avoided a particular bug. They were playing a version of the game that was not deemed stable enough to release to the public. As a programmer, I can tell you that sometimes the "simple" bugs are a nightmare to track down or to fix, sometimes both. I've had more than one occasion when just writing up a description of the problem and possible solutions took more time than my non-programming boss thought it would take to fix the bug because what appeared to be a simple bug was actually a complex interaction of multiple subsystems. When in this kind of position, you can play it safe and not announce a release date until you actually have something you're willing to release, or you can announce a release date and hope your estimate for fixing bugs isn't too low. As good as this community is, it still tends to blow up if Squad fails to deliver on something that it perceives to have been a promise, and a missed release date would definitely meet that criteria. With that in mind, I don't mind that Squad's release dates are usually either "Not yet" or "Now."
  21. A good writeup. The only part that triggered any "that's not quite right" alerts was a matter of interpretation. While I think I understand what you're saying, it sounds like you're saying that a suicide burn is the most efficient way to land. The horizontal landing method that's been discussed is more efficient if you do it right, though as the TWR of the ship increases, the two methods converge. At infinite TWR, they should be equally efficient. Then again, that landing method tends to be an article in itself, so I can see why you wouldn't want to go into that in an article about getting someone to the moon for the first time. I just think that line may be giving a false impression to people that don't know otherwise, so you may be encouraging people to aim for the suicide burn when it isn't necessary from an efficiency point of view.
  22. Yup, need screenshots or .craft files, fuel flow in KSP can have some odd behaviors until you get used to it, though I think Kasuha is the expert on that.
  23. That was what I was thinking as well (which isn't to say that that makes it a great idea, I readily admit that my view probably won't match the dev's view). For the kinds of ISRU NASA is talking, finding a compatible biome would be sufficient, they're not talking about trying to find the equivalent of natural gas or oil deposits, which for the most part gets rid of, or at least greatly simplifies, scanning. Without a simplification to scanning and deposits, we'd still be looking at Kethane, but with water taking the place of Kethane. The important part about the discovery of water on Mars, from the ISRU point of view, was that it wasn't in specific places, it could be baked out of just about any soil on Mars. Water has been discovered on the moon as well, so it's possible that the moon may be in a similar situation, though with lower amounts of water per Kg of soil and it may be harder to extract. Maybe just having a per-biome variable of how fast a basic processor could extract fuel would work.
  24. He issued a warning. I wouldn't call it veiled, that's pretty much a standard warning the mods issue any time a thread starts discussing something that's either close to but not over the line on something on the do-not-suggest list (or on occasion even something over the line provided it's discussed reasonably), or something highly polarizing within the community. This is more the former than the latter, I don't think there's very many people that would argue against ISRU in any form, and yet it's still a rather sensitive subject because we're all dealing with something we're passionate about. Source? As I said, when they discussed the cancellation, they said that resources as diagrammed in that chart where dead because that mechanism wasn't fun or fitting into the game the way they wanted to. They said at that time that they'd consider alternative mechanisms provided that the alternative met their criteria (this was in one of Harvester's live discussions during the KerbalCon that coincided with the announcement that they were ditching the proposed resource system). They've repeatedly said that they won't put something into the game resembling that resource chart but I've never seen them give a blanket rejection to ISRU in any form. They're not interested in making a stock but more complicated version of kethane, and at least some of their criticism and comments would apply to something as simple as kethane as well. I've never seen anyone suggest an ISRU system that wasn't derived from the chart or a clone of kethane, so I'm not sure where you get the idea that they've said no ISRU at all. On the other hand, I'm having a hard time imagining an ISRU system that could avoid all their concerns without messing up the game. No, I'm not forcing words into your mouth and I never said anything about an incomplete career mode. They've been working on career mode since the time they decided to can that version of resources, and in order to have worked on a replacement ISRU system by now, they'd have to have prioritized it ahead of career mode. Which is not saying that we'd end up with an incomplete career mode, it's a question of which gets worked on first. Since I haven't seen them shoot down all forms of ISRU despite following the forums, the dev streams, etc., I'm working from the assumption that they may or may not get back to ISRU after things with a higher priority, such as career mode, are functional enough. You're assuming that since they've decided against anything kethane-like or more complicated that they're against all forms of ISRU and I haven't seen any evidence of that. Which is why things get on the do-not-discuss list. They gave their answer, and you don't consider it valid. This leaves them with rather limited choices. They can waste time giving the same answer over and over again, they can just be uncommunicative on the topic, they can add the topic to the do-not-discuss list, or they can give in to the demands. You may have convinced yourself that your argument is flawless, but you haven't convinced me, and I'm in favor of ISRU. Heck, at the time they killed it, I said that while I could understand their reasoning, it's not the decision I would have made. That's still my opinion, in fact. I'm not about to say that ISRU mechanics shouldn't be in KSP because I want them. My point is that the devs have said no to that specific implementation for their own reasons and for importing Kethane (they generally give that answer when asked to make a mod stock even when they code up a very similar implementation themselves). If you want to change things, throw out ideas that haven't already been brought up. Some form of ISRU that addresses their concerns, or even alterations to a system like Kethane that would address their concerns. If I had an idea for an ISRU system that did address their concerns, I'd be throwing it out for discussion, but I really haven't come up with anything. Then again, new game mechanics really aren't my area of expertise.
  25. I assume you mean the feature, not the whole game. I agree with this even though I don't agree with everything you say. I respect your opinion even where we disagree, and as long as we all follow that, we'll probably have a discussion that the moderators don't have to jump into. I agree completely here. In fact, I think the devs do as well. They haven't said "no resources ever." What they did say was "not that way." In fact, they sounded like they were interested in finding a more interesting way to do ISRU. Nothing has come of it because career mode takes priority, but that isn't saying that there won't be a simplified ISRU system after career mode is at least mostly in place. Agreed. I think the original mechanic was to cover both ISRU and orbital construction. While I think that the devs intend to cover ISRU type stuff, I think that orbital construction belongs to mods or an expansion, it really doesn't fit well with the dev's current focus of KSP. I think that the point of view on AFK gaming revolves around the fact that the longer you do it, the greater your gain. Waiting longer for a launch window might get you a better window, but diminishing returns set in fast. Waiting longer on a transit orbit means you miss the target. The devs made it very clear early on that they wanted to stay away from time-based incomes for precisely this reason, so I don't think we'll see this. I think that this is where we start disagreeing. The devs have stated why they scrapped the resource system the chart was based on, and you even seem to agree with that decision. They did not say that there would never be an ISRU system in game. And then they turned their focus to career mode, and not a lot that isn't career mode is going to happen until career mode is more fleshed out. What part of that are you disagreeing with? It seems to me that the only points of disagreement would be 1) the original resource system shouldn't have been scrapped, or 2) a replacement system that can cover ISRU should be prioritized higher than career mode, with a possible 3) the devs should commit to covering ISRU before the game is considered finished. The first has been responded to. The second assumes that ISRU would be more important to the finished game than career mode. The third assumes that the devs consider ISRU important enough to commit to doing something they have yet to find an acceptable (to them) way to implement. Here's were we more strongly disagree. Just because they don't follow the community input in every case doesn't mean that they aren't interested in community input. Ever want to go to the movies, and ask what movie someone else wants to see and they suggest something you're not at all interested in? Just because you aren't interested in seeing that movie doesn't mean that you're not interested in finding some other movie that you're both interested in seeing. The community is not in charge. I believe our input is valuable, but it's not going to force the devs to do something that they consider unacceptable. The customer is not always right. They have given what I see as valid reasons. The reason that this is such a touchy subject is because some people don't consider those reasons valid, and some of these people can get rather insulting about their disagreement. Even with how "friendly" this community is, usually as soon as this comes up, there will be people leveling accusations at the devs about being lazy, incompetent, and similar, without any more evidence than they didn't get what they want. There's not much reason to discuss something when the people starting the dialog aren't saying anything new and don't consider the previous answer to be acceptable unless you've got a different answer, as all that will happen is that the previous discussion is going to get repeated. Repeating the same argument over and over without anyone changing their opinion may be a popular internet past time, but I don't think it has a valid place in software development. That said, being insulting is not the exclusive domain of people that are upset with Squad, and I don't support that either. I may be indelicate expressing my opinion to someone being likewise indelicate (not referring to you, I hope I haven't insulted you, I'm legitimately trying to answer what I can and I'm open to discuss what I can't), but I've got no reason to be insulting. Insults don't win debates. Not that there's much that does win debates on the internet, but what can you do?
×
×
  • Create New...