ferram4

And it is actually only 41 tonnes? This is what it says in the flight info thing in mapview? If that doesn't fix it, kick it off the ground and then see if it works. Maybe it's the sticky pad bug. Maybe it's tweakscale messing with the mass of the parts that you think are low mass.

That's probably because it weighs more than 50 tonnes. If the window says it's producing 500 kN of lift, it'll lift if it's under 500 kN of weight, alright.

This doesn't technically work through the API. Instead, what you want to do is to call part.SendMessage("UpdateShapeWithAnims") on the animating part and all its children, and that should do the trick. Rate limit sending it though, or else you'll lag everything out.

The wing code will account for it right now. The voxel though will need to get an event from IR; it'll need to send an event to each child part on the deflecting part in order to update the geometry.

And, FAR version 0.15, "Euler" is now out, containing all the voxel-aero updates that I've been working on. Changelog is extensive and crazy. Thanks to everyone who has helped with testing, especially tetryds, NathanKell, awang, and probably some other people who I've forgotten. Also thanks to stupid_chris for the RealChuteLite implementation to do break all dependence on stock parachute modules, and a last-minute addition by mjn33 to make some GUI stuff behave better. There are two things that I think that should be acknowledged right off the bat: 1) the wing code is still legacy old-FAR wing code. This is simply because I haven't had the time or the inspiration on how to pull wing shape data from the voxel model, so I'd rather have the new stuff out now rather than wait for several months bashing my head against the wall. 2) All the engines have been given a 1.5x boost to gimballing range, because flying a rocket with a wide payload fairing through Mach 1 is rather tough. This isn't applied for Realism Overhaul (whenever that comes back) but will be for all other setups because, frankly, it's kinda necessary. As a final thing, since apparently this describes a significant vocal portion of my userbase, I've added a nice little "throw ferram money" link in the first post. It doesn't entitle you to anything, but it's nice. Alright, now try not to break everything immediately, alright?

Thrust is the limiting factor... because the engine needs to throttle down to prevent itself from melting. If you could keep the internals cool, there's no compelling reason why you couldn't sustain Mach 3 at SL. Now, I think it would be great if KSP engines modeled that, because then what you'd get at SL is that you can continue pushing the engine far past what you should do, eventually leading to the turbine failing, possibly in a spectacular uncontrolled fashion that destroys the entire region of the aircraft around the engine. It's really not the thrust that's an issue, it's creating the thrust without destroying the engine that is. Also, yes, Learjets can't handle Mach 3 partly because of the skin temperature. 2.8x the ambient absolute temperature will be enough to cause most aluminum and steel alloys to being losing strength, and then you're in deep trouble.

