Stoney3K

That definitely has to do with the cube struts which are known to cause issues on time warp. As an alternative to the Docking Port Sr., for those cases I use a set of flat 2,5m-1,25m adapters with a regular docking port, and attach the strut end points on the adapter plate in 4-way symmetry. Easy to attach when on EVA and rock solid.

^^^This. Already working on such a thing, having a set of interchangeable engine bodies and nozzles which just provide a "CompressedAir" resource, that is expelled through the nozzle you can attach wherever you want. This would be similar to real jet engines which can have air ducts and other plumbing to redirect the air flow if necessary. It also allows you to close exhaust nozzles as well as intakes, so for low altitude flight, you could have a high-flow, low-pressure nozzle, and when you're supersonic, those exhausts are closed and the high-pressure exhaust opened, which is more efficient at high altitude. The nozzle only defines Isp, not mass flow. Jet-powered RCS ("puffer ducts") and re-using the same engine core for both VTOL and horizontal flight is also a possibility then.

Noticed the same thing. Mk3 space plane with Mk2 side tanks and utility/cargo bays, causes uneven drag even though the tanks and bays are exactly identical. Ultimately this leads to the ship yawing to one side and losing control when supersonic. I noticed the phantom lift issue as well, which would cause a similar problem on the roll axis.

OK, different but related question: Which wings does everyone use for their SSTOs? I found the big airliner wings to be too draggy, even though they have massive lift. Shuttle wings are better, but you need quite a lot of them if you want to get a 100+ ton plane off the ground and up to some decent speed.

In most cases with those keyboards, hit 'Fn + ESC' to enable 'Fn-Lock' which switches the keyboard mode back to normal until you turn it back off or reboot.

