Jump to content

ferram4

Members
  • Posts

    3,132
  • Joined

  • Last visited

Everything posted by ferram4

  1. Except that makes no sense. FARBasicDragModel doesn't exist anymore. There is no code for it. Unless the block includes typos and errors that break the entire config (which should have other issues) there is nothing in there that can be added / removed from the config to create / remove the problem. Yes, I need the craft. I explained why about a dozen posts ago. No, I'm not going to spend hours trying to reproduce the same exact weird edge case that you're hitting by nothing but luck.
  2. @AccidentalDisassembly: I can't help you unless you provide the problem craft with as few mod parts as possible. Not much I can do to fix an issue I can't recreate. You could try the garbage_reduction branch on github, but keep in mind that you'll need to download not just the dll, but also the configs to ensure that things work properly. @cantab: At this point, the only option left available to me is to disable explosions due to overheating. It's a stock bug, all the skin temperature settings have been set to use the stock code as a fallback if it reaches the point where FAR could exacerbate things, there is absolutely jack that I can do. Take your bug report to SQUAD and ask them why they didn't bother to hotfix it. I'm not chasing after their bugs.
  3. If you manage to get something to break, you need to provide a test case. Just telling me that it can happen doesn't let me do anything, because there are an infinite number of ways that you can put a craft together. I have no hope of finding your issue without a test case.
  4. And as I've told you, until you get me a reproducible case, I can't even hope to fix anything. It's not within my power to fix something when I don't even know how to cause the bug, and that's assuming it's something in my code that I can fix.
  5. @DaMichel: Oh my. Okay, this is a real nasty screwup that I managed to hide from myself; actually, everything was wrong for radially attached parts except for BDArmory parts. New garbage_reduction dev build has that fixed. @Feni: Apparently it's fixed in the current dev build on the garbage_reduction branch, if you wanna give it a go. I haven't seen any issues myself, tbh.
  6. Yeah, rocketplanes are difficult. Actually figuring out what you're doing wrong will require pictures, but you're probably better off asking in the RO thread if you're trying to do a rocketplane with all those planes. It's a fair bit past standard FAR at that point.
  7. @Cosmonauth: A few posts above you was a conversation about adding that to the build in the future. Of course it still happens now. @DaMichel: That is not a stock craft; what mod includes SmallGearBay3? @Kobur: I can't fix people that dislike me or that make attribution errors, especially when Malwarebytes and Kapersky are both telling me the zip is perfectly fine.
  8. I was gonna do something similar as a hard-coded thing, but if you're up for it, can you set it up with some way to specify modules using exempt animations in a config? It'll help with future-proofing it a little. Also, make sure to fork the garbage_reduction branch instead of master, or you will encounter the wrath of Ferram When He Is Dealing with Merge Conflicts.
  9. DaMichel, try the garbage_reduction branch dev build, and see if the issues still occur. Still, I can't get any issue with the forces breaking with the BDArmory parts. As for the main axis being messed up, for some reason, part.partTransform.up is not the forward direction for those parts, despite the fact that it is for everything else; I'll see if I can add something to the heuristic to maybe detect that, but the more parts differ from stock standards (and the more it is for arbitrary reasons) the more this will happen. I'll merge the parachute PR when I'm closer to a release.
  10. @AgentWhite: Alright, so first, I need the logs. Everything else is at least a good start. Now, I need you to reproduce the issue with no other mods so there aren't any confounders. I also need you to reproduce it with minimal flying to other bodies; probably loading it in just space will do. And I need you to do all of this exactly as you did the last time you caused the bug, doing exactly what you did before except for things that you're trying to simplify, and I need you to tell me exactly what you did, without leaving out any of the nitty-gritty that you did for this report. Because the actual reproduction steps are likely in that. They always are. @sashan: Not possible unless it also has no affect on any of FAR's aerodynamics whatsoever. Which would mean that adding missiles to your plane wouldn't increase wave drag at all. There aren't any good solutions here besides setting up the BDArmory parts to fit with all the other parts in KSP rather than trying to hack everything together.
  11. Logs people, give me logs, they are useful in figuring out the problems. Otherwise, I'm just guessing at what the problems are because I don't know what's happening on your machines. And if you're absolutely certain FAR is causing the issue, create the issue without 50 different mods installed. Confounders do not make diagnosing issues easier. Good news for the voxel update stuttering is that I'm making progress on reducing the garbage created by that, so hopefully most of that can be removed entirely. Bad news is that has no effect on garbage production from other mods, so very mod heavy installs might still have issues.
  12. Not KJR, KJR does not affect temperature whatsoever. This is a stock bug.
  13. There are no variables to tweak, FAR is what it is. If you're having those problems, it means that your planes are horrendously overweight. Bring their mass down to realistic levels.
  14. Oh, I see. Somehow the landing gear are the source of the problem. I'll see what I can do.
  15. @sashan & Triarius: I can't reproduce any of these issues, both of them seem like install errors. Maybe Azimech's solution works, but if it doesn't, you're both on your own until you provide full, complete reproduction steps ("it just doesn't work" isn't full reproduction steps, I know you're leaving stuff out, people always do), a complete copy of the output log, and all installs must be manual, no CKAN.
  16. @Ser: First, FAR doesn't change anything that would be related to the aeroFX; those are based off of vessel velocity and air density, and FAR does not change the velocity fed in or the density read in, so it must be something else. I need full reproduction steps with nothing but FAR installed and a full copy of the log. Same for the other issue. Edit: Also, you're not using CKAN, right?
  17. @soulsource: I need full reproduction steps; there were no changes in that commit that would affect anything being "stowed" and many of those changes were superseded by the next commit. And please don't link your log like that, it's a pain to try and go through. Use dropbox or another file hosting site without such a tiny limit. @Amedee: Well, if the AppLauncher exception occurs, and I have no data about it, I have to worry. You're the only one who's had that occur, so yes, I have to worry about it. No idea if there is a way to fix the CompatibilityChecker exception. It's throwing from a static class when the scene is ending; I don't know if there's a way to even detect what's going on there besides a try{ ... } catch{ //Do nothing } block. @gilflo: And that's why I'm more annoyed with people blaming it on FAR than anything else. It's not like I have any means to fix a bug created by Squad that they're not willing to hotfix.
  18. First, that bug did get fixed. Hence why there was an update. Second, read the thread, the problem was identified in the 2nd post of the last page.
  19. @Ser: Pods smacking into the ground at 400 m/s was never a realistic thing and points instead to an error calculating drag. @Amedee: You need to provide actual reproduction steps. The AppLauncher exception is something I've never seen. The RealChuteLite exception is known, but that's stupid_chris's territory. The ComaptibilityChecker exception is known, but harmless. @cantab: That would be a good comparison... if the stock pods were not overly dense for their size. Note that the 3-man pod weighs as much as the Apollo capsule, while only being 2.5m diameter rather than the 4m diameter of Apollo. That will lead to the forces being 0.391 times that of real life, resulting in a terminal velocity of 1.6 times the real life equivalent. Currently, things seem to be correct. @includao: Maybe? That's stupid_chris's code, no idea what happens in there.
  20. @run1235: There was a fix for an issue like that in the current update. However, if you're using CKAN, you're not eligible for support here; there is a CKAN-specific thread linked in the OP for CKAN users to help isolate CKAN-specific issues.
  21. Alright, BB v1.4 is out with fixes and better surface-velocity damping.
  22. Not possible. There were no changes to the code that calculate the main axis between 0.15.4 and 0.15.4.1. I see that the FAR icon isn't showing up for you; did you install this using CKAN, or make any error in a manual install?
  23. If it fails in space, then FAR is not the cause. FAR does not apply any forces if the density is 0. In addition, the only structural failures that FAR applies directly note that the failure is due to aerodynamic forces; none of yours do. Your issues are either due to a stock bug or due to another mod, not FAR.
  24. Alright, so v0.15.4.1 "Goldstein" is out, with some attempt at helping that heating issue, but as I noted, it's a stock bug, so I can't fix it. Also includes the return of the old aero viz coloring during flight thanks to mjn33 and a few other bugfixes; changelog is pretty short this time.
×
×
  • Create New...