Leyvin

All units in KSP are SI (Metric), this is why Distance is shown in Meters and Kilometers; Weight is in Metric Tonnes and even your speed is shown as m/s not KM/h Kerbin is a strange little planet when you think about it. Compare it's Statistics to Earth's and you will see what I mean. From a Part and Balance Development Standpoint it is actually a pretty big Nightmare; as in order to get similar performance to Real-World Equivalents they must perform at 10% value; but have a 10% faster Rate of Change (end result being they are half the performance) To be honest right now I don't think there is any Thermodynamics simulation; so achieving better performance than should realistically be possible with things like Jets (which makes SSTOs relatively easy) ... It's understandable given KSP is intended to be primarily a game about Rockets and going to Space not Aircraft that can do silly non-sense, but hopefully it is something that is considered for a later Aerodynamic expansion - that means things like Nose Cones do become important and making an SSTO is one of those Unicorn Dreams that only a few will achieve without Mods; rather than there being a Stock Aircraft capable of doing it.

It is there in the final variant but it isn't really presented in a very good means. http://en.wikipedia.org/wiki/Drag_coefficient Follow that link and you'll understand the equations being used considerably better.

Fuel will only flow via the Docking Ports provided the part count is below 250 at Launch... why this is the case has confused the f**k out of me for weeks, as it was how I built my NASA-Style Shuttle - with one launch it worked, the after that it just stopped working for no reason (along with the body engines despite fuel lines being setup on it) causing me to completely redesign it. Leads me to believe this is bugged behaviour and they should still be working correctly but Part Count will cause them to be ignored as if they're not there.

70KM ... as soon as you hear the soothing space music, you've made it up there; as far as KSP is concerned at any rate

They don't actually need to be, nor does he realistically need a TWR above 0.6 for Take-Off (in Space is a different matter, but then Lift has absolutely no baring on that) Still as far as Take-Off is concerned, ideally you want your Lift to be Behind and Above your Centre-of-Mass; reason for this is because while Up-Force Lift below the Mass requires the Lift to be a "Pushing Force"; which is fine for VTOL Craft (such-as Helicopters) where this is assisted with Thrust but when you're Thrust is so far back it actually begins to act like a Down-Force. Instead positioning it so that it is above the Mass will turn it into a "Pulling Force" that will aid the Engines in creating Lift. The easiest solution to this with your current design is to provide your Wings with a Positive Angle of Attack (i.e. Pitch them so the ends are aimed upward Shift-E 2-3x should do it), doing this will not only increase the Lift Height; but it will also increase Stability at higher Speeds while also allowing for some basic "Glide" Capabilities. The second thing you need to keep in Mind is that your Rear Landing Gear are a 'Pivot' Point for the whole Centre of Mass, so ideally you want them close to that point but behind it slightly so you don't just fall over backwards. If you're worried about the Tail, then note there are 2 Solutions to this: 1 • On the Interconnection Joint between the end of the Tail and Body, take one of the landing gear and just slide it up the middle so it is just sticking out of the end. This will generally act like a Skid Wheel, but sometimes it can lead to hilarious torque and explosions so experiment if it's the right thing for that Aircraft. 2 • The M-1x1 Structural Panel, is actually incredibly resilient and can often be used as a Skid Plate (or even landing gear in some cases) but keep in-mind they can only really take getting hit at perhaps 60m/s (130mph) I would say though being 180 MG, might make it a considerably Challenge to make it in to Orbit with that... ideally you want to be a light as you can possibly make it as you want your Air-breathing Engines to ideally do the Majority of the work for you before switching to the Orbital Thrusters. Still that'd just be a suggestion

