The war against lag: Anti-lag fairings

[Rassa Farlander]

I like this idea Not sure if the devs would implement a thing like this but Im all for something that combats lag

[Psycix]

Phycix, if Procedural Fairings is still current and in development, why not talk to the person developing it to see if a "proof of concept" can be made.

Was thinking that as well. I'll send him a PM.

Fine, that works then. But what prevents someone from strutting the fairing to hell to prevent it from failing and physics suddenly being enabled on the payload?

I don't think you're supposed to be able strut the fairing. Is that even possible with the current procedural fairings mod?

Why would two payloads, with the same sizes, have different masses?

And if we did this, if there are fuel tanks in there do we base the fairing mass on the full mass or empty mass?

Good question.

Although the volume might be the same, I'd say that a heavier payload comes with a heavier support structure to support the weight. Think of the fairings being custom made for both payload volume and mass.

Of course the fairing weight is then based on the mass it starts with. The fairing base doesn't crossfeed, and fuel lines should not be able to cross the fairing hull. Moreover engines aren't operable while within the fairing since their physics are frozen anyway. Actually, perhaps no component should be accessible at all.

Either the fairing would allow you to launch that flimsy payload without the huge girder mess, at which my "inconsistency" complaint still stands, or it would break, at which point we're back to where we are now.

You're forgetting that the root purpose of this whole fairing idea is not to support the payload, but to greatly enhance the performance of the game.

The main reason the fairings have to work this way is a result of freezing physics without gameplay consequences that can be used to cheat or exploit.

-The fairing supports the payload, because that's what freezing physics will practically do.

-The fairing has extra mass, this is for balancing reasons, because that's what the weight of the support structure you'd otherwise have in the form of girders and struts.

-The fairing is breakable, because that is realistic, balances compared to conventionally strutted payloads and in general prevents the problem of abuse as invulnerability capsules.

I think that this approach will make sure that the anti-lag-fairings cannot be used to cheat structural physics and allow us to enjoy massive FPS improvements during launch.

[ferram4]

I don't think you're supposed to be able strut the fairing. Is that even possible with the current procedural fairings mod?

Yep! The way struts are currently coded, while you can't start them from the fairing and then attach to whatever else, you certainly can do it the other way around. You'll still have the lag situation going on, just with people strutting the payload fairing to hell rather than the payload itself. You could argue that it's entirely their own fault in that case, that they could launch a smaller payload with a smaller fairing on a more gentle launch vehicle and use docking to put it together in orbit, but the same argument can be used for the current strut-monsters people insist on launching.

Good question.

Although the volume might be the same, I'd say that a heavier payload comes with a heavier support structure to support the weight. Think of the fairings being custom made for both payload volume and mass.

Payload fairings (at least in real life) are just aerodynamic shells that can only support the aerodynamic loads on them; their mass shouldn't vary with anything other than size, since they only need to support themselves and aerodynamic forces. The payload fairing base could vary in mass since that would be responsible for supporting the payload.

Of course the fairing weight is then based on the mass it starts with. The fairing base doesn't crossfeed, and fuel lines should not be able to cross the fairing hull. Moreover engines aren't operable while within the fairing since their physics are frozen anyway. Actually, perhaps no component should be accessible at all.

I guess this is reasonable, especially since if you didn't do that you'd have to recalculate the mass and MOIs of the payload every physics frame as the mass distribution changes.

You're forgetting that the root purpose of this whole fairing idea is not to support the payload, but to greatly enhance the performance of the game.

The main reason the fairings have to work this way is a result of freezing physics without gameplay consequences that can be used to cheat or exploit.

-The fairing supports the payload, because that's what freezing physics will practically do.

-The fairing has extra mass, this is for balancing reasons, because that's what the weight of the support structure you'd otherwise have in the form of girders and struts.

-The fairing is breakable, because that is realistic, balances compared to conventionally strutted payloads and in general prevents the problem of abuse as invulnerability capsules.

I think that this approach will make sure that the anti-lag-fairings cannot be used to cheat structural physics and allow us to enjoy massive FPS improvements during launch.

I understand that it would enhance the performance of the game, but optimizations come at a cost: we could greatly improve the game's performance by combining every rocket stage into a single rigid body, but it would be at the cost of removing the current part failure mechanics (which would probably require a lot of code to re-implement in that situation), which is probably one of the best game mechanics KSP has. I still have reservations about how strutting the fairing to hell could be used to make invulnerability capsules.

