Reddot99

Is there an ETA for v 0.4?

The 'pre' delay means 'wait x seconds after the last stage delay ends' and 'post' is 'wait x seconds after whichever of the following happens later in time: "running out of fuel" or "last stage was triggered" before advancing'

I figure you could do that fairly easily. The open while checking, that is.

Action groups toggle the parts, though at high speed, parts will drift a bit

There was a bugfix to keep it onscreen with window size change included in the September 9th build though, and that's in this one.

Speaking of 'solutions', I took the source from the September 9th update and piled together a version without the 'shutdown on vessel switch' code, and built it with monodevelop, the whole thing, including code I compiled from is here -> https://www.dropbox.com/sh/djj3ptsqm8efmtg/fBH1UxbBxK (source will be there as dropbox finishes syncing, which is taking a weirdly long time)... Just for those who want to be able to move the tab without the mechjeb shutdown thing... I also haven't tested yet, so overwrite at your own risk.(ie, make a backup first)

Actually, I think this is the perfect place for a spring, especially since it'd be to the pistons as the free spinning washer is to the regular ones. (Hint, you can probably make one with just cfg changes.

Ok, my plan was a flop, but I did discover, as spinning objects drift away, they're drifting as if regular physics were applying single frames during their turning process. (I know *what* I would need to do to fix it, but not *how* to do it... essentially need to have the rotationjoints translate back to their 'homes')

Well, I have a slight improvement, methinks, after a rotatron has drifted off, it'll at least stay put, XD Edit: Looks like I'm on the right track, at least. Next thing to try, increase that projection snapping thing Edit 2: Err, is there a way to swap out the dll while KSP is running? (Also, the motion stuff is in toggle.cs, right?)

The moment of truth! ... Err, anybody got a sure way to replicate the 'docking washers falling apart' reliably?

Actually, I think that may not be the culprit, digging through documentation, I think I've found a possible candidate for the exploding parts issue. The issue may be that the joint between the (washer's) parts themselves is rather weak though KSP's joints seem to take most external torques/forces (hence it's appearance more often at high speeds). I'm gonna try to build a modified dll to test, if I manage to eliminate the issue, I'll send you my changes to the source.

Stack overflow might be from trying to draw too many lines, (maybe), could trying to read every 'Nth' entry in the tracklog solve that? I'm not sure how C# handles these things, much less how your code does. But if it isn't being tidy and clean in it's 'read tracklog->grab point, connect to last point->draw track->return to tracklog entry;' loop(or however you constructed this), it may be leaving junk on the stack after each iteration. In any case, this looks like it'd be fun, are the tracks positions fixed based on position within a SOI?

I await the witty comments about the history of the parts

Thought, deduct from monopropellent stores?

Suggestion here, why not have Gammoner's code able to 'update' areas as they're flown over. In other words redraw that little segment of the map image being 'scanned' with a fresh read of that terrain. Figure out what the scanning arc would be, and make an array of raycasts coming straight down over the coordinates of the pixels, that reports the first position they encounter something solid. That position is used to repaint that little segment of map, possibly catching anything large enough (or close enough, if another craft happened to pass below you.) to affect that ray. (This would be a runtime toggle, ideally.) Seems sorta like a fair compromise between the procedural methodology/mapping of MapSat and the memory reductions of Gammoner's version. Also, I assume the terrain map generation would be best done on the first entry of a mapping-enabled craft into each world's sphere of influence (or perhaps with a gui button trigger while in a stable orbit), possibly putting a KSP version flag onto the map, so it'll know to rescan only if the image is either out of date, or missing from it's 'library'.

So THAT'S where those came from! I was wondering about those,

Thank ya much. I might think that control surfaces may work better for that, (Use a long narrow (mostly straight) wing, apply control surfaces to trailing edge, and use FAR to set the surfaces to be action group controlled flaps with a very wide range of deflection). Just a crazy idea, I'll try this myself, see if I can get something (remotely) controllable.

(Un?)fortunately, Kerbals do not seem to think seatbelts will be useful in a chair designed to be on the outside of a spacecraft, since acceleration isn't exactly sudden in space. (Unless of course, you're Jeb, and use a first stage motor for orbital maneuvers, I'm constantly surprised to not lose that little chair while at full throttle with 30+ m/s^2 acceleration) Perhaps now's the time to start promoting safety harnesses...

Now, the question, can it land? (Also, I assume no FAR?)

Hrm, forum update the other day seems to have broken the quote action (among other things). Anyhow, cy-one, the idea was that now you use the gantry upside-down compared to before, (old 'platform' is now the mounting piece, try to surface mount it to see what I mean. After all, I only changed where it attaches when surface mounted.)

Alternately, replace the 'node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1' with 'node_attach = 0.0, 0.65, .0, 0.0, 1.0, 0.0, 0' in addition to the rest of the reversal process. (I used this to mount three engines in a row on a gantry and it actually looks pretty good, I think.)

A note for folks, NEVER attach struts to try and hold the gantry steady, it'll think those struts oughta be moving.

I'll play around on Ike or Minimus to try and catch it, if you like, heh.

I'm uncertain if this has been covered elsewhere, but is it possible to set a color to a resource on the hexmap, like how kethane is green, I could say, make another resource (say ice for harvesting oxidizer/hydrogen for use with modular fuels) turn bright white instead of the default grey?

I'd say release with the note, and mention upfront that you're not sure of a fix, (Actually, that's probably why the dromoman rotohubs have their little cube's mountpoints on the rotated section.) Edit: That said, I'm not sure that a simple fix exists, it's like mounting a piston backwards, only way to prevent the problem is to attach carefully... Edit 2: It would probably take a non-trivial amount of code to change, in all likelyhood, so yeah, don't worry about the bug.