The issue with Multiplayer isn't so much the Server-Client ability to communicate, heck by the very definition all you need to really do is setup the Server as a "Dedicated" Server... this way for each player you merely shift to the 'current vehicle' in use, when people are in the SPH/VAB they can then be ignored from the update loop. Although this will lend issues, firstly that there is only a single SPH/VAB on Kerbin (so perhaps a creative solution to add another per player might be a good idea, Kerbin Town seems to be a good start for that) but the biggest issue really comes in the form of the "Time Dilation" ... as you can't have 1 Player Time Warping when the others aren't. A viable (but I guess arguable unrealistic) would be to disable Time Warp and instead create a /Hyper-Space/ Style Device that would effectively transport that player /near/ instantly along the Orbital Path they were on. This is relatively easily done, but balancing it so it isn't an "I win" movement or that trips would take too long would be quite difficult to do. Again there are some mods that have delved in to this, but don't recall seeing any that weren't just OP; which as I said would be the major tricky part. The final aspect that likely will prevent this from being particularly usable though is the games performance, sadly (and I feel this is likely more a problem with Unity as it is not exactly amazingly optimised tbh) is actually pretty terrible. I mean have you ever had a Space Station in Orbit that has like 1,000 Parts when put together? The game starts to hit single digit framerates even on high-end machines. Unfortunately there just isn't a way around that without Kerbal moving from PhysX (built-in and OMG piss poorly implemented) to something like Bullet Physics or Open Dynamics Engine... which isn't a bad idea to be honest, as it would provide better opportunity for optimisation, multi-core and OpenCL (GPU) support - but they aren't the easiest thing to implement. -|- This said, and consider this for a second... if instead of focusing on making an asynchronous multiplayer (traditional Server-Client, everyone playing at the same time) instead you looked at perhaps something that simply allowed players to Collaborate... i.e. Aerospace Manufacturer(s) [sPH] ... Launch Vehicle Manufacturer(s) [VAB] ... Mission Control (Provides Missions / Objectives / Budgets) and Pilot(s) (who actually Fly the Missions) Then that might be a far more interesting form of Multiplayer that doesn't require any real alteration of how KSP works at all. Instead you could then have a group of friends who are basically playing together doing each of the individual components, then sharing what they come up with. For example someone working on an Space Plane, would be considered to be in a 'Simulated Environment' once they're done they would then hit the "Ship to Space Agency Button" that then makes it available to Mission Control for actual Missions they want to set the Pilots. Best part would be that it could all be backed up to an SQL/WebServer so they don't even have to be playing at the same time to be playing and 'sharing' the experience. When there are launched then have it so any of the /other/ players outside of the Pilots could then get a "Live Feed", for what is going on. It also kinda keeps well to the /spirit/ of KSP being the whole peaceful, yet often disaster ridden exploration of Space. I mean after all most of us have different things we like about KSP, I for one have never really made it past the Mun; instead I prefer to spend most of my time messing about in the SPH making interesting Air/Space Craft. If you have what you have above for say up to 3 Kerman capable of being controlled by individual players; could be cool to see them doing close operations or performance actual Apollo Style missions and such where they're all relatively still close to each other.

The actual 747-SP/HL (which the one I made is based upon) actually has roughly 880kN Thrust / 450-passenger Capability for up to 9,300 KM (roughly half the Circumference of the Earth) and tend to weigh roughly 325 Metric Tonnes on Take-Off with the dimensions of 6.5m x 8m x 56m (roughly) In comparison the one above features, 460kN Thrust / 24-Passenger, for roughly 350 KM (half the Circumference of Kerbin) and weights approx. 60 Metric Tonnes on Take-Off with the Dimensions of 3.0m x 4.0m x 35m (approx.) really on of the biggest discrepancies comes from the Weight/Passenger/Count (and technically Lift Ratio, but Kerbal Aerodynamics is a special snowflake ) This said, while remaking aircraft in Kerbal is fun trying to get realistic proportions and such... I've found that the SPH/VAB isn't designed for anything with real-life dimensions but rather the scaled world that the Kerbals actually live in. Particularly given that if they were real, they would be considered dwarf people as they're only like 3ft Tall. So making things roughly Half-Scale actually works out to be almost right within their world.