Then there are the glitches this would cause. Do you remember the bug where rockets would lose parts when coming out of timewarp due to how physics restarted? You're essentially proposing a situation where a bug similar to that is very like to occur.

Here's the most common failure I see happening for a standard rocket using this: the rocket has a payload that is somewhat flexible; not very flexible, not flimsy, but it does deform a little under thrust. The flight scene loads, and its physics are frozen while it is in an un-deformed state. The rocket launches, and once out of the majority of the atmosphere, the player detaches the fairing; however the thrusters are still running. Physics restarts on the payload, and now one of two things happens: 1) the payload glitches on physics start and the rocket suffers spontaneous disintegration; 2) the payload suddenly deforms under this new load and it springs around a bit; the rocket becomes difficult to control until this settles down, possibly losing control in the process. The larger and more flexible the payload, the more problematic option 2 will be; it may even turn into a problem if the throttle is off for large enough payloads.

I really worry about how the inconsistency in handling the payload's physics would work out in-game.

[e-dog]

Was thinking that as well. I'll send him a PM.

I decided to reply here.

Calculating mass, center of mass and inertia tensor to replace a bunch of bodies with a single one is easy.

Disabling/removing part rigid bodies is problematic. Setting them to kinematic and disabling collisions might work, but I didn't try that.

Removing them will cause a lot more problems, because they must be recreated, and all their parameters must be stored, saved to persistence etc.

Removing parts is likely no go. If you know how to create parts dynamically in flight, tell me. I don't know how to do it.

So even if disabling rigid bodies and hiding models will work, it's still a question how it will affect performance.

But parts aren't just physics, a lot of code is run processing them. Some, like fuel tanks, change their mass as the result, which should cause recalculation of the total mass parameters used to replace them, adding more processing too.

I'm not sure that all stock parts will work properly if their rigid bodies are disabled. Needs testing.

Then, there are mods. Some like Damned/Infernal Robotics won't work because they move rigid bodies. Others might break too for various reasons.

All in all, I'd rather see someone first make a proof of concept code that replaces a bunch of parts with a single rigid body and restores them later.