@thorfinn: All I know is that every editor -> flight -> editor cycle seems to add 20 MB of RAM. I was hoping it was me being stupid with voxels and I could fix the leak, but nope, it's KSP. Dunno any more about it, but it's there, lurking. Seems to explain all the crashes after a long time of playing issues, tbh. @etheoma: There's actually nothing stopping you from increasing the number of voxels for each vehicle from 250k to 2.5m if you want to. The only problems are that it's slower to generate and that you'll have fewer editor -> flight cycles before crashing. I've already optimized that whole thing about as well as I can based on profiling, unless I get some stroke of genius that lets me cut out a huge amount of overhead. The voxel generation is already as multithreaded as I can make it. The actual in-flight aero calculations can't be multithreaded due to 1) not having strict control of when things run in the physics frame and 2) letting the forces come back one frame (20ms) later results in everything becoming horribly unstable due to the phase lag. Yes, I already tried this, no, it doesn't seem fixable. If there were no hard limit I'm honestly not sure, mostly because anything that cuts out the bottom 10%-30% would cut out me; I'm running a 4-year old Lenovo T520 (with 16GB of RAM, granted, but it's not super-fast) so I'm more concerned about it working for me than for anyone else here. @4plains: Hmm interesting. To the best of my knowledge, I've done everything required to make it work, unless it's doing something screwy and it's applying OnRescale multiple times on load, in which case, things are going to be very screwy. I'll see if I can do anything. @Hodo: That would probably be stable were it not for the canards at the front and if the nose + cockpit came a bit further out. You've got a lot of lift far forward on that. @Dimenius: Sorry if it came off as mean, but you'd be surprised how many times I've gone on a wild goose chase for what I think is One Of Those Bugs That Won't Die when it turns out that it's something to do with the user being on a different version or missing dependencies. It prevents development from going as fast as I'd like.

@RevanCorona: Well, the forces are still applied part-by-part, it's just that the aero calculations aren't done for each part alone, they're done separately and then divided up among each part. The aliasing is a minor issue, but most of that has been fixed by allowing voxels to be "partially filled" so that a voxel that is only barely touching something counts as less than a voxel completely filled up by the parts. This seems to have fixed almost all the issues. While increasing the resolution is an option, the issue isn't framerate: it's memory usage. The voxel model generation is rather memory heavy, and it also involves a fair bit of garbage, so if it runs at too high a resolution too often you get the garbage collection hitches. Also, we're heavily memory bound in KSP, so we can't afford several million elements for the voxel. The system is built in craft-space assuming an unflexed vehicle. Then cross-section data is taken from the voxel model and is used to generate aerodynamic properties that are stored for each section, and then the voxel itself is thrown away, because it's simply not needed anymore. @Zorbaq: Funnily enough, the way that everything works out makes it seem to be approximately the same or even less expensive than what FAR was before. Most expensive stuff is in generating the voxel (which is multithreaded because it can be) and the initial geometry work for each part (which could be multithreaded as well, but that would require a large amount of work to prevent race conditions, I think).

@etheoma: Yep, it's great, ain't it? I've also noticed what appears to be a few MB of leak every editor -> flight -> editor cycle, and I'm not sure where it comes from, though I can reproduce it in stock KSP, so it's not anything I'm doing.

@LuvSicGirl: You mean, I should be nice and accepting towards trolls and spammers? I mean, this is what's going on, and it is interfering with the ability to get feedback from the people who have been competent and diligent enough to get it working. Ultimately, the dev builds being publicly available aren't a courtesy, they're a trade with the users that will use them: they will try them and point out issues in the code, and I will be able to fix issues before a full release. Now, if you can't be bothered to set up everything, I get nothing from this trade, and there's no value in it. Worse, it drowns out any actual feedback, resulting in reduced value from the users who are actually participating in the trade. @theend3r: Works perfectly fine in stock. Managed to get a booster to gain a few tens of km in apoapsis using that trick. @etheoma: Hey, I take exception to the implication that I am not an ass. I am an ass, I'm just competent enough and honest enough about it that people let it go.

@Dimenius: Upon my testing, I find that the CoL drops to where it should be. If you aren't absolutely certain that you're running the latest nuFAR and you're not absolutely certain you've installed every dependency right, don't post a bug report. @etheoma: As I said above, stop helping. If they can't figure it out themselves, don't help at all. @Jax Pok: Yes, it's completely realistic and there's no need for FAR ever again. It's gone forever and development has ended. You see, stock is so realistic, it even accounts for the way that clipping things together works in the real world. As we all know, if you attach a nosecone to a booster, and then spin the cone around so that it's inside the booster and a flat end is facing the air, that will result in a minimum drag. This is why the ideal frontal shape is a flat face, because it results in the lowest drag when you have internal nosecones with the flat-end facing outward. In real-life tests (which have been replicated very well in KSP), doing this can reduce drag by 30% after Mach 1, and even reduce frontal drag to 0 as Mach -> infinity! It's amazing that so few real-life designs use this, I mean, KSP is realistic, right?

@Eddie Rod: [/b[i'm sure you have no issues whatsoever. No crashes at all, right? But didn't you mention in the General Discussions thread about this something along the lines of how a crash every so often is good to get you to stop playing? Yeah, there are still issues. Even more so now that it's no longer official, but fortunately, that's just even more reason to not bother supporting it. @s.maelstrom: As noted before with M3Man03, I cannot reproduce your issue at all, nor does KJR do anything that would involve the movement of launch clamps. Please provide full reproduction steps and a full copy of the output log with no mods other than KJR installed, or else the exact minimum required to reproduce the issue. If you can't do this, I have to assume that it's another mod entirely, because I can't recreate it. And I've been playing all of 1.0 with KJR and never seen it.

I'm gonna say this right now: If you're trying to get a dev version of FAR working, and you're going to try and do that without any research about what it needs, you deserve it not working. It's still a dev ersion for a reason, and I haven't packaged it for release because it's not finished. I'd like to ask everyone who keeps trying to help people who clearly can't be bothered to read back a few posts to stop helping them because they're not going to help the dev process at all. If it continues I'll simply stop pushing the updates to github and wait until it's ready for release, because at this point the thread has turned into a spam of people who are too impatient to wait but are too clueless to do research.

@DundraL: So the effects of parts very, very far from the lifting surfaces under consideration will still have a large effect on the mass of the parts connected. Come up with a method that doesn't result in strange interactions between parts and then maybe I'll consider it. Also, as much as you might insist that a single bar strut is identical to the flat braced area at the bottom of a wing, it isn't. It never will be. They are structurally different, flex differently, and if constructed that way in reality would behave differently. So they will behave differently in FAR. Build your wings sensibly; when you insist on supporting a large mass of wing not through a solid connection to fuselage, but through a crazy daisy chain through other wing structure plus a single strut, it will require additional mass. @Jovus: Maybe? First I need an algorithm to pull wing shapes out of it to begin with. No, I don't want, "maybe you could do X..." unless it's been backed up by at least pseudo code. Otherwise, I'm busy looking at things like DundraL's idea where there's strange behavior all over the place due to not thinking things through.

@DundraL: Your method fails horribly in one clear way: you will make tiny canards and fins much heavier than parts at the wing root because they will be far from the CoL. In addition, you will make wingtips much heavier than wing roots. You will make wing mass depend not on anything related to the construction and loading of the wing itself, but instead on the properties of some part of the aircraft far away from it that contributes little to the forces on the wing. Finally, you will make wing sections that are carrying comparatively little load heavier than wing sections that are supporting huge amounts of wing area heavier for arbitrary reasons. The inverse (having it vary with 1/(dist to CoL)) will result in even stranger behaviors and will cause NaN masses and encourage parts used a wing buffers to keep them away from the CoL. This is not an exhaustive list though, considering I just got back from working an election and that I spent less than 30 seconds thinking about it. I appreciate that you, like many other people, have this idea that how things are actually put together doesn't matter, only the way it looks matters. Unfortunately, In real life, if you have two unconnected metal plates sitting next to each other, the first plate won't do anything to help the second resist a shear force, and instead that will need to be accounted for elsewhere. You know what really irks me? Vegemeister's criticism (that for any wing shape, as number of wing parts N -> infinity, mass -> infinity) is actually a legitimate and serious downside of the current wing model, but instead of taking that tack, you're arguing that wing mass should be divorced from how it's constructed. @Surefoot: Old issue from a very old build. Keep up-to-date with the builds before reporting issues. @jrandom: How much wing area do you have? Based on the math, you need a combined Cl * Area = 3.6 m^2 to keep it in the air at that speed. Frankly, given the way that it's designed, you probably just don't have the wing area for all the heavy junk on it.

@Vegemeister: 1) I need reproduction steps. 2) It's not supposed to save its position. @ss8913: The only thing odd is that you expect a prediction to work perfectly when MJ has no idea what to call to predict. NuFAR is a complete refactor with very little left of the old methods. If it was compatible, that would be damn amazing.

@SymbolicFrank: Already planned. However, you'd be surprised, area ruling something sufficiently isn't that difficult. For example: That is the redesigned Firehound M. It's supermaneuverable, is capable of Mach 1.1 at SL, and Mach 1.9 at 10km on the basic jets, and only stock parts. I'm only playing with the slightest amount of smoothing available necessary to handle the discreteness of the voxel (and even now that's less of an issue that I've added a measure of "partial filling" for each voxel to improve lower-res voxelization), and the drag at full realism, and with a pair of engines that perform fairly close to the F-15's engines, it behaves pretty close to an F-15 in terms of speed. I don't think that lego parts are going to be an actual issue. @Vitasalato: Even oldFAR was better than the current stock aero, if perhaps a little less robust. The soon-to-be-released-whenever-I-stop-finding-issues-that-I-really-should-squash version of FAR will be a whole lot more accurate than oldFAR was.

Yeah, actually placing the aerodynamic center in the right place is actually a difficult challenge to get right, unfortunately. The indicator is currently wherever the forces are applied, but with a moment attached that can also vary with angle of attack, and that kind of defeats the purpose of using it for stability. Frankly, I prefer the graphs myself, they're clearer, but people want indicators, so I'll see what I can do. The subsonic zero-lift drag is probably a little low simply because I'm not accounting for all the interference drag and what not, I may be able to add a factor to increase that based on variations from a nice, simple body of revolution, but I don't know how bad that might be.

There are no win64 builds of KSP anymore, so the question of whether it disables itself on a win64 build is a moot point.

@M3Man03: I have never seen this behavior and have never been able to reproduce it. I suspect there is another mod to blame, or else it is a stock issue. It cannot be reproduced with only KJR. @Krakenfour: The word is to uninstall KJR. The physics easing is necessary to prevent all of KJR's other settings from exploding everything when physics resumes, so you will need to accept it. @marc40k : Absolutely nothing changed, so yes. @biohazard15: No, there is no reason to waste bandwidth.

@Nerd1000: Perfectly understandable. Future refinements are probably going to have to properly recognize that yes, this shape does adjust the cross-section favorably, but no, it should not make drag lower. And probably rip of the gear. A problem for another time, I think. @Darkway: 1 and 2 are actually somewhat related. I was working on a graph for specific excess power for this purpose but found the calculation incredibly slow. We'll have to see how things play out later, but in practice, figuring out the speed and/or climb rate is a little bit difficult otherwise, simply because of Cd variations, but for speed, it's just whatever speed is when excess power -> 0 and you can't accelerate anymore, and climb rate is all excess power -> gravitational potential energy. 3 is something on my wishlist for awhile, technically as an autotrim feature. It shouldn't be too difficult, but it's a lot of number crunching to do. 4 is something a lot of people have requested, but that I'm not adding. I think that the game deciding to make decisions for you is kind of irritating. @Naten: Now, while getting the collider / mesh every single time and using that would work, it turns out to be horribly expensive. In order for voxelization to occur, all the meshes/colliders used need to be listed in the same reference frame. Doing this requires me to first get the mesh, then transform ALL its points into that reference frame. Since it takes (I believe) 12 multiplications to transform a single point, and then that has to be done to the THOUSANDS of points for each of the meshes, it makes more sense to cache a separate list of transformed points; this reduces the overhead for each voxelization to somewhere between 1/2 and 1/25 of what it would be, depending on how detailed the meshes are. So basically, it's necessary to make voxelization viable at runtime. However, that means that whenever the shape changes, something needs to inform FAR of that. I believe I did tell NathanKell what he needs to do to make that work, and Crzyrndm should be aware of what's needed as well, so pParts and pWings should be compatible as soon as nuFAR is out for reals. Also, I'll deal with the saving of flight GUI data better. I've been a little frustrated with the stab augmentation settings not saving.

@HawkedUpSpace: Yes, FAR is completely gone. There is absolutely no room for aerodynamics improvement since Squad hacked together a barely functioning model. There have been no improvements at all, and all the posts including my status updates are simply a ruse. You've figured us out, time to go home now. @Nerd1000: I can see that happening. One of the things that should be accounted for is the area ducted through the fuselage for the intakes, but I think the first version is going to be released without that. The gear changing the area that much is likely an issue of it changing where the voxels are relative to the wing, causing less voxels to exist for the wing in the gear-down case than the gear-up case. I've got an idea of how to fix that though.

@Virindi: Yeah, I've got an idea on how to handle that. Should be relatively simple. @John FX: Interesting. We'll see how things pan out, but since the drag multipliers don't change much, with most of it going into how it processes the cross-section, I guess that's not surprising if you've already got something good. Also, Glad to see someone wants more detail on their debris. I mean, the default vessel count is 250k, and if I can get the voxelization efficient enough to push that higher I will.

@KillerRaccoon: Soon, hopefully. I'm doing some diagnostics and stuff to make sure it's good, and possibly adding one more tweak to voxelization before calling it good. Maybe some more polish since the cross-section overlay is drawn underneath see-through parts instead of on top like it should be. @ObsessedWithKSP: The reasoning is that it's somewhat necessary for rockets with wide fairings. Those create a lot of drag and body lift and using stock gimbal ranges makes those rockets prone to flipping even though they should be fine. A 1.5x increase is rather small, but it makes a big difference. @jofwu: Planes built without accounting for the same kind of body lift and with no need to area rule don't work well? That's not surprising at all. The stock craft are being redesigned. Yes, things are changing that much.

etheoma, wouldn't it be more helpful to stop mentioning the dependency everyone knows about (ModuleManager) and start mentioning the dependency that no one knows about (ModularFlightIntegrator)? Surely you know about that one if you've got it working, right?