m4ti140

It's "SPAAAAAAAAAAAAAAAAAAACE" personality core from Portal 2:

Not a good idea... I don't know how about others, but I can hardly run my game with either of these packs installed (lagging and crashing) while with both it runs out of memory everytime. And that's even with all the optimizations that have been made. I'd rather suggest including resized versions of stock engines and tanks (would only require including .cfgs in the mod) and requiring procedural wings and fairings, and stretchy tanks (though the last one may not be that good of an idea if you include modular fuel). Still looking for realistic (aviation>probes>manned) tree for stock game.

Guys, GUYS!!! SLOW DOWN!!! Could you at least consider just scaling Kerbolar system to reasonable sizes (aka everything x10) instead of turning it into Solar sytstem? I've seen voices about not only adjusting all parameters so each planet has exactly the same radius etc. as their RL Sol counterparts but also moving planets arround. But it is NOT Solar system, it's the Kerbolar system, the home of Kerbals. Unless someone develops "human mod" for KSP, I think scaling everthing up times ten, randomizing a tiny bit (bc perfect 6000km diameter is not believable but e.g 6129 is), tilting rotational axes randomly and adjusting orbital speeds/periods, rotational speeds and gravitational accelerations of planets so that they make sense for realistic densities is enough. When I saw the realitic kerbol system in add on development forum what I thought of was making Kerbol system reasonable not turning it into Sol. The problem with this game never was with Kerbals being in it but with ridicoulus body parameters, with e.g Kerbin having 600km diameter and at the same time having atmosphere and 1g on surface suggesting that it is made of dark mater or something.

It's from Firespiter not from B9, B9 just borrows it.

I'd suggest using kOS for this monster, you can code it to use "pitch schedule"

Good idea, although as some already pointed out - ideally there should be seperate experiment, called "probe analysis" or something, and IMO: 1. It should give less science than crew report. 2. It should have seperate science pool, so it doesn't exhaust the manned one. It should also exhaust faster. 3. It should only allow to transmit data, not store it. This way realistic tree mods (aircraft>probes>manned) would make more sense. It would also be nice to have a "sampling arm" part that would allow picking surface samples, at the same conditions as probe analysis - less science, transmit only, etc. - this would give "automated" rovers and landers some purpose.

May I suggest something? - Give flight recorders high crashTolerance, enabling them to survive catastrophes; black boxes are meant to be durable - just an immersion thing, but since crashing is an important part of gameplay in KSP, it would be fun to search for recorders around wrecks.

We can play Moonbase Alpha in KSP now!!! Aeiou!!

This movie makes me want a Kessler Syndrome implementation in KSP

Hmm... That started when I was 6 or 7... Remember the LEGO Space Port sets? I got the space shuttle set for Christmas and since I was always a perfectionist and I wanted to know everything about space travel imediately, next thing I got was a children's book about spaceflight... Then some more serious book followed... There is something special about space that draws me to it. Oddly enough, I have not learned the orbital mechanics until I discovered Orbiter. When I discovered KSP I was like "OMG!! An actual GAME, with proper newtonian physics!! THIS IS AWESOME!!!!"

Now we need flight data for Saitek X-52 Pro display.

So, a few pages ago I asked about pod lift, and since you told me it already works, today I tried to do some skip reentry, coming in from Mun. I am playing with both FAR nad DR. I was using 1-2 pod with 2.5m heatshield from DR designed specifically for this capsule. To get a correct angle at reenrtry I shifted CoM of 1-2 pod in part.cfg, using CoM offset command. During reentry it should work more less like this: where v is velocity vector and F is lift (or lift + drag bc I appearently suck at drawing, but you get the idea) vector. Insted it worked like this: And I got pushed harder to the ground instead of getting lifted. Oddly enogugh, when I inverted attitude (pointed heatshield towards space)... I got positive lift, and literally pulled up, allowing me to perform a skip reentry. This is exactly the oposite of how the capsule should behave during reentry. It appearently takes the plane, in which wings would be if one built an aircraft with 1-2 pod as root, as lift surface, instead of heatshield plane. As a result the vector of lift produced by pod during reentry is more less inverted - you get positive lift at negative AoA and vice versa.

Are you planning to add inertia dampers in future? I know that they are more 'fiction' than 'science' relative to alcubierre drive, but still...

Screenshots?

Yea, because look of the font is the most important... even if it spawns more issues than it's worth. I'm with Honey Fox on this one.

This is great. Finally an autopilot which will not get any hate from hardcores - mainly because it's hardcore itself. Not to mention that it gives 100% more possibilities than Mechjeb. I can write my own ascent autopilots for historical crafts. +1 I'm quite used to C++ syntax and since it's a very common programming language (in my country it's the first programming language you ever learn bc it's teached on IT in high schools)

LOL, science as a resource... "And the science gets done" now has a new meaning

Any chance for future compatibility with modular fuels?

http://onthefiringlines.com/wp-content/uploads/2012/06/GAU-8.jpg