My estimate is it's a lot of work. I'm fine with how it works now (it won't help my huge space stations anyway), and I have a lot of other stuff to do to try it anytime soon myself.

That said, I'd like Squad to join most (if not all) rigid bodies of a vessel together into a single body and simulate internal stresses from collisions and external forces like thrust and gravity. That'll eliminate wobble completely and improve performance of vessels with many parts (just try timewarping a large space station to switch off physics and compare frame rate). And you'll still be able to break ships.

But that's a lot of work too, and it'll break some mods.

[Dunbaratu]

Either the fairing would allow you to launch that flimsy payload without the huge girder mess, at which my "inconsistency" complaint still stands, or it would break, at which point we're back to where we are now.

No, we would emphatically NOT be "where we are now". You are (perhaps deliberately) forgetting that the goal here is to reduce FPS lag, NOT to reduce breakability. Others including you brought up the potential to change the breakability of the craft as an argument against the idea, but to pretend that it was the original intent is to argue against a dishonestly caricatured strawman of the position. Your last sentence there claims (read it again) that "it would break, at which point we're back where we are now". That's a claim that presumes the goal here was to prevent breakage when it wasn't. If someone has come up with a way to do it that does in fact preserve the exact same breakability, but with faster FPS, then it would be exactly what the suggester WANTED.

Arguing that making fairings that preserve the exact same breakability with less FPS lag is just not possible, and arguing why, is a fine argument, and you've been making that argument fairly well here in the thread. But then at times you edged over into pretending that less breakability was the intended GOAL and when you do that you start arguing against a strawman, which is not being fair.

Edited August 18, 2013 by Steven Mading

[ferram4]

No, we would emphatically NOT be "where we are now". You are (perhaps deliberately) forgetting that the goal here is to reduce FPS lag, NOT to reduce breakability. Others including you brought up the potential to change the breakability of the craft as an argument against the idea, but to pretend that it was the original intent is to argue against a dishonestly caricatured strawman of the position. Your last sentence there claims (read it again) that "it would break, at which point we're back where we are now". That's a claim that presumes the goal here was to prevent breakage when it wasn't. If someone has come up with a way to do it that does in fact preserve the exact same breakability, but with faster FPS, then it would be exactly what the suggester WANTED.

My "we would be back where we are now" quote referred to the fact that suddenly, with the fairing broken, the physics of the payload has to be simulated again; whatever fps benefits that would be gained from freezing it would instantly be negated the second physics started again. I appear to be failing to be coherent, and I apologize for any confusion there. It should have read something closer to, "Either the fairing would allow you to launch that flimsy payload without the huge girder mess, at which point my "inconsistency" complain still stands, or the fairing would break, at which point we're back to where we are now with respect to the physics-based framerate issues." I suppose I should note that I'm making the assumption that the fairing strength isn't based on the payload "strength" in any way, since two similar payload fairings failing at different loads entire based on how overbuilt the payload is would be incredibly strange.

Arguing that making fairings that preserve the exact same breakability with less FPS lag is just not possible, and arguing why, is a fine argument, and you've been making that argument fairly well here in the thread. But then at times you edged over into pretending that less breakability was the intended GOAL and when you do that you start arguing against a strawman, which is not being fair.

Fine, so then the mess of girders and struts around the payload will need to be required for the payload fairing to freeze physics properly, correct? Or some type of similar structural reinforcement, right? Every argument here has focused around reducing lag by reducing the number of parts simulated and the number of struts needed. It always comes down to the number of struts needed; why else would Psycix have brought up this picture of what he doesn't want to have to do if the goal isn't to remove the need to structurally reinforce the payload to the necessary degree to launch it? Further, I would quote this from the OP:

-The fairing "protects" the part from structural failure as a result of wobbling or G-forces. (For realism, you can think of the parts being structurally attached to and supported by the fairing.)

-Less flailing, wobbling, wiggling and whatnot that makes attitude control a PITA. (We can actually steer.)

This implies that an intended benefit of this is that a structural weak payload can be launched when it otherwise couldn't; that part of the plan was to reduce breakability, you know, what you called a strawman?

Further, I would argue that even if the reduced breakability did not appear to be an intended goal, it would be a consequence of implementation. Further, I would argue that if a feature can be exploited, it will be exploited by the userbase, and as far as I can see, there is no reason why any of these fairings could not be strutted until they had effectively infinite strength, creating a magical cocoon of protection from forces that could cause the payload to break. I see no reason to separate intended and unintended consequences since, in the final analysis, intent doesn't change how the code runs.

My argument isn't based on just what is proposed, but on what the consequences of that implementation would be. This strikes me as the type of system that can be very easily exploited and that would be exploited very quickly since the potential gains in protection from structural failure are incredible. I also have concerns that the suggestions made to try and fix the proposal are a little too band-aid-like and will start to inspire fridge logic in players and might break immersion and cause frustration.

[Kerbin Dallas Multipass]

Just a thought, no idea if this is in any way feasible:

We have subassemblies coming, right?

Why not have a "certification process" for payloads that travel inside fairings? The subassembly gets taken to a kerbal test facility where it is rattled around by all sorts of g forces. If it breaks you are not able to transport it within the fairings.

Perhaps the game could work out center of mass, "wobblyness" and so on in that test to generate a simplified representation of the payload.

This process would make sense from a gaming perspective, would avoid cheating and the engine would not have to simulate the wobbling of each individual rear view mirror of each rover during launch.

[arq]

I like the OP's idea. Using a part with the proper mass, CoM, Rotational Intertia, Drag, and CoD for the innards would indeed allow identical physics. If something doesn't hold together in this game you can always just strut the #*% out of it and it will (and struts are currently weightless anyway), so the 'internal structural stability' argument is not a big issue IMO (just pretend there is a spiderweb of struts inside that get jettisoned with the fairings). Disabling the physics on those parts would be a massive computational saving on its own (and is the current bottleneck), so disabling rendering is probably unnecessary. The only issue I see is at the instant that the fairings are jettisoned and physics are enabled (stuff might explode unexpectedly), but maybe they could only be staged when the engines are off.

[Zaeo]

Coming from a standpoint behind making ksp more "part friendly.."

Unrendering parts before launching, it is a fools dream for the scale you desire. However, for things like engine fairings, it actually is a decent idea.

Unrendering, but not disabling physics. This lets you cut down on the Face count dramatically, as engines tend to be rather high poly. It helps the low end pc guys out, and generally improves performance of multi-stage vehicles.

Multiple parts under the fairings would be excessive, and require more than you think to do coding wise, which is a BIG step backwards in terms of productivity, and would have one major drawback.

If you didn't lag launching it, as soon as you jettison the fairings, you will experience extreme lag as all the parts render, Plus physics would freak out and rip the craft apart 9 times out of 10. Sure, you might have a stable orbit, but at the cost of "loosing things to do" because you are able to launch whole pre-fab'ed structures without effort, thus resulting in loss of interest, and the relentless "When is the next patch" cycle will become that much more vicious.

My vote? Yes and no.

Yes for simple existing fairings to unrender excessive faces of an engine.

No for the "almighty procedural fairing".

[Psycix]

My "we would be back where we are now" quote referred to the fact that suddenly, with the fairing broken, the physics of the payload has to be simulated again; whatever fps benefits that would be gained from freezing it would instantly be negated the second physics started again.

A crash will indeed be as laggy as before.

Succesfull launch will not be, as by the time the fairing separates and the payload starts to simulate, most of the rocket is already gone. We all know rockets get wider towards the bottom.

This implies that an intended benefit of this is that a structural weak payload can be launched when it otherwise couldn't*;

*without strutting it to hell that is.

Still could if strutpocalypsed of course. (Which I'd rather not have to do because I like to play my games with more than 1 frame per second. I'd be fine with strutting if the game ran on a quantum computer.)

as far as I can see, there is no reason why any of these fairings could not be strutted until they had effectively infinite strength

Reason: Fairing base gets a force greater than X -> it breaks.

You can attach a million struts to it, but it still wouldn't be able to handle a certain jerk or acceleration.

The fairings itself wouldn't be struttable, and even if, it wouldn't help as the base is what carries the load.

the suggestions made to try and fix the proposal are a little too band-aid-like and will start to inspire fridge logic in players and might break immersion and cause frustration.

The proposal was not a fully worked out concept the moment it was posted (and still isn't). Throughout the the thread people discover new problems, which are then addressed. This develops the concept until it is accepted by all parties (aside from the people who think it is "simply unethical" because that is a matter of opinion)

Just a thought, no idea if this is in any way feasible:

We have subassemblies coming, right?

Why not have a "certification process" for payloads that travel inside fairings? The subassembly gets taken to a kerbal test facility where it is rattled around by all sorts of g forces. If it breaks you are not able to transport it within the fairings.

Perhaps the game could work out center of mass, "wobblyness" and so on in that test to generate a simplified representation of the payload.

This process would make sense from a gaming perspective, would avoid cheating and the engine would not have to simulate the wobbling of each individual rear view mirror of each rover during launch.

I was thinking something like this as well, and while it would be cool, implementation would have to modify the game quite a bit.

Here's the most common failure I see happening for a standard rocket using this: the rocket has a payload that is somewhat flexible; not very flexible, not flimsy, but it does deform a little under thrust. The flight scene loads, and its physics are frozen while it is in an un-deformed state. The rocket launches, and once out of the majority of the atmosphere, the player detaches the fairing; however the thrusters are still running. Physics restarts on the payload, and now one of two things happens: 1) the payload glitches on physics start and the rocket suffers spontaneous disintegration; 2) the payload suddenly deforms under this new load and it springs around a bit; the rocket becomes difficult to control until this settles down, possibly losing control in the process. The larger and more flexible the payload, the more problematic option 2 will be; it may even turn into a problem if the throttle is off for large enough payloads.

The solution to number 2 is simple, throttle down while separating or do it right after separating a stage. (TWR is generally lowest after stage sep when the current stage is full) You could jettison the fairings together with a stage sep since MECO puts the craft in microgravity anyway. Or separate them while in orbit.

Option 1) would not happen with any sensible payload which does not glitch out and explode if deployed on the launchpad. On the pad an entire rocket's physics unfreeze from a neutral state as well, and most of the time this works fine!

@Zaeo

Rendering cost is nothing compared to physics calculations. While I think it is indeed a sensible thing to be implemented, the effectiveness of your proposal is like adding a bottle rocket to the first stage of a Saturn V.

Edited August 19, 2013 by Psycix

[Dunbaratu]

My "we would be back where we are now" quote referred to the fact that suddenly, with the fairing broken, the physics of the payload has to be simulated again; whatever fps benefits that would be gained from freezing it would instantly be negated the second physics started again.

Okay fair enough, but that FPS lag would only apply when the break happens. Right now the lag happens ALL the time whether its a good successful launch or not.

Fine, so then the mess of girders and struts around the payload will need to be required for the payload fairing to freeze physics properly, correct? Or some type of similar structural reinforcement, right? Every argument here has focused around reducing lag by reducing the number of parts simulated and the number of struts needed. It always comes down to the number of struts needed; why else would Psycix have brought up

By reducing the number of struts RENDERED, not the number NEEDED. But again, the weakest parts in the game, the struts, being the only allowed way to break tree structure is a secondary problem. If you could break tree structure with more formidable parts then the need to superstrut would be reduced. The idea that its being realistic that you can't have two girders attached to the same part is ridiculous. No that's not realistic at all. The need for the excessive number of parts because struts are the only way to make a loop structure is an artificial simulation artifact *in the first place*.

This implies that an intended benefit of this is that a structural weak payload can be launched when it otherwise couldn't; that part of the plan was to reduce breakability, you know, what you called a strawman?

Incorrect. The inability to launch being talked about was due to CPU lag not due to breakability.

Further, I would argue that even if the reduced breakability did not appear to be an intended goal, it would be a consequence of implementation.

And that's an okay argument to make, but please stop lying about intent. Telling people they are trying to cheat when they're not is an insult that will make them not listen to you.

[ferram4]

Reason: Fairing base gets a force greater than X -> it breaks.

You can attach a million struts to it, but it still wouldn't be able to handle a certain jerk or acceleration.

The fairings itself wouldn't be struttable, and even if, it wouldn't help as the base is what carries the load.

If that comes with similar crush / tensile failure forces for all parts, then I'm fine with it (which I would actually like a lot). If it's a special workaround for the fairing base only, then it begs the question of why the fairing base needs special failure criteria, above and beyond any of the other parts carrying loads.

The solution to number 2 is simple, throttle down while separating or do it right after separating a stage. (TWR is generally lowest after stage sep when the current stage is full) You could jettison the fairings together with a stage sep since MECO puts the craft in microgravity anyway. Or separate them while in orbit.

Doesn't this essentially require the player to be aware of an issue in the games code an make decisions to try and avoid it? When the "parts separating off of ships coming out of timewarp" bug occurred, the problem could be gotten around by slowly coming down from timewarp, but that didn't justify leaving the issue unsolved. Why is it the player's job to avoid issues caused by code implementation?

Option 1) would not happen with any sensible payload which does not glitch out and explode if deployed on the launchpad. On the pad an entire rocket's physics unfreeze from a neutral state as well, and most of the time this works fine!

