Dunbaratu

Wow that web interface is broken. I have NEVER seen the "Search in Forums(s)" field on the advanced search page, and only after messing about a long time after seeing your post did I find out how to make it appear. When you first see the Advanced Search Page it is missing most of the fields of the "Search Single Content Type" page even though the "Search Single Content Type" tab is actually highlighted as if it had been selected. To make the fields you're talking about appear I have to click on the already selected "Serach Single Content Type" tab even though its already been selected so it looks as if such an action would have no effect.

Incorrect. Even if the math operations are simple a process can still be accurately called "tricky" if the information you input into it is hard to assemble together and easy to make a mistake. Finding the sum of 10 numbers? Easy. Finding the sum of 10 numbers taken from a set of 100 numbers, which are hidden from view except one at a time so you have to keep notes on the side to do it - is extremely error-prone and therefore quite accurate to describe as "tricky". The tedious nature of the work *causes* it to be tricky, because it activates the thing human beings are bad at - repetitive rote operations. Human beings are actually good at math. What they're bad at, is *arithmetic*. It's a distinction people often fail to make. When you use a tool to do dV for you, you're not doing it to save yourself from the math, although it has that side effect. You're doing it to save yourself from the arithmetic. And manually tracking all the data is part of the boring arithmetic. You know - the **tricky** part.

People seem to be misunderstanding what annoys me about this. When you describe it as "having to look in 2 threads", then you're not getting what's annoying about it. I'd *love* to be able to JUST look in 2 threads. That would be a huge improvement. What the current layout does is make me have to look in *hundreds* of threads. Currently the only way to be sure to catch any mansions of a particular mod needing support is to literally read *every* thread in the support sub forum. It's not that I have to read the modded installs sub forum that's the problem. It's that I have to read *all* of it that's the problem. In the release sub forum, its' organized per mod. In the support sub forum it's not. Posts are not flagged by what mods they're talking about. You have to go look inside them at the body of their text. It's not that the support subfurm exists that's the problem. It's how it has a flat hierarchy and isn't per-mod that's the problem.

