ferram4

Hey, swamp_ig, you said you thought that the SRB nozzles should vary in relation to thrust? Turns out they should! I have a bit of complicated math for you. So what we're looking at is a converging-diverging nozzle, like above, where the left-hand converging portion is embedded in the tank and the diverging portion is visible. In order to get supersonic flow in the diverging portion of the nozzle, the flow must be choked, and the closed form expression for the mass flow through a choked nozzle is: m_dot = p0 · A* / √T0 · √(γ/R · (2 / (γ + 1))(γ + 1)/(γ-1)) where: m_dot = mass flow rate = T/vexit = T/(Isp · g0), kg/s p0 = stagnation pressure = combustion chamber pressure, Pa A* = throat area, m2 T0 = stagnation temperature = combustion chamber temperature, K γ = ratio of specific heats of gas, probably ~1.2 R = specific gas constant = universal gas constant / gas molecular mass, J/(kg)(K) You'll know m_dot from burn time, p0 and T0 can be estimated from typical solid fuels, γ and R can be found for the combustion products of typical solid fuels. From that you can solve out A* for a given amount of thrust. Based on some searching about how to handle gases with solid particles in it and how aluminum and ammonium perchlorate react, you can use the typical gas equations but use a γ of 1.195 and an R of 172.64 J/(kg)(K). I'm not exactly sure what pressure and temperature to use though, since it looks like that gets pretty complicated in itself, though I'd take educated guesses of ~30 - 50 atm pressure and ~1500 - 3500 K temperature. So that tells you how big the throat area has to be for a given amount of fuel flowing through it. Now, nothing stops the nozzle from becoming smaller, but the diameter of the tank should put some type of upper limit on the throat area. Based on what I've read, it looks like the general rule is that the upper limit on throat area is about 0.5 times the area of the initial open space for combustion in the SRM; I'd say that that should set the upper limit at about 1/3 - 1/2 of the cross-section of the SRM, which means that the throat should be able to get slightly larger than it currently is for the sea level nozzles and quite a bit larger for vacuum nozzles. Edit: I feel like I should note that the above equation would work for any rocket engine, not just solids. So if someone wants to go about making a procedural engines mod, that is the equation you want for figuring out how large the engine throat needs to be for a given chamber pressure and temperature.

If it's the part I'm thinking of, that single part tapers too quickly for its own good. Now, that said the numbers will probably drop a bit in the next FAR update, since I've got a somewhat better algorithm for that sort of thing partly-worked up. For the most part, it's a part issue, and it's an issue that's shared with almost all the tapering parts that exist in KSP; they're designed to look cool, not to be aerodynamic. Go ahead, post the craft and a picture of the problem part so I know that I'm checking the right thing. I'll see how it plays out in the dev build and make sure nothing truly horrible happens.

@MAKC: I've made some changes that will reduce the basic skin friction drag (it was ~50% too high) and the transonic and supersonic drag of wings. My F-15 had no problem getting up to speed using those settings, but the F100 apparently overheats at really low speeds, or it's stuck using a normal shock inlet, since getting it past Mach 1.6 quickly led to burning off. It seems about right now, though you still kind of need to go into a dive to get through Mach 1 efficiently. So wait until FAR v0.13. @DirtMerchant: Negative deflections should also appear in the next update, but I'd prefer not to bring back the old GUI, since that GUI always kind of annoyed me. It was just a necessary evil since I didn't have something like tweakables to use.

@DebatedNothing: Not much that can be done there; you've got a single part connected through a very small connection area that's probably getting quite a bit of force acting on it. Try struting the wing to the rotating bit of the hinge to see if that helps. There's also no way to increase the stiffness for just one part, because stiffnesses that are too high for the part's mass / moment of inertia can break the physics engine.

But those random crashes in-game aren't due to the way that parts are loaded, it's due to either memory leaks (which will only be exacerbated under on-the-fly loading), bits of code needing just enough memory to put it over, or an unhandled exception somewhere. On-the-fly loading will only help ease the crash-during-game-initially loading and game-crashes-on-initially-going-to-flight-scene / VAB situations. And telling the player that they've gone over the game's memory limit, so they can't do the mission they've planned on doing when they get to the crucial docking procedure is only "graceful" when compared to a crash; otherwise it's the most jarring, unpolished way to handle this type of thing. It should gracefully say that the game won't be able to allocate enough memory at startup and that the player should consider uninstalling some mods. I'm not even sure how you manage to get that many crashes; I've had a surprising lack of random crashes, and this is with me actively developing and testing mods in my saves. It makes me think there's something else interfering with KSP that is the cause of those issues to be honest.

