Jump to content

Trueborn

Members
  • Posts

    483
  • Joined

  • Last visited

Everything posted by Trueborn

  1. If you start at a pole and burn in any direction you'll end up in an orbit with 90 degrees of inclination. So if you want to get from a pole to an equitorial (0 inclination) orbit, you will need to burn sideways. The easiest way to do this is: 1) Launch from the moon, and turn immediately to almost horizontal (heading is your choice). 2) Burn until you have an orbit that goes at least 1/3 of the way above the equator, then let it coast. 3) Build a maneuver node on your orbit where it crosses the equator. Use the triangle on the side to pull your orbit down until it matches your target orbit. You will probably have to add some retrograde to avoid escaping the mun's SOI. 4) After you get your orbit matching inclination, burn to circularize or set up for your rendezvous. For non "perfect" orbits, set your target and build your inclination changing burn at the ascending or descending nodes.
  2. Control from here just reorients the navball to reflect whatever docking port/control source you select. If its already pointing that way, you won't see a change.
  3. You ought to be able to define a new resource to be used by your plugin rather than using the part's mass itself. Then you can make the part 0.01 tons (or whatever you experimentally determine to be the lower limit to be) and have the resource make up the rest of the mass. Obviously this won't work if you want it to affect every part on the vessel, in which case you would have to totally replace the stock mass system.
  4. The largest potential flaw I can see with this is the audit process. Namely, who would do the audits and how long it would take. Consider 0.24 release day. The new version drops with some change to game architecture that breaks a majority of mods. I sit down, spend the next few hours fixing up my mod, and post the new source code to the auditing forum. Unfortunately, no one is available to do the required (say 3, or at most 5) audits. Why? Because the other mod authors are all working on their own updates, or auditing the mods that came in half an hour before mine. For normal, day-to-day updates of mods, I imagine turnaround would be pretty good. Patch day would be quite a different story. Now, this doesn't necessarily invalidate the whole idea, but it is worth considering. After all, I imagine most of the people willing (and able) to do auditing work are already involved with mod development. This assumes you can get enough volunteers to begin with (probably not unreasonable, but its hard to say).
  5. SteamGauges also allows you to see orbital info from the main flight view.
  6. Read this tutorial: http://wiki.kerbalspaceprogram.com/wiki/Tutorial:Advanced_Rocket_Design That will let you calculate the delta V for each proposed design. Delta V is a much better indication of where you can go than total burn time. Then you can look at a delta V map to see if you've got enough to go where you want to. Then you can decide which is more appropriate. If you've got plenty of dV with the design with more thrust, that'll make landings a bit easier. And if you would rather not do the math by hand each time, you can use Engineer Redux to calculate delta V in the VAB as you build. It can really help you tweak your designs.
  7. They actually take quite a bit of energy to run, so for 25-30 you'll need a lot of solar panels. Also, you end up doing really long burns (30 min or more, no time acceleration) for heavier vessels. Still, its an interesting challenge to design something useful with one. I'm sure you can find some good ion probe designs around on the forum.
  8. I would be interested in integrating this into SteamGauges. Conversion to C# shouldn't be too bad, but I haven't done any threading in KSP yet. Not sure how much time that would take me, although there are some examples that should make it easier. No guarantees until I see your code though.
  9. 1) With a fully staffed (2 Kerbols) science lab, you can not only process the reports before sending them, but you can also clean and re-use the one-shot experiments. 2) They used to do different things, but now the only differences are as you pointed out. 3) I always try to do 4. Other configurations make translation difficult (though there are some RCS balancers out there to help counteract that problem). 4) Yes, but I don't remember off hand. For mun/minmus landings, 3 or 4 should be fine. Just keep your speed down on landing. 5) Very, very small ones. 6) A lot of people find that its an odd choice from a game balance perspective, but yes. The first transmitter is the most efficient, while the last one is the least. If transmission time is relevant though (say for a flyby mission or on descent), the large dish can be useful. 7) Depends on where you're landing. Check out Engineer Redux. This mod calculates delta V and TWR for you in the VAB, and you can change the body you are concerned with so you can make sure your lander's TWR isn't excessive. Technically you need it just over 1.0, but 3 or higher is better for actually slowing your descent.
  10. Once you transmit the results you should see it counting up towards 100% transmission. Once that's done a green text line should show up saying you got 30 science (or whatever). Then you can go to the KSC and the lab to see if you got the Science. You don't have to recover the probe.
  11. Correct. I took the highest terrain feature, rounded up to the next 100m or so, and declared that as a "safe" orbit. I'm still not entirely sure that the orbital gauge is where I would want to put impending terrain impacts anyway. I almost want to say that if you plan on orbiting inside a canyon...good luck to you. If you are manually flying, you can use the HUD to see if you are going to clear the terrain in front of you (line up the W with the centerline of your ship, and then just keep the FPV above the mountains). Even better might be terrain following radar or TAWS. It looks like a radar map, but it uses a digital terrain database and shows terrain height relative to vessel altitude. Green stuff is safe, yellow is pretty close to you, and red is above (depending on mode). Anyway, I'm not really planning on doing either of those. What you're asking for is just some warning to come on if, somewhere in the next orbit the vessel will be below terrain level. I'll think about it, but no guarantee at this point.
  12. Annnnd, that's done. Well, the HUD jetpack fuel readout anyway. In EVA, it replaces the throttle readout. I'll have to look at jetpack ISP and Kerbal weight before I can crunch delta V though. I'll probably change the fuel gauge to read out jetpack fuel as well (when appropriate). Unless I need to make any significant changes in this beta though, expect it in the 1.4 stable release.
  13. The only thing the current HUD won't do for you is delta V and jetpack fuel. Orbital mode shows you pro/retrograde and rad +/-, Ap/Pe and time to both, velocity, and distance to target (with target cue, anti-target cue, and target velocity vectors). I'll look into the EVA fuel (already considering a delta V readout of some sort), but otherwise it seems to have you covered.
  14. I think someone already has a first person EVA mod somewhere. The HUD should work fine in it, although I don't believe it tracks jetpack fuel (which could be arranged). What else would you be looking for in an EVA HUD besides life support, which I don't believe is standardized enough yet for me to link to.
  15. Yeah, I'm sure its possible. That being said, with the current beta versions that shouldn't be a huge issue unless you're doing some really low orbits. Or not using the orbital gauge/radar altimeter. If your Ap/Pe show a red or yellow light, you're probably in trouble. Also, the RA shows a time to impact and suicide altitude if you're on a descent path towards an airless world (though this is strictly vertical, so at high surface velocities it could be way off). That's my intent anyway. If you're in a shallow orbit with a low Pe without a red or yellow light, please let me know (I might have to update my altitudes). If I do extend the RA's calculations to do atmosphere stuff, I may do some more work with actual trajectory, but that isn't on my short list. If I'm way off of what you're thinking, please let me know that as well. Break. I'm also releasing 1.4 beta 5 today. The biggest change is some FAR integration. The air gauge and HUD now use FAR data for EAS, terminal velocity, and Mach number. If you don't have FAR, it uses the stock atmosphere model instead. Next, the Air Gauge and HUD now use Equivalent Air Speed instead of Calibrated Air Speed. This is a bit more relevant at high airspeeds and altitudes, but as with CAS it will always be lower than TAS. The Air Gauge now displays a Mach needle (small blue arrow), because its cooler than the digital readout. There were a few performance tweaks to the HUD. Finally, the plugin should gracefully handle missing textures. If this seems pretty stable, it might make for a full release, so please let me know if you encounter any problems. Special thanks goes out to a.g (as usual) for the FAR integration. Download
  16. I'm planning on making the keyboard command mapable in-game, but for now, you can go into the config file and change it to some key you aren't using for anything else. It might be possible (can't remember how much of those are public vs private), but I would prefer to limit my dependencies. I might do an optional dependency for engineer, but that won't be first on my priority list.
  17. Well, the terminal velocity indicator is still in beta, so don't worry about it I already effectively calculate TWR for a couple of things, and current ISP as well. At the current point in time I don't want to go to the full length of simulation that engineer or mechjeb do in order to get their stage delta V's. I'm also not quite sure where I would put it (the HUD might still have room). That being said, I would like to get just the current stage's fuel for the fuel gauge. If I do that, I could easily determine the dV remaining in the current stage. When I get that worked out, maybe I'll put a fuel/dV section into the HUD. But first I've got some recommendations from a.g. to integrate, and want to make sure the plugin can elegantly handle missing textures. At some point I need to call this feature complete. I do have other plans...
  18. I'm sorry, but I don't see a whole lot of utility for splitting all the gauges. The total size of the plugin is only 15mb, which I hope isn't the straw that's breaking your computer's back. I will look at making the plugin resilient to missing textures, so you could delete the texture file to disable the gauge. I thought about making each gauge have it's own toolbar button, but I thought that might get cluttered for people who do use more than one or two gauges at a time. I will also look into making that an option though, so users can select the classic single button style or 9(?) buttons for individual gauges and settings window. If there is a lot of demand for that I can make it a priority. Anyone else?
  19. There is currently no budget for career mode, so parts costs are meaningless. It sounds like you are in the spaceplane hangar instead of the VAB. Try the taller building. And finally, fuel tanks should stack just fine without any other pieces.
  20. It's currently hard coded. I'll look at something more variable though. Maybe, x% of atmosphere height, or above my "safe" altitude (green light on orbital gauge) for airless worlds. In the mean time, the orbital gauge always displays Ap, Pe, inclination, and time 'til next 'apsis.
  21. You're welcome. It looks like that's the system's thumbnail file for all the textures. It doesn't show up in the folder once extracted (even with hidden files shown). If you do see it, it should be safe to delete though. Obviously the game doesn't need the thumbnails at all.
  22. Terminal velocity markers are now in 1.4 Beta 4. It also includes Toolbar 1.3.0. The maker shows up on both the Air Gauge and the HUD.
  23. Version 1.4 Beta 4 release is now available! Quick update for terminal velocity indications. Blizzy's Toolbar 1.3.0 included Terminal velocity is now displayed on the Air Gauge and the HUD's airspeed tape. The hashed maker or Vt> maker indicate terminal velocity at the current altitude. (The HUD will only display Vt up to 4000 m/s. If that limitation impacts you let me know, I can bump it up to the rest of the airspeed tape if you really want it.) The Air Gauge can now be toggled between displaying CAS and TAS. Just click the button! Updated gauge architecture (internal). If you notice any strange behaviors, this is probably the cause. Please let me know! Download link.
  24. Screenshots are helpful for diagnosing rocket failures. You may have too much thrust, or may not be strutting properly, or have things too far out of balance. Hard to know without a better description or, preferably, a picture.
  25. KOS is another mod (Kerbal Operating System) that was originally developed as a scriptable autopilot, but has since added a lot of stuff that would allow you to grab game info, do math, and display it. I'll look at the terminal velocity calculations from engineer or something. Maybe I can build a second pointer that would do terminal velocity (like the Vne needle on some airspeed indicators) for the air gauge and HUD. Also, there is a new beta release of SteamGauges with the Air Guage and toolbar 1.2.2 SteamGauges beta thread.
×
×
  • Create New...