I think you may be 'stuck' thinking in single-ended voltages here. All of your voltages are with respect to ground, but since op-amps are differential, you can have these voltages to any "zero" reference level you may want. If your op-amp has an inverting input at 2,5V and a non-inverting input at 2,5V, it will output zero. Put the non-inverting input at 0V, and it will output -2,5V, multiplied by the op-amp's gain. (The power supply to your op-amp needs to be symmetrical, of course.) For the 400Hz excitation sine wave signal, you don't need a fancy waveform generator. Just a pulse generator is more than enough, meaning you can switch the gain of all of your amplifiers between 1 and -1 with a 400Hz pulse. All you need from there is an RC filter (or RL filter, since it's a current-controlled device) to enable some low-pass filtering. In your first example, the absolute output of A would be 0V, but its gain would be -1, which is correct if your synchro is pointing all the way up, since the excitation and coil currents are in opposing phases, they will attract with maximum force. The gains for coils B and C are directly related to the gain of the A coil, since these are part of the same cycle, only shifted 120 degrees out of rotation. Therefore you only need a single look-up table which contains sine values from zero to 360, to get coil A gain, you index the table directly, to get B gain, you use the angle + 120, and for coil C, you use the angle + 240, taking wrap-arounds into account. This is no different from driving an AC synchronous or asynchronous motor - an AC synchronous motor is identical to a synchro, with a static field (DC) excitation. A synchro has an AC excitation in the rotor, which is more beneficial for holding a position instead of rotating at high speed. If you want to go the *really* easy route, you can generate the excitation and the gain waveform in one go. To do that, you need to switch the index of your look-up table by 180 degrees (or use a separate lookup table for the 'high' and 'low' levels) every half-cycle of 400Hz. As an alternative to that, you can also multiply the value you looked up by -1 if you are in the far 'low' half of your 400Hz cycle. The whole she-bang of looking up and transmitting over I2C can be done at an interrupt. Damn, now I want my own synchro dial indicators to play with and test it out.

Is it still unstable if you only try to lift up vertically and not apply any cyclic (tilt)? You could do that by angling the wings a little more in the VAB so you have more collective pitch. It looks like your wobble starts when you move the craft out of its plane of rotation to move forward, which causes a lot of stress on the joints where the wings are attached. This causes the wings to flex, which results in your instability. From the looks of it, the physics is correct. You need to swivel your rotor axis to move, not apply torque to it with a reaction wheel.

Yes. The output polarity does not neccesarily have to be with respect to ground, if your final amplifier stage is differential. You can have a 2,5V bias on one input of the amplifier and a 0-5V voltage swing on the other, resulting in a -2,5V output when the DAC is set to zero. For the output voltage to read zero, you need the DAC to be at exactly 50% of full scale input. Most DACs support this built-in and some can even understand negative numbers coded in two's complement (signed) integers. If you have your DAC board already assembled, you may be better off programming the DAC board as a 'dumb' slave which accepts 9 gain numbers over the serial link, and do all of the arithmetic on a remote controller. With a decent refresh rate (50Hz), you need at most 18 bytes per data cycle, or 7200 bits per second of data transfer rate, which is well in the range of AVRs.

This. Please.

Why does it have to be a Vernor block? I mean, we've got massive Monopropellant tanks in the Mk3 spaceplane series, but there are no huge Monoprop-gulping RCS blocks that provide a comparatively massive thrust, just the teensy blocks and RCS ports. The only thing we'd need is a bigger RCS block that is in all other ways the same as the one we already have.

I had a re-check there and found out that synchros are actually 3-phase synchronous motors, which have a wound rotor (instead of a permanent magnet one). Usually the rotor is excited with DC to make it work like a motor or generator, like in your car alternator, but when the rotor is excited with AC, the output voltage on each winding is proportional to the rotor position. Your approach with a look-up table seems to be OK with that. As an alternative, you can use a DAC with higher resolution (like the Microchip MCP4921/4922 series) or use a separate DAC to create the reference voltage for the first DAC set. In that case, the easiest approach would be to generate the reference sine wave with a single I2C DAC, and use that sine-wave voltage as the reference voltages for the other DACs, which only output a static gain which you can easily fetch from your look-up table. This takes a lot less processing power than looking up the sine wave and multiplying it for each synchro coil output. The chained DAC approach is described in more detail in application notes from the various DACs, basically you just hook the output of one DAC to the reference input of your other DACs.

I've had crashes on scene changes when my disk where KSP was installed was full. In that case, KSP is unable to write to the auto-save file which causes it to crash.

Just enable "Display Aerodynamic Data in Action Menus" on the ALT+F12 screen and right-click the intake. The drag number (in kN) is displayed there. Opening or closing that intake makes zero difference on the part drag. *If* there is drag from the intake flow, it's an induced drag force that is calculated in a different subsystem and not added to the "total" part drag.

Nice and clean looking panels, do you have your own laser cutting machine or do you get that done at a Fablab? Regarding the trig calculations: Those synchros work on a phase difference, right? Doing trig calculations *in* the AVR is slooooooow, so you really don't want to do that. If you can find a way to precalculate the phase shift for each indicator synchro you want (AFAIK, they're linear with pitch/roll/yaw), you can just pull them out of a look-up table if the table has sufficient resolution. Small tip: Use multiples of 120 degrees to calculate the look-up values to begin with, so you only need to look up a total of three values, and find the rest of the accompanying synchros by simply skipping 120 degrees in the table. So for example, have a table that has 7200 entries, and for a synchro reading zero, the first coil would get a DAC value at entry 0, the second at entry 2400, and the third at 4800. That saves you memory and calculations because you only need one table which is the same for every synchro (including the reference one). I can cook up some AVR/Arduino code that does this for three values easily, it's only a few dozen lines of code.

If you want to go the spherical display route, you would only need a hemisphere since you can't see the back of your navball anyway. Get a frosted plastic or glass hemisphere and a pico projector and you're pretty much done. But frankly, this would replicate the look of ancient oscilloscope-style CRT displays more than it would look like a mechanical ball, might still be neat for other instruments or camera views.

