VaporTrail

Just from my experiences with IR, I rarely go above 5 for anything "useful." The "pogo option" for liftoff has been really the only reason for exceptionally high speeds from linear driving parts. On the other hand, I think people have used large rotatrons for rover wheels at some point, so they might actually have a use for a higher speed setting.

Personally, I think the RTG should be the middle step between the fixed solar cells, the smaller (6 panel) tracking arrays, and the gigantors. RTGs are (I think, in game terms) meant to power small probes and rovers that aren't meant to carry large battery loads. Basically the RTG should replace a bunch of batteries and the solar cells required to recharge them, supplying constant energy instead of cycling a rechargeable battery (or fuel cell) up and down. A single RTG replaces approximately 6 static solar panels and 1000 battery capacity (one 1.5m battery, five .625m batteries, ten 100 charge radial packs, etc). A combination micro-nuke + generator + radiator array (basically a high-power, re-fuelable, waste heat enabled RTG) in a single part might be a good, high-level tech, niche item.

I went the MacGyver route, rather than the coding route. I use radial decouplers as connection points for multiple struts... and use staging to break the strutting when I want.

The one thing I'd like to have is a way to center the 90 degree hinges like you can with the normal hinges. Press the circle and they go to the center (which would be the start position for the regulars) position, the arrow buttons for either side. This would keep me from having to judge the angle for things like extendable solar panel support arms by eye. Other than that, I've got nothing in the way of ideas at the moment. [Edit] Of course, no sooner than I say that... A 45 degree (possibly 30 and 60 degree version too) piston that has the moving attachment node move at said angle from the root attachment. Basically these would move outward and up/down (or to the side... if you rotated them that way) instead of just outward, and still be able to easily keep a common vertical with the fore-aft axis of the craft.

Corrupt file verification attempt. Download attempt from link: http://taniwha.org/~bill/Extraplanetary_Launchpads_v4.1.2.zip Download successful. Comparing to known good version: Extraplanetary_Launchpads_v4.1.2.zip - -Size: 22.0 MB (23,118,275 bytes) Extraplanetary_Launchpads_v4.1.2 (1).zip - - Size: 22.0 MB (23,118,275 bytes) File structure, identical. File contents, identical. Gotta be on your end JuanxLink.

So... the docking washers could concieveably be done away with (as literal docking washers, meaning their intended function of aligning docking ports) by replacing them with a part that contains both the docking port and docking washer functionality (best description right now would be a welded docking washer and Clamp-o-Tron). A third possibility would be to have the functionality of all three... a "recessed" docking port that extends to allow clearance, and rotates as needed to align the docking port. Perhaps a fourth possibility that adds in a hinge function and a second rotation? Basically a "recessed" docking port that extends to allow clearance, rotates to align the port, hinges (up to 90 degrees) to allow offset docking (say docking to a spaceplane with an in-line Clamp-o-Tron behind the cockpit), a second rotation to rotate the 90 degree bend to any direction... Basically the more complicated stuff that generally takes many parts with the current IR set, could conceivably be condensed down into a single discrete part, although that part would extremely specialized, and generally only perform the one function.

Most likely a ram limit crash. Do you have a lot of mods installed? If so consider using the Active Texture Management mod.

