-
Posts
2,934 -
Joined
-
Last visited
Community Answers
-
Laie's post in Comets was marked as the answer
Check in the tracking station, after it's updated to lvl-3.
You see Asteroids? Great. Now just wait, a comet is bound to show up. Space objects pop up, and if you don't track them, they will disappear after a while, making room for new objects to turn up. Over a timespan of years, you can expect to have a comet on the radar more often than not.
By default, you will at most see one comet. Setting up Sentinels anywhere for object tracking will increase the number of objects that can be seen at the same time, but the number of comets doesn't scale linearly. You get ten objects from the tracking station, and another ten for every Sentinel. With eight sentinels you can see 90 objects at a time, but at most three of them will be comets.
-
Laie's post in How to best achieve a target Eccentricity? was marked as the answer
RCS is both throttleable and multi-ignition.
Just wait until you get to Gemini: you'll do a lot of maneuvering on RCS then. Might as well get used to it.
-
Laie's post in Retrograde High-Solar Orbit Rescue was marked as the answer
Standard approach: go out to a high AP for changing directions. 6y to get there, 6y to get back, should be somewhere outside of Eeloo already. Though that's probably not far enough to make the maneuver truly cheap.
Alternative 1: get some help from Jool. Won't suffice for a complete reversal, but certainly helps. Might be just as cheap or expensive as the standard approach.
Alternative 2: just brute-force it. In first approximation, it should be on the order of 20km/s. I just plotted a plan that will leave Kerbin for a sub-Moho PE with the Sun, already retrograde, for 15km/s -- from there, it's another 4km/s to your target orbit.
Attention: IIRC it is not possible to aerobrake on Kerbin from a retrograde orbit. Check the "Rescue Burberry" challenge for details, @ManEatingApe has just posted the link as I write this. AFAIK you should be no faster than 8500m/s when hitting the atmosphere.
Use fuel cells. If I got the maths right, consuming one large Xenon tank worth of propellant will require 13.2u of liquid fuel + the appropriate amount of oxidizer -- that's less than one Oscar-B tank. Seems I didn't get it right, experimentally it's more like one FLT-200 tank for 5700u of Xenon.
I've just thrown together a quick mock-up (poodle, then nuke, then ion) and ended up with a vessel of 20t dry + 80t propellant for the required delta-V. That's easy if you have a fuel source in space, otherwise I'm afraid that you won't make much, if any, profit from this contract.
-
Laie's post in Port, Drag, and Payload Bay was marked as the answer
Nothing inside a cargo bay (or fairing, for that matter) is supposed to generate any drag. This includes decouplers or docking ports that are attached to the inside nodes of a cargo bay.
In reality, this doesn't always work. It's usually fine when you first roll out the vessel, but once a cargo bay has been opened and closed again, the parts inside may generate drag. This doesn't always happen, but to me it happens quite often. I'm not aware of any method to make the game reconsider.
-
Laie's post in (RSS-RO) Any idea on how to un-edit the ion engines back to stock thrust? was marked as the answer
Not sure where you're coming from... let's start small:
Like most every mod, RO relies on ModuleManager (itself a mod) to apply patches to configuration files while they are being loaded. The main benefit of that approach is that you can install and uninstall mods at leisure and don't have to worry about what happens to the game's data files in your install: they remain unchanged at all times.
ModuleManager creates a file named "ModuleManager.ConfigCache" in your Gamedata folder. That's the complete config with all patches which is then loaded into the game. Keep that in mind. Whenever you try to mod something and it doesn't work as expected, checking the ConfigCache is a first step in finding out what went wrong.
As for your specific question:
Look at /GameData/RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Engines.cfg
search for "ionEngine" -- there's a set of patches doing stuff, you'll probably be most interested in the Thrust values. Tampering with that file may or may not work for you, depending on whether there's later patches that overwrite the values you need.
Realism Overhaul is a whole layer cake of patches, it's not uncommon that a part is patched several times over. Some are changed beyond recognition. If your part belongs to that class, don't try to unravel that knot. That way lies madness. Just write another MM patch of your own, and make sure that it's applied after everything else:
@PART[name]:FINAL{ ...stuff... }
Hope that helps.
-
Laie's post in How do you launch from the ground straight to an interplanetary trajectory? was marked as the answer
Without advanced computing tools like kOS or krpc? Saveload, try, repeat until you succeed.
I'd start with a markup satellite in orbit that has a Duna transfer dialled in, select it as target, then try and make it so that my rocket flies off on a course that's about parallel to to the projected trajectory of the markup probe.
Transfer means that you have a certain velocity (direction & speed) at the moment you cross the SOI boundary. Problem is that you have no way of knowing whether you're on the right track, or how far off you are in which direction, until you take the time to put down a maneuver node. Flying parallel to to a markup track should get you close, though.
You don't have to leave the SOI at precisely the same point as the markup trajectory, but you should be going in the projected direction, and at the right speed. For the latter, you have to figure out the time interval between the markup maneuver and the projected SOI exit, then cut your engines when your time to SOI boundary is about the same -- give or take a little depending on how much further out you already are by the time you cut your engines.
With a few attempts, I guess it's possible to get the transfer mostly right, down to within 100m/s or so.
-
Laie's post in Probe control Point (or: do I need the manned command module?) was marked as the answer
In order to provide remote control to a probe, you need
a command module that provides "Probe Control Point". a spare pilot on the controlling vessel. Most probe control points are "single hop only": you need a direct comm link between the two vessels. No relaying. the receiving vessel must have a command module with "remote pilot assist available" -- I think that's almost all of them.
What it gives you is a) remote control of vessels even outside commnet range, and b) the SAS skills of the pilot giving assistance. Note that you can give remote assistance to crewed modules -- those still need to be manned in order to work at all, but you can (e.g.) provide pilot assistance to a lander carrying a lone scientist.