Crzyrndm

Fairly sure it doesn't (and shouldn't) reduce drag. An open intake is a restriction on airflow, a closed one is a blockage. The only real reason to close air intakes is to exploit the instant jet throttling to prevent any imbalances in thrust from occuring.

It takes a bit to unlearn the "I can always rely on RW's for torque" and treat them as having a fuel of sorts (albeit one that is massless and slowly recharges over time...). If the recharge rate was too high it would spoil the effect. *sigh* ...I fixed that. Then I broke things and had to revert. Now I need to fix it again... */sigh*

To be fair, that's exactly the kind of impact the change was designed to have (Reaction wheels aren't intended to be used to apply a constant torque in one direction, but for small corrections in orientation). There are a few ways to keep RW's from saturating early: Disabling torque when in the lower atmosphere. The impact is minor compared to the authority you get from gimballing and control surfaces on most rockets Roll 180 degrees and desaturate for the same action (somewhat, your change in direction will mean it won't eliminate everything) Let gravity do the turning for you (ie. gravity turn rather than forcing it through) For providing a constant torque regardless of flight situation, RCS

Er, good point. Basic jets would probably work best going for a vertical ascent anyway (assuming the plane is small enough for >1.0 TWR) since they have more thrust the slower you are moving. Makes wings area irrelevant

He looks to be limited to basic jets, so T4 or T5? Using basic jets also means he's going to be flying at ~400-500m/s, so he'll also want a fair bit more wing than is normal for high altitude flight to keep the AoA reasonable (lift is ~v^2, but only linear with area IIRC) and probably will have a notable impact on intake efficiency

Not quite sure what your picture is trying to convey. I rebuilt the plane to try and make it a little more structurally sound (plus a few other improvements). I can consistently get it off the ground now without it imploding which is a good start (Although I do keep clipping the rocket, which is less nice...). Short version is more wing, less control surfaces (what's there seems to be enough), and a big tail. EDIT Fixed link derp

Sounds like you have a particularly long trip to make, so maybe I was being a bit quick there. If you have already flown in the general vicinity a few times, you'd have the best idea of how much is required. Do you really need to come back all the way back though? PS I just built a replica for testing. Moving the gear in (reduces torque on wings which was causing some "fun") and forward meant I could take off if I was careful about how fast the nose came up. The biggest issue I had with it is structural stability. Those side tanks are a complete nightmare attached as they are without any struts (not a huge issue in the air, but on the ground...)

Ok, so v1.3 is up. The only change is in how available torque is calculated, it keeps the vector direction and scales it properly, which stops it oversaturating and wreaking havoc when I try and add things. There are a few "odd" things you may notice about this 1) Delay in torque decay If you aren't perfectly aligned with the reference axis, there will be a period where torque will not decrease. *excuse my terrible paint drawing* Blue line is the torque you are requesting of the x axis, vertical red line is the torque that the x axis could provide at it's current saturation. The remainder is the torque available to the other two axes that is currently unutilised (or will be once I get to that) 2) Multi-axis torque decay If you partially saturate an axis and aren't perfectly aligned with it, the other axes may have to reduce their output to retain the torque direction you wanted depending on your alignment

@enceos Always nice to hear people appreciates my efforts On another note:If you're looking for something more advanced/configurable, this looks to have it well and truly covered (or will after the dev updates to include a few suggestions I made based on Analog Control).

Rear landing gear look like it may not be aligned with the direction of travel. If they aren't straight, they will flex and can cause all sorts of mischief Rear landing gear also looks to be a long way back. How close are they to the CoM? It will take a lot to rotate if there is significant seperation. Rear landing gear looks to be lower than the front. This will pitch the craft down on the runway and force it into the ground. You want to reverse that. That's an awful lot of jet fuel (3 tanks per basic jet). You can almost certainly drop that down to a single tank (each for structural purposes) and probably remove about half the fuel and still get to most places. If problems persist: A side on screenshot with CoM and CoL indicators showing would be helpful A screenshot of the stability analysis (the one with all the numbers) run with 0km altitude and 0.35mach would also be helpful

So, my apologies to Tuareg over this, I didn't ignore anything you said, but I struggle to understand just from theory. I have to be able to visualise it to understand it and that typically means breaking it down to it's base elements (conservation of rotational momentum in this case). This wasis my major sticking point. For Tuareg's position to be correct, I hadhave to be making an incorrect assumption about this situation: When I was thinking of this, I seem to have been observing it from the reference frame of the body *which was rotating* while considering the ang. momentum of the blocks (I feel like an idiot for missing that) When the block on the end of the arm is spun up, in the frame of the body it has the same ang. velocity and hence momentum as the central block. However, in a stationary reference frame, the motion of the body is counter to that of the wheels and that decreases it's apparent spin velocity proportional to the distance it orbits at. As the orbital distance of the wheel is reduced, it's apparent spin velocity increases. The block moving out experiences no change in ang. velocity and thus the ang. velocity of the body must also increase to again balance ang. momentum. Thus angular momentum is conserved by a torque not acting at the center of mass causing a slower rotation of the body in free space. Atleast, that makes sense to me. Could always be barking up the wrong tree again (I feel like I'm still missing something, what I have no clue...) Doesn't make sense in the morning:sealed:, wheel spin rate has to be constant in any position on the rotating body and any position on the body has the same counter spin rate. I'm lost in the middle somewhere. I have a feeling Tuareg's position is the correct one, but I cannot rationalise it. My apologies once again to Tuareg for any offense I may have caused, it was not intended. I may have been somewhat frustrated at the inability to reach a consensus in a field that I consider to be about as black and white as you can get, but I shouldn't have let that have an on effect my discussion.