The shallow/deep plan is very similar to what I developed, but I had a third stage. My shallow set was a constellation of six omni-equipped sats in comparatively very low orbit (think it wound up like 150km) It was pretty easy to put up a single vehicle to install all six. This gave me 360 deg coverage out to reliable comm16 range (roughly 2Mm. any farther and there's gaps in the coverage, I'd think that this might be a contributor to the loss of contact that some people might be having. More below). I set up the middle stage @ semi-geo(kerbi)sync orbit, 1 585.18 km (or whatever that translates to as a SMA for a circular orbit) with three multi-dish sats. They still have omni antennas to connect to the low orbit network, but they're set up to provide comms to the deep space network and Kerbin's natural satellites. The deep space network was going to be two sats with at least one of the largest available dish, which would have pointed to whatever body I was working on at the time... However, 0.23.5 came along. Anyway, the issue with intermittent coms might be coming from gaps in coverage. If you're using omnis to link geo(kerbi)sync dish sats, your omnis have to be in a high enough orbit that they provide full time coverage to each of those kerbisync sats. Here's an illustration: Each of those gray crescent shapes represents a signal gap caused by the range of the omni antennas on a six sat constellation in an orbit slightly less than 500km. Those signal gaps will rotate as the constellation does, providing intermittent coverage to any sat in kerbisync orbit. A two-, three-, or four-kerbisync sat constellation is going to have all sats lose comms with the low network at similar times. If KSC is linked to one of these sats it will still provide an uplink... but if there isn't a link to the other two sats you'll lose comms if the uplinked sat is blocked. Best options if this is the case is to lower the planned orbit of the kerbisync sats to semi-kerbisync, or raise the orbit of the omni-sats to ~750-800km.

Nope. Had that question a few pages back... with the answer a page or two before that.