First, the bug I mentioned above had the entire rocket's physics unfreezing coming out of timewarp and things still went wrong. Second, dealing with the entire rocket's physics unfreezing is probably easier than dealing with trying to connect a new group of physics objects to a group of currently active physics objects.

By reducing the number of struts RENDERED, not the number NEEDED. But again, the weakest parts in the game, the struts, being the only allowed way to break tree structure is a secondary problem. If you could break tree structure with more formidable parts then the need to superstrut would be reduced. The idea that its being realistic that you can't have two girders attached to the same part is ridiculous. No that's not realistic at all. The need for the excessive number of parts because struts are the only way to make a loop structure is an artificial simulation artifact *in the first place*.

I don't think that rendering is actually any significant part of the lag in-game, unless you misspoke there. I know the requirement of a tree structure isn't realistic, but I'd rather the unrealistic requirements be consistent rather than change based on whether the parts are in a fairing or not.

Incorrect. The inability to launch being talked about was due to CPU lag not due to breakability.

Then perhaps Psycix could explicitly state what his statement in the first post ("The fairing 'protects' the part from structural failure as a result of wobbling or g-forces") referred to: being able to launch payloads (that otherwise couldn't be launched) without needing to consider the structure necessary to keep them from falling part or wobbling and phantom forces caused by simulation errors due to huge lag. If it is the latter one, then you are correct.

And that's an okay argument to make, but please stop lying about intent. Telling people they are trying to cheat when they're not is an insult that will make them not listen to you.

This feature effectively implements the inertial dampers from Star Trek as a consequence of how it functions. Wondering whether inertial dampers are a part of the plan is one of the first things I think about, since my first thought about features is "how can this be exploited?" "how can I twist this to my advantage?" "how can I break this so it works in my favor?" If anything, I'm thinking about how I would use this to cheat and get things to orbit far more easily than could otherwise be done.

[iueras]

Just so I am clear, the biggest argument against this massive FPS gaining feature is that some people might purposefully try to break it and "cheat" by launching bigger payloads than they would be able to otherwise... in a SINGLE player game, right?

Ferram, don't get me wrong, I LOVE the work you have done, and for what it is worth I am more on the realism side of things... but denying a feature that would help many tremendously improve performance because someone else might want to use it to break realism in their own single player universe seems a little silly. You could always just not put payloads in it that wouldn't work otherwise.

Edited August 20, 2013 by iueras

[ferram4]

The single biggest argument is that it results in different physical laws inside and outside the fairing; the possibility of launching otherwise unlaunchable payloads is a possible consequence of this. Unless the fairing is set up so that its strength is directly proportional to that of the payload, so that a force that would cause the payload to break breaks the fairing, causing physics to start acting on the payload, the world is inconsistent.

Then, though it's more mundane, is the issue of how the physics engine reacts to a single payload "part" being replaced with the assembly of parts that the payload is made up of; this is an opportunity for incredibly nasty physics glitches to occur, which could range from the rocket merely twitching as the payload physics start to it being spun around like mad or exploding if things glitch enough.

Finally, yes, it is a single player game, but that doesn't mean that we should argue that exploits should be left in the final product because "you can just not use it." What if I'd like to have a version of anti-lag fairings that doesn't allow payloads like that to be launched? What if I want fairings at all? I wouldn't expect any of the devs to code two different fairing types, one that packs the payload so that physics is run on it and another that doesn't but blocks aerodynamics code from running on it.

If this was a mod, the "single player" argument would have a point, but it's not; it's proposed as code for the stock game, so the fact that it could be exploited, perhaps unintentionally (since the most common way to find out your payload isn't strong enough is that it breaks on the way up) makes this a problem I'll have to face to. It'll be like trying to design planes with the infiniglide bug; your ability to design things properly runs into the issue of just being able to twitch the control surfaces to go faster. In stock KSP we can't get around that bug; why wouldn't freezing the payload's physics have a similar effect of a positive benefit that should definitely not be there?

[Artophwar]

I am pretty certain that parts are already not rendered when inside a fairing using UNITY's built in Occlusion Culling as they are blocked from the camera by the fairing it self. So if you use fairings you already have reduced the amount objects rendered to only each side of the fairing, which is usually only two parts. It is the physics that cause the lag, and it is the physics that make the other part of the idea just not feasible. As many others have pointed out, you cant just suddenly activate the physics on all these objects as crazy glitches will happen.

Edited August 20, 2013 by Artophwar

[pizzaoverhead]

As many others have pointed out, you can't just suddenly activate the physics on all these objects as crazy glitches will happen.

Do we know this? The only way to be sure without a dev joining the conversation is for a modder to try it. "There could be bugs" is a poor reason not to try something.

[Zaeo]

Do we know this? The only way to be sure without a dev joining the conversation is for a modder to try it. "There could be bugs" is a poor reason not to try something.

We know this from several other physics simulators that are out there.

Take for example, Universe sandbox.

The faster time goes, the more calculations have to be crammed into a shorter period of time, resulting in a loss of physics accuracy.

Take for example, take two galaxies roughly 400 million light years from eachother*relatively close, in terms of galactic distances goes* As you accelerate time to 1,000 years a second and beyond, they begin to look like giant solar systems in real time, you see the particles rotating around the center of gravity*galactic core*.

The faster time goes, you begin to see some strange things occur... As star *particles* get a close approach to the galactic core, it accelerates FAR beyond the speed of light, and increased further, even the galactic cores begin to break down and get slungshot from eachother at several times the speed of light, leaving the outer rings to drift endlessly without anything to rotate around but themselves.

The point that I'm trying to get at, is the "faster" you are forced to do physics calculations, the more inaccurate they become. shutting off physics of everything in this "magical fairing", then suddenly enabling them, WILL rip the monstrosities apart that it hides, completely and utterly nullifying any "reduced lag" benefit you get for actually launching it to space, dealing with the "cruddy" launch lag over an extended period of time.

Certainly, under a certain number of part counts, the effect is less and less noticeable, but it still exists. More parts just amplifies it immensely.

To this day, the best way to reduce lag would be for unity to support x64 without the game breaking bugs that their current release has.

4 cores calculating physics +*4 threads* vs 1 core, and up to 64 gigs of ram supported will fix almost ALL of the lag issues up to a point of maybe...3000 part behemouths? of course, old hardware is old hardware. *i know it is more involved than that, but these two things will seriously help*

Understand now?

PS: never underestimate the diversity of the internet. you have fools who play video games, but there are also quite a few tech-savvy gamers out there as well. don't rely on "Devs" and "modders"

Edited August 20, 2013 by Zaeo

[pizzaoverhead]

The theory being suggested is that resuming physics would have an effect similar to the Kraken, moving and detaching parts or similar. I hypothesise that slowdown due to extra processing during resuming physics would be dealt with the same as slowdown due to part-heavy craft; using the physics delta time. Any glitches should be visible under regular heavy load, unless the effect is due to resuming physics. As we are potentially dealing with situation-specific effects, comparison with other physics simulations is unhelpful.

We have exactly one example of suddenly resuming physics, acting on the whole craft at once: Leaving on-rails physics, when leaving time warp for example.

If there is any evidence of the Kraken effect, I would like to see it.

This is why we need real-world data from experimentation by either the devs or modders.

Edited August 21, 2013 by pizzaoverhead

[Cannibal]

Very bad idea. You want to disable all the phyics within your magic bobble leading to the ability to launch the most rediculous constructs to space that normally would completely distort the rocket and everything else?

What about torsion forces and inertia of your giant part? The fact its stable in space doesn't mean it is stable during launch with high G-stress.

This would completely destroy the idea of KerbalSpaceProgram.

What you want is a magic cheat box to bring your too big constructs with a too slow computer in orbit - the thread should be renamed accordingly.

Just use docking!

You cannot launch anything.

I have to disagree with your assessment. The game suffers badly from structural stability problems (attach main sail --> small silver tank --> other tank --> command pod and watch the rocket bend and flex like jelly at the connection between the silver and other tank), and will suffer bigtime from aerodynamic problems with the 10's of struts needed to stabilize a naked/rough edged payload since we don't have a stock way of putting a custom launch fairing around a payload.

A proposal like this looks good now and will be an absolute necessity once realistic aerodynamics come in.

Some real world examples of why flexible fairings are a necessity if realistic aerodynamics come in:

1) Proton rocket configured to launch a single dense object smaller than the central column (big diameter)

2) Proton rocket configured to launch 3 GLONASS M satellites side by side has a fairing slightly larger than the rocket body, but shown here wrapped in a thermal management sheath.

