StevenRS11

Veteran KSP1 guy here. First rocket had bad staging, blew up all over the place, and I started smiling for the next hour or so. If KSP2 beta can capture even a fraction of the magic that KSP1 development had going for it (HYPE TRAIN CHOO CHOOOOO) it will be a monumental success. The game is beautiful already, and I betcha most common issues will be fixed within a month. Im excited.

Fairings are behaving oddly for me- they dont seem to close when I reach the end. Could be that im doing it wrong, though. I can second the stages not separating issue, too.

I don't think I did a very good job of explaining myself, sorry. I can manually hover my craft (this time 9 ton heli with a hippo) at 850 RPM and ~4.3 degrees collective. Activating hover mode rapidly oscillates the collective pitch, reducing RPMs, and causing the craft to fall out of the sky. Deactivating hover mode causes the craft to fly back up again. Here is a short video- Video The hover autopilot fights both the weight of the craft and the inertia of the craft as it jiggles it up and down. The rotor easily has enough power to lift the heli at high RPM and low collective, but cannot lift the heli at low RPM and high collective. This is honestly a very surprisingly accurate representation of real life helicopter behavior- a rotor/powerplant pair has a very specific design RPM and powerband- outside of that bad things happen. Max collective does not equal maximum lift. This craft cannot get off the ground at max collective pitch because the rotor RPM's cant get high enough. If I reduce the collective to zero and allow the rotor to speed up, I can take off easily with only 5 degrees collective and fly around all day.

Something I noticed with hover- it rapidly alternates the collective between -15 and 15. This causes the rotor RPM to rapidly decrease. For example, take the beluga on a reasonably heavy heli. Start the engines, but leave the throttle at zero. The RPMs will increase to whatever max they are set at, and when you increase collective, you will lift off. (Duh) Now, try decreasing collective while landed to large negative values. You will see the RPM's drop from the set value, as it should. The problem is that hover mode rapidly alternates the collective, asking far too much torque from the rotor, killing its RPM and crashing the craft while technically the rotor can easily lift the helicopter.

*Sees FAR update* Time to play some KSP again! Also, I recently purchased a basic starter kit from flitetest.com and have been having a blast with it. It's amazing what flies with insane power those electric motors put out. Equally amazing are modern lithium ion batteries- the amount of energy those things store is quite frankly scary, especially when you see the equivalent amount of mechanical work they can produce. (ie, fly an airplane around at 50+ mph for over ten minutes) The reason for this? Well, I want to see if my FAR creations really fly

You know who you are. If FAR isn't installed, then it's not KSP. You've ripped the wings off a hundred planes a thousand times. You have PWM modulation for the pitch up key in muscle memory. Now, it'ts time to show off. Peg the g meter. The rules are simple, and the objective is even simpler. Objective: Build a plane that can generate and survive the highest gee-forces possible. Post an F3 screenshot of your plane (landed or flying) showing the max g-force as well as vessel mass. Short videos or even a gif of the attempt are always great too! Scoring is measured in kilonewtons, which is (the mass of your plane) x (your max g-forces survived) x (9.8). Rules- 0.) You have to have FAR installed, with all default settings. 1.) Your plane has to survive the attempt. (This is a flying challenge, not a crashing challenge) 2.) Your plane cannot have any stalling surfaces during the attempt. 3.) Your plane cannot have a TWR greater than 2. (This a plane challenge, not a rocket with wings challenge) 4.) You must perform your attempt in Kerbin's atmosphere. Other than that, have at it! All mods are in, nothing else I can think of is off limits. You get the spirit of the challenge by now I'm sure, which is pretty much make the most maneuverable plane possible. So far my best is 28 gees with a 1.2 ton plane, and after a bit more refinement I'll submit it! One submission per person on the leaderboard at a time, but feel free to one-up yourself as much as you want! Leaderboard: 1.) 2.) 3.) ...