The issue with TSAS/old ASAS is that it requires turning off and on to change attitude, which is annoying if you don't use MJ. And if you use MJ, there is a serious issue with TSAS that seems to have went unnoticed - Mechjeb doesn't recognize it as ASAS, and keeps it on all the time. If you don't disable TSAS using right click menu before launch, the shuttle will go straight up until SRB separation, messing up whole ascent, no matter how agressive gravity turn you set. IRL SRBs are separated when shuttle goes almost horizontal - otherwise gravity losses would be horrible because SSME has relatively low TWR. Funny thing is that MJ performs best without any ASAS unit installed, with its own input only. BTW, I'm gonna try finding the most realistic launch sequence for this shuttle and post it here. EDIT: As of going way down - old asas kept constant attitude in global refference frame instead of LV/LH. I dunno about the new one though . Whichever one you use though, if CoM isn't almost at CoL (or even behind), it won't keep attitude (actually attitude is on reentry is adjusted using CoM shift IRL), it will pitch back to 0 AoA, but it also won't be controllable on final - unless you drop fuel, which will turn you into a leaf if you drop more than 3/4 of tank (unless you use FAR). If I were to suggest some change to the mod - besides a probe pointed at OMS thrust vector - is shifting the whole COM backwards and adding monopropelant tank to the nose - that's how it is done IRL. Before EI nose tank is emptied to shift COM to the position required for 40* AoA (which shuttle kept during entire reentry, using bank to change sink rate). Now with a bit more gentle fuel drop part and TAC fuel balancer one would be able to adjust CoM before reentry (and after reentry drop the rest of fuel to shift CoM back forwards, to get controll).

TSAS is AFAIK the old ASAS, but it's tooglable. So, since it uses old ASAS logic it is still wobbly and wastes RCS. Unless it was updated by author. The new ASAS logic would work great on space shuttle, since it works like fly-by-wire on spaceplane - it helps with stability instead of locking the attitude (or rather - it keeps attitude unless pilot changes it). It would allow aerodynamically unstable CoM position, which is necessary to allow maintaining attitude at reentry, without making it impossible to land. TSAS is an outdated addon and old ASAS was useless, I never used it bc it tore my planes apart. Also SAS isn't system that deals with trust imbalance, it's the job of compensator plugin, which is AFAIK a bit broken in 0.20+, that's why it doesn't respond fast enough. Old one doesn't deal with thrust imbalance better. EDIT: About take-off and roll program - I suggest rotating whole shuttle in editor so that vertical stabliser points west. No, not east, I'm not suggesting eliminating roll program. Note that at liftoff shuttle drifts downward relative to the shuttle (in the direction of ET). That's because resultant thrust vector points there. If you set it ET-east on launchpad, you will get horizontal velocity pointing east right at the liftoff, so that after doing 180* roll you will fly in correct direction. If you leave the deffault VAB orientation, the shuttle will drift north before roll program, and you'll need to cancel that. If you turn it in VAB it will drift east instead - and that's when you want it to go. Besides IRL shuttle rolls much more than 90*, close to 180* IIRC. You should also try starting gravity turn already at 0 km, right after liftoff and roll program (this would prevent drifting west after roll program) and ending it as soon as at 45-50km. If your vertical velocity starts to approach 0, do the roll-upright. If it does it to early, use OMS assist next time (after SRB seperation engage OMS engines and disengage them before roll-upright using action groups). IRL Shuttles used agressive gravity turn as well, they even had negeative vertical velocity at some point. Also remember to disable TSAS before launching, that's why I suggest switching to new ASAS - MJ recognizes TSAS as regular SAS and it will try to kill you by enabling ASAS to prevent itself from performing the correct gravity turn

^this. Advanced joystick settings allowing to adjust response curve is something I miss from KSP. In real live chopper moving the collective lever results in pretty much instant change in vertical acceleration, that's why rotors are kept pretty much at constant RPM and only blade pitch changes - while changing pitch gives instant reaction, changing throttle gives lagged reaction due to spool up/slow down time. Also in real live chopper attitude is controlled by dynamically changing pitch of blades when they are on the side of the chopper we want to ptich into - so pitch/roll/yaw rate doesn't depend on collective setting, you can even change your attitude 0% prop pitch (like RCS) So it should work pretty much like lunar lander XD

NO! There is only one modulemanager.dll and you should only have one (preferably newest, downloaded from Module Manager thread link) in your GameData folder (in root GameData folder, not in any particular mod folder). Each mod however comes with it's own, perfectly editable .cfg file which contains all the changes that have to be applied to part.cfg in stock parts/other mods. There is a manual in the first post of Module Manager thread on how to write/edit these files to make own changes. And JDP, you should, for that reason, remove modulemanager.dll from your mod and just give link to it in install instructions, because it causes confusion - people end up with multiple modulemanager.dll files in their install, which breaks their game, as each of them processes all cfg files on its own and people end up with duplicated entries, causing e.g. antennas to have multiple 'deploy antenna' buttons in right click menu/action groups (or double/triple energy drain from multiplicated SPUs).

6* is a bit suicidal IMO. IRL these are configured to something arround 3* (which is also deffault glideslope in MechJeb spaceplane guidance). Would be 58.65% more useful if glideslope was customizable, so one can set different glideslopes for different planes.

Are you going to add UDMH to the mod in future?