3) Proton rocket diagram showing it with an optional very large diameter fairing for a very wide payload

[Psycix]

We know this from several other physics simulators that are out there.

Take for example, Universe sandbox.

The faster time goes, the more calculations have to be crammed into a shorter period of time, resulting in a loss of physics accuracy.

Take for example, take two galaxies roughly 400 million light years from eachother*relatively close, in terms of galactic distances goes* As you accelerate time to 1,000 years a second and beyond, they begin to look like giant solar systems in real time, you see the particles rotating around the center of gravity*galactic core*.

The faster time goes, you begin to see some strange things occur... As star *particles* get a close approach to the galactic core, it accelerates FAR beyond the speed of light, and increased further, even the galactic cores begin to break down and get slungshot from eachother at several times the speed of light, leaving the outer rings to drift endlessly without anything to rotate around but themselves.

What do inaccuracies in sped up physics have to do with this? We're freezing it, not speeding it up.

Actually, we're saving CPU so that the rest of the rocket can simulate lagless AND accurately.

The point that I'm trying to get at, is the "faster" you are forced to do physics calculations, the more inaccurate they become. shutting off physics of everything in this "magical fairing", then suddenly enabling them, WILL rip the monstrosities apart that it hides, completely and utterly nullifying any "reduced lag" benefit you get for actually launching it to space, dealing with the "cruddy" launch lag over an extended period of time.

