Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Matt77: Yes, I know. It's been fixed in the dev build, continuously reporting the same issue doesn't make the dev release come out faster. It actually makes it take longer because I have to check to make sure that this isn't a new issue. SpacedInvader: That's an error in the part that has been safely (but not silently) recovered from. Take it up with the part modeller, they're the one that added degenerate triangles to the mix. Also, I can't reproduce that pFairings issue. I can reproduce a different pFairings issue, where all the numbers end up as 0s and the log is spammed with update lines, but that is not related to that one and is fixed in the dev build.
  2. ferram4
    That was noted as an issue a few pages back. It'll be fixed in the next release. I don't blame you for not reading back though given the state the forums are in though.
  3. ferram4
    I tried to make a post earlier, but apparently it got wiped out by the 502 fun. Anyway, the gist was: WYSIWYG editor is a pain. I always turned it off, especially for editing the initial post of a mod thread to help with making things responsive enough that I could be sure that it was updating properly AND so that I could be sure that the formatting was right because I could see where the BB code markers ended. I have no control over this anymore, and frankly, that's a huge step backwards. Not to mention all the links that are busted. The nice thing about forums was always the lack of silly formatting shenanigans. Why bring it here?
  4. ferram4
    [b]@SpacedInvader: & Dermeister: [/b]Well, you're both going to have to recreate the issue with as few mod parts as possible and post the resulting craft files. Things should be updating, but I need reproduction steps if there's a problem. I don't get these issues, so you need to tell me how to cause them.
  5. ferram4
    So the lateral simulation tells you that you're unstable in the dutch roll mode; you've got too much dihedral effect / too little yaw stability for your plane. You'll need to either, 1) reduce wing sweep, 2) add more vertical tail, or 3) make the wings have slight anhedral (negative dihedral angle) to compensate. As for the other oscillations, everything actually looks perfect. Your plane is very close to the way real ones are. The rest is all stuff that should be handled through control systems, so you might want to activate the pitch damper when you fly this thing. That, or add one of the other control mods; this isn't something you really want to fix with changing the plane design, because you'll just lose out in terms of performance as a result.
  6. ferram4
    That would be wave drag, mostly due to the wings. The tinting system doesn't play well with the shader stuff that B9 Proc Wings does, so you don't see it on those.
  7. ferram4
    [b]@Psycho_zs: [/b]True, but my solution was to have SAS on on all the pods. :P I figured if stability was the only reason that there were better options. [b]@Shnyrik: [/b]It was a weird race condition that could show up when adding some procedural parts. I only noticed it with the fairings, but I suppose it's possible with the other parts as well. Nevertheless, dev build has it fixed. A new update should be out relatively soon fixing a bunch of issues unless I find something that requires a ton more work to fix.
  8. ferram4
    [b]@Psycho_zs: [/b]I found something. You should have specified that ultra-high speed spinning was required to cause the issue; turns out it was an edge case with ModuleJettison. Fixed in dev build. [b]@Shnyrik: [/b]Ahk, I see. That's something funky with Procedural Fairings, not Procedural Parts. Did it happen in 0.15.5.2 as well, or just with 0.15.5.3? [b]@Venerabilius: [/b]It's already been fixed in the dev build.
  9. ferram4
    It is intended to work in space. It would be much worse control system design to have the system automatically shut itself off without user input; the controls are supposed to follow the user's instructions, and in the cases you're describing, the last instructions were to activate the control systems. They're exactly the same as SAS in that regard.
  10. ferram4
    I cannot reproduce the issue. All pods and the remaining upper stage have drag, regardless of how many times I switch. I cannot see any difference in drag properties that cannot be explained by different orientations and all drag values are positive. Your reproduction steps are missing key information, or the issue does not exist in FAR itself.
  11. ferram4
    [b]@RevanCorona: [/b]Yeah, RoverDude's stuff seems very prone to that. I'll need to find what exactly happens there; it probably spawns in some funky way. [b]@cantab: [/b]Only dev versions that were incredibly buggy and are not available for general use. [b]@Psycho_zs: [/b]Then you are going to have to provide [i]full and complete[/i] reproduction steps of how to cause the issue. And I mean [i]exact[/i]. Reverted to the SPH 30 times that session? I need to know that. Switched vehicles multiple times that session? I need to know that and how much (exact numbers). Deployed landing gear, cargo bays and stuff? I need to know that and how many times. Included specific parts on the vehicle with the issue? I need to know that. Yes, I need to know all of that.
  12. ferram4
    [B]@Venerabilis & VanDisaster: [/B]I cannot confirm this, flap and spoilers continue to act as they always did. There are no issues that I can find. If there are any, you will need to provide specific reproduction steps. [B]@CrazyESP: [/B]That issue cannot be fixed on my end. It will need to be fixed on the Firespitter end in the same way that Baha's Adjustable Landing Gear fixed it; by calling part.SendMessage(GeometryPartModuleRebuildMeshData) after the collider is deactivated. I have no way of fixing that myself other than polling constantly to see if it's active, and that will reduce performance drastically. Edit: hrm... I might have a fix. [url="https://github.com/ferram4/Ferram-Aerospace-Research/raw/master/GameData/FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll"]Try this dev build and see if it fixes it.[/url]
  13. ferram4
    Yeah, that's the current limitation with the stab deriv GUI. So, your problem is that you're too roll stable for how yaw stable you are, which will probably show up if you try a lateral simulation with some sideslip. So you've got a few options: 1. Reduce wing sweep (a lot) 2. Reduce dihedral (a lot) 3. Add a much larger vertical (really vertical, not angled) tail There's a reason why no one builds planes that look like that. Turns out they have dutch roll issues.
  14. ferram4
    No, actually, the physics that lead to steeper reentries being safer hasn't changed. All the values in configs config that leads to heating being proportional to sqrt(air_density) are still at 0.5 in 1.0.4. So that means that drag increases faster with density than heating does (since more air does mean more heat, but also more air to pull that heat away from the craft), so the ratio of drag to heat drops as density increases. The absolute magnitude of heat applied might be different, but the variations in it are still the same, and shallow reentries always lead to more heat soak than they did before. The trick is to realize that a shallow entry is banking on your ability to radiate away / ablate away the heat over a long period of time while a steep entry is banking on your ability to withstand high gs and a high, but short-term, peak heat flux. Shallow entries are good for spaceplanes (after a relatively steep initial entry to bleed off the worst of their speed), since spaceplane parts have much higher heat tolerances than normal parts (~1600 for normal parts, but 2000 for Mk1, 2400 for Mk2, and 2600 for Mk3), so they are better at radiating away heat (radiation goes with temp^4). Steeper entries are better for things that can't soak in the heat for a long time (anything that relies on ablator), but that can handle a rather high gross convective heat flux for a brief period.
  15. ferram4
    [quote name='Pthigrivi']How many of these aero qq threads are we going to see? Ive done it. Lots of people have done it. Its not impossible, its not even that hard. You're coming in too steep.[/QUOTE] Except he's not. He's coming in too shallow. My post on the first page was taking his vehicle and coming in steeper, which allowed it to survive. This kind of statement is what leads to people like OP taking a ridiculously shallow trajectory like he showed, blowing up, and then declaring that reentry is impossible. The fact is, it's not.
  16. ferram4
    [URL="http://forum.kerbalspaceprogram.com/threads/139855-PSA-Eve-%28re%29entry-is-impossible-CONFIRMED?p=2301560&viewfull=1#post2301560"]And as I noted in the other thread[/URL], the failure of your rocket, Xyphos, is due to your reentry procedure, not due to Eve's atmosphere. It is perfectly possible to reenter that vehicle. Edit: as a general suggestion to anyone having reentry problems: check to see if your reentry is too shallow. The goal is to slow down, and heating is not proportional to drag. You can get more drag with less heating (proportionally) by diving deeper. That's why Xyphos's design exploded; he was too shallow. A steeper trajectory was survivable.
  17. ferram4
    Your test was fundamentally flawed, and even with stock aerodynamics and stock heating that very vehicle is capable of surviving reentry and smacking into Eve's surface. Starting from a 100 km orbit, dropping periapsis to 7 km (expending 100 m/s of dV retrograde), your vehicle ends up like this: [IMG]http://i.imgur.com/WkYtoc8.png[/IMG] Your reentry periapsis was simply too high and didn't bleed off enough speed. The problem is your procedure, not Eve. I'll also note that since I left the RCS off besides for initial orientation, I likely had more mass than you during the entire reentry, so I should have had more heating.
  18. ferram4
    Using Trajectories? That's something that needs to be changed on [i]their[/i] end, they're clearly not simulating things correctly if it's actually causing things to break. I gave them a way out of the aero failures, it's their fault if they don't disable it like they should.
  19. ferram4
    That means that one of the triangles in the mesh either has a bad point (location includes a NaN value) or that the triangle includes two lines right on top of each other (and so, is degenerate; it isn't a triangle). Either can be fixed by opening up the model to fix it, but FAR should still work okay even with that error. Still, you should fix it.
  20. ferram4
    [b]@randman22222: [/b]I cannot reproduce the issue. The vehicle launches fine, its engine turns on fine, and everything seems correct. I suspect your issue lies in another mod interfering with FAR or some other program you have installed preventing FAR's worker threads from running. [b]@PickledTripod: [/b]None of the log that you have snipped out has anything to do with what you're describing; all of those are lines that occur in other installs without any issue (except perhaps the Trajectories line). Without context they aren't much use anyway, so please, if you're going to upload anything from a log in the future, upload the entire log, not a disconnected snippet. In any case, those issues should not occur during normal use if Trajectories is set up correctly. If it's calling functions that could cause aerodynamic failures though (and that are only supposed to be called by the main game for the purposes of physics simulation), then that could happen. If that's the case, it needs to be fixed on Trajectories's end, I can't fix that. [b]@RevanCorona: [/b]It's in the editor. You will know it when you see it, it's kinda hard to miss. [b]@Crzyrndm: [/b]Could be that. Except FAR's method for reading atm density should just read back the current air density now, so I don't know what could cause the discrepancy.
  21. ferram4
    Well, I tried the craft, and I can't reproduce any issues. It's yaw happy, yes. But not roll happy. Aerodynamic forces appear to be placed equally from everything I can see. It flies like a slightly yaw unstable brick, which is kinda what I'd expect. Not sure what your exact issue is then.
  22. ferram4
    @Sean Mirrsen: 1. Trim settings with FAR are exactly the same as trim settings in stock KSP; ALT + WASDQE. If you're intending to use the flap options for trim, then you need to assign the controls to respond to flap action groups in the editor (or toggle using the more/less deflect buttons in flight), and then tweak the flap deflection slider to get the deflection you want. For elevators used to trim the plane up, you'd want to set that number to be negative. 2. That's normally a sign of uneven flexing on the plane. Should also happen in stock, but now that I think about it, since FAR actually cares about sweep angle, flexing could reduce / increase the sweep on one wing, increasing / decreasing the lift it produces and causing a roll tendency. However, if all your planes have massive anhedral wings like that, they're going to want to roll all over the place no matter what you do. Anhedral wings are less roll stable regardless of the flight model, FAR just might make the effects more noticeable. Oh, wait. I see. Swept wings + not much vertical tail. Yeah, the problem with that design is that it has no yaw stability and would like to slide on sideways. So I think most of these are your fault. That said, if you do find anything funky, issue reports are always welcome so long as they come with repro steps, craft files (if the repro steps include a specific craft), logs, etc. @Boris-Barboris: Hrm. Damn. I brought up changing it to exponential decay since that would be much better for you, Sarbian and the other MJ guys, and for Squad if they decide to overhaul SAS. We'll have to see if anything pans out though.
  23. ferram4
    Actually, I think the stock control surfaces do model it as a first-order system. I'm not sure exactly how the actuatorSpeed field is used, but I think that they do end up modelling an exponential decay towards the desired control deflection. A simple test would be to load up the game without FAR and one of the control surfaces modded so that it has an actuatorSpeed field with a very low number and then see how the control surface behaves.
  24. ferram4
    @VanDisaster: I don't change how the stock airbrakes behave. At all. @Boris-Barboris: Oh, yes, I originally added the exponential decay code, DaMichel just adds comments everywhere when he contributes anything (and is much better than me in that regard). The original reasoning was that it not only closely follows how servos respond to deflection commands but also makes for a very easy-to-handle result for control systems (as I'm sure you're aware). So the first-order-system response / exponential decay isn't going to go away. That said, depending on how the overhaul works out the current methods you're using to figure out what kind of control FAR can provide might not work. Once development of that feature starts in earnest it'll show up on the FAR github on a more recent wing overhaul branch; feel free to mess with the builds from that (I always upload the latest dll) and either comment there or PM me here if you need anything on my end to make hooking into that easy. @randman22222: Well, the first thing I need is the craft file. Preferably with all mods removed. If that's not possible, stripped to the barest minimum of mods necessary to cause the issue. And then I need a full, complete copy of your output_log.txt (or Player.log if you're on Linux / Mac) so I can see what when wrong. And I mean complete; don't snip anything, lest something important get lost in that.
  25. ferram4
    Oh, I see what happened. Somehow I packaged MFI 1.1.1 because I had to do a system restore. Dammit Windows. I'll fix that. ...and done.
×
×
  • Create New...