Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Well... what does your rocket look like? That should give us something to start with. Problems I can think of: If MechJeb is in control during launch, that could be the problem; it doesn't know how FAR's controls work, so what ends up happening is it tends to over-control and over-correct the rocket. There's also the possibility that you're just asking for an absurd amount of force to be applied to the rocket to correct its trajectory; if you're flying at full thrust low in the atmosphere when you do this then FAR's aerodynamics will probably apply forces that would tear the rocket apart in a real scenario. Another possibility is that you're connecting a very heavy part (say a fuel tank) to a very light part (say, a decoupler) that happens to be right near the center of mass of the rocket; such joints are naturally more flexible due to the way physics works in-game and if you manage to get control inputs strong enough to flex the rocket that will ensure that the maximum amount of flexing occurs due to the large amounts of mass on either side of the joint.
  2. ferram4
    @arbpotatoes: I believe that I've fixed this issue in my build; would you mind providing a craft suffering from the issue and the list of mods necessary for it so I can work more on it? @asmi: The "Launch Clamp Break Force / Break Torque set to Infinity" message doesn't have anything to do with the extra clamp reinforcing; that message has to do with the stock joint force limits being set to huge values to try and protect the joint from what happens if the extra stiffness causes the vessel to twitch too much. I think I successfully fixed the clamp issue, since I've managed to get it to fall to the pad as one piece and break apart. The random failures seems like it's a combination of stock breakForce and breakTorque values (which are each 22 incidentally) for the parts (which were originally set for stock 1.25m parts) being used on parts that are a little to large for such weak values, the larger joint forces that this plugin causes in general, and Real Solar System + the Launch Clamp shifting on load bug causing very high forces when the rocket loads. I honestly wonder what's causing the Launch Clamp bug, since it seems to be somewhat intermittent; perhaps a floating origin issue? @NathanKell: Based on the debug log, it seems like KJR works with Stretchy Tanks without your patch being needed. That said, the huge mass disparities the mod encourages easily overpower a lot of the rigidity that KJR adds; I don't know if they're really much I can do about that.
  3. ferram4
    I have noticed that Kerbals seem to jitter up and down a bit on the ladder, kind of like they're all incredibly excited for no reason, but nothing along the lines of slipping and falling off.
  4. ferram4
    If you're not using the most recent build, get it and see if that fixes the problem. If you are using the most recent build, go into the config.xml and set "debug" to 1, cause the issue, and post the entire output_log.txt along with a link to a craft with the problem with the minimum number of mods possible and a list (and hopefully links) to the mods necessary, and I'll look into it.
  5. ferram4
    @asmi: What does the output log say? I suppose I can add more code to make sure the extra launch clamp joints break properly. The large ASAS breaking is news to me; try lowering the damping values in the config.xml and see if that helps. @MOARdV: Known issue; see if lowering the damping values in the config.xml helps.
  6. ferram4
    I'm not surprised it's incompatible with Advanced SRBs; it's using a different PartModule, which means that KIDS wouldn't know to change it. I'll look into a fix.
  7. ferram4
    Actually... that indicates that the problem is more likely in FAR's modeling. The difference in real life is due to real gas effects, which include reacting flows; FAR does not model this at all, and it shouldn't appear until around Mach 10. I suspect that it's actually an error in how FAR accounts for lift from wings instead.
  8. ferram4
    It's possible that FAR isn't properly simulating aerodynamics for that shape; I'm going to look into the lift and drag of wings in large-scale stall and make sure that it is modeled correctly. It's also possible that the CoM on the Space Shuttle is further forward than yours is, and that's why it works. The fuselage has such a large pitching moment because most of the weight of the fuselage is at the back while most of the surface area is near the front, which means that the slight amount of lift created by the forward fuselage is more than enough to force it to pitch upwards. It's really not too far off reality, since even a uniformly dense fuselage tends to be unstable, especially at higher angles of attack.
  9. ferram4
    @Surefoot: There's nothing stopping a mod from making use of multithreading, but the problem is moving the data from the mod thread to the main Unity thread for physics calculations. There's also the issue that none of the Unity methods are threadsafe, and thus unusable outside of the main thread. @tech_op2000: Ultimately the problem is that your shuttle is stalling at the back before the front, and there are three things I can think of trying to fix that: Shift the wing forward a little bit and add a separate, highly swept tail at a slightly negative angle of incidence; this will cause the tail to stall much later than the other surfaces and to be less severely stalled at any angle of attack. Shift the majority of the wing forward and add a swept root extension just behind it, sort of an inverse of what you have going on at the front. This will have a similar effect as option 1. Put a heavy tank / counterweight near the front too shift the CoM further forward and compensate with more pitch control surfaces. A thing to keep in mind is that your tests were all done at Mach 0.5; this corresponds to compressible subsonic flow, which will behave much, much differently than the Mach 5 high supersonic flows you will encounter during reentry. In considering the high-AoA stall behavior at low Mach numbers you and trying to use that to judge supersonic performance you are doing the aerodynamic equivalent of designing an apple corer for the problem of peeling an orange. Your analysis of the wing alone also includes some messy data from the structural pieces down the center, which are affecting the numbers quite a bit, though it's difficult to say how much.
  10. ferram4
    Ah, that would explain it then. I'll consider that a known issue with Stretchy Tanks, to be dealt with at the same time as the pWings issue. In the meantime, version 1.2 is out, fixing the "don't decouple bug" and the "struts don't disconnect bug," at least in all the test cases I have done. It also fixes the other Infernal Robotics conflict. It also fixes the "decouplers don't apply ejection force bug" by way of applying a workaround that also happens to fix the stock "If struts interfere with decoupler ejection force bug."
  11. ferram4
    Wait a few minutes until v1.2 is out; people have weird issues with struts and fuel lines messing with decoupling in the current version.
  12. ferram4
    That falls under decoupler issues. It is known and has been fixed in my build; a fix should be out soon.
  13. ferram4
    @Herra Tohtori: Well, it depends on how different the masses between the parts are. If you're connecting a 1000 ton fuel tank to a 0.1 ton decoupler and expecting this to have no problems, you're too optimistic. Since Stretchy Tanks basically breaks physics by making gigantic, massive parts and then having them connected by a bunch of small, light decouplers and engines there is really nothing that will fix the wobbliness of Stretchy Tanks without adding in struts. With that in mind, I'll extend the decoupler-style stiffening to Stretchy Tanks to see if it helps; no promises, because the mod basically breaks the physics engine, but it should help. @Everyone having decoupler issues: I have that fixed and a new version should be incoming in an hour or so once I finish testing a new feature for even larger rockets.
  14. ferram4
    @pina_coladas: That's probably the case not liking the higher attachment forces; you can try increasing the linear damper value in the config to see if that helps. @Galane: Thanks, I reproduced the bug, and I think I know what's happening: the extra decoupler stiffening is interfering with the parts. I will make the exemption extend to extra decoupelr stiffening. @sirkut: Provide a copy of your output_log.txt (not KSP.log); that sounds like something critical nulled on physics start and prevented it from finishing properly. @Umlüx: You'll need to provide a craft file if it only involved stock parts. I have noticed issues where decoupler forces weren't applied, but not issues where stock parts would not decouple. @Zaran: The code currently excludes specific PartModule and Part types from being affected; you can't use it to exclude a specific part. I will investigate the issue Sum Dum though.
  15. ferram4
    @NathanKell: Just as a clarification, 64% scaling of rockets refers to diameters and lengths, correct? Which would mean that the constant for scaling areas would be 0.64-2, which works out to ~2.44.
  16. ferram4
    @Hodo: Turbojet got modified a bit; it's thrust falls off more gradually than it did before, but the other parameters should be balanced to compensate. @camlost: FAR already has a hypersonic aerodynamics calculated in; the nonlinear supersonic equations I use tend towards the hypersonic limit for assumptions of negligible viscous effects. I can't actually implement hypersonic aerodynamics including proper shock-boundary layer interactions without causing your processor to become an experiment in electrically-powered heating and KSP to drop frames like crazy.
  17. ferram4
    @Galane: Your idea for doing the physics lurch "off-screen" actually makes a fair bit of sense, though I'd invoke another constraint: instead of having unbreakable joints + suddenly load 1g, have breakable joints and gradually scale up gravity from 0.01g to 1g over the course of a second or two before giving control over to the player. That would allow the physics simulation to internally calculate the deflection needed without manually shifting parts around outside the context of the simulation, which has a tendency to cause Very Bad Things. The end result should be that if the clamps will still fail to hold the rocket that they will fail, but removes the large initial jerk and extra load at launch. I will have to look into implementing that tomorrow; thanks for the idea. @smunisto: And I think I know what's causing that. I added some code to manually break all strut connections when a stage decouples (somewhat leftover from trying to find a workaround for the "struts kill ejection force" bug). I'll look into fixing it. @bac9: The "decouplers not applying forces bug" is something that I know about, but I don't consider it particularly critical since it's also caused by stock struts; I didn't think that was what he meant, since I actually did have some issues during development where the parts would stick to the rocket. Realistically, the best way to solve both issues would be a refactoring of the decoupler code so that it broke all joints between parts on different vessels before actually applying the ejection forces. Main problem is currently it requires a serious workaround (essentially, a new decoupler module) to make it work currently. I will look into the parts failing on touchdown; I can't say I'm surprised, but it shouldn't be that severe; they should really just shear off, and at slightly higher velocities (read: ~15m/s). Odds are that the joints have become stiff enough that the current strengths are incapable of breaking them; as a temporary measure you can try looking in the config.xml and lowering the linear and angular "maxForce" values and decreasing the breakForce and breakTorque values to see if that helps.
  18. ferram4
    Well, to start you have a lot of wing for the size of the vehicle there. Is it using B9 jet engines? I haven't made any changes to mod engines, so they would be absurdly overpowered compared to the stock engines. It looks like you've just combined massive engines and wings with a tiny payload and successfully proved just how significant vehicle mass is in how it performs.
  19. ferram4
    I haven't seen any issues with things not properly decoupling; are there any particular parts / mods that that issue occurs with?
  20. ferram4
    Alright, version 1.1 is out, making the connections a little stiffer. For reference, a 3.75m KW Rocketry decoupler can now handle ~160 tons of payload at ~5gs without severe flexing, unless you're desperately trying to flex it. No promises if you try to go higher than that. Includes option to exempt specific part types or parts with specific part modules from having their joints stiffened to avoid conflicts with other plugin-based mods, if necessary. Documentation in the README. Bugfixes include: Doesn't conflict with Infernal Robotics anymore. Extra stiffening properly applied to radial decoupler connections. Procedural Fairings can't get magically stuck to the fairing base. BreakForce and BreakTorque no longer have any effect at all on connection stiffness, only failure criteria. Fixed situations where NullReferenceExceptions could be thrown.
  21. ferram4
    @MOARdV: I've made some changes that I think will stiffen things up more, but understand that asking too much of a particular joint will always cause issues. Procedural fairings not decoupling is something that I'll look into; a joint may not have been properly destroyed.
  22. ferram4
    @StarWaster: The only time "breakForce *= 1000" is called is for launch clamps; otherwise it changes nothing about the default breakForce or breakTorque other than to multiply by universal constants, which are set to 1 by default. In the other situations if a breakForce or BreakTorque was equal to zero the parts would separate instantly, because it would mean that the part joints could not take any force before failing, so I'm fairly certain it is non-zero.
  23. ferram4
    OK then, the next release will have both increased by a factor of 10. The real issue in KSP with building these gigantic rockets is that you're connecting a massive tank (100 tons) to a decoupler (1 ton) to an engine (10 tons) to another massive tank (50 tons) and such disparate masses connected together plays havoc with rigid body physics simulations. On the other hand, connecting lighter tanks to the decoupler and engine combo results in more joints closer together, which leads to more opportunities for flexing. It's kind of a terrible situation all around, and it would be better if we could choose to apply a decoupler PartModule to the top of a fuel tank, and then directly attach the tank to the engine, and not bother with the separate lightweight and problematic decoupler part. But that would probably be confusing for players, new and old.
  24. ferram4
    They control the maximum force that the "drives" can apply; the drives are essentially spring-damper combos that keep the parts where they should be, linear controlling how far it can move in any direction, angular controlling how much it can twist. The max force would be set to infinity, but then if the simulation hiccups or you're dealing with a particularly large rocket on load the force can become incredibly large and tear the rocket apart, so I set it slightly low. I'm thinking I should have set it higher by default now.
  25. ferram4
    Break force and Break torque don't do anything to affect stiffness. Try increasing angularMaxForceFactor in the config.xml file, which will increase the max force that the angular drive setting can output. That will likely help. How do the drive settings compare between the decoupler and the other KW parts?
×
×
  • Create New...