Speculation.

An entire rocket can go from frozen to an acceleration of 9.81 without spazzing out.

Why would a part of a rocket not be able to unfreeze, especially in zero-G?

Certainly, under a certain number of part counts, the effect is less and less noticeable, but it still exists. More parts just amplifies it immensely.

To this day, the best way to reduce lag would be for unity to support x64 without the game breaking bugs that their current release has.

4 cores calculating physics +*4 threads* vs 1 core, and up to 64 gigs of ram supported will fix almost ALL of the lag issues up to a point of maybe...3000 part behemouths? of course, old hardware is old hardware. *i know it is more involved than that, but these two things will seriously help*

Understand now?

PS: never underestimate the diversity of the internet. you have fools who play video games, but there are also quite a few tech-savvy gamers out there as well. don't rely on "Devs" and "modders"

Such a fundamental engine change is not gonna happen.

I completely agree that KSP would be better off running on a more powerful engine where physics run in a multi-threaded, GPU-accelerated environment. The fastest way to achieve this is to rebuild the game from scratch on a different engine.

We are stuck to 1 CPU core, and there is no way around this. If we want to get the most out of it, sacrifice is required: part count limitation, slow gameplay and lag, inaccurate physics, or tricks that lower the load on the simulation like physics-freezing fairings. Pick your poison.

