cameroon

I've really been enjoying the return of RemoteTech and I've been happily setting up satellite networks and planning interplanetary missions, but I seem to have hit a bug with undocking and I don't know if it's a bug with RemoteTech or if it's a different bug and RT is just highlighting it. When I try to undock using the selected port, the command is queued and never executed. Additional commands just queue up behind it. Only reloading a save (F9 or from the start screen) returns normal control (though undocking from that port still doesn't work). Other docking ports do seem to work, though, which is what makes me wonder if it's just a bug with undocking. Interestingly, the rotational keys (WASD) and throttle still work. I didn't try all the other commands (toggling RCS, translation, etc.). (I have somewhere around 0.005s signal delay, as I realize it's cut off in the pictures.)

My experience with VTOL craft (that have wings) in stock KSP is that they behave BADLY due to the way aerodynamic forces work. For instance, going "backwards" is a huge problem with stock KSP aerodynamics. I've had much, much better luck with VTOLs using the FAR mod. I'm about to try out a design, inspired by one of yours, with FAR and this mod. I haven't used this mod too much, but I really like the idea and I have a feeling that some combination of the B9 atmospheric RCS and some limited engine control will probably make for a very flyable VTOL.

The science crew looks forward to the firmware update

I noticed the WarpPlugin.cfg in the game save directory. It is updating, and the packets are apparently being written as being 0 science even though the science lab shows 0.06. DATA_PACKET { science = 0.000000E+000 UT_sent = 3.0857999988323217E+005 } Edit: I went to my rover that has 4.27 science and clicked Transmit Science and it also wrote a 0 science packet: DATA_PACKET { science = 0.000000E+000 UT_sent = 3.0870873988335265E+005 }

I can't recall, but on the chance that was the cause I deleted and replaced the WarpPlugin directory, but that didn't help.

Ok, I've removed all but the plugins that would break my save due to parts, which leaves me with the mods below and I still can't transmit science: Procedural Fairings Procedural Wings MechJeb2

Well, that explains it - though before (0.6) I could send whatever I had. Thanks!

Sorry if this was already asked/answered, I've been reading the thread and haven't seen it so... Is there a reason that I can't transmit/receive science? I've got powered science labs (1 on Kerbin, 8 on a ship waiting for a transfer window and 1 around the Mun) that have been in play since 0.6. I updated to 0.6.1 and now clicking on Transmit Science does nothing. There are no computer cores involved. All 8 of the labs in Kerbin orbit show 0.06 science available. I'm quite enjoying the mod otherwise!

Infernal Robotics supports action groups: I only briefly toyed with DR, but I've used Infernal Robotics for awhile and while group names are global, group assignment (and action groups) are all craft specific.

Infernal Robotics (and Damned Robotics before it) has input areas in the VAB for setting the names of groups and parts. I'm not sure if those are saved with the craft file or not, but maybe it could give some ideas.

I attach mine with rotatrons and control by setting keys for rotation. Set the speed low (.2 or so, wish this was set-able during build) and its easy to make gradual changes. Sudden changes are a way to escape controlled flight pretty easily I don't think I've put this image in this thread, so apologies if this is a re-post: The hardest part of VTOLs in KSP (to me anyway) is actually the stock flight mechanics. Pretty sure lateral movement ends up creating funky lift and "backwards" movement really messes badly with stock KSP flight physics, so I ended up installing FAR in order to reduce silly things from happening when my VTOls drifted sideways.

sirkut and devo (I'm probably missing someone else) , thank you for all your hard work on this plugin. I'm addicted building high mobility rovers using IR parts, though getting this to other locations is probably not the easiest thing in the world I did have independent track articulation as well, but it turns out that the tracks plugin for mirrored tracks requires the orientations of the tracks to be the same or it simply doesn't operate. Still, there's enough articulation here to get unstuck from pretty much anywhere (or drive upside down, if you flip it).

@AncientGammoner - I seriously don't get why you're commenting in such a (seemingly) hostile manner. If it isn't your cup of tea, fine but why bother commenting at all if you don't like the premise.

Sorry for all the pictures/posts, but learning what the analysis is telling me has really made for a fun evening - thanks to all who have helped me figure it out I was wrong - this has a lot of lift from the tail to pull the CoL behind the CoM, but giving the horizontal stabilizers a bit of negative AoA seems to have fixed the stall characteristics. It's been recovering from very off-axis stalls, which it certainly couldn't do prior to the rear AoA change.

Absolutely, I build with shifting CoM in mind constantly. I usually give myself a decent margin between CoM and CoL, pushing it forward only to the point where control starts to get "twitchy" rather instead of smooth. It's the only way something like this works Building VTOLs (with Infernal Robotics) is one of the reasons I decided to dive into FAR completely. Stock KSP can't really handle a VTOL if it has lifting surfaces anywhere - all sorts of bad things happen. As ungainly as that ship looks, it flies reasonably well.

I think this was directed at me actually, thank you for describing how to read the split Cm - that's immensely helpful! I have noticed that once in a stall it's far easier to get that particular craft into a spin then it is to exit the stall. I'll definitely try those suggestions out, I think the lift is substantially in the mid-body, but I think they're all 0 AoA. I'd picked up that some positive AoA at the nose or negative AoA at the tail was a good idea, but had never heard why that was. Unrelated, but I was testing out the FAR Hypersonic craft that comes with the mod using my newly gained understanding of the static analysis tool and noticed that the fuel tanks drain in a very unbalancing manner. I didn't start editing to fix it, just told TAC to balance them all, but I thought I'd mention it.

So some testing seems to indicate that it does recover, unless it enters a spin - which it has an alarming tendency to do. Fortunately I wouldn't actually fly this aircraft with this much pitch authority anyway. With this much pitch, it's just as likely to snap in half as it is to actually get where it's going (plus it is super twitchy). Van Disaster and Taniwha, thanks for your explanations and help - I think I now grasp what that graph is telling me so I should have less frustrating builds

Time to climb to sufficient altitude to check that out

Ah, ok, that does seem to make more sense - the graph is showing all positive AoAs, just one is post-stall. I do wish the line was a different color or something. I was reading decreasing AoA as "negative", but that doesn't really make sense now that the fog is lifting. And yes, spin recovery is something I plan on practicing (I have vague notions individually firing one of the engines to just disrupt the spin). Until then, abort systems that recover the cockpit are the order of the day

Thank you taniwha, as I understand it the craft would be stable ("controllable") but the stall around 16 degrees would kill my lift. The negative Cm line means I would (in theory) have enough control authority to try and get my nose pointed back at my velocity vector for recovery. I think one reason I was having trouble was that my aircraft didn't have the pitch authority to hit 16 degrees AoA (it does now, in my quest to figure this out). That still leaves the splits - I definitely don't know what the split is actually saying.

So I've caved and am going to ask I can't find resources that spell out how I should read the Static Analysis graph (believe it or not, google for '"Static Analysis" aerodynamic graph' you end up at brief mentions within the FAR thread). While I understand a general "Negative Cm is stable" and that the sharp divergence of the various plots happens at a stall, I can't seem to determine how I should interpret them for the purposes of flight operations. In particular, while the help for the graph states that it plots a positive and negative AoA I don't know if that's the divergence of the lines (and then no idea how to read them if it is). My current "best guess" is that the graph below is telling me that the aircraft would be stable with the nose pitched up to ~16 degrees from the velocity vector, after which it would stall and then not recover until the nose was pitched down to somewhere around -28 degrees? Or do I have that reversed (or, likely, just altogether wrong)? I've come and gone from FAR a couple times, in part because I feel like I've never had a grasp of the analysis tools, but I'd really like to make it one of my must-have mods because it really improves the experience. So thank you in advance!

Oh fantastic! That's going to make folding rovers so much easier, thank you!

Is there anything that can be done to make the closed hinges work better with SPH symmetry? As far as I can tell, right now you can use the rotation buttons in the UI to get them facing correctly when using symmetry, but that seems to alter the rotation orientation as well (so one of them "closes" even more). Am I just missing a trick or is it a limitation we're stuck with due to how symmetry works?

I'm in the process of trying to squeeze down the amount of memory KSP is using (too many mods ) and was about to write that for the hinges (and docking washers probably) you can use one model & texture and and just define multiple parts with rescale factors, but turns out that's what you did for the rotatron already

Well since that sounds like a "what would people like" type of question... If I had my choice, these are the features I'd want: * Setting the "start" position during assembly (like being able to set a ram half-way in its travel) * Variable speed settings (would be nice to be able to set these during assembly and have them persist with the craft too) * Being able to set minimum and maximum travel ranges during assembly I do like being able to change the speeds, but if I could have setting the start position or having variable speeds, I think I'd pick start positions. As an example, I'm working on an airplane design that lets it shift the CoM during flight (for payload offset) and it would be great to be able to set the ram to 50% of its travel so that I could build the airplane with a balanced CoM in the editor and still be able to shift the CoM forward or backward during flight. As-is, there's a lot of guesswork to get positioning right.