I needed more alerts in my life. This provides them... with just the right amount of cowbell. However... Found an interesting... aspect... of this mod. Not exactly a bug, not exactly a feature. Not exactly fugly either. You will get this: ...if you have SA active in the Orbit map view, and get an EVA report alert, and click on the experiment from the SA button in Toolbar (which immediately pops a Kerbal to EVA, provided you're not presently in-atmosphere...) This image was taken after successfully taking the report and reboarding the craft. It's not gamebreaking as far as I can tell, but sometimes the scale can get a bit wacky. A simple change back to staging view (once aboard the craft) corrects this. Recommend a forced view change out of orbit view before popping the Kerbal out on EVA. Managed to recreate it easily. Steps: Have a low orbit (69km +) EVA report undone. Launch manned craft on high ballistic arc with intended apoapsis > 75km. As craft approaches 65 km, switch to orbit view. Bring up nav-ball. When SA goes off, wait a few seconds for apoapsis to climb so you have enough time to reboard craft. Kill main engine throttle. Left click on SA button to bring up experiments. Click on EVA Report. Laugh as you realize that you may have finally matched Jeb's body to his ego:

The first thing I thought of when I read this was throwing copies of Bill at a circular target in grass. Clawn darts. Grr... tag no worky.

Hmm... Just a random idea for the spinny indicatior: could it be possible to tie the direction and rate of spin to the value of difference between relative (notional) verticals of the two controlling hatches? Basically if you're > 45 degrees off, the indicator spins at full speed ( 90 degrees per second I guess, in the direction you need to roll to bring the verticals into alignment). As the verticals get closer to parallel from 45 degrees, the rate of spin lowers from 90 degrees per second, to zero in roughly 5 degrees per second increments, until verticals are aligned (1 to 5 degrees off alignment ==> 5 degrees per second of spin, 6 to 10, 10 degrees per second, etc). So if you need to roll clockwise, the indicator spins clockwise. If you need to go widdershins () so does the indicator.

Hmm... Is there an extant issue with the toolbar button not hiding the IR GUI in the flight scene and/or orbit map view? Having that issue, flight staging/docking and orbit views. New release candidate for 0.14, verified Toolbar as the version bundled with it. On the plus side, the toolbar icon works in VAB scene.

Actually did... but it was two posts above the report... But yes, it is. This is good. Was the only remaining issue that I had with that part. The Mass-displacement bug got thoroughly squashed it looks like... was the first thing i tested as it was giving me fits.

Release candidate 0.14 (Thanks phoenix_ca) Parts used: Powered Hinge (IR, block, not door) RC-001S Remote Guidance Unit FL-T800 Fuel tank BZ-52 Radial Attachment Point Modular Girder Segment Launch Clamp Of these I believe only the hinge itself is significant. Here's what I've found: Screenshot: Built this way: part (orientation keypresses) attachment type, Fuel tank, RadAttPt (none) radial, Girder (D) node, Hinge (S, Q) node, Girder (A) node, Hinge (S, Q) node Fuel tank, RadAttPt (none) radial, Girder (D) node, Hinge (S, A) node, Girder (A) node, Hinge (S, Q) node Expected behavior: both arms are expected to look and perform exactly alike, with the exception of orientation of the first hinge. Actual behavior: To detail: The axis of rotation (first hinge) is reversed. The notional "static" face (bottom node, without logo) does not move, and it should. (Needs bigger hammer). The notional moving face (top node, with logo) moves when it should not. (Needs Duck Tape). This behavior seems tied directly to which node is used to attach to parent part. Surface attachment is similarly broken. The surface attached ones are copies of the opposite side, surface attached to the tank, and oriented so that "up" is common for all hinges on the end of their respective arms.

Yep. I've got misbehavior on the full size powered hinge (not the door, the block) in the new release candidate. Gonna run a full series and detail. @ctbram Try the "Raw" button next to the "Open" button. Should say "Open - Raw - History - - Delete" Click "Raw". Should download the zip.

Are there any changes between this and the original beta for Powered Hinges? I'm currently in the middle of a behavior description test that should help detail how they misbehave. Heck with it, I'll see if I can get them to misbehave in the new release candidate.

You might find utilizing "all the orbits" to be a more practical answer. A nine relay constellation in three 60 deg inclined orbits with those orbits spaced so their equatorial ascending and descending nodes are spaced every 60 degrees around the equator (and their orbits timed correctly) should give you enough different angles that you'll get the most reception. Though actually getting those spacings and timings... that's the trick. I know it can be done with Hyperedit... but actually getting those timings flown... the orbit rounding errors are going to be your bane.

Wait. Free fiber? Deceptus for First World Dictator. (read that either way...) May he reign long (enough I get free fiber).

Good to hear. Designing space stations without the use of IR parts is getting troublesome for me, and I eagerly await release of the beta package. Thanks for the hard work you've put into the original parts, and the retooling necessary to make them work again.

That video of the hinge also reminds me a lot of behavior of "strutted" joints. Had quite a few problems with those when I used Quantum Struts several months ago. Question: Does the force balance out when symmetry is applied to the hinge? Basically, if you put two hinges in 2x symmetry on the top of the can, do you still get weird forces, or are the forces canceled. Not sure what this kind of thing reveals, but the experiment might be helpful in tracking down exactly what is going on.

Didn't realize that it was part of the same problem. There's nothing radially attached to the printer at all... And I thought that was what was initially triggering the issue for you. I'll apply suggested fix and test though. What's the bulk comment notation used in the .cfg files?

I seem to have run into an issue with the 3d Printer. Short version, when I try to launch a payload with the 3D printer in the stack the rocket undergoes a RUDE at roughly 6km. Without the 3D printer in the stack, the payload launches just fine. YouTube video of good launch, adding the 3D Printer, and the subsequent bad launch (starts @ 4:15). Not sure where to go with further narrowing down the problem.

I ran into the need for strut reinforcement when launchinig Solar Microwave Generator Sats using KSPI. I wound up using linear decouplers (four or so) as attachment points for multiple struts, which made the folded array (made of quite a few cubic octagonal struts, telescopic pistons, and 90 degree hinges) rigid enough to launch, and cut loose completely allowing deployment of the arm (twenty-one Gigantors per arm). These arms aren't deployable when not in freefall. A 1g field causes them to bend quite a bit, and seperate in odd ways. Even trying to reorient the sat with the arms deployed takes quite a bit of time, and the arms still bend quite a bit. With the struts done the way they are, they can't be deployed... but they're solid as a rock. I've thought about using KAS struts for reinforcing unfolding structures, but usually the part count is already high enough that I think the struts aren't going to be worth it.

Idea/possible request: KSPI pack including resources like Xenon, Cryo Helium, Reactor fuels (Fusion mostly, but I guess fission might be considered), Monoprop (for plasma thruster)... possibly even small antimatter bottles?