Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Alright people, version 0.13.1 is out, fixing the EAS-Mach-Navball issue, the improper engine fairing issue, and marking a change in FAR's license, which is now GPL v3. Its source is also on Github now, so all glory to the octocat!
  2. ferram4
    I did. And it didn't cause the issue. That's why I went to orbit to check there. Nope.
  3. ferram4
    Nope, 1 didn't work, Jeb was floating next to the ship quite happily. And 2 just resulted in him being resurrected perfectly after his 100+ m/s impact into the ship. So either some other mod is implicated or something important is missing in the reproduction steps. :/
  4. ferram4
    Well, that's because of the way that normal wing parts are set up. The only way for you to achieve what you want to do is to offset the part origin so that it is b_2 * 0.5 to the right of the center, and then shift the CoM of the part back to compensate. However, this won't work for stock winglet parts. FAR currently doesn't currently support what you're trying to do, and likely will not ever do so because of the problems involved in trying to model multiple wings using the proeprties of one wing; you would be better served by splitting your wing design into multiple parts to achieve the goal.
  5. ferram4
    @Moon Goddess: Lower TWR. Smoother, earlier-starting gravity turn. Fairings. Tall rocket, not asparagus pancake. Fins. Pictures of problem vehicles are helpful here. @flywylx: Well, that depends on what you're trying to do and what FAR modules you're trying to use for it, and what you're calling the "x-axis," since that could point in any direction. I need a more detailed explanation of what you want to do first.
  6. ferram4
    Alright, then I'm going to need detailed reproduction instructions. There's nothing in there that indicates the error starts with KJR; it may be a stock bug for all I know, but the first error that occurs with anything involving the EVA is trying to get the rigidbody's velocity (called by the regular game, so there's nothing I can do), which ends up nulling out somehow. So either it's breaking right before that or it's a stock bug.
  7. ferram4
    You want to check the ballistic coefficient, which is a measure of how strong drag is relative to mass; lower means it will decelerate better. Anything above ~1000 kg/m^3 for BC is probably not going to come down properly, or will at least risk it heavily if it can't spend lots of time bleeding off speed high up. You might just be too aggressive with the pods.
  8. ferram4
    @coldblade2000: I've got something in the works, but there's not much you can do for now. Just make sure that the parts you're using have the appropriate node sizes, which helps a lot. @illectro: Dammit Scott, stop breaking my mods! Alright, the first one, I have no idea what you managed to do there, but it's quite entertaining. I hope you saved a copy of the output_log.txt from that one, since I don't know what broke and I can't even guess what went wrong; I've never seen that myself. I'm guessing that something interfered with whatever code was used for creating the vessel that held the KerbalEVA, or else the KerbalEVA broke on load, but I dunno what would cause that. Or else something went wrong determining the initial orbit, since that was messed up as well. Edit: Derp; KJR v2.2 is not back-compatible with KSP 0.23. Make sure you're only using KJR v2.1 with KSP 0.23. The second one is much simpler: you've got a nice limit cycle going on, likely caused by the spring and damping constants for the parts being a little too high (creating the initial instability) but the angular velocity limit preventing the forces from growing past a certain point. So the thing to do there is to head into the config.xml and look at the "angular drive" parameters. Reducing the spring constant there should help with reducing the initial disturbance, and reducing or increasing the damper constant should affect the stability of everything; the effect really depends on how the frequency and physics timestep play with each other. The constants are currently ridiculously high to get around the angular velocity limit, so reducing both should help, though it will make a lot of things a bit more wobbly. Try dropping the spring constant one or two orders of magnitude and see if that helps.
  9. ferram4
    @DivisionByZero: FAR's drag properties got changed a little bit for 0.13, but that should be causing ships to burn up more. If that's not your issue, you're just flying differently. @wasmic: The only parts that should be causing the issue should be parts with ModuleJettisons in the config that don't have fairings of any sort to jettison. There's not much I can do to get things to work after it throws an exception, that simply halts execution and there's not much I can do besides going an adding my own exception handling system to deal with this. Ultimately, I'm not too concerned, since this is a problem that should be solved on the part modder's side in that they should clean the junk out their configs, since unnecessary PartModules will slow things down a bit. All of that said, all the tests I've done indicate that the upcoming version of FAR won't have that issue. Until then, remove the ModuleJettisons from the config file if the part doesn't have a fairing; it shouldn't be there anyway.
  10. ferram4
    Well, the lift rating is completely bogus, and it's part of the stock lift system, which FAR removes; it's pretty difficult to simplify everything FAR does down to one number.
  11. ferram4
    @ghimb2000: I have no idea what's going on then. It sounds like something's horribly breaking, but I've never seen that behavior before. Any errors in the output_log.txt? @phoenix_ca: Here's a flowchart of what to do; it's very simple. After the fourth entry it's completely speculative, but a very accurate portrayal of what tends to happen. FAR GUI -> FAR Flight Data -> Bottom of the window -> terminal velocity -> attempt to chase terminal V -> lose control of rocket -> stick closer to prograde next launch -> end up on really tall suborbital or escape trajectory -> abandon chasing terminal velocity as a thing only encouraged by the stock drag model being awful Further progress report: It looks like I managed to fix the gear being a problem, the release will be out when I finally get the source on Github and I'm sure that I know what I'm doing. It's moments like these that I'm reminded that I'm an engineer with an affinity for coding, not a programmer.
  12. ferram4
    If no stock parts affect the CoL at all, that means that FAR is not installed properly or another mod is interfering with it. All parts will affect the CoL in the editor.
  13. ferram4
    Actually, a quick test on my end (for future KJR stuff) indicates that larger node sizes do make the connections stiffer, so there is a good reason to use them. Angular stiffness of the joints seems to scale linearly with the node size applied.
  14. ferram4
    The dishes tend to be quite un-aerodynamic, though they shouldn't make much drag if they aren't deployed in the atmosphere. Any phantom forces in space caused by dishes is probably a result of part clipping. When outside of the atmosphere FAR doesn't even run any drag calculations, let alone call the methods to apply them to parts.
  15. ferram4
    The CoM doesn't move at all after you burn fuel to get it in orbit? Use tweakables to remove fuel from the tanks that are empty on the craft in orbit (while you're in the SPH), and then tilt the spaceplane to the same AoA you were at when you lost control. If the CoL is still behind the CoM, then I'm going to guess that the problem is not enough yaw stability, which causes lots of rolling, and you're losing control that way.
  16. ferram4
    @Hyomoto: Update isn't out yet, that's just a progress report. I still need to make sure that everything is functioning properly, so it might take until tomorrow. @GentlemanJack: Nope, there's no way to do that. Besides, FAR isn't that much different from stock aerodynamics; the basic causes of stability issues (aerodynamic forces centered ahead of the CoM rather than behind) will still affect the craft if it has a large number of wings. You'll probably have an even worse time landing it, since you'll have the number of wings needed for FAR, which is much less than the number needed for stock, so you'll have to land at a very high angle of attack at a very high speed. The thing you need to do is to redesign the craft to account for and reduce CoM movement due to fuel drain and payload deployment. This is something even basic planes have to deal with, and you'll have to deal with it with stock aero as well. If you insist on disabling FAR to attempt "fixing" the reentry, you'll have to resort to uninstalling FAR (which is quite simple, just delete the FAR folder), which means closing KSP to delete FAR and then restarting the game. I'm just going to warn you, it's not going to fix things like you think it will.
  17. ferram4
    @flywlyx: No, the aerodynamic center is calculated internally by the module from the values used to define the size of the lifting surfaces. It is not currently possible to manage a single-part plane with FAR, and given the way things are currently coded very weird effects will be caused by having a single part with multiple aerodynamic modules defined for it.
  18. ferram4
    No, the forces would be applied at the aerodynamic center of each defined aerodynamic surface, where the aerodynamic center would be defined as an offset from the part origin. They still would be all over the place. So I've got the Navball fixed, the ModuleJettison null fixed, I've got the not-updating-properly-after-undocking bug fixed, removed the coefficient readouts, and just have to test my changes to see if the weird behavior with the B9 gear on different parts is fixed. Then we can have 0.13.1 with bugfixes.
  19. ferram4
    It makes asteroids behave like somewhat rough spheres, which is to say, they're pretty draggy. They still end up being the leading part of a spacecraft during an aerobrake though, simply because there ends up being much more mass than surface area for an asteroid (except for the very puny ones). It seems to work well, and they smack the ground going supersonic, so everything happens about as it should.
  20. ferram4
    @Einarr: Okay, so something must be slipping by. See if you can recreate it with the fewest parts possible, and with only the active vessel loaded (so no debris within 2.5km) so that nothing else can interfere. I hope it's not some stupid floating-point-caused thing. @Yarbrough08: Well, you'd need to do a bunch of simulations of the rocket during ascent, varying control inputs and such. This is one of those situations where there's no simple formula to use, unfortunately.
  21. ferram4
    @Kalista: Okay, so it's not sending the proper drag update event. I'll look into it; does it require docking and un-docking to cause the issue, or can it be caused without docking at all? @Einarr: Ouch, a nullspace bug. The problem is that FAR is set up so that anything it can do that could possibly cause a nullspace bug causes it to stop and then print to the log (those are all the FAR Aerodynamic Error messages in there). I think that Firespitter might have needed an update for 0.23.5 compatibility, and you didn't specify that you updated that for 0.23.5 compatibility, so could you make sure that that isn't the issue? Does removing KAS fix the issue? @Jaxx: It's distributed because ModuleManager is necessary for many of these mods to function. FWIW, I don't know if Kerb Paint is up-to-date, so you might still end up having issues with it.
  22. ferram4
    @Yarbrough08: It's part of the extra decoupler stiffening. Enabling that should bring it back. @MrHappyFace: Yes, it will. As I've answered quite a few times in this thread.
  23. ferram4
    @Jaxx: Using stock parts or mod parts? What other mods are you running? I haven't seen this in my save, so I'm assuming a mod conflict somewhere.
  24. ferram4
    Try launching it again to see if the craft loading in orbit caused things to work correctly. I suspect that the heat shield just barely managed to be "shielded" by the bay, and if that's the case then I might have a weird transform error somewhere or I need to add some more margin-sort-of things to see if I can make sure that nothing bad happens again. Yay edge cases.
  25. ferram4
    @m4ti140: The warhead CoM is about half the way down the length of the cone, and you sent it in spinning like a top, right? MIRVs are intended to smack the ground (on Earth anyway) at about Mach 4 or so, and make quite a bit of heat on entry (see time-lapse photo). Technically the nosecone on that only exists to protect the warheads on the way up; each should come down independently, but it doesn't sound like that's what you're doing here. @photas: What are you reentering with? A payload chock-full of fuel, or a standard command pod? The density of the vehicle matters a lot. Also, what mod you're using matters since they might not be set up for compatibility properly. @Kalista: I'm not seeing any errors in the log, could you post a picture of the problem-craft?
×
×
  • Create New...