natsirt721

Members
  • Content count

    93
  • Joined

  • Last visited

Community Reputation

63 Excellent

About natsirt721

  • Rank
    Kurious George

Contact Methods

  • Website URL http://steamcommunity.com/id/natsirt721/home
  1. There's 2 levels of interaction here, and I think it's important to separate the two because they really are separate issues programming-wise. First, we have the large scale, which is how the atmosphere/ground/oceans interact with one another and the sun. Using the stratified cells and heat flux is good enough (I think?) to handle this at a planetary level, and the break-even line is determined by the size of the cells. Smaller cells == poorer performance. Events can be randomly generated - if not all the time then some of the time, maybe not at higher warps? - and the generated events (read:storms) would just propagate through the system requiring no other attention until eventually they dissipate into the 'default' weather. Alternatively, depending on the intricacy of the weather system, storms may spontaneously appear, propagate, and dissipate. Either way, variations from the norm require little extra effort on the simulation. Graphically, the natural or RNG storms would have to be blended into the surrounding clouds at a regional or planetary level, which is probably pretty hard. Then we have the small scale, which is how the weather interacts with your craft. This, I must say is where the real difficulties begin. The flight engine would have to look at the cell that the current craft is in and determine from the available data what sort of weather was going on. Then apply wind, rain, temperature, etc. to make the magic happen. Then, it also has to display these graphically. The current system is pretty adequate for handling static atmospheric conditions and the Microsoft FlightSim crew seems insistent that dynamic atmospheric conditions are no problem, but IMO the graphics are going to be the issue. The fancy clouds are already performance intensive, and unless some better way to display them is discovered (don't hold your breath) it is likely that and good-looking weather is going to be somewhat intensive. So to me, it seems like the limiting factor for weather is making it look good. Maybe if I ever get around to learning how to mod KSP I'll tackle this because it doesn't seem to be impossible, just pretty difficult.
  2. Filtering by SOI would be a nice feature for sure, just as a QoL thing.
  3. @MiffedStarfish That's a good workaround, but if you have multiple Kerbs on EVA that won't work. Yes, thats is what I said was the workaround. But, it is not the best strategy and fine controls would be quite nice.
  4. I say 'zero relative velocity' but what I mean is 'stationary with respect to my ship'. When placing multiple parts it is frustrating to be floating around w/ respect to your ship, especially if you're near the max range of your box. With multi-ton modules, having 3 or 4 kerbals floating around with some non-zero velocity is a pain in the behind. Currently in stock there isn't much to do EVA, but if/when that gets changed the player should have some way of precise maneuvering. Therein lies the issue: the kerbal's RCS is too powerful, such that the shortest bursts still cause my velocity to overshoot the necessary correction (unless I'm KIS carrying something massive). Something that is mitigated with fine controls.
  5. It seems silly to have fine precision for spacecraft RCS but not Kerbal RCS. I know personally it is difficult for me to exactly zero my velocity relative to my spacecraft when doing EVAs for KAS work (or harvesting science from parts), something that has led to me carrying ladders around everywhere.
  6. I think the DLC is going to be huge for people with problems about motivation in KSP. Having access to a vast range of player-made mission options will allow you to pick some that sound interesting and actually have meaningful constraints. In addition, the default missions will set some baseline for what's possible which should include random failures, part constraints, mass and volume and time constraints, etc. in addition to specific rewards. For example, if I'm doing a series of flybys for the inner planets and the whole mission scheme only gives me n science, I'm going to have to budget that science very heavily - actually placing meaning on the oft-bashed points-tree system. I'm not sure if missions would be standalone or integrated into a common save but if they were standalone saves it would place a lot of emphasis on managing funds and science in a meaningful way.
  7. Yeah that's probably the best option.
  8. Probably not, as when changing orbits you rarely go from your current position to the closest point on the target orbit. Hohmann's need minimum 2 burns 180 degrees apart, which is just about as far away as you can get. Personally, I think that eyeballing it with the maneuver nodes is fine, especially given how generous the game can be in determining if your current orbit is close enough to the target.
  9. I started playing KSP in late highschool and when I got to uni and had to take a class on orbital mechanics it was a breeze. There's a huge difference in the learning curve between 'doing the math and understanding what happens' versus 'actually doing it first and understanding the math later'
  10. This would be a nice feature, however the targeting system currently requires a tangible body (spacecraft or a planet), and the orbit is just a path. In my experience, you can pretty easily match the target orbit by simply looking at where your trajectory is relative to the target and adjusting from there. Liberal use of maneuver nodes is recommended. If the contracts were modified to require a position (as a function of time, but a concrete position nonetheless) then you might be able to target a dummy spacecraft, but this seems a little excessive as far as precision goes.
  11. In general, you are going to want less torque for fine-tuned attitude control such as a telescope requires. You can achieve that by reducing the wheel authority slider in the HECS's RMB menu. I would also recommend using fine controls mode (CAPSLOCK). You also may want to disable SAS altogether and manually train the scope, which should be easier with fine controls. If you are using the CactEye telescope, IIRC there are some high-precision gyros that you can use to really dial in on a distant target.
  12. I recently created a spaceplane using the FAT-455 wings, but due to their low thermal tolerance I have to nail my reentry trajectory or the wings burn off. My question is, does increasing the amount of fuel in the wings increase the thermal mass and the amount of heat the wings can soak up before failure? Or is the thermal mass of the part only dependent on the dry mass of the part. The latter seems like it would be really incorrect but I'm not sure exactly how the thermal system handles it.
  13. Or, they should at least be able to be fixed, partially if not fully. This is a whole 'nother can of worms (how do you 'fix' a busted engine?) but if we get a stockalike KIS sorta deal it makes repairs at least feasible.
  14. There's an option in the right-mouse menu in-flight to reverse the thrust, but if you have more than one then yeah, action group is necessary to avoid excessive yaw. I think @Whisky Tango Foxtrot has it correct - It fills a niche that doesn't exist (yet?). I have to say the only reason I use it is because it looks nice mounted on a nacelle with the circular intake for low-altitude craft.
  15. This is a good point, however I support moving the altitude requirements into KSPedia rather than moving the inclination requirements out.