impyre

Yep. Since I'm using NEAR the drag is a little different (it probably costs me more to stray too far from current airspeed vector), which causes me to favor gradual turns. But negating the effects of increased drag due to AoA, simple angular turns are a fairly good approximation if executed at the proper altitudes/speeds.

Glad I could help! I couldn't find a page on the kOS documentation site with an example to link, but I knew I remembered reading about it somewhere. As for the reality thing, maybe someone will build a mod that will create a dynamic atmosphere that can toss you off course if you aren't careful. Personally, I doubt I'd use it... but who knows. Edit: What I've been attempting to do is develop a more robust script similar to what Steve Mading uses in his youtube videos. However, I was trying to use something a bit more... efficient than the square root function. It seems that the root function is a pretty robust and efficient solution for being relatively simpler (as far as I can tell)... the OCD side of me wants something closer to the optimal trajectory, but it's incredibly difficult to represent mathematically.

It sounds like you want ship:velocity:surface:direction, if I'm not mistaken that usually works for anything that can return a vector, and instead returns a euler direction in the form of r(#,#,#). Of course, you lose any magnitude data with that, but it seems like the most direct route.

It seems right to me. What's most important to notice is the axes orientations relative to each other. I believe this is a left-hand-rule system, which is common in games. What you must remember is that "up" isn't always what you think it should be, and that these vectors represent the absolute x, y, and z directions free of any particular reference (that i'm aware of). If you do a time warp for a bit, then stop and check the orientation of the vectors, I think you'll find that the axes appear to rotate (but it's actually your ship that's rotating due to movement on the planet's surface)... there should be at least four points where the axes "look more right" with either the red or blue lining up with your ship's alignment. Edit: If you want to create something like this that is oriented correctly with your ship, you could store ship:facing:vector in some variable, directionvector for example, then create three vectors just as you've done here, but instead of setting x to 1, you'd set it to directionvector:x. It'd look like v(directionvector:x,0,0). If you did that for each other axis, you'd have something that would look exactly like you expect it to. Edit2: at about 5 minutes in he does the same thing you're trying to do here (with the same code). You can also see how the positioning makes more sense while in orbit.

Thanks, that's really helpful. As for the whole documentation thing, I just assumed I was not typing something correctly lol... but I couldn't find anywhere that showed me how to actually access the sensors. As for what i was trying to do, a text readout would be just fine by me... I'm building a datarecorder script that logs altitude, current TWR (since there seems to be no good way to read throttle position) as g-force + 1, and pitch into a csv... then I feed that data into a graphing utility afterward so that I can look at/analyze trajectory and compare different trajectory/thrust profiles to their related efficiencies to get a better idea of what works best for different vehicles with the mods i have currently set up. EDIT: The sensor vs. sensors was what was getting to me, i had put a accelerometer on my craft and was trying to have kOS read from it lol. The ship:sensors:acc is much better for what I want to do. Thanks again. (btw, love your kOS videos... they are the reason I downloaded this mod)

It was already answered, but from what I understand, what he was looking for was a way to query how many seconds *behind* the vessel the apoapsis is at a given moment. IE: I want to go to apoapsis, wait an amount of time (so that I'm coming back down), and then do something... so I know how long after apoapsis I want to wait, but I need to know how long it's been since apoapsis to compare the two. (kinda like how when you pass maneuver nodes it switches from T-"some time" to T+"some time". He was looking for a T+"some time" for his apoapsis.) Personally it seems like it would've been much simpler to just set a timer while at apoapsis and wait the specified amount of time (rather than constantly reading apoapsis eta and orbital periods, which seem like they might be computationally expensive) especially since (regardless of apoapsis eta and orbital period measurements) time is really what you're wanting to measure.

i like this mod, but the documentation seems out of date (even on the "newer" documentation). Do sensors work? I can't seem to get [print ship:sensors:acc:readout.] to do anything, and attempting to print without the readout just gives what I assume is the part's location/orientation.... also the sensor dump example doesn't work as shown (not to mention that it seems silly to use a list if you only need data from one sensor).

Another way (unless this is what you're talking about) is to break the code up sequentially, and have two successive sequences loaded simultaneously, then just add a couple lines that erase the last unused section and then upload the next section all at the beginning of the section in use. To minimize (theoretical and/or actual) load times you could also isolate the routines that are used by most or all sequences and simply keep them loaded from the beginning (although that might increase the memory overhead a bit).

^What he said. The only reason I'm not using this yet is that reason. I can't deal with stock aero in ksp, but FAR is a bit more than I'm willing to fuss with... so NEAR is perfect. If this gets NEAR support, I'll definitely be using it.

There are a couple other pieces of advice I can offer that may or may not be immediately obvious. First, respect the CoM. The CoM will shift during flight, and there's nothing you can really do about that... (unless you're flying something really well balanced with fuel located at CoM) but there are a few steps you can take to mitigate it's effects on your craft. A) Place RCS blocks as far from center of mass as possible, since the torque produced by RCS acts on CoM, any force due to misalignment will be related to the ratio between the two different distances from CoM to the related ends being turned activated... and by maximizing distance between RCS blocks and CoM, you will bring that ratio closer to 1 and decrease the effects of being unbalanced. You can also help by configuring RCS while viewing CoM with fuel tanks set at half-used (for a single stack of two tanks, this generally means the top tank will be empty, and the bottom one will be full). You may notice that this relocates the CoM considerably, and will represent the "average" CoM... This means that however much fuel you've used, you're more likely to be close to the balance point (rather than if you start at it and just get further away as you use more fuel). Depending on how you use this vehicle, you may want to configure RCS to specific fuel profiles (IE: a one-time lander that should return and dock with orbiter with nearly no fuel, etc.) Secondly, don't use more RCS than necessary. Too much thrust from RCS can cause the thing to be jumpy and make it much harder to correct for imbalanced thrust. If you use as little thrust as possible, you can usually manually correct for all but the most unbalanced vessels.

Everything I've read and understand about the math agrees with the concept that it cannot be analytically tackled, what math suggests that you should wait until 34km to turn? Also, does this account for KSP's lacking aerodynamics? As far as I can tell, the whole issue can be summarized by looking at the amount of potential work done against the vessel by different components, namely atmospheric drag, gravity drag, and inefficient fuel usage. Since I use NEAR to provide enhanced aerodynamic simulation, atmospheric drag also has a component related to the vehicle's AoA (which adds another level of complexity)... but even without it one can see that it takes a lot of work to change the velocity vector from pointing nearly at the horizon to straight up, so it seems like you should point as prograde as possible as early as possible... at least after a balance point (where the savings in fuel efficiency are offset by additional costs incurred from staying in the atmosphere longer), although good aerodynamics can allow lift to offset the penalty for turning earlier and may in fact provide an incentive to do so. I've been working on this problem for awhile, and what I'm seeing is that the tipping point is actually about 24km... and if you assume a smooth turn is better than an impulsive turn (which it usually is [at least with decent aerodynamics]) then depending on velocity and rate of turn, it could be completely reasonable to begin a slow steady turn at about 10-12km, be at the 45 degree point at about 24km, and then horizontal by 34-36km. This seems to be in line with what i've noticed in-game; however, I must admit that I doubt a truly constant turn rate results in the absolute best result... based on the exponential nature of the atmosphere, I imagine it's probably something that looks more like a turn which begins gradually, but picks up speed as you gain altitude and then slams on brakes when you are horizontal... though I have nothing that mathematically supports this.

I suppose I'll have to try it out. Thanks for the response.

I'm thinking about maybe adding this mod to my repertoire, but I'm on the fence. Mainly, I'm concerned that this mod will make the Sol system much more readily accessible. Part of the allure (for me) is that these distant places can be so hard to get to. Won't it take some of the fun out? What is the balancer to keep me from just installing launchpads everywhere? You mentioned the economy breaking, and possibly preventing that by changing configs... if you change the configs, does it change the way EL plays in a drastic way?

Well... it seems that while I was accusing you of doubting my competency... I forgot to check it myself first. It was really awesome of you to not only continue to help me, but also stay patient in spite of me being a jerk. Thank you for your help and time. Sorry for being lame.

Okay, I'm going to try again. I'll let you know what happens.

I'm having the same problem with the map not actually showing the resources. The settings to show karbonite are available, and the scanner does indeed work as a SCANsat sensor, but under sensors it lists no data while scanning. It's almost as if the scanner isn't configured properly. I'm still trying to figure out what the cause is.

using MM 2.2.1

On that note, I was unable to get this working with an old save (after removing FF) without first stripping all the FF stuff from the save manually (I also deleted old map info just in case).

Look man, I downloaded off the dev rc4 link... unless he linked the wrong file... I've listed it accurately. If you truly doubt my sincerity or competency, you're more than welcome to try for yourself and post your results. EDIT: I just realized you said "mislabeled by the user"... I never said *I* mislabeled it... I said it was mislabeled... as in the dev hasn't updated the version numbers in the mod itself, it also reports the wrong version in-game as well. EDIT2: When I called it version 7 rc 4, I use that version because it's how it was listed by the dev in the link, not because that's the version on any of the files.

It's mislabeled for some reason... it is indeed the latest version. In fact, today is the first time I ever downloaded it. EDIT: in case you were wondering... it does indeed work with FF uninstalled... as I mentioned. Including the ORS scanning feature (well, it's present, but not working as expected... I suspect that's an issue related to my karbonite install though.)

I came across a very obscure bug and it crashed the game. Here's the deal, when using scansat v7 rc4 alongside FinalFrontier 0.5.6 (and 0.5.1, i checked if updating FF would fix it, but it doesn't). I did a couple tests: FF 0.5.1 + SCANsat7 rc4 = crash FF 0.5.1 without SCANsat = fine SCANsat7 rc4 without FF = fine FF 0.5.1 + SCANsat 6.1 = fine All tests were performed on pre-existing saves and new games (career mode) with exact same results. All tests were also repeated once I updated FF from 0.5.1 to 0.5.6, again with the same results. Link to error info: https://www.dropbox.com/s/5zt4mwel3h1s382/error%20info.zip As a bit of additional info, I'm running the latest x64 version of KSP on a windows 7 machine. I'm by no means a coder, but I saw in the error log that the last thing going on before the crash was that FF was trying to draw its icons so I figured that the problem was something to do with FF, and the only thing I'd changed was upgrading SCANsat6.1 to dev version 7 rc 4 (due to realizing that it was the version required for the SCANsat integration with karbonite).

The magnetic docking ports are quite weak... and rightly so when you consider how heavy these vessels are. If we're talking realism here, magnetic docking alone would never work, you'd need something that will physically lock in place. That said, the optimal approach speed is .2 or .3m/s... or as close to zero as you can get it. Consider that the key thing here is momentum... the magnetic docking ports have a limited range over which they can act, and a limited force/torque they can exert... which means they can do limited work to negate momentum. As momentum is speed*mass, you can see how those numbers can get big fast with a ship that weighs several thousand kilograms (at least). There are two "fast" ways to dock: Get a speed near .1 or .2m/s, and use phys warp to close the distance from 8-10m until about 1-2m (which could prove dangerous)... OR approach at .8-1m/s and then slow down as you get closer(which could also prove dangerous). Which approach you use may depend in part on your ship design. If you have too little or too much thrust, trying to adjust velocities at the last second is probably unwise, so physwarp may be a better option; however, if your ship has optimal thrust for its weight, adjusting velocity at the same time may offer better control. Bear in mind that you can use "fine control" mode to help keep you from over-correcting if you have "too much" thrust. EDIT: Another thing to keep in mind is that due to moment of inertia, torques applied at odd angles have much less effect on longer objects (namely, rockets). So docking ports will be much less effective if the angle isn't *exact*. Combining this with high-speed approaches often leads to failed attempts. I'd recommend some docking port alignment indicator mod. There are two that I've used, one which uses the navball and one which uses a popup window. Both are excellent and helpful for docking, I'll never dock without at least one of them again. This allows you to get your alignment perfect, then coast in at the desired velocity.

It shouldn't spawn inflated. What mods are you using?

One of the things I love about these is the stack-ability of them. Though the engine doesn't snap on a stack (so alignment is difficult), they can be aligned with some effort... and once aligned I generally just pop 4 or 5 on, and then decouple with action groups like an emergency pez dispenser. This is ideal for rescuing kerbals as popping a pod off the front doesn't wreck symmetry, thus the ship is still maneuverable enough to go and rescue more kerbals.

I really like the idea of this, and I've tried using it several times; however, it does not play nicely with deadly reentry + NEAR at all. It seems to have very little drag, flips around backwards every time, and the chute never fails to kill my kerbals from excessive g-force (because I'm still going 2300m/s and picking up speed at 15km altitude). If you're wondering "wow, what kind of reentry trajectory is this guy on???", it's pretty standard... apoapsis around 100km and periapsis around 40km. I let drag lower apoapsis until I'm suborbital. However, with the derp pods, I find myself having to do a retro-burn just to keep from flying out of the atmosphere. Not sure which particular mod could be said to be at fault here, but in general my realchutes seem to work fine.