Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    If you're sitting there wondering why Z+ is down, it's because 1) we'd like a pitch-up moment to be positive, and 2) we'd like a right-handed coordinate system because we like consistency. So since X is forward, in order to have pitch-up be positive Y+ needs to go to the vehicle's right, which then leads to the requirement that Z+ be down.
  2. ferram4
    @Volt: To the best of my knowledge, latest dev build fixes it. Then again, I'm trusting taniwha, since I don't use KIS. @Darkway: Known issue, fixed in dev build, has been addressed a few times in the thread already. @Zorbaq: Should be fixed in the latest dev build.
  3. ferram4
    @Ser: I'm not able to reproduce that with a 2.5m shield and a 1.25m bay, except at very low Mach numbers where the convective flux should get around the shield. Then again, the heat isn't gonna be that high at those speeds. @Kitspace: I see what happened. Multiplied by surface density rather than dividing by it. That's the only error there, everything else is correct. @Volt: Merged taniwha's fix into the dev build, so that shouldn't happen anymore. @Kirondoll: Yes, that can happen if you pick root parts that are facing in strange ways relative to the main axis of the vehicle. If they're facing in the same direction, nothing will change. There isn't much I can do to fix this, because it quickly falls under, "deliberately trying to break the model" and there's nothing I can do to prevent that.
  4. ferram4
    Nope, not happening. Also, can't be done without risking things getting really funky every time you did it. Because it would mean destroying a lot of joints that KJR adds and resetting values on the stock ones that it adjusts. Lots of extra memory to keep track of things. Probably cause everything to instantly explode when you press the button.
  5. ferram4
    @earth: Unlikely, I can't necessarily stop whatever in the stock game causes that kind of a memory leak. Also, this is unlikely to fix landing gear and wings burning off at 150 m/s. @Ser: My test case was the very same thing with the stock heat shield. This makes me suspect that the actual issue is something with the Deadly Reentry heat shields that breaks voxelization, but that needs to be fixed on the DR side. From all of my tests, heating is now perfectly accurate and things placed behind a 2.5m heat shield are properly protected from aerodynamic heating.
  6. ferram4
    It doesn't always face the main axis at all though. So that's not a valid way to do it.
  7. ferram4
    @jrandom: More of the main axis issues... You know, I don't know if I can fix that besides adding a user-implementable override. There's just too many ways that it can go wrong, and the main axis (which is amazingly apparent to us) is actually not well-defined enough for me to come up with a solution that will work in all cases. I mean, how am I supposed to determine if those structural panels are being used as wings or not? *sigh* I should add that and then find a way to get people to change it if they come up with something stupid enough to break the heuristic.
  8. ferram4
    @Hacki: Voxel updates only occur if something triggers them. Either you have a mod that is constantly sending "HEY, THE SHIP UPDATED GUYZ!" events or you have something that is constantly driving animations; either of those will trigger the update. I do know that Toadicus's TweakableEverything has been causing some issues with that, and he's looking into that, but AFAWCT, it looks like it's something strange on his side. Nothing I can do to fix it. @Synighte: Reading the topic a bit would lead you to the conclusion that many people have had this very issue and that the latest dev build on github fixes it. Be patient, I'm making sure there aren't any more issues associated with the build before making it a full release.
  9. ferram4
    @jab136: It simply includes it's own super-light version of RealChute to replace the stock behavior that FAR basically nuked out of existence. It'll play fine with RealCHute, but you don't need it. @Ser: Yeah, and I found the issue. This is what happens when I don't bother transforming the part's orientation wrt the airflow properly for the stock heating. Derp. Fixed on master, along with the save issue.
  10. ferram4
    No, wait, I just tried it with a much large heat shield and it didn't protect it. Alright, I'll look into that more. Probably something wrong in me setting areas for heating because the heating code has the most confusing area names I have ever seen and doesn't make a whole lot of sense in how it's laid out and what does what.
  11. ferram4
    I think that sounds perfectly reasonable. There is a good reason why reentry vehicles aren't super-tall. It's because the heat flux can get around the sides of it. Probably what's happening is that those parts are wider than the heat shield, which helps get them more heating. This seems like an excellent accidental feature to me, to be perfectly honest.
  12. ferram4
    Alright, so first point: Memory "leaks": Some additional memory will be allocated over time as you need more voxel chunks. This is not a leak, this is on purpose, and those chunks will still be used. The memory is allocated and not released because otherwise you'd all be complaining about hitching during voxelization because of the garbage collector. All of my tests indicate that the only memory leak I can find is a steady 10-20MB leak every editor -> flight -> editor cycle, which can be reproduced using a purely stock game. In addition, maximum memory usage of chunks on a FAR-default-settings install is capped at ~63 MB total, ever. If you're leaking above that, it's not me, it's the stock game. Second, yes, I just heard about the save file madness, I'll fix that. This is what I get for trying to fix save settings by doing something that I thought was safe. Did you know that forcing the game to save on scene changes actually causes bad things to happen? @DuxDucisHodiernus: I haven't gotten to it because, though you may not have noticed, other people using the mod are having complete and utter gamebreaking issues. These are higher priority than your issue right now, and continuing to report the issue doesn't make it higher priority. It will be fixed, but nagging doesn't speed it up; in fact, it makes me take my time so as to not reward such nagging. Edit: on heatshield testing with the Mk1 pod; a hop up to 800 km that reentered at about 2.5 km/s at a 45 degree angle burned off 60 ablator from the shield and heated up the pod itself somewhat substantially. Given how tall the pod is and the small size of the shield, this seems about right for a hyper-aggressive reentry to me. My previous tests were using the 3-man pod with a higher velocity, but much more shallow reentry.
  13. ferram4
    I cannot reproduce any heatshield issues. The msot aggressive reentry I tried had me hit 3.3 km/s, I burned off nearly all the ablator on the heat shield, and the shield took the entire hit. Alright. I want to know everything about how anyone having any issues installed FAR, where they got it from, what other mods they're using, what steps they took to produce issues, their computer specs, OS, how many processes they're running in the background and how much of the processor is being used by KSP and other things. Something screwy is going on here, but it's not on my machine, and I can't find any of these issues no matter how hard I try. So we're back to me taking shots in the dark and hoping that maybe I hit something, but for all I can tell, you guys might as well just be trolling me for all the luck I've had reproducing these issues.
  14. ferram4
    @Dermeister: It's linked in the OP. You did read that first, right? @Volt: If you're getting frequent update messages for no apparent reason, then either A) FAR's voxelization broke (try the dev build on github, I think I killed it), or some mod is sending lots of "HEY THE VESSEL CHANGED SHAPE GUYZ!" messages, and then FAR does its duty and revoxelizes everything. It is highly unlikely that there is actually a memory leak in FAR, considering most of the issues currently seem to be caused by my addition of code to cap voxel memory usage and only comes into play once lots of voxels are needed all at once (to the best of my knowledge). @Dedalous, Sokar408, anyone else with the issue: You should try this dll from the repo, I think it fixes that. @smartdummies: I believe the dev build (link above) has that fixed. Only happens in space because I was a dumb-dumb.
  15. ferram4
    And it's the same thing that was plaguing FAR's right-click-wings-causes lag bug. And likely the same thing that cause(s/d) pFairing's right-click-lag bug. @Lakel: I'll take a look at it, but seeing as you're the only one suffering this bug right now, can you try and narrow it down to the simplest, barest craft possible that causes the issue, and also post pictures of the transonic cross-section graphs resulting from it? This sounds like the main axis is screwing up, or the voxelization is working with something gigantic, but I need the simplest test case possible to be sure. @DuxDucisHodiernus: As I already said, I have some ideas for how to fix it, I just have to see how they play out. Shouldn't be too difficult to do though. @zengei: Thanks, I'll fix that.
  16. ferram4
    It's currently coded as an aerodynamic center, i.e., as close to a center of lift as I can get it to be. It can still shift a bit due to the assumptions used in finding its location not being perfect, but I can't make it any more accurate than it already is. It hasn't been a center of pressure at all, simply because that really is damn useless.
  17. ferram4
    Yep. More fixes should be there as well. Hopefully I can resolve whatever strange "cannot voxelize" issue is going on and then push another bugfix release.
  18. ferram4
    @DianonForce: Confirmed, fixed in the dev build. Turns out I was being dumb and thinking that returning from a method was safe when air density = 0 it wasn't. So I separated that into its own method and everything is fine now.
  19. ferram4
    @DianonForce: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 <- halfway down this post for the logs, and also example reproduction steps. The more detail, the better. @DuxDucisHodiernus: The exception is already for all surfaces, the problem is that I think the surface is being voxelized before the fuselage, and so when the fuselage comes along it overwrites the surface. Sometimes. Normally the exact balance of where things go isn't so important as long as everything is accounted for, except in this particular case, it seems. All it actually requires if the surface is flat along the vehicle is that it deflects a certain amount. It's just realizing that it's flat on the vehicle.
  20. ferram4
    @DianonForce: Then I need full reproduction steps and a full copy of your log after causing the bug. @DuxDucisHodiernus: I seem to be able to reproduce it; I think it is a case where it's failing to realize that the surface is actually on the outside, and I need to handle a special case for spoilers that sit flat against the body normally (in which case, they don't behave like wings) but when they're deployed, they should, and it's treating the spoiler as if it were hidden in a cargo bay. I have a few ideas for how to fix this, and it should be fairly straightforward. For now, you should be able to fix it by moving the surface a little bit away from the vehicle so that it bumps out a bit more.
  21. ferram4
    @DuxDucisHodiernus: Considering that this craft is obviously such horrible issues, maybe you could post the craft file so I can diagnose it. Obviously, something is wrong, but without the actual test case I can't do anything. Now, I think what might be happening is that the voxel isn't properly recognizing that that particular surface is actually on the outside, but until you post the craft, all I can do is guess. And finally, the drag settings only affect transonic and supersonic speeds, and don't do jack to control surfaces. So no, it's not that. @DianonForce: An issue related to this was fixed with Fanno. You are running Fanno, correct? @Shnyrik: That is because oldFAR didn't recognize just how blunt and draggy the front of that rocket is. Also, the fins on the second stage make it much, much worse. CoL issues are only related to the CoL displaying where it shouldn't be. AFAICT, you've got a very tail-heavy rocket with a really draggy front end. Of course it's gonna flip.
  22. ferram4
    @Ser: As was already noted, data of replicas compared with actual replicas built in KSP show drag between 1.3x and 1.8x what it should be for subsonic flight. Do you have data from real life showing that a craft identical to the one you built had different drag properties?
  23. ferram4
    All of the recent rocket launches you've seen have engines with large thrust vectoring ranges and stay directly on prograde, while also being designed to avoid very sudden changes in cross-sectional area. Your rocket has no sudden changes in cross-sectional area, has a large amount of thrust vectoring capability, and stays directly on prograde, correct?
  24. ferram4
    Yes, I am aware of the saving issues; you can stop confirming them now. I also figure out what was going on with the asymmetric plane, and I think I have some ideas on how to fix that. It's just another one of those main axis issues, and because it's asymmetric it doesn't hit the nice notes that I added for taking care of symmetrically-placed parts.
  25. ferram4
    @bagofholding & Neuntausend: I did find a possible race / deadlock in the vessel voxelization code, and it should be fixed in the current dev build. Try that, and see if you can reproduce it. In any case, if it's that, I think I might have fixed it, so I'll consider this closed unless someone can reproduce on the dev build. @Kitspace: Yes, it will default to the middle at neutral. As I said, adding code to adjust that would mean adding more sliders to the bloated tweakables menu, so not unless I do something like implement the B9 tweakables method instead. Never flown a plane at very low altitude at very high Mach number on a plane that displayed raw IAS, have you? Most planes that can fly fast enough to hit those effects automatically go for EAS to avoid confusion. Also, wikipedia is correct... for incompressible flow. They're actually talking about total pressure, technically, which is equal to stagnation pressure for Mach = 0, but is lower than stagnation pressure for all Mach > 0. This is unfortunately how wikipedia operates; incorrect information because the people that can follow wikipedia's red tape are only competent at following the red tape, not with what they're describing. God knows if it's even possible to get that fixed. Most aerodynamics textbooks will cover the difference correctly. @Sterbehilfe: No idea why you're telling me, FAR doesn't touch engine thrust, fuel consumption, or the throttle at all.
×
×
  • Create New...