It would make sense to have the "Support [modded installs]" subforum if its purpose is to let people with modded installs post about problems in which they haven't identified which mod might be the problem yet, or even if a mod is causing the problem. It saves SQUAD from having to debug problems they might not have caused, while still getting the problems out in the open for advice from other users and to see if lots of people are having the same problem, and so on. But that doesn't seem to be the way that subforum is being used in practice. In practice a large number of the posts seem to be from people using it to get support for ONE mod that they already know is (or at least think is) having the problem. Rather than people thinking "I installed a bunch of mods - I started having this weird problem - I wonder what's causing it?", it seems to be being used by people thinking "I already know this is a problem with mod XYZ, but I'll post about it here instead of in the thread that's specific to mod XYZ." And that's a bit annoying to me, because it now means if I want to keep on top of problems occurring in a mod I help develop, I have to read through ALL the threads in that entire subforum, the vast majority of which are about other mods, to find the few here and there that might be about the mod I'm checking for. In the past, reading through just the one thread in the "showcase" or the "development" (depending on the state of the mod's release) about the ONE mod was good enough to see all the user support reports. On a few occasions I've found posts about a mod I'm helping develop in the "support modded installs" subforum only a week or two after they were written, and only accidentally via a google search that turned them up when I was looking for something else. So I'd like a clarification on this: If you *already* know the exact mod you're trying to get support for, should that support request go in that mod's own thread, rather than in the generic "support modded installs" subforum?

Spoiling the Callisto environment isn't the concern that's driving this issue. Spoiling the experiment's validity is the concern. An experiment to test if Callisto has life, that's designed to be extremely sensitive to find the tiniest trace of life, needs to be sure not to generate a false positive from the life the probe brought with it.

I'll keep it in mind if I see it again. I suspect if it does have something to do with MCE2 it's not *directly* because of MCE2 but because of one of the other mods it bundles with that's doing it. MCE2 bundled in a few other mods I also had not previously been using.

What if it's not on an externally exposed surface, but is instead on an interior surface of something? The bit of shielding provided by the walls of the craft might protect it, especially if it's contained inside one of the areas intended for holding electronic equipment. Such areas might be better shielded than the rest of the craft.

Can people having this problem save the output_log file immediately after this happens (as in, kill KSP immediately as soon as you see the camera pan back behind the rocket - don't come out nicely via the menus, just kill the program quickly using whatever means your OS uses for doing that.) I'd like to examine the log as it exists at that point. It makes no sense what's happening there. (And to make it clear, I'm referring to the camera moving behind the vessel problem, not the exploding part problem. The two might be related because whatever is miscalculating the position of parts could be miscalculating the heat a part is undergoing.)

I remember an episode of the TV show QI (which has gotten space facts wrong before, like claiming that Cruithne is a moon when it's not), in which the question was what was the first animal sent into space. The idea was to catch people out who thought it was the American chimps or the Soviet dogs, when the right answer was a small fly on one of the earlier flights... .. and I immediately thought, "actually that's wrong too. It might be the right answer to the question what was the first animal intentionally launched into space, but unintentionally there must have been lots of single-celled things clinging to the early rockets before that."

I've been away from Mission Controller for a while, playing KSP 0.25 with just the stock missions, but I recently put MC2 on it and started a new campaign. Now I notice that the camera does a *weird* thing when I transition from suborbital to orbital flight. You know how normally the camera swings 90 degrees to a new position when you achieve enough velocity to go from a suborbital path to an orbital path, or visa versa? Well now whenever that happens, in addition to the camera rotating it also zooms WAAAAAAAY out, until the ship is but a tiny pixel in the distance and I have to spin the mouse wheel a lot to zoom it back into view. It's not a fatal bug, just a bit annoying and just odd as I can't figure out what it has to do with MC2, but it only started happening after I installed MC2. Is this unique to me or has anyone else experienced this?

So it seems parameters aren't quite as "local" as they're supposed to be, if they're able to mask off globally locked variables like that. darn it.

Could the fact that you used the identifier "throttle" as the name of one of the parameters for launchdisplay.ks be causing the problem? See what happens if you rename that parameter of the launchdisplay program to some variable name you haven't used anywhere else, say tParam for example. If you try that, will it work?

Did you not see a popup window on startup after updating that mentioned the movement and offered to move the files for you? It was supposed to appear and if it didn't that's a problem. It was mentioned in the changelog, and in the thread announcement, and the official HTML docs describe it in the new place. The readme is too small of a place to put everything.

I know next to nothing about RT integration but I can report that I had on several occasions in the past seen the bug where the camera ends up pointed well *behind* the ship as it ascends past 6000m. I noticed the problem never happened anymore recently, and I haven't been using RT at all recently - maybe the two are connected. I know that normally the camera points at the center of mass, and I sometimes saw along with this bug a weird case of one or two VERY LONG lines trailing out behind the ship, as if a piece of the ship was left behind but still being calculated as part of the ship, and I think the long lines were struts connecting to it. I also know that several mods (NOT koS) used to have problems that summoned the kracken at exactly 6000m many versions back. For a brief moment you'd see the red launching clamps reappear at 6000m, reattached to the ship, which would blow it up. Stock KSP does *something* weird at 6000m altitude. I don't know what it is but if you look very carefully you can see a few puffballs of white cloud always appear around the ship on the screen at 6000m as you launch a rocket. I have no idea why. I have a few random guesses though. I know that at some point as you raise altitude the game switches from "real ground" mode to "fake ground" mode. (where the ground is no longer composed of polygons with a real physical presence you can collide with, and is instead just a hologram to look at.) I also know that at some point as you ascend the frame of reference switches from universe-rotates-planet-is-still to planet-rotates-universe-is-still. Either one of those may cause a bit of a jolt teleportation of position when that happens. It may be that the puffballs you see are actually your own exhaust ahead of you, because you jumped a little bit in position as everything was recalculated to the new reference frame. I could see how that might really confuse the heck out of lots of mods, or even break a ship apart, or miscalculate the position of a part of the ship, making enter of mass calculations wrong. As to what to do to fix it, I have no clue. SQUAD would need to be a lot more forthcoming about what secret weird proprietary stuff they're doing at the 6000m mark. It's *something* weird, and it seems to confuse more mods than just ours.

Why subtract a velocity from a position? They're not the same sort of thing. The basic concept of cancelling units is always a good thing for sanity checking. Just like when you do addition and subtraction on scalar numbers, when you do it on vectors you want to make sure the two vectors are measuring the same units. Position is meters, velocity is meters per second. Subtracting them directly doesn't give a valid meaningful answer in vectors for the same reason it doesn't in scalars. If all you need is the aim to be in the same direction as P, then try finding it experimentally during flight. Use NORMALIZED to erase the differences in magnitude and just look at the directions with trig. Like so: SET PNORM to TARGET:POSITION:NORMALIZED. SET VNORM to SHIP:VELOCITY:SURFACE:NORMALIZED. Now you can take the diff between them: SET NORMDIFF to VNORM-PNORM. Now you can get the component of that diff that is in the up direction (to get if it above or below the target). SET NORMDIFFUP TO VDOT( NORMDIFF, TARGET:UP:VECTOR ). Now NORMDIFFUP will be a number between 0.0 and 1.0. 0.0 means your velocity is in the same direction as the target. 1.0 means its perpendicular to it, upward. -1.0 means it's perpendicular below it. a value like +0.05 means you're a bit above it, and -0.05 means you're a bit below it. So you can keep recalculating that in a loop (or LOCK it to make it recalc it), and move your aim up or down a bit to bring that number to 0.0. If its > 0.0, aim more down. If it's < 0.0, aim more up. Use PID logic if you want that to be nice and smooth, or try with just plain P alone if that's good enough.

There is a significant different between vessel:surfacespeed and ship:velocity:surface:mag. They are only identical when you are actually ON the surface right now. When you are up in orbit, or flying in atmosphere they differ. Ship:velocity:surface is your 3-D velocity relative to the point at sea level of the surface directly under you. Vessel:surfacespeed, on the other hand, is a 2-D speed that ignores your vertical motion. For example, if you are aimed straight up and flying up at 100 m/s, ship:velocity:surface:mag will be 100, while vessel:surfacespeed will be 0. It's linked to from all the places where something mentions a thing related to it - like WHEN/ON triggers, the WAIT statement, and so on.

Vector addition and subtraction works just like basic algebra: __\ __\ __\ if: C + B = A __\ __\ __\ then: C = A - B i.e. SET vecC TO vecA - vecB. (Note the same does not apply to multiplication, as that's quite different in vector math than scalar math, as there's two different kinds of "multiply" for vectors - cross and dot products). "Trim" is the aviation version of "cruise control". Often when flying you have to hold the controls a bit off-center for a very long time with a slight amount of force. For example, you might have a slightly unbalanced plane that wants to tip to the right, so you have to push the control stick slightly to the left just to stay straight. Or you might be a bit nose-heavy and have to pull back slightly on the stick a certain amount to stay level. Over a long time this can become very fatiguing. So aircraft often have trim controls, which is a way of moving a dial or a lever to change where the neutral 'center' of the controls are. (where the controls will go when you let go of them). This is actually accomplished using little tabs on the control surfaces themselves that push the physical surfaces offcenter a bit in the wind. Autopilots often operate *via* the trim controls, especially when they are in 'maintain' mode - just trying to level things for you. They leave the main controls alone and just fiddle with the trim instead. That way you can still grab the stick and override what the autopilot is doing. To see the effect in the game, put a plane on the runway, and make sure SAS is off. then notice how the little PITCH slider moves when you press S and W, and how it moves back to the center when you let go. Now hold "ALT" and "S" for about 10 seconds, and then try S and W again (without the ALT). Notice that the location the pitch control centers to is no longer in the middle. Now it's a bit above the center. That's the effect of trim. In game you can fiddle with trim using ALT+W,A,S,D,Q,E, but often players don't see it because turning on SAS overrides it, making it hard to both trim and use SAS (which I find annoying a bit, when SAS doesn't hold the nose up but I want it on for its help with the other levelings).

http://ksp-kos.github.io/KOS_DOC/structure/control/index.html#pilot-commands

No idea, but I can say that this is wrong: print round(vo-v). Because the round function takes 2 arguments. You're missing the second one that says what digit to round to. That might cause a problem?

There's still a bug with the local filesystems. Files are saved but what you get back when you reload them has mangled the spaces and end-of-lines. I've fixed it but I'm reluctant to issue the fix and up the rev number for just one single fix, and would rather wait to incorporate more stuff into it. If you need the fix immediately let me know and I might reconsider.

I was keeping mostly out of the steering code and leaving it up to erendrake, but he may be out for a while so I might look at it. But I don't think it's realistic to expect anything in "just a few days".

@erendrake gave me permissions to issue a bugfix while he's away, so here it is: Bug fix is NOT on curse yet, because I don't think his attempt to give me co-author permissions took hold. At any rate I don't seem to be allowed to update it on curse. However, it is on Github and Kerbalstuff. v0.15.3 BugFixes: * Issue #417: No error message on nonexistent function. * Issue #413: Name tag window should get keyboard focus when invoked. * Issue #405: Equality operator is broken for Wrapped structure objects. * Issue #393: Files on local volume do not persist through save/load. The last issue is the important one. #393. It should fix the "zero size" files on the local volumes when you save the game. I have another update with what I think are very useful features to help with dealing with Directions, but as those are not bug fixes but new features, I held off on including them in this update.

kOS doesn't have any special cases to handle the fact that FAR breaks parts of the KSP API. kOS is just currently returning the stock game's notion of terminal velocity. In general there should be external chunks of code to make kOS work with other mods that can be updated by other modders easily enough. I.E. a way to let other modders write kOS function calls that kOS scripts can use. In the meantime there is the ability to read things on a PartModule's fields, but not necessarily everything every other mod calculates. It's accurate as of kOS 0.15.2, just a week ago.

Let's say you have this when-trigger right now: when whateverCondition then { dostuff. PRESERVE. }. And you'd like to change it into one in which it has a 3 second cooldown time before it can trigger again. Then edit it to be this instead: set coolDownMark to 0. when TIME:SECONDS > coolDownMark and whateverCondition then { set coolDownMark to TIME:SECONDS + 3. dostuff. PRESERVE. }.

Terminology error: You're not using the word SAS correctly. Not only does LOCK STEERING not require SAS, but rather just the opposite. It doesn't even work *at all* with SAS. You say "SAS" when I think you mean "torque wheels". They are not the same thing because SAS is still called SAS regardless of the mechanism it uses. It's still called SAS even when it's using monopropellant fuel to accomplish it. "SAS" refers to the *mode* you toggle with the "T" key, not the hardware that mode makes use of. It could be the case that LOCK STEERING doesn't work properly without torque wheels, but if so it's very very weird that it doesn't, because all LOCK searing does is take control over the "stick and rudder", overriding the player's WASDQE controls with its own. In other words when LOCK steering wants to pull up a bit, all LOCK STEERING DOES is tell KSP "set the yoke to 50% back" and leaves it up to KSP to decide whether that means to use torque wheels or RCS or both. I haven't had my hands down in that code for a while. I didn't write it and have pretty much left it alone as a black box. The only thing I think it might be is that in order to decide how to set the controls it seems to be asking the KSP API for some information about the vessel's rotational forces and that API might be only taking into account torque wheels. If so, the math would get very wonky indeed as it would end up dividing things by nearly zero values.