Fine, here's a good argument against on-the-fly loading: it will cause unwanted behavior when a situation comes up where the game needs to load enough assets into memory that it goes over the memory limit. If you have a space station made up of parts from enough mod packs that it almost, but not quite, goes over the memory limit, but then you go to rendezvous with a ship built of parts from another pack, so that the total memory needs of the station part assets and the ship part assets exceeds 4 GB then either one of two things happens: The game runs out of memory and crashes. However, since it doesn't happen during loading it's worse from a gameplay perspective, since you're interrupting someone's game partway through. The other ship isn't loaded to prevent the game from crashing. This avoids the crash, but it still means gameplay is interfered with due to memory issues. Neither of the above solutions are good because instead of a mod-heavy player worrying about memory usage when they're putting their mod setup together they're trying to figure out the maximum amount of memory that their particular mission will require based on what parts will be loaded all at once. There's no way to tell if you've planned enough for your game's memory usage until you head out there, and a player shouldn't have to think about this type of theoretical memory allocation in the middle of the game. And then there's the fact that you could cause the crashes in the VAB as well by building a ship with too many different types of parts. Finally, once this is implemented there will be less incentive for any modder to reduce the memory usage of their parts; it's not like memory limits will cause people to be unable to play with their pack, so why should anyone decide to use smaller textures when they could use much more detailed ones? So that will just cause the inevitable in-game crashing / vessel not loading to become more prominent. The reason that it's a bad solution is because it has really nasty consequences if it's pushed (as it certainly will be, since that's what mod users do).

Except the numbers I get (from using the Cd, reference area and Q values) that you're dealing with 65 kN; I think the difference is due to the intakes, which might not be set up correctly. Now it's possible that the cockpit is making too much drag due to the approximations used, but I don't think the pWings would be making too much drag.

@bs1110101: Try doing this: Measure the chord of one of the sections for the fin (so that's the distance from the front to the back; it should be very, very small). Then measure the span of one of the sections (the side of one of those grid squares). Figure out how many sections there are, and multiply chord and span by those; use those values for MAC and B_2, respectively. Set MidChordSweep to 0. Set taperRatio to 1. Set e to 0.85. See if that sort-of works. @bulletrhli: It'll be awhile. I think I've figured out an algorithm that can remove my dependency on attach nodes being the correct size that still works with pretty much any mod part I can think of (especially fairings), but I haven't started implementing that, so that might take a few days. It's especially critical with the new, larger stock size parts we'll be getting in 0.24; everyone speculates that they'll be some multiple of 1.25m wide, but I don't see any compelling reason for that myself; if that's the case then FAR will be completely wrong at simulating even stock part aerodynamics, and that will not do. I've also just implemented the exact equations for the wave drag around slender bodies with conical sections, along with a little bit of a fudge to make it more accurate at hypersonic velocities. That works well, but there are quite a few parts in KSP that violate slender body theory, so I'm going to have to implement proper conical shock relations to handle that sort of thing; unfortunately, the values I need are not the type that can be calculated using an explicit formula and instead have to be either read off of a graph (which means I'll have to rig up an approximate equation or look-up table) or solved numerically (which will be fairly slow, even if I only have to do it on part loading. There's still a lot to do. @Dragon01: So basically, a way to set the zero-input angle of the control surfaces? I think I can do that. @ANWRocketMan: Probably the best way to do it is a flight test, where you're going to keep track of the BC at various Mach numbers. Basically, boost the craft (unmanned, I would hope) into space on a sub-orbital trajectory and then boost it down into the atmosphere. While that's happening, take a look at the BC at Mach ~5, ~2, ~1.2, ~0.8, and ~0.5 and record them. Make sure that it has the mass that you expect it will have on atmospheric entry. From that, you can figure out terminal velocity at any gravity and air density based on this equation: Vterm = SQRT(2 * BC * g / density) You can look up g for a planet. Density is a little more difficult, since you'll have to use the ideal gas equation to calculate it from pressure, temperature and the molar mass of the gas; I'd approximate it using atmospheric pressure in atm and assuming that's density in kg/m^3; it'll be low, but that gives you margin to work with. If you want more exact, send an atmospheric probe in to get better pressure, density and temperature data to use. BC will vary a bit with gas composition at any Mach number, but it shouldn't be by much. You'll select your BC based on what you think your Mach number will be when you have to start the burn; there's no need for Mach number data above 5, since it doesn't change too much above there. That should give you the amount of velocity you need to get rid of, but you'll need to add some for gravity losses and for margin. Of course, adding a lot of dV to that will increase the mass of the vehicle enough to mess up the BC, so you'll want to scale BC up or down to compensate; it's just mass divided by drag area, so you just need to multiply it by the ratio of the current mass to the original tested mass to get the new BC, but then you need to run the terminal velocity numbers again.

@Hodo: Try replacing all of the launch clamps with new ones and see if that fixes it; perhaps there was some weirdness due to the update. If it's breaking for it finishes loading than that means that even the crazy amount of strengthening that KJR adds isn't enough for it to hold together; it breaks before the KJR message in the top right corner disappears, right? Try reinstalling KJR, and if that doesn't fix it then provide the craft file so I can play around with it. @bulletrhli: That's because of the wonky way that the stock landing gear are set up; since only the wheel is affected by physics it works as a very good way of isolating the rest of the vehicle from physics forces, as has been exploited by many people using them in the place of standard landing gear. There's not much that can be done than to reduce the settings in the config.xml (which are there for fixing what you're complaining about) and hope that it doesn't have negative side effects.

Grid fins could probably be approximated using FAR's current wing model, but I'd have to look up if there's any easy way to do it. Honestly, it should have a lightly different definition than a standard lifting surface, but I'm not sure if it's worth coding up an extension of the current model for a single part.

That's just the physics simulation using too high a timestep for the forces involved and the rate that they're changing. There's nothing I can do to fix that, since that part of the physics simulation is out of my hands.

If it's true that FAR breaks it, no one has explained how, why or given reproduction steps, and has simply stated that it breaks. FAR doesn't have anything to do with the way sounds are played or how the effects are rendered, so it shouldn't interfere with what this does. I suspect that means that something else is wrong and it's simply the echo chamber repeating false information again.

Hunh. What's the vehicle's acceleration at that altitude? Does strutting it to something else help in any way? At least there's some progress, right?

Alright guys, KJR version 2.1 is out, which fixes the KAS issue, reduces some of the physics overhead, and also includes a workaround for some of the launch clamp weirdness that everyone suffered, but was particularly noticeable for RSS users. Also probably other tweaks that I've forgotten about. Have fun guys!

I hope it's not something like Nexus. I don't want to have to try and support someone's mod manager in addition to my mods, and I'm not sure it's a great idea for users to have no idea what happens with the mods they "install" (can you even call copying over a folder an installation?). I wish they'd just get in contact with the big modders and ask what we want / need. If whatever they create doesn't meet our needs / wants, it'll probably not end up being supported as fully by the modding community. The worst case scenario is that it's bad enough that none of us want to deal with it and try to prevent our mods from being distributed / managed / whatever with that system. Whatever the case, if their "better mod support" thing involves any type of Squad-produced mod manager they're going to have to provide support for modded installs, or else it becomes impossible to get any support for the mod manager; the only time bugs in the manager will appear is if someone installs mods, which means under the current setup that they don't get any support. So then modders would end up having to support Squad's code, even though we have no idea what's going on in there; the end result is that we'll just have to tell users to never use Squad's mod manager and that users will be more annoyed with both Squad (for lack of support) and with us (for be unwilling to use the "better mod support" mod manager). A mod manager must come with official support for modded installs or else there should be an explicit statement that the mod manager will not be supported, since that's what will end up happening in practice. Suffice to say, I'm skeptical, since I expect this system to be driven primarily by user demands with less consideration given to modders. The last time something like this was tried, where the modders were only brought in near the end was SpacePort, and we can see how that turned out; why shouldn't I expect the same to happen again?

If you're flying on stock-sized Kerbin then the atmosphere is slightly shortened, with a scale height of 5000m rather than Earth's 7500m; so that works out to you flying at an Earth equivalent altitude of 15km (49.5kft), while MAKC was flying at an Earth equivalent altitude of 9km, or 28.5kft. You're a lot higher up than you think you are, and so you're getting less thrust than you expect because you're comparing the wrong things.

How much does this stuff hurt performance? Does it put any more load onto the CPU, or is it primarily GPU intensive?

I like the one on the right, but I'd say to make the main section of the nozzle a little less dark and to try to make the section of the diverging nozzle section just after the throat look more like the one on the left, though using textures rather than polys. They all look quite good. Since you're doing this, would you consider making a modified F-1B version of it? The center version already seems to be pretty close to that actually, though I don't know how easy it would be to remove the ribbing and the complicated turbine exhaust ring.

Check in the config.xml. You can add more if you like, but that can cause strange behavior if you get a false positive.

It's only the title of the part that has to change, not the name. You don't break compatibility by changing the title. Adding another flag to the part isn't that simple, since it would basically require defining all of the drag parameters right then and there in the config file for it to work properly. That, or lots and lots of code refactorings to allow you to define only some of the drag parameters without FAR overriding those when it calculates the other parameters.

Currently FAR ends up zeroing out every affected part's AngularDrag and substitutes its own air density-based angular damping function, so that already happens. I suspect the reason that angular momentum isn't being conserved is due to some amount of numerical errors in the physics engine, and there's really not much I can do there.

Define a FARBasicDragModel but give it an area (S) of 0. Then it won't apply any drag forces to that.

Are you using the most up-to-date version of KJR? Also, how large are the masses on either side of the docking port? It doesn't matter how much stiffening KJR attempts to apply, if you put a stupid amount of mass on either end of a docking port there's nothing that can be done to help besides redesigning the entire ship.

Yes, I am aware of it. There's a fix for it in my current build and I'm just testing stuff to make sure that I haven't horribly broken something with the changes I've made.

It would have been 0.12. I remember my first thing was trying to build a rocket to land on the Mun, but not being able to radially attach fuel tanks; many tricouplers were used and my rocket included SRBs halfway up so that I could sorta-kinda have large liquid boosters on it.