Jump to content

johnsonwax

Members
 View Profile  See their activity

  • Posts

    291

  • Joined

  • Last visited

 Content Type 

Posts posted by johnsonwax

    Now-defunct-thread-that-should-not-appear-in-google-search.

    in KSP1 Mod Releases

    Posted

    A couple of questions.

    If I understand correctly, to get a good KSO orbit for a satellite you need a semi-major axis of ~3469km and a period of 6 hours flat. I guess that small variations in the distances of periapsis and apoapsis are not that important if you can see mission control at all times.

    Variations in peri/apo mean very little. Viewed from the ground, the target will drift back and forth and return home each day. With some inclination it'll drift in an ellipse. You'd need quite large variations (hundreds of kilometers) to lose contact with the ground.

    Now, how close do you have to be to the orbit period for a good grid? I'm asking since using RCS for orbit corrections jump my numbers 5s per push or so and getting exactly 6hrs is very difficult with my current design. If you are one or two seconds off, how much is it going to bother you in a couple of years of game time?

    1 second per 6 hours is .004%. So you'll drift about 7 degrees per year (if I have that math right). After about 12 years you may no longer be in contact with KSC if the satellite was stationed directly above it. A bit worse, it depends on your error. If you have two adjoining satellites and they're each off by a second in different directions, then you may lose coverage even faster - or wind up with both satellites in shadow for extended periods. So at the very least, get all of your error either fast or slow. If they're all off by a second in the same direction, then your array will remain intact but slowly rotate around the planet, which is much more acceptable.

    There are some low-power RCS ports in some of the mods. AIES has a small 1/6th power one. A single linear RCS pusher is also handy for this, though you'll need to rotate the craft for direction. You can also use an ion drive for this, which is quite low power. If you use MJ, it has a handy feature under the 'Utilities' panel to limit throttle. Limit it to 1% and you can get thrust down to .005 which is much lower than you can usually get with RCS. You can get a little lower with a mod ion engine. Roemi-Lemdum Atomics has a .25 thrust mini ion engine which is handy for this. I can usually get my orbits within .1s. Kerbal Engineer Redux will give you orbital periods to .1s.

    And a second question. I see that dishes have a cone variant. Does that mean that the dish has to orient itself with the target so that it works? When you choose a target is it done automatically, or do you have to point the sat to the correct location?

    The dish doesn't need to orient, but it does need to be given a target. It does this automatically, and if the antenna is physically pointed away from the target, it still works fine. The cone only really matters (from what I can see) when you point it at a body, rather than a spacecraft. If you are around Duna and select Kerbin as your target, the narrowest cone dishes won't be wide enough to paint your geosync array. In fact, it might fire right between two of your sats and if KCS is on the other side of the planet, you'll lose connection. So there's a tradeoff between distance and cone angle. A long range, narrow dish used at short range will target individual satellites fine (until they orbit behind the planet), but will probably miss most or all of your array if you point it at the planet unless you have a low altitude array.

    Within the Kerbin system, you want a nice wide angle because your geosync array will be dozens of degrees wide from Mun, and maybe 10deg from Minmus. Personally, I think the angles set by RT2 are a bit too narrow for the long range dishes. I can't imagine designing a dish for Jool that couldn't cover the angle of a geosync network (no need for more, though) and the current settings are just a bit shy for that. They'll definitely fire through a 4 sat network from Dres.

    FusTek Station Parts Dev Thread (continuation of fusty's original work)

    in KSP1 Mod Development

    Posted

    Ok, just getting around to building some stuff with the dev build. One question: I understand .4 is not save compatible, but is it designed to be otherwise equivalent to past parts?

    An an example, the old node end ring had a node that would sit it flush with a flat Karmony module, and a second node near the surface of the ring, so that an IACBM wouldn't sit flush to the Karmony, but would instead sit on top of the ring. This was handy for me to build up a way to attach 2.5 meter parts to the side nodes of the Karmony hub. This made sense before the IACBMs with Fusty's old berthing modules.

    The new node end ring has two nodes that sit flush with the Karmony modules. One to attach it to the Karmony, and one to receive the IACBM properly inset into the ring. This is much more sensible with the IACBMs, but means that some kinds of constructions are now either not possible with the new parts, or are possible but look, well, quite silly.

    Are you worried about this sort of thing? I don't think you should be, but you have set this up in order to migrate parts forward, and I don't think it's going to work in a lot of these cases. I also noticed you kept the odd CoM for the Karmony Node, which leaves me to think that you are trying to minimize breakage.

    (For those that don't know, the Karmony modules' part origin isn't in the center along the long axis, it's 1m offset, so the CoM needs a 1m adjustment to balance. It's the kind of thing you notice when you are welding parts and have to do this. In a save breaking update, it would make sense to correct this and shift the origin and eliminate the CoM offset. Just makes all of the math easier.)

    Now-defunct-thread-that-should-not-appear-in-google-search.

    in KSP1 Mod Releases

    Posted

    Your first two requests are already ingame. The flight computer has a queuing system (Press the "Q" button), and the target selection has a delay-less "Name" button. Heck, you can even cancel your commands!

    Oh, that's what Q does! I kept assuming it was 'quit' for the flight computer. I was so mired in trying to work out why the other issues were happening I didn't think to take 'Q' completely literally. Excellent, thank you. I will help spread the gospel.

    Now-defunct-thread-that-should-not-appear-in-google-search.

    in KSP1 Mod Releases

    Posted

    I'm working through a variety of issues on mine. One is already on the bugtracker courtesy of someone else that I've now encountered a second time in a somewhat different manner but I'm having trouble getting it to duplicate. I'm going to try and put together a stock case where it's duplicatable, but I suspect it's related to bridging omnidirectional antenna and dishes (rover/lander/etc with omni -> mothership with omni + dishes -> Kerbin constellation with omni + dishes -> KSC = problems, sometimes). That I've got AIES antenna that I'm modded into the game and whatnot makes it difficult to rule out a problem on my end, so I'll rebuild it with just stock + RT2 parts. But I've seen it a few times now.

    I've also just experienced another problem twice with the aforementioned mothership while trying to nail down the other behavior: after undocking a lander and switching focus the ship then loses all velocity and is left in a free-fall. I'll try and get that to duplicate as well, but I've done that maneuver several times and it's only happened twice, so its also not easily duplicated, and may not be related to RT2 at all. Could be MJ or something else.

    But I do have two feature requests one small, one larger:

    Small: can we have it so that renaming a vessel does not suffer from the time delay? It's an action performed on the command module, but in reality its simply a change on the ground so we should be able to do it at will. Besides, it's damn irritating after undocking a satellite to then have to wait 10 minutes to rename it just so you can properly find it in your list of ships.

    Large: would it be possible, possibly as part of the flight computer or some such to get a list of issued commands and how long until they are received? I'm trying to decouple my sats around other planets and KSP is sometimes a little twitchy with keyboard focus and sometimes my stage command needs to be issued twice. That's irritating, but when you have to wait 10 minutes to determine if the stage command went through, well that's slightly catastrophic and requires a much higher level of F5/F9 use than I prefer. Just being able to see what command RT2 has held in the queue would be very helpful. Maybe a little slide-out panel from the computer to show it or another window or something. I'm not sure how you would do more analog things like throttle input, maybe just note throttle up for 3 seconds, throttle cut, that kind of thing. But I think with a flight delay, we need some sort of ability to see what's been issued. No other UI on them needed (cancel, reorder, etc) - it's issued, so you have to live with it.

    Oh, a third very small: The long range dishes have such narrow cones that they can fire right through the middle of my 4 sat Kerbin geosync array from other planets when I have them set to target Kerbin without hitting a single sat. That's from Dres, and it's just on the edge for Jool (CommTech-1). With a 3 sat network it would clearly fire through from Jool. I would think that they wouldn't design a dish to have such a limitation - that from the nearest planet the dish would have enough angular coverage to hit the full 6200km or so diameter of a geosync array. It's not necessary to go to geosync to ensure continuous communication with KCS, but it's exceptionally common. NASA also uses geosync for deep-space communication, so I would expect that's a RL design requirement as well. Instead of a minimum cone of .005deg, going to .015 I believe will get everything covered. The two giga dishes are somewhat compromised as a result of this. They might only hit your network reliably from Eeloo, and only during part of its orbit. That strikes me as a design fault with the dish.

    Now-defunct-thread-that-should-not-appear-in-google-search.

    in KSP1 Mod Releases

    Posted

    No matter how hard you try, sats in KSP will always drift relative to each other. The relative position of sats on nearly-identical orbits is never stable in KSP.

    I notice you put everything in terms of altitude, presumably apoapsis. Altitude really doesn't matter for geosync or even for maintaining uniform coverage in other orbits - orbital period does. Further, you get more precision with orbital period in game than you do with altitude. You may not be stationary relative to the surface this way (which requires having both apo and periapsis dead-on equal), but as long as apo and peri are in the same neighborhood, the sat will not drift far from the target over the course of an orbit.

    A geosync satellite should have an orbital period of 6 hours (21600 sec). You can get that period with an expected error of 0.05 sec/orbit or .00023%. That's better than what you can accomplish by using altitude and would amount to a maximum of 5 minutes of drift per year. That's not nothing, but it's pretty tolerable. Chuck an ion engine on your sat like I showed on my previous comment and you can correct that drift every few years without much trouble.

    There's a number of utilities for giving you orbital period. MechJeb will give you period to a precision of 1 second, but Kerbal Engineer Redux will give you to .1 sec. Very handy for this sort of thing. Getting the orbital period dead on 6:00:00.0 requires very low thrust/weight (.01 or below). Ion drives are good for this, but may be insufficient for getting your sat into the proper orbit. Combining a conventional engine with either an ion drive (for station keeping) or some RCS and a linear RCS port for that purpose are a good idea. You'll use very little RCS for that fine-tuning. Click on docking mode if need be.

    Kethane Pack 0.9.2 - New cinematic trailer! - 1.0 compatibility update

    in KSP1 Mod Releases

    Posted

    This perhaps should be part of a generic plugin that all mods can easily take advantage, but ...

    Perhaps when a vessel is packed, store:

    (stuff)

    Or, create a 2nd part, add .2t or so to its mass, call it an RTG, and take away the power requirement. If you want background scanning, bake in the dv cost of the RTG and call it a day. If you don't want the extra mass, lose the background scanning.

    Let's face it - most people are going to put the RTG somewhere on the craft anyway.

    PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]

    in KSP1 Mod Development

    Posted

    Sorry, I'm not buying it. I don't think anyone even reads the part descriptions that the devs themselves wrote:

    "The Mk 3 Cockpit is the pinnacle of airframe cockpit technology. In the rare event of a Kerbin Penetrating anomaly, this cockpit will ensure your Kerbs are interred according to health and sanitation guidelines."

    "This cozy capsule seats two, and is very lightweight. However, don't expect it to survive atmospheric entry or even a sneeze."

    "The EAS-1 External Command Seat provides all the controls needed to fully operate a spacecraft, just like a command pod, but without such needless frivolities as "pressurized interiors", or "seat belts". It's bare-bones, pedal-to-the-metal efficiency at its finest.

    "Although criticized by some due to its not unsignificant use of so-called "pieces found lying about", the LV-T series has proven itself as a comparatively reliable engine. The T30 model boasts a failure ratio below the 50% mark. This has been considered a major improvement over previous models by engineers and LV-T enthusiasts."

    "While considered by some to be little more than "a trash bin full o' boom", The RT-10 is used in many space programs, whenever the need to save cash is greater than the need to keep astronauts alive. Use with caution, though. Once lit, solid fuel motors cannot be put out until the fuel runs out."

    "A more reasonable engine for rough economic times, the Poodle engine doubles as a BBQ when at low power."

    "The Mk16-XL Parachute is a double-sized variant of the Mk16, now with only 50% of the structural integrity!"

    "This unit was something one of our engineers came upon while dumpster divin-- Erm, while researching alternative applications for existing technologies. It's a sealed container which appears to be filled with a strange-looking substance. We couldn't reach in or break the canister open, but watching how the Goo behaves when subjected to different situations could be very educational.

    "

    If the devs are trying to argue that Kerbals (at least the astronauts) are not stupid or reckless, they they should start by not making the description for half of the stock parts, and the very characteristics of the kerbonauts not reinforce the idea that they are both stupid and reckless. The last description just showed up in .22 for the first time. Playing darts inside of an inflatable hab module is not out of character if they're using their engine as a barbecue.

    PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]

    in KSP1 Mod Development

    Posted

    While Kerbals are many things, they aren't dumb.

    Um.

    In-game, Kerbal astronauts (perhaps not the engineers) have two personal metrics: courage and stupidity. Collectively, Kerbal astronauts are extremely stupid, and stupidity is a praised characteristic. Just tour through the Astronaut Complex.

    Bill Kerman would definitely be playing darts up there given his stats in my game.

    RLA Stockalike v10 released 11th August

    in KSP1 Mod Development

    Posted

    I think it's best to leave the science parts alone, unless someone can think up a good solution for this.

    Put them much higher up in the tech tree. Early on you have to use them because you have nothing else. But they're not worth hauling to Jool unless you want to spam transmission (which they're going to break in .23). They don't produce nearly as much science as a MUCH smaller gravioli detector (which has a much larger modifier). As a result, I've never taken those parts out of the Kerbin system. As soon as I get up to tier 4 or 5 and have better parts, I aim for Duna and Gilly and leave these two behind never to use them again. If they reappeared out in fieldScience I'd start using them again.

    Now-defunct-thread-that-should-not-appear-in-google-search.

    in KSP1 Mod Releases

    Posted

    Finally got my geosync sats up.

    Javascript is disabled. View full album

    I like this new design a lot. It's based around a THSS truss with a THSS probe core. 3 RemoteTech CommTech-1 dishes provide deep space communication (and fit the THSS perfectly). It's powered by 6 RLA ASRG RTGs (Roemy-Lemdun Atomics kit) that sit along the corners of the truss (also fit perfectly). They can keep all dishes/antennas running even in shadow. Mounted on the RTGs are 3 AIES frying pan dishes (5Mm) (unfortunately also named CommTech-1) provide for inter-satellite communication as well as downlink, 3 AIES ESC-EXP antenna provide redundancy and near-orbit communication without need for targetting, 3 small solar panels to provide extra power for station-keeping, and a trio of flashing beacons (AviationLights) so I can find them if I need to send a manned service crew up. Tucked behind the large dishes are xenon tanks and on the end an RLA resistojet engine. All told it's a reasonably compact package, but weighs in at 9 tons. The dishes are 3t. The RTGs another 3t (those dishes require a lot of power). 1.5t in xenon. The truss is .5t.

    I launch an array of 4, 90 deg apart, which puts them 4,055km apart, connected by a 5,000km dish. It's a reasonably heavy lift - 36t of satellites, hauled into final orbit by a NERVA. The NERVA goes into an elliptical orbit of 16,200s (4.5 hours) with apoapsis at 2868km and pops off a satellite every time it reaches apoapsis. With a geosync period of 21,600s (6 hours), the previous sat has fallen exactly ¼ orbit behind. The sat pops off, fires up the resistojet, and circularizes. It's also weak enough to fine tune the orbit to exactly 6 hours. Previously I would have put a bit of RCS on to do that. Might have been the better decision as I could have dumped 1.5t from each sat, put that into extra fuel for the NERVA and just used it to set each orbit, and used a wee bit of RCS to fine tune it. But I think it looks cooler this way. Putting all 4 up at once makes it hard to design the lifter, but easy to get them precisely positioned. I always struggle to get them properly positioned when I launch them individually,

    In the first image you can see the main lifter having just detached and the NERVA cowlings falling back. There's a bit of scaffolding to keep the whole thing from wobbling apart (even with joint reinforcement it wiggles a fair bit). It was a coinflip on the NERVA over a lighter but lower ISP engine. It had barely enough thrust to perform this role, so it worked out pretty well. Even managed to get it home in one piece (there's a probe core and a bunch of chutes on it). The second shows the sat moving into position with a nice view of the design. The last has the engine disabled and ready to transmit.

    Assuming one satellite may be blocked at any given time, I can configure each pair of sats redundantly, and hold 6 different targets anywhere in the solar system. Or I can hold 12 targets with half an hour of downtime every 6 hours. Now I can send my massive science mission to the Jool system and get my experimental techs all unlocked.

    You can find my tech tree and RT2 patch for AIES over on the AIES thread.

    [WIP] THSS - Tri-Hexagonal Structural Strut

    in KSP1 Mod Development

    Posted

    Haha, cool. Well, hopefully this helps you a little in some way. I like the sound of standardised lengths and Kethane tanks too, so I'll probably end up using your version when you release it. I ended up just using your AIES configs :).

    Have you considered making a thread just for MM codes and examples? You would get the community contributing and hopefully end up with a centralised database of MM configs. You could have sections to add support for various mods like Deadly Re-Entry, RT2, Modular Fuels, Bobcat's new ECLSS system, etc. It would be a really handy resource for players.

    Yeah, I'm considering it. I've got a number of other tweaks to parts, and for this set I also have a bunch of welded bits, mainly to cut down on assets. With a 1.25m standardized truss length, you just weld 3 together and you can toss the 3x one and it eliminates a model that needs to load. I have lengths from 1.25m to 12.50m. Helps with framerates a bit as well. I've done the same with the HOSS tanks, etc.

    I also have a number of specialized welded THSS parts that are designed to mate properly with FusTek, so you can have a truss length that matches the length of the Karmony modules. Then you can snap everything together like legos. Stuff like that. Takes a lot of testing through, and I need to go back through all the FusTek stuff to make sure it lines up with his redesign properly. We've got a community established standard for diameters, but not for lengths, and even within a kit getting everything to line up can be a bit of a pain. For example, the tri-strut is 3.855m long, but the tri-strut-short is 1.326m, so 3 of those together is .143m longer than the tri-strut. A small scaling of the latter to 1.25m is barely noticeable and welding them up to make the longer lengths means everything lines up perfectly. Even the stock parts suffer from this kind of problem.

×
×
  • Create New...