The forces are still calculated but they are calculated as if the 'physicsless' part was part of its parent. So if the physicsless part has a drag coefficient, that is added to the parent's drag coefficient and the parent drag is calculated from that. Correct me if I'm wrong on that...

Your center of thrust is offset, that's what causes the flip. Angle your thrust so the arrow is pointing through the center of mass.

That would mean you need to make 20 laps of takeoff, transfer, landing, mining, takeoff, return to Kerbin, re-entry, land on Kerbin and take off again. IN A SINGLE GAME SESSION. I suspect my girlfriend will call the mental health department by the time I reach lap number 3, because I need sleep... OTOH, KSP would have crashed before you reach a good handful of laps anyway. Re. part clipping: I will only clip parts because of cosmetics. If a part doesn't fit where I want it to go, clipping is cheating and asking for bugs.

Lift varies with speed and wing angle of attack. When your plane is properly balanced and a wing generates more lift, it will pitch up, leading to more drag and reducing speed. This eventually ends up in an equilibrium where thrust, drag, weight and lift are balanced. If you back off the thrust, drag will win, slowing the plane down, thereby reducing lift and dropping the nose, which will *reduce* drag and estabilish a new airspeed. Conversely, with more thrust, your plane will speed up and raise the nose by itself to maintain that equilibrium. A common saying in real aviation is, that pitch attitude determines your airspeed, and thrust determines your rate of climb or descent. If you trim to maintain a pre-set attitude, your airspeed will stay constant, and more or less thrust means the plane will climb or descend. At least, that's how it works in the real world with proper aerodynamics. Your mileage may vary in KSP, but a high TWR only means a lightning fast climb rate. Low TWR means slow climb and shallow angle of attack, but since that means you spend longer in the higher atmosphere to accelerate to hypersonic speeds, it would have a positive effect for an SSTO.

I still think the current pad/runway weight limits should be sufficient if they are maintained at game time. If landing an object that is too heavy already explodes the pad/runway as it is now, it would also happen if you try to launch something empty and re-fuel it to exceed the weight limit. Somewhere, the idea of fueling a rocket and failing miserably in a dramatic explosion because the launch pad collapses underneath you really sounds like a very Kerbal option to me. Implementation wise, you could just have a static fuel tank on the pad that you can interact with if your craft is landed and nearby enough, so you can ALT+right click on the tank and transfer fuel in like with any other tank.

They would just cease to be modeled as parts -- the cargo bay would be modeled as a lumped solid if it (and all connected bays) were closed. The parts would only spawn when the cargo bay doors are opened. This has the implication of all of the parts being unusable when the doors are closed (which is really annoying for fuel cells, batteries, monoprop tanks, etc.) but it would prevent physics from rattling the parts around in the bay. I don't think it would matter much performance wise because the reduction in part count is marginal, unless you haul a 150-part station core up in your SSTO.

Backlight looks good. You could look into replacing the paper decals with a transparency, which blocks more light in the dark areas and has a more uniform color transmission in the back-lit areas.

I guess, with those prices, you're better off buying a 2-buck China toggle switch and get the tabs 3D printed.

The point is that there is no way to find out numeric data on your drag numbers or even the center of drag in KSP. So when it comes to drag (as well as body lift), you just need to wing it and hope your numbers are in the ballpark. All you can do is guesstimate from the length of the arrows in the F12 overlay. We could really use an improvement on KER to show the amount of drag along with the lift, weight and thrust numbers. It would mean we can tweak our SSTO's in a more structured manner. Also, when it comes to MechJeb, having a feature that holds either a pre-set airspeed (and adjusting pitch/vertical speed to match) or a pre-set vertical speed (and adjusting pitch/airspeed to match) would be *really* helpful for SSTO pilots.

I think the more simple solution would be just to be able to launch plain Kerbals from either the pad or the runway. That should be very simple to add, since a Kerbal is already a controllable object.