A) More pitch control authority. Canards up front, move tail back, use the deep/short control surface on the tail, add canards to the side of the tail, etc. Check the FAR static analysis @<0km/mach 0.35>. That will tell you how much AoA you require to take off. If you can't get that angle without tailstrike, you need more wing. Nothing else to it.

Programming 101: If it's not working at all, it's something small and you always feel silly when you find it (case in point)

Is part case sensitive? Your working example has it all in caps

Nada, had a quick go at it last night when I found it, but I'd already been trying to work out why it was over-saturating for about 2 hours at that point and the solution doesn't strike me as a simple one. I think I know *how* to solve it in theory (project available torque vectors and requested torque unit vector onto worldspace axes, find ratio of available torque to requested torque unit vector for all axes, scale torque unit vector by the smallest ratio, and then project back onto vessel axes) but the math just didn't want to behave.

Text file is *.cfg? Maybe a parsing issue with the PART open brace ({) not being on it's own line? (I'm just guessing here, don't know how KSP/MM handles this) Also, search the MM cache (can be opened in any text editor) and see what the final config actually looks like.

Quoted values are somewhat out of date, current version should be something like 900 science for the same contract at maximum commitment (conversion rate of 0.2-0.14% depending on commitment) E: Note to self: 0.90 makes funds scarce, need to play with the numbers to compensate for that Er, did I bundle miniAVC it with this? It's been a while... (Assuming I did, I should probably check the version...) If you don't want the functionality, just decline when it asks. I don't see any reason not to include it.

Or MS Flight Simulator's mouse yoke, or w/e X-Plane/Prepar3d calls it. Mouse control systems are fairly common in Flight Sim's On another note, it just occured to me that the settings file is probably (I can't test right now...) being read from disc every time you enter the flight scene. If you want to play around with the config, you should be able to just jump out to the space center, make your changes, and them jump back into flying/driving a plane/rocket/rover. RE: Improving activation How about enter "arm"s the system (giving you the GUI), while a mouse click unpauses/pauses control (with paused control holding the current input, probably drawing a red dot or something to indicate where that is)

How about a delay where the GUI shows up but the mouse is not yet used for control (or maybe enter once: GUI, twice: control, third time: off with a timeout of 5-10s on the first-> second stage transition) Rover: are the wheels turning at all? That sort of sounds like all turning is being done by reaction wheels or something of the sort. I'll have a poke around Settings: Numbers are just plucked out as they are from the code. I can certainly reformat them if there is a consensus as to what is appropriate. Deadzone I'm not particularly concerned about, but I much prefer absolute coordinates (because as you mention previously, the center of the screen isn't exactly marked), although maybe a percentage of screen width/height would work better.

No SDK as such, you just need a program capable of compiling C# (Visual Studio, Monodevelop, Sharpdevelop) for plugins. See links on this page for getting started.

The second number in the bleed rate keys is the % of average torque (for now. I intend to get it based on the axis torque and alignment shortly. Average was a simplification to help get the foundations done) recovered per second (the first number is the % saturation) this would be 1/4 of the current rate bleedRate { key = 0 0.0125 0 0 key = 1 0.0125 0 0 } EDIT And while digging round to find the source of a nullref, I have realised that there is a massive oversight in how available torque is being calculated (it's not reducing enough) because I forgot to keep the torques in balance (because direction). Gigantic *doh* moment right there...

All current numbers are fairly arbitrary. Any feedback on what reasonable "middle of the road" values are is much appreciated though E: For reference, saturation limit (1000%) and recovery rate (constant 5%) in the release make for 200 seconds to completely recover from full saturation

Alright, v1.2 Available Torque is now using a float curve for configurable torque/momentum relationship Bleed rate is now using a float curve for configurable decay/momentum relationship Part forcibly activated (*attempt 2*) Logging dump once per second to aid debugging with minimal impact on game performance/stability note: don't use torque curve for reducing the torque a wheel is capable of. Other mods won't be able to see this in the VAB

Needs plugin code, but it's only a few lines per module you want to apply this to. // spitballing code here. Results may vary public class newmodule : oldModule { // if effect is physics related public override void OnFixedUpdate { if (this.vessel.isLanded) base.OnFixedUpdate(); } // else public override void OnUpdate { if (this.vessel.isLanded) base.OnUpdate(); } } and then a Module Manager patch to replace "oldModule" with "newModule"

Yup, just wait for an update please. It shouldn't be too long now that I finally worked out the floatcurve issue