The fairing is not a perfect solution, but it's as good as it gets in this non-perfect engine.

[allmappedout]

For my 2c, having a sudden loading of physics impacts a craft - we can see this on the launchpad. A craft that is put together in the VAB may all of a sudden just collapse in on itself sometimes, and then other times it may be okay to launch. The physics calcs aren't perfect, and loading an amount of physics all of a sudden (as is the case from purple light to green light pre-launch) can cause spikes in the calculation which can cause issues.

Not saying this would definitely happen, but also not saying it definitely wouldn't, and if it ever did, I'd be a bit frustrated that my vehicle tears itself apart after getting it up there (I prefer it to fall apart on the pad )

[Winter Man]

Even if ejecting a hidden thingymabob from a fairing induced a little temporary lag, you could hide it with an animation of the fairing slowly detaching and locking out controls for a couple of seconds.

[Rascal Nag]

I don't think I can get past the fact that this would make things inside fairings invincible. And as people said, once the fairing opens, the part count shoots up and all of it is wasted. It seems like less of a performance piece, and more of a "make launches easier" piece. While that may not be the goal of the part, it certainly seems like the end result. My advice would be to break up payloads that are too big and awkward to lift in one launch and dock them later, or aim to make them as lean as possible.

I still think fairings should be added, of course. And they still could make launches easier - but it would be through aerodynamics alone rather than through turning off physics for a payload.

