Jump to content

Red Iron Crown

Members
  • Posts

    15,119
  • Joined

Everything posted by Red Iron Crown

  1. I was reading a thread today in the Suggestions forum and when I went to open the next page the forum gave me a permission error. A bit of back and forth revealed that the thread had been deleted. I found this odd as most of the forums I frequent just close threads that are getting out of hand or too contentious. Often times these closed threads can serve as useful counterexamples for proper forum etiquette. I was just wondering, what makes a thread worthy of deletion rather than merely closing it? Don't take this as criticism of moderation, just curiosity as to how such decisions are made. I have the utmost respect for the moderators and the difficult and often thankless job they do. I realize that this post might be construed as a violation of forum rule 3.4, but in my defense I don't know who I would contact directly as I don't know which mod removed the thread. If it is out of line please let me know.
  2. The best thing about using delta-V to analyse craft is that it is allows comparison between ships of greatly differing masses. If you only looked at the amount of fuel in a craft, it would not be directly comparable to another craft if the masses were different, because the lighter craft could accelerate more for the same amount of fuel. It also makes mission planning much easier. All craft require the same amount of dV to reach a given destination, but the fuel requirements vary greatly depending on mass. So as long as your craft has enough dV to reach its destination it doesn't matter whether it's a 300 kg probe or a 1000 ton space station. There are four basic techniques to increase dV: 1. Add more fuel (the most obvious) 2. Use more efficient engines (higher Isp, converts fuel into acceleration more efficiently) 3. Reduce dry mass (the mass of the ship without fuel in it) 4. Staging (in effect reducing dry mass mid-flight) Kerbal Engineer Redux and MechJeb are two mods that do the delta-V calculations for you, they take much of the guesswork out of craft design.
  3. I don't know why anyone would bother with nukes for attacking Earth from the Moon. The moon is near the top of Earth's gravity well, kinetic energy weapons would do just fine without all the political and radioactive fallout.
  4. Somehow I don't imagine they pester the Unity people for release dates, given their own policy about such things.
  5. This is far from being as cut and dried as you make out. EULAs haven't been rigorously tested in court, and it is thought by some lawyers that the doctrine of first sale applies to software licenses and they can be resold. Software companies are sidestepping the legalities by using DRM to make resale difficult rather than roll the dice on whether EULAs are enforcable. No, they can't really. A mod is the mod writer's work; it presumably contains none of Squad's code and none of their art assets. That it is meant to interoperate with KSP does not make it a derivative work controlled by the original copyright holder. Shapeways' case is different because it uses Squad's artwork and is clearly a derivative. No, they wouldn't. As long as the mod contains none of Squad's code it is not a derivative work. Their only recourse would be to break its compatibility in an update. It doesn't work this way. There is a huge market in software that extends and builds upon the software of others. Think management tools for databases like Oracle, administration tools for Windows, etc. As long as the software doesn't contain any of the original software's code and doesn't decrypt anything to work (thanks DMCA!), it's legally in the clear.
  6. I'm not saying that what Squad has developed is insignificant or easy, but it's not a game engine. Squad wrote a game, a very good and complex game, but not a game engine. KSP's game engine is Unity. KSP could only be developed as quickly and by so few developers because they didn't need to write their own engine from scratch. Game engines take many thousands of programmer-hours to develop; that's the whole reason they get reused and licensed.
  7. I don't think this is correct. As I understand it, all of Unity's physics calculations are done in a single CPU thread by an old version of PhysX that doesn't take advantage of the GPU for that. The GPU is used for rendering only.
  8. What is it you want docking ports to do that they don't?
  9. ^^ You realize that Squad didn't write an engine, they licensed Unity and built KSP on top of it.
  10. It should be mentioned that Isp is not the same as fuel consumption, though fuel consumption is calculated using Isp and thrust. For example, the LV-T30 and the LV-T45 have the same Isp characteristics but the LV-T30 consumes fuel faster as it is generating more thrust.
  11. There is also the fact that people feel more entitled to bugfixes/ongoing support once they've put money into something (KSP is a good example of this). I think most mod makers are hobbyists, modding for the love of the game. If it became a job, with deadlines and quality expectations, I think you'd see far fewer mods.
  12. After playing around with ion engines I found them to be painful to use due to the extremely long burn times. Nukes are bad enough for this and ions seem to be an order of magnitude worse. Sometimes the efficiency with which I use real life time is more important than using the most efficient propulsion. Plus I hate that they turn the ship into a solar power plant.
  13. These guys used to be *the* name in model rockets, I had a bunch of their kits as a kid. http://www.estesrockets.com/
  14. That's the dictionary definition, and gimbals are used in the real world for many things like artificial horizons, boat compasses, etc. When used in reference to KSP, it's generally understood to be the thrust vectoring feature of some engines. The exhaust nozzle in a vectoring engine has a gimbal for pitch and another for yaw.
  15. I mean no offense, but you are wrong here. DeltaV doesn't change with throttle setting as the engines have the same Isp over their entire throttle range. Throttle management consumes less dV on ascent in the case you describe because it avoids exceeding terminal velocity; it does *not* change the amount of dV available.
  16. Your question is a bit ambiguous, as you haven't defined "efficient" very well. Let me share what I understand about how it works: Isp is a measure of how efficiently an engine converts fuel into thrust. It is *not* a measure of fuel consumption, though fuel consumption is a function of thrust and Isp. Think of Isp in terms of thrust per unit of fuel; i.e. a higher Isp engine produces more thrust for a given amount of fuel than one with a lower Isp. If you are trying to get the most dV from a given amount of propellant, a higher Isp engine is what you are looking for. For game balance reasons, engines in KSP with a higher Isp have a lower Thrust-to-Weight Ratio (TWR); this is not necessarily the case in real life. In real life, Isp varies with throttle setting as an engine is only most efficient under a narrow set of operating conditions. In KSP's approximation of engine behavior the Isp stays the same throughout the throttle range and all other variables are linear, too. So an engine at half throttle in KSP produces half the thrust with half the fuel consumption while Isp remains the same. So it is no more or less efficient to burn longer at a lower throttle setting. What does matter though, is how the in-game conditions affect the use of a given amount of thrust. During an atmospheric ascent, if your craft is exceeding terminal velocity for its altitude it is wasting fuel trying to punch a hole through the thick air. In that case it would be wise to throttle back; even though the thrust:fuel-consumed ratio is the same you would be using the thrust generated more efficiently. Similarly, once in orbit and trying to complete a maneuver node the calculation assumes an instantaneous change in velocity. The longer the burn takes, the more fuel is expended away from the optimal point. Even though the Isp remains the same, the thrust is used less efficiently. So in orbit it is better, efficiency wise, to complete your burn as quickly as possible, i.e. at full throttle. This effect is large enough that sometimes a lower Isp but higher TWR engine can complete a maneuver using less dV than the more efficient engine, even though it converts fuel into thrust less efficiently, as more of the burn is completed near the ideal point. Hope this helps.
  17. A Mk3-2.5m adapter would make the Mk3 more useful, too. I've tried making heavy shuttles with the Mk3 cockpit, but all the payloads I want are 2.5m and direct attachment looks horribad.
  18. My best lessons to pass on: 1. Test, test, test! Whatever you want your craft to do in space should be tested on Kerbin as much as possible. Make sure Kerbals can easily get back into your lander, make sure your staging is right, make sure the landing legs extend far enough to clear the engine, etc. Test each stage independently. Nothing worse than investing hours in an interplanetary mission to find that one of your later stages is somehow broken. 2. Don't forget electricity. I've been playing since before electricity was implemented, so I often forget to include it, especially on the core stage of my booster that I want to deorbit once it delivers its payload. A couple of solar panels and a battery weigh almost nothing but will save you the frustration of a craft with dV left and no way to use it. 3. The navball. Learn it, love it! No part of the interface is more important. The visuals of your ship are pretty but they tell you almost nothing about your craft's orientation. When doing maneuvers manually your eyes should be glued to it. 4. Generally, less is more. Big craft are cool and all, but they make the game laggy and are more vulnerable to the Kraken. Learn to minimize your part count and mass, especially in the upper stages. 5. Occasionally, more is less. Landing on a high gravity world? It's generally more efficient to leave your transfer stage in orbit and dock with it after ascent than it is to bring all that mass down and have to boost it back up. 6. Have fun and don't worry about other people. Use mods and cheats if they are fun for you. Whatever goals you set for your space program only have to satisfy you. *** As for the whole MechJeb thing, here's my take: I think it's a valuable learning tool. Watch what it does when you give it an order, examine the maneuver nodes it sets up, and think about how it is making things happen. Not everyone learns the same way, so saying that everyone should become a good pilot through trial and error before using MechJeb does some people a disservice. If craft design and mission planning are more enjoyable for you than piloting, then use MechJeb and don't look back. It is frustrating to have a capable craft fail a mission due to pilot error. It also allows consistent, repeatable flights for testing designs or repetitive chores (I use it for launching/rendezvous/docking of tankers to fill interplanetary craft that I launched empty). That said, there is sometimes great satisfaction in manual piloting. I don't think I've had a more satisfying moment is KSP than my first successful Mun landing (back when the Mun was the only destination). Docking manually is satisfying, too. Personally, I make landings on each body manually until they become repetitive, than I let MechJeb handle it. Basically, I think MechJeb is a great enhancement to the game. It is useful for beginners and experts alike, for reducing tedium, frustration and learning time.
  19. The game engine already computes the location of the center of mass and the center of thrust, so it shouldn't be *too* hard to have it automatically detect when it's appropriate to reverse gimbal response. (Disclaimer: I am not a programmer, nor do I play one on TV. What seems simple to me may actually be very difficult for reasons that are obvious to any experienced programmer.)
  20. SimpleRockets is fairly similar to KSP, but much, much more limited in that it is 2d only, has fewer parts and only one ship in use at a time. Even with those limitations it still pegs the CPU on my Galaxy S4 on any craft with a non-trivial number of parts. That said, it does help scratch the KSP itch when on the go.
  21. Yes, if the radiation is going to kill the crew before they get there. A trip to Mars is too expensive to roll the dice on whether there'll be a solar flare event or not; I can't imagine any mission to Mars craft not having at least a "storm cellar" radiation shelter. Not to mention that in today's risk averse culture, deaths on the first mission would probably set the whole program back by decades. I truly believe that if Apollo were happening today, an Apollo 1 style accident would shut the whole program down for months, if not years, of inquiry and finger-pointing. Nonsense. Certainly there are significant differences between the environments, but some of the problems that need to be solved for inhabiting them are very similar. To turn your analogy back on you: If you were from another planet, Denver and Antarctica are similar enough (or, more precisely, different from your home planet in similar enough ways) that it would be worth practicing in Antarctica if the costs, risks and travel time were so much lower than a straight trip to Denver. I do believe that Mars is a friendlier environment than the Moon for colonization, but the travel costs and times make any mistakes or oversights very costly to correct. The Moon is much less so, so I think we should establish the basic, common techniques required on the Moon first.
  22. ISS is safely within Earth's magnetosphere, so the radiation is several orders of magnitude less than would be present during interplanetary flight, especially during a solar flare event. Personally, I think we shouldn't bring back the first Martian visitors. Use unmanned missions to set up basic infrastructure, then send the people on a one way colonization mission. Repeat until enough people are present for a sustainable gene pool. We should probably practice colonization on the Moon first, as help is only days away instead of months/years.
×
×
  • Create New...