I still think that this is the best mod ever made. I recently started tinkering with foamboard RC planes irl, and I have found myself using KSP + FAR as a design tool. I am still working on my first real plane right now, but once I get it finished (ghaa servos) I cannot wait to see if it flies like the ksp model. Two questions, one related to RC and one not- Does FAR model the effects of close coupled canards, especially the airflow stabilizing effect they have with deltas at high AoAs? I tried to test this by having the same delta plane with canards either level with the wing (shouldn't couple) or slightly above it (should couple) but I didn't notice a difference. That said, I might be just doing it wrong. Now, I know that wings in KSP do not have camber (right?), but would far recognize a cambered wing made from multiple parts without using flaps?

Yea, it's really easy to get massive TWRs in KSP. Unless it's something like a sounding rocket, when you have a TWR over 3 things start to get a bit silly. That said, I'll sometimes add a few short burning SRBs for my rockets that have a TWR under 1.25 so they get a bit of aerodynamic stability going sooner. Anyway, I usually play with FAR, and lately RSS. The difference is unbelievable.

Getting a totally optimized ascent profile is very hard, but getting a good one isn't so bad. You really have two things to balance- air resistance and gravity losses. Obviously, you loose energy to the air whenever you are in it depending on how fast you go. You loose energy to gravity whenever your acceleration vector is not perpendicular to gravity, aka non sideways. In a airless environment, you want to accelerate at the maximum possible rate at the maximum possible horizontal angle that keeps you from impacting terrain. So from say minmus, you pretty much thrust a tiny bit up and then just go sideways. You want to minimize the time in which you accelerating against gravity. If you want, its fun to hyperedit launches from Tylo and practice a bit there. With only a single variable, its really easy to optimize your 'gravity turn'. Put a single mainsail under a single orange tank and get the maximum velocity you can before you reach your apoapsis. That's pretty close to the optimal turn for that TWR ratio on Tylo. It gives you a good intuitive feel for what's 'right'. If you want to be even more precise about it, build a rocket with 3,100 m/s dv and escape tylo. That allows for only ~30 m/s of gravity losses, or just 4 short seconds of thrusting directly against gravity. Accounting for air resistance isn't that hard if you guess and check. At various heights during your launch, quicksave, throttle all the way down, and look at your accelerometer. Any acceleration you see is caused by air resistance, and if its greater than the fraction of the gravity vector that's opposing your thrusting vector, its probably much. Atmospheric drag should ideally be 1/5 to 1/10th of the gravity drag, with smaller rockets having more atmospheric drag relative to gravity drag. Also don't forget that any signifigant angle of attack drastically increases your atmospheric drag. I generally try to use fixed winglets on my rockets and use very limited thrust vectoring to start my gravity turn. My best launches are when I don't have to do anything but stage after that. The less steering the better, especially in denser atmosphere.

As far as I can tell, Kerbal's aren't made of regular matter- obviously the pauli exclusion principle doesn't apply to them. It may apply somewhat to their spacesuits though, which seem only loosely coupled with whatever quantum state the Kerbal actually resides in. In fact, I think evidence supports the theory that kerbals are capable of partially phasing out of reality at will. A kerbal can choose to walk on top of his spacecraft, but if he wants to get in that chair buried inside struts and whatever else, nothing seems to get in his way. If sufficiently agitated though impact, they also seem to temporarily loose cohesion, so maybe it takes a conscious effort of will on the part of the kerbal to remain solid. More severe impacts tend to totally disperse the kerbal with only transient remains- oddly similar to how high energy particle collisions work. Kerbals also seem to possess the ability to teleport over short distances, which further supports the theory that they are somewhat wavelike, and are really only describable in terms of probabilities.

So I was reading around on the unity website and its discussion forums. I heard quite a bit of talk about upcoming optimizations for jointed rigid bodies- specifically, that each branch of the 'tree' will have its own physics thread. That seems like it could provide some pretty significant performance benefits, especially if we design our crafts with that in mind. Anyone else heard about that/have input?

So true.

I actually just finished setting up FAR configs for the 3 basic fin types. I'll send your a PR when I finish testing them. The grid fins may be beyond me, though. Edit: ninja'd. It makes me happy that our configs are almost the same, though.

I had totally forgotten that FAR recognizes landing gear now. Deployed gear at mach 3, and my 'plane' turns into a cockpit all by its lonesome.

So, I got one of my friends who is in the Air Force to just try KSP with some mods I recommended installed. (He plays stock, unaware of existence of mods.) He called me the other day, and said that he had built a model of the T-38, which he has flown in quite a bit I think. He said that he got it to fly almost exactly like the real thing, except for very low speed performance. He said that the real thing's controls get 'mushy' faster, and the plane gains a significant control lag that he never saw even just barely above stall speed in KSP. Personally, I think that's pretty cool, and I bet the mushiness/ control lag not showing up might be more to do with the physical properties of the airplane like its various moments of inertia. Ill tell him to increase the mass of the wings near the edges and see if that helps.

Actually, the first method is probably O(n) or maybe O(nlog(n) for thin features. Each voxel only searches until it finds one non-adjacent voxel, and then it stops, because that means it's on a wing. They all stop once they reach the distance limit, which is whatever the cutoff for max wing thickness ends up being. The voxels need to be in a graph, though, for it to run in log time. You end up with one big list of voxels that are separated by thin geometry, and that's it. You just pick one 'wing voxel' and follow all of its edges, checking if those voxels are also wing voxels. If it is, you remove it from the primary list and add it to a different one, which represents a single contiguous thin piece of geometry. Once all the remaining edges point to non-wing voxels, you are done with that wing. Repeat on the now-shorter unsorted list of wing voxels. Its log time because the number of negative checks on the "is the adjacent voxel part of this wing" scales based on the boundary of the surface area of the wing voxels, essentially a one dimensional feature. Because it follows the surface of the wing it is almost always a positive check, and then those get removed from the pool for the next go around. Very little re checking a voxel more than once. It would be O(n^3) with respect to wing thickness, though, because that's a 3D volume search. (I think?) If the thickness is very low, it shouldnt be too bad. Because all the searches done are limited radius volume searches, I don't think anything will scale primarily with the number of total voxels. Know, if it was just a big unsorted list of coordinates, then yea, it would. But hey, that's why voxels are great! As for polyhedral wings, (or a tail fin sticking straight up out of a wing), you could calculate the angle of vector connecting the across-wing nearest voxel and the opposite wing plane. The opposite wing plane could be approximated from the directly adjacent voxels, and that angle could be used to determine polyhedral or a tail fin. Other wing parts could be split along a vertical plane following the axial symmetry line, too. All that said, if its a 3D array and not a graph, then I am not sure how to use the first method. It really depends on each voxel outright knowing what's adjacent to it. That way one or two iterations through the list can just sort voxels based on their nearest neighbors into various lists, and then all those lists just magically turn into physically connected geometry. I guess if you made sure that the maximum wing thickness was less than half the separation between two voxels you could still do it, but you would have to make a pass though the 3D array to build a graph of adjacent voxels. That wouldn't be a cheap operation, but it still would only really scale hard with the max wing thickness. Otherwise each cheap 'voxel.getAdjacent()' would become a tiny area search, which I guess still wouldn't be too bad anyway. Also, if you have a little memory to spare, you can give each integer voxel added precision in the form of metadata. When you are building the voxel model, you can attach a few decimal places that represent the offset from the center of the voxel to the actual point on the geometry that you are measuring. All the advantages of integers with the precision of a float! Though you may already be doing that. EDIT: I just thought of an even better way to do this, because voxels. You can collapse the step that sees if voxels are on a wing and the step that identifies single wings into one, and if you started with a way lower resolution sample (just to make sure you get atleast a single voxel on each wing) then you could probably make the the whole thing amortized O(log(n)) with respect to voxels. Well, with respect to voxels that arent on wings. No way around constant time for wing voxels, have to check each of those at least once.

@ferram4, I think I figured out a way to determine what's a 'wing' from your voxel models by looking at their surface area to volume ratios. That seems like the best distinguishing charateristic to use, just from looking at lots of pictures of KSP planes. Wings are thin, other parts are thicker. Now actually *doing* that is a different matter, but I think I know a way of doing that too, depending on how your voxels are represented and what they know about each other. This is the process I am imagining- 1. If the voxels are stored as a graph, find the nearest voxel that is not adjacent and add it to a list if that distance is less than some amount. The idea is to find voxels that are separated by a thin volume. A bit of tuning would be needed to make this work, especially to find the right distance to look for nearby voxels- You could probably use the slope of the line relating voxels discovered nearby to distance searched. When the slope of that line changes very quickly, you have gone from finding flat, thin wing parts to thicker more sloped structural parts. When you are done, each list would represent group of adjacent voxels, all forming a wing. This other way would work if you didnt have a graph and just coordinates. "Seed" the interior area of the voxels with small points, and grow these in all directions that are not constrained by the voxel boundary. Keep growing them until they reach a certain surface area to volume ratio. When they reach that, all voxels they touch form the outline of a wing. Of course, this is all super broad, but I have coded a very similar algorithm but for 2D. I was drawing fractals, and I had a voxel representation of the outside of the fractal. I would control the iterations of the fractal in different areas until the structures where too thin too look good, and then stop it. I had a graph to work with, so I used the first method, but the second would have worked too. If you think this sounds like something you would use, I could probably manage to write it in a few days for you.

Wow, this is amazing! I've been looking for something like this since I started playing KSP. The only thing I think might be missing is a way to automatically switch between two different PID presets based on subsonic or supersonic flight. If you wanted to get even fancier with it, you could define two presets and then attach each one to two different Mach numbers/dynamic pressures. Then represent each one as the endpoints of a spline, and have user defined control points create the spline. You could then interpolate between the two presets based on the spline curve. That way you could cover the changing aerodynamic properties.

If you wanted to fill out the pack a little, you could make a few more high temp aerospace parts, like air intakes and a nosecone. You could also make high temp wing leading edges and control surfaces. I'd stay away from actual wing parts, though. We have lots of those already, heh.

Better than full of wasps I guess. *shudder*

I was playing around with reactors and radiators, and with the way stock heat params are it feels like my entire ship is one giant solid copper block. It's very hard for any meaningful heat gradient to build up. I'm really tempted to write a plugin that outright replaces the stock system and tries to do a better job. Does anyone know if the stock heat model can be "turned off" like aero? I'd also rather not mess with reentry stuff, so hopefully reentry heating works through the standard heat transfer methods. (Physical API I guess?)

So instead of just the landing gear leaving violently, everything leaves with them.

I was playing with the dev version, and let me say this. Don't deploy your landing gear going mach 2 at sea level.

OH MAN Github commit for the mod compatibility stuff just happened! Its getting closer!

Yea, I was thinking more about a CFD solver like Stallion 3D, but you know, not $24K.