Seeing this gave me the idea of providing 'passenger' capability on my 747-Heavy Lifter that I used for testing the Glider Capabilities of my STS Orbital Vehicle... Can't really carry as many as yours can (only 24 Kerbals + 3 Man Flight Crew) not really cruise are high or fast as yours does, as it really tops out around 12-3km @ 350m/s (780mph) but still it's not suppose to go Super-Sonic anyway so really going that fast is an achievement; esp. when you consider it's nearly 60tn at Launch. Still was pretty fun to convert it, here's a picture of it and the .craft if you want to check it out. Think it could still use some improvements, perhaps some better Lift / Glide capabilities for example, as without engines it pretty much will just nose-dive to oblivion; plus landing can be well "interesting" if you're not careful with the brakes. (made that mistake the first time I test flew it to one of the poles to see what range it would have) Still you can pretty much point it where you want, stick on SAS then leave it to it for the next hour or so until you reach where you need to. Download 747 .Craft >> HERE <<

What you will want to do is: • Setup A Radial Port • Attach The Docking Port • Between the Space Plane and Craft Docking Ports, place the Blue (Non-Explosion Pin) Separator • Make sure that the Space Plane is Kept Stable with the Structural Connectors --- Now an alternative to this is actually to create an Interplanetary Shuttle Craft that you attach the Interplanetary Engine to the back with a Large Docking Port as they are incredibly secure.

GMax has not been a valid 3D Package for almost a decade now, this isn't because it lacks features (although feature wise it is as I said a decade behind 3D Studio Max, the Parent Program it is based upon) but actually more because it completely lacks support for modern formats used by todays engines. In-fact if memory serves correctly it only supports Microsoft Flight Simulator and Quake 3 out-of-the-box with only a couple of formats that have been added over the years. None of which are particularly universal. While Blender might be difficult to use, there are other options available that are still supported. Softimage Mod Tool for example is the "Free" program that Autodesk do still update and support, with out-of-the-box support for Source, Unreal Engine 3 and FBX (XNA / Unity) Although it can be equally as difficult as Blender to use if you're used to Gmax (3D Studio Max) As I recall Autodesk do also sell "Student" and "Non-Profit" variants of 3D Studio Max, although not sure their price nowadays but they used to be quite pricey if memory serves. There is also Aztec3D (Free), Silo ($50) and Milkshape 3D ($20) that are relatively good modelling apps that are similar to Gmax. Another option is you keep using Gmax, but also get Blender ... output to Quake 3 format, then import it in to Blender so you can export it to a format that Kerbal Supports (OBJ / DAE / FBX) although I'm not sure how well that will work and really you'll be causing some extra headaches as things might not work exactly how you hope they would.

Post an image example of the difference between Maya and KSP (Unity), but from experience Maya > Game Engines usually this is a precision issue. As most game engines use far lower precision than 128-bit Floating Points (which Maya uses) It is common practise to make sure your Texture Image is 2-3 Pixels outside of the UV Map as this will handle any precision differences and close seems that might appear. Another thing to make sure is that prior to exporting you "Modify > Freeze Transformations" then "Edit > Delete by Type > History", this literally just cleans up the mesh prior to exporting so all the values are using a Root-Base instead of Offset-Base. It's a small thing but it can help with precision of UV Maps and Animation Keys often, it is actually good to get in the habit of using these quite often unless the local transformation is important to what you are working with.

Suggestion for your friend... ALWAYS purchase Sapphire Radeon Cards, as they are the only company that uses Reference Hardware over custom designs. It might be tempting to go with a group like XFX because they make "performance" hardware but their product quality relies on the fact that most of their customers upgrade every 12months. As for the performance difference from Unity 4.0 to 4.1, as was suggest before... upgrade your drivers. Tessellation 'Tricks' from NVIDIA do not work in Unity in-fact they slow them down (so be sure to turn off Optimisation within your drivers), also upgrade your PhysX drivers.