[Psycix]

I don't think I can get past the fact that this would make things inside fairings invincible.

But the fairing itself is vulnerable.

And as people said, once the fairing opens, the part count shoots up and all of it is wasted.

By which time at least the first (and by far the largest) stage of the rocket has already been separated.

People somehow keep forgetting this, so I'm going to run a simple thought experiment for you guys. The numbers are arbitrary but do help showing how the lag is kept under control through the fairings.

Assume our CPU can simulate up to 300 parts smoothly.

Imagine this situation:

-200 part lifter

-200 part payload

-100 part structural reinforcement which the payload would need to be reinforced with for launch.

Together they are 500 parts and would overstrain the CPU causing massive lag.

So now we slap on an anti-lag-fairing. The fairing freezes the payload. The structural reinforcement no longer needs to provide structural integrity for launch and is reduced to 10. The fairing base weighs a bit more than this reinforcement would.

The 200 part lifter + fairing lies within the CPU budget and flies up smoothly. As stages separate, the lifter reduces to an upper stage of 50 parts.

Now we separate the fairing where payload physics comes back into play. Let's see what we got: 50 part lifter + 200 part payload + 10 part structure = 260 parts. 260 parts are within our budget and therefor we can enjoy a lag-free flight while we circularize our orbit.

You can benefit even more by, for example, encapsulating a rover in it's own fairing, which is kept closed until the rover deploys and separates from the lander.

My advice would be to break up payloads that are too big and awkward to lift in one launch and dock them later, or aim to make them as lean as possible.

Well, yes, breaking things up in multiple pieces and docking them together is easy and effective. The problem is that once everything is assembled, the end result is wobbly, contains extra parts (docking ports), and perhaps even more if you need RCS on every module to dock.

Want to use something like quantum struts to reinforce the docking connections? Part count goes through the roof.

This is the reason I attempt to send up as much as possible in one monolithic unit: No overhead parts and strong structural connections.

So while the split-up approach seems to be an answer to the lag, it is actually counter-effective after assembly!

[Dunbaratu]

I don't think I can get past the fact that this would make things inside fairings invincible.

And I can't get past the fact that people keep claiming this as a "fact" instead of actually reading what was proposed. The proposal does not call for the fairings to be invincible.