Wercho

As Rhomphaia said, it is not telling you that it is producing lateral thrust. It is telling you that the axis around which your thrust would produce a rotation is that direction. The circular arrow shows the rotation. RCS build aid uses light blue arrows to show thrust. As for why it does this, a vector along the axis of a moment (angular force equivalent) is in common use in engineering because it has computational advantages. In your case, the red arrow doesn't mean anything for you, just look for red circulars and blue straight arrows.

I had this happen to me several times back with 1.50, so this problem isn't new to this version. I never figured out a pattern to it with regard to which parts were susceptible. I know that when I encountered it, it seemed to happen rehappen with that particular part consistently, UNTIL I exited back to KSC and then reentered the VAB (or SPH). Then I was able to build the thing I was trying to build before without issue, using the same parts in the same configuration. So, whatever this bug is, it's a strange one.

I get "unbound" if I do something like "SET ship:control:neutralize to true." but since my PID loop just updates the control every round, that is showing up many times. It only puts unbound into the log when the script stops controlling things. Pseudocode: UNTIL end { WAIT 0.001. Calculate PID control. SET ship:control:pitch TO x. //adds "binding" note to log every time the loop cycles. } //control done SET ship:control:neutralize TO true. //adds unbound to log

I just noticed that kos puts a note in the debug log whenever you bind a control using the raw ship controls. The notes are "kOS: FlightControl Binding" and "kOS: FlightControl Bound". When using them in a PID loop, this results in large amount of log spam, so I might suggest taking out those notes. (I assume they were debug notes). It's not a big deal, though.

The addition of rotations is pretty confusing to me, but with the inversion it sounds like you are running into a problem with order of operations for the rotation. You could try switching the '+' to '*' (which AFAIK perform the same operation on directions). Check out the documentation on directions and maybe you'll understand order of operations better than I do. For these situations, I use the heading function instead because I understand it, and combine it with lookdirup if needed. So I would write your code as : wait until altitude > 100. lock steering to heading(90,90). //90 heading is east, 90 pitch is up print "Beginning roll program.". wait until altitude > 500. lock steering to heading(90,70). //still east, now 70deg above horizon ... etc. ... wait until altitude > 55000. lock steering to lookdirup(heading(90,15):forevector, (-1)*ship:up:forevector). //gets the "point at" direction as east + 15deg above horizon, and points the top of the ship at the opposite of the up vector ...(Code may have typos) You can totally do things the way you are doing them, I just don't understand direction math well enough to do it.

You also shouldn't add chutes to the weldment (according to the OP). From my limited bit of using this mod, I also think it doesn't handle animated parts well (such as extendable solar panels and landing legs as mentioned, but probably also those radiators and cargo bays. So I bet if you put more than one in, only one will move. I'm not sure though.

Or better yet, throw this line in the appropriate spot so you don't even have to remember. SET sas TO false.

Decouple with the engines on, as others have said, and then hit [ or ] to switch to the probe before it gets 2.5km away and unloads from physics. Landing on a docking port is haaaard. I've done it but only with autopilot help. Very precise hovering is needed.

Hmm. I can't tell exactly, but I suspect the problem is that due to a quirk of the physics engine, symmetrically placed parts sometimes behave a tiny bit differently, so you get a tiny pull to the left. This is compounded by the fact that with that ring thing and the goo containers hanging off the side, the top of your rocket will have a lot of drag making it want to flip. Now, why can't you fix it? I think it is because your tailfins are HUGE for that rocket, and it doesn't look like they are control surfaces. Do you have access to the AV-R8 fins, or other full control surfaces? If so, swap your fins out for those and see if it helps. If not, I'd actually just remove the fins and rely on the pods torque, but keep it very straight or you'll flip out. You might consider moving the goo containers lower to move the drag backwards on the rocket if you do that.

I've now looked again and I realize it's just overwriting lines, not clearing them. Thanks for some great work!

AFAIK, RT doesn't expose the targeting to a part module field or event. I'm guessing the target event activates something in the RT dll which creates the menu, so I'm pretty sure there is no way to automatically target an antenna through RT. I can't be positive though, because I use RT but have't looked at the source. I switch the terminal font for "Fixedsys", which sounds like fixed width and looks like it. I get the same result. I don't know enough about telnet to know whether this is a Putty problem, or kOS, or just some weird interaction with the settings. Looking at it, it seems that sometimes the Putty terminal puts the PRINT...AT in the right place (eg. "Tar.Land" "No" "Yes") and sometimes appends the new text to the end of the text that has already been printed on that row rather than putting it at the correct horizontal position. (eg. "Varies" "Hover" "Land"). Different craft for the new image, but the kOS terminal looks the same. Reposted for ease of viewer. Another idiosyncrasy I've noticed is that when kOS clears the terminal when a program ends, the telnet terminal doesn't get cleared so I end up typing over the text. No big deal though.

The new telnet is pretty fun. One bug I've noticed is that it doesn't seem to handle PRINT...AT properly. Specifically, everything shows up in the right place on the kOS ingame terminal, but in the Putty terminal I have connected things seem to be moved randomly left or right 1-10 characters. Does anyone know why this might be happening?

It is in this post: link.

I get the same error anytime I have an "ahem" rapid unplanned disassembly, usually due to some sort of lithobraking. It seems that if any part gets destroyed, regardless of whether it is a crewed part or has CLS, I get tons of these error messages. EDIT: Well, not any part. I'm not sure what the pattern is. I'll try to get a good log for posting.

FYI, the github 0.19 release seems to be different than the dropbox version MOARdv posted in the thread. I installed the latest from github, and it didn't work properly. But when I downloaded from dropbox everything was great. Has anyone else encountered this, or was it just me?

I'd like to put in a small request for some right angle pieces added to the structural pack. Your parts are so cool looking, and it would be sweet to have those to make seamless mechanisms. Great work with these. I especially like the foldatron parts.

I would turn on FAR's control dampening. While in flight, open the FAR menu and click 'DCA'. You may need to fiddle with the settings for your particular plane, but it will help.

I think using body:obt:velocity will give you what you want.

Would it be possible to make jointSpring and jointDamping tweakable, possibly through a flag the same way as limitTweakable? I know I'd like to be able to create suspension systems easily, and using MM to duplicate the parts with springy values leads to extreme part clutter. This mod is so sweet.

Ok, on your first attempt you kept mixing IF statements and WHEN..THEN statements. The WHEN statements appear to be set up correctly, for the most part, but the IF statements are the problem. The WHEN statements are just triggers, so the program continues executing when it finds one, and just stores the trigger condition. That means your IF statements are getting executed immediately upon the program getting to that stage... eg. right after countdown. So, what the program sees is this, sort of: Until countdown = 0 { Print "T" + countdown + "s". Set countdown to countdown +1. Wait 1. } set q to 1. set u to 1. if ship:altitude > 90000 { set q to q - 1. } etc. with a whole bunch of WHEN's stacked up waiting to happen. That IF evaluates to false, kOS doesn't ever execute the code inside it, and moves on. You need to change those IF statements to WHENs, or better yet, rewrite them as WAIT UNTIL or do things with UNTIL loops. In one case, you have an IF nested in a WHEN, and that one would have to be made a WHEN, I think. Your second attempt suffers from the same problem. IF statements that evaluate to false and the program moves on. For the last one, directly from the tutorial. I assume you are locking steering to prograde. Is the engine firing but never stopping on that one? I think it probably just needs the last check changed to ship:obt:periapsis > 99500. "Periapsis" has been deprecated and shouldn't be used anymore, but more importantly, it is unlikely for the periapsis to be exactly 99500 at any physics tick, so waiting until it is greater than the specified value should suffice. Also, it would probably be best to finish with "LOCK throttle TO 0." just to make sure you don't keep going. The program should release control when it starts, and return the throttle to whatever it was set at before it started. Hope that helps.

I'm in favor of making this change. I'm using angularvel for a PID controller, but I'd much rather have it make sense and fix my code when the change happens, rather than currently where angular vectors don't make mathematical sense but work because I switched them around. ----- Secondly, I seem to have found a bug with the pilot-translation GETs. Specifically, ship:control:pilotfore and ship:control:pilotstarboard return the negative of what they should. Eg. when you press the translate right key ('L'), ship:control:pilotstarboard returns (-1) when it should return (+1), and the opposite for 'J'. It's easy to work around this, but it should probably be fixed. Can be demonstrated with this script : UNTIL false { WAIT 0.001. PRINT "pilotfore: " + round(ship:control:pilotfore,1) + " " at (0,3). PRINT "pilottop: " + round(ship:control:pilottop,1) + " " at (0,4). PRINT "pilotstarboard: " + round(ship:control:pilotstarboard,1) + " " at (0,5). PRINT "pilotpitch: " + round(ship:control:pilotpitch,1) + " " at (0,6). PRINT "pilotyaw: " + round(ship:control:pilotyaw,1) + " " at (0,7). PRINT "pilotroll: " + round(ship:control:pilotroll,1) + " " at (0,8). } Ship:control:pilottop works correctly, as do all the rotate GETs (pitch, yaw, roll).

I quite like the idea of straight color sets. I might lower the saturation or something to make them less bright, but whatever. Your suggestion of separating the nrm and color also appeals to me, though not so much that it would be worth a lot of developer time. But it would allow some cool colored craft, with interesting texture. The customization of appearance as well as function is already one of the things I like so much about PP.

Give this a try. I just wrote it based on the wiki and didn't test it, so it may have typos. This will double the range for all stock science experiments, I think. Change the '2' to your liking. @PART[*]:HAS[@MODULE[ModuleScienceExperiment]] { @MODULE[ModuleScienceExperiment] { @interactionRange *=2 } }

The vector from your port to the targetted port would be: lock myporttotargetport to targetport:position - myport:position. The code you pasted would find the vector from the origin (approximately ship center of mass, I think, NOT "controlled from" part) to the target port, and then rotate it by the port facing. That's why the drawn vector is slightly off. You are calculating targetportposition based on the ship origin, then basing future calculations assuming it was calculated from the port origin. For the rest, I would definitely suggest changing all of your facing statements to portfacing, because I suspect with the surface mounted docking ports those directions may not be the same. In fact, based on the picture it seems clear that the FORE vector is pointing along the ship's FORE vector, and I bet the portfacing FORE vector would point directly along the ports docking axis. It'll probably mess with your immediate calculations, but I think that'll help in the end. I hope this helps and I didn't get stuff to wrong. - - - Updated - - - Double post, but this one is on a separate topic. Devs, would it run better better to write code that references the part suffixes everytime, or set a variable to a given quantity and then reference that variable? As in should I reference ship:velocity:surface multiple times per loop, or set varSVS to ship:velocity: surface and then use varSVS? Basically, I'm asking if the ship:velocity:surface or other such calls consume much processing power, such that a kOS script could have an appreciable affect on the smoothness with which KSP runs by repeatedly querying the KSP engine.

This happens to me, and I also use KCT. I've never bothered to do anything about it because it doesn't affect play, but it is a bit distracting.