Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    I have reproduced the CoL bug; the actual issue is that building a craft part-by-part with it active results in an error, but loading a complete craft works properly. @asmi: Can you post the output_log for when that issue occurred? I suspect I caused a NullReferenceException in the EditorLogic class but I'd like to be sure.
  2. ferram4
    @Yarbrough08: Gah! The cargo-bay-shielding-parts-outside-the-bay-bug still exists... That will require me to mess with the code more. Mind posting a copy of the craft with the problem so I have something to work with? @NathanKell: Sounds good. I'll look into setting things up properly for the next release. @Sokar408: For part packs that don't include any wing parts nothing needs to be done; FAR will account for everything without any extra input. If the pack includes wing parts then it needs to be specifically set up for FAR or the wings will not function properly. B9 Aerospace's wing parts are set up to be compatible with FAR. @Event Horizon: Did KSP crash in the SPH or VAB? Is that the only NullReferenceException in the log, or are there more? How close was that error to the crash? @People having the CoL bug: Make sure that ModuleManager.dll is properly installed and is loading; make sure that the wings actually have FAR aerodynamics applied to them (try right-clicking on them in flight). Try the static analysis and see what the results are. I haven't been able to reproduce the issue on my end.
  3. ferram4
    @8clusiv8: What's happening isn't that your vehicle isn't stable enough; it's that it's too stable at supersonic speeds. The CoL shifts back a bit when moving from subsonic to supersonic flight, so a vehicle that needs a lot of control input to stay on course at subsonic speeds won't have the control authority to stay on course at supersonic speeds. Try shifting the CoL forward and adding more pitch control surfaces and see if that helps. @VanDisaster: Make sure you've re-downloaded FAR 0.9.5.5; I uploaded the wrong dll by mistake the first time. If you've done that and the problem persists, could you post a craft with the issue? @finestgreen: This online resource is decent and should be a good start; it's free as well. @NegativePositive: The benefits and detriments of swept wings are modeled at all Mach numbers, so you should probably sweep the wings on your craft. @Weatherman159: First, make sure that you're not going above an AoA of ~5 degrees during the ascent. Second, consider what Mach number your craft flips out at; as Mach number increases, a fin-less vehicle will become less stable. You may want to consider adding fins to the bottom of the vehicle. You may also want to consider adjusting the staging so that it doesn't stage while still deep in the atmosphere; staging can sometimes precipitate a loss of control.
  4. ferram4
    @NathanKell: I can look into that more, but I honestly don't know how much I can do without having to try and replace the stock parachute code. Especially since the parachutes should make some drag when they aren't deployed otherwise there would be a huge benefit to replacing regular nose cones with parachutes. I'll look into MechJeb's code a bit and see if there are any problems there; it might be adding drag that doesn't exist. @asmi: I actually forgot to add your code... whoops.
  5. ferram4
    Should be fixed now. I included the wrong version of FerramAerospaceResearch.dll.
  6. ferram4
    Any orbit above 70km should not decay. Odds are there are two possible sources to your problem: You're spending a lot of time in orbit with physics running; this is timewarp < 5x Physics simulations aren't perfect, and errors will grow the longer you're using that approximate solution to the orbital equations. Accelerating to higher timewarps will fix this by clamping it to the exact solution of the 2-body problem. You're not setting the throttle to zero while you're in orbit This would cause your orbit to change a lot. Make sure that your throttle is actually set to zero. If you're using an unmanned probe, make sure that you aren't running out of electricity, which would make changing throttle impossible.
  7. ferram4
    @Leicontis: Sorry I didn't get to you last post, a version history is listed at the bottom of the README file included in the download. I removed the copy that was in the first post when the forum's spoiler function was removed. @NathanKell: I honestly don't know what else to do to remove the extra drag. Perhaps it isn't the parachute and is simply the MechJeb part that is contributing to the drag increase? @Everyone with positive comments about FAR: Thanks, though the extent of support for FAR makes me wonder if this is how cults start. Most of my frustration is caused by the fact that I've been rushing through hotfixes somewhat hectically with the recent KSP updates and then I find out there are more bugs. Don't sweat it guys, keep the complaints coming; they make the mod better. So version 0.9.5.5 is out. The L/D scaling bug has been fixed and the majority of the blunt body drag code has been reset; the only part remaining is the change to drag for a part in crossflow. I suspect some of the drag complaints might simply be driven by the erroneous L/D graph (basically, I screwed up and the 1/10 scaling was removed). I also removed my copy of the FAR.cfg that was causing the Flight GUI to appear offscreen for some people with lower screen resolutions.
  8. ferram4
    @White Owl & Weatherman159: I guess I'll just scrap the fixes to the blunt body aerodynamics since they "feel" wrong. I guess I can't seem to get them right. In the meantime, make sure that all of your wings are actually "FAR-ized" by right-clicking on each one and making sure that Cl, Cd and Cm values show up; ModuleManager might be screwing up. @rpayne88: That looks like it's a bug caused by either the B9 aerospace wings not properly using the FAR aerodynamics or the stock canard aerodynamics not being properly overwritten. Make sure that you're using the most up-to-date version of ModuleManager and that there aren't multiple copies of that dll in your GameData folder. @SkyHook: The Cargo-Bays-shielding-parts-they-shouldn't-be was supposed to have been solved; make sure you're running the most recent version and then post a picture along with a craft and a link to the mods necessary to build it. @SpaceRodent: FAR uses ModuleManager, so it doesn't actually change anything in any of the Parts folders anymore. @Obj4ct7: SAS doesn't expect the minor control delay that FAR introduces and your stages probably aren't struted up enough to counteract the wibbly-wobbly joints bug. Use fixed winglets or fly without SAS; you shouldn't need SAS for ascents with FAR. @DividedByZero: The new SAS was fine with FAR until everyone complained that it wasn't as quick to respond to errors in orientation... and then C7 made it more twitchy. But see the above answer for why that would happen; try using the dampers but reduce the "k" value to something smaller. @longhornchris: The raise and lower commands are for flaps, not airbrakes currently.
  9. ferram4
    So I've just put up version 0.9.5.4 which adjusts the lift and drag of blunt bodies. They'll still make less drag, but that's because the drag of a cylinder in cross-flow was far to large in previous versions and it has been dropped down to regular levels. Hopefully, the flying blunt SRB problem is solved. @Decoherent: Sure! First, find out what the drag and lift coefficients of your vehicle are at the Mach numbers and AoA that you expect to fly through the atmosphere at. Then, find a program that can account for the gravitational and aerodynamic forces acting on the vehicle as it flies through the atmosphere. You'd probably have to build a tool to run all of this. All you need is lift coefficient, drag coefficient, mass of the vehicle, and the planet characteristics. @NathanKell: Are you sure that the drag on the undeployed parachutes are that high? If setting stowed drag to zero doesn't do anything then I'll have to write my own parachute code rather than leave it alone.
  10. ferram4
    @White Owl & Weatherman159: I have confirmed the "issue" which turns out to be the result of an undocumented change: I had been updating the lift and drag of blunt bodies and had not realized that a version of this was in the current version. I've tweaked things a little bit here and I'll have to do some more testing to make sure that nothing truly silly happens. @Playful1510: The Flight GUI is powered by command pods and probes, so if you're focused on a vessel without one of those you won't see it. An alternative is that the window is being displayed off the screen; if that is the case, then deleting the file in GameData/FerramAerospaceResearch/PluginData should fix it. @NathanKell: Yeah, that's a known issue with how drag is calculated. Basically, the larger part thinks that its blunt end is completely covered when it isn't. Hopefully I can come up with a solution to that soon. @Dexee: I doubt anything FAR uses would have been broken between 0.21 and 0.21.1. FAR isn't as intertwined as some of the other mods are with KSP's code, so minor changes (of the type that would happen in a KSP hotfix) shouldn't change anything at all.
  11. ferram4
    @SkyHook & WhiteOwl: Make sure that your KSP install is outside of ProgramFiles; I believe the problem is KSP not giving the plugins the permissions it needs to function properly. This would be especially true to make ModuleManager.dll work. I will check the Editor GUI to see if there are any stupid problems occurring. @taniwha: Noted, will fix for next hotfix; this one was just to guarantee 0.21 compatibility and nothing else. @NathanKell: The reason Cd increases with winglets is that Cd needs a reference area to be calculated; if any wing parts are available it uses the total wing surface area while if they are not it uses the total surface area. Basically, the drag is similar but it's being measured "acting" over a smaller area. The effects of drag on that payload are probably correct; at very high Mach numbers the majority of drag is produced at the front of the vehicle, not the back. @palker: Could you post pictures? If the SRB is flying at a bit of an angle while this is happening it is possible that it is simply producing enough body lift to stay in the air. @Ound: It works with Procedural Fairings; this is noted in the Procedural Fairings thread. It also doesn't need to overwrite stock files anymore.
  12. ferram4
    @JunkyardDog: Congratulations, you've discovered what happens when you use a booster to propel a tiny (or nonexistent) payload; you should take a look at the rocket equation and think about what happens when the mass ratio becomes very, very large. This is completely and totally normal. If you think FAR makes KSP too easy, you should try building a large space station. You'll have lots of fun trying to figure out how to launch an oddly-shaped payload or how to break up each section into several launches. If you stick to launching nice, simple, easy payloads don't be surprised if getting them into orbit is easy. @KOCOUR: There are only a few possibilities here: You're building massive, unnecessarily huge aircraft that would be a problem even without FAR. Your processor is slow; I can only reduce the number of calculations that FAR needs to do so much, and it's already running close to the minimum there. You don't have enough RAM and KSP is using the page file on your hard drive; FAR uses quite a bit of memory to reduce the load on the already stressed CPU and reducing memory usage won't help this too much. In all of those cases, the problem is your designs or the hardware you're running. Unless your output_log got spammed will NullReferenceExceptions, there's really nothing I can do without making FAR less aerodynamically accurate. Oh, and version 0.9.5.3 is out, with the most recent ModuleManager and 0.21 compatibility (I think). Any error reports from 0.21 are appreciated, but please post your output_logs or I can't do anything about it. I've left the coefficient debugging in for now to help with bugfixing (if necessary).
  13. ferram4
    @theonegalen: First, make sure that KSP is installed somewhere where it has the proper permissions to run; try running it as an administrator or making a new install with it in a directory that doesn't need special permissions like ProgramFiles does. Make sure that there is a folder in your GameData folder called "FerramAerospaceResearch". If that exists, go into it and make sure that there is a "Plugin" folder with ferramaerospaceresearch.dll and ferramgraph.dll. Further, make sure that in the GameData root there is a file labelled "ModuleManager.dll". If one of those is missing, go back into the FAR zip and extract the files to the relevant location. If all of those files are in the proper place, load up KSP, check to make sure that the problem hasn't magically fixed itself, and then quit. Go into the KSP_Data folder and find output_log.txt; upload that here so that I can go through it and find the problem.
  14. ferram4
    Spanier, FAR doesn't change anything with the LV-1; that's either a problem with another mod or MechJeb is wrong.
  15. ferram4
    @birrhan: What drag coefficient does the heat shield have when you're oriented retrograde for reentry? Right-click on the shield to see what drag value it has; that should determine if NathanKell's fix is working properly. If not, I don't know what to tell you. If the drag values are high enough then it's not a problem on my end; it is a Deadly Reentry problem and there's nothing I can do to fix it. @Frederf: Yes, of course; I will stop including a dll absolutely necessary for my mod to function properly and ask everyone to find ialdabaoth's thread to download it from there, even though he said it is ok to redistribute it. There will be absolutely no instances of people coming here complaining that things don't work properly or that they need to do unnecessary work, no sirree. I assume you're also gone after MechJeb, Damned Robotics, Damned Aerospace, and other mods in the past because they all used the MuMechLib.dll and it was so hard to figure out which one you should keep based on when the mos were released. Also, you're using a third-party application to apply mods; why should I make things difficult for people not using an unnecessary application so that you can use it? This sounds like a problem better suited to support in the JSGME thread than here.
  16. ferram4
    First, the "isShielded" flag refers to whether the part is inside a cargo bay or payload fairing, and so that is the proper value if FAR is working. Aside from that, I suspect that Deadly Reentry is currently set up to be more compatible with stock aerodynamics than with FAR aerodynamics, which would mean that you will have a much narrower reentry window to work with. I would suggest setting your periapsis lower and trading lower heating for higher g-loads. Probably pushing periapsis down to 10km or less should work for reentry from a circular 80km orbit. Remember, the longer you stay in the upper atmosphere the more heat is absorbed by the heat shield, which will degrade it faster. You want to dive quickly to try and bleed off speed so that the heat shield survives the reentry.
  17. ferram4
    @Autochton: The solution is to make sure that your CoL is fairly close to the CoM and to make sure to come in at a very high angle of attack so all the wings are stalled; this will allow you to maintain a high angle of attack while the wings are stalled. Make sure that you have some RCS for attitude control though. Eventually, the dynamic pressure will increase enough to push your spaceplane's nose down, but you should have bled off quite a bit of speed in the meantime. @regex: First, make sure that the attachnode sizes for the heat shield are correct; you can find them in the part.cfg file where they will be the last number in a list of 7 numbers, indicating position, orientation and then the size of the attachnode. The last number is an integer and should be 2 for the 3-man command pod heatshield; it should be 1 for the 1-man command pod. This determines the amount of drag created by those various parts. Second, understand that FAR's more realistic drag is much lower than the stock drag model; the atmospheres of all the planets are kept the same as they were. Kerbin's atmosphere still ends at ~70km and its atmospheric density still goes with ealtitude/-5000m. So to help explain what happened, the atmospheric density at 48km is 6.773 * 10-5 times that of sea level density which means that there's pretty much no air there for you to push against; without a very large drag area you're not going to slow down too much at that altitude. With FAR, it's actually possible to stay in a 55km orbit for a bit if you really want to. Basically, you didn't account for FAR's lower drag values enough in your first aerobraking maneuver.
  18. ferram4
    You'll need to post the output_log and a list of any other mods you're using before I can help. You should check to make sure that the ModuleManager.dll plugin is the most up-to-date version and that you're not using an out-of-date version of any other mods. If you're still running 0.20.0 rather than 0.20.2 that might be part of the problem too.
  19. ferram4
    Technically it's only easier to get to space with FAR if you're counting dV requirements and nothing else. If you start trying to account for aerodynamic stability and control it can be very difficult since you need to prevent your vehicle from either flipping out or breaking apart on launch. It can be easier for small payloads and ships but for larger payloads the design problems become much more numerous: how to keep it stable during launch, how to keep it stable during staging events, and how to fit the payload on top. The main problem is that it is "easier" with a properly aerodynamic rocket; the challenge is in designing that properly aerodynamic rocket.
  20. ferram4
    @asmi: I guess I can implement that; I've been thinking about redoing the GUI for awhile. Go ahead and PM the code. @EvilNando: Set all the control surfaces you want to act as flaps to be flaps. Then switch to Action Groups and select each of those control surfaces; set the increase flap deflection and decrease flap deflection actions to the appropriate groups. @WeaselsInTheWalls: You need to either increase the maximum deflection of the control surfaces, make the control surfaces larger or push the CoL a little bit further forward. Your basic problem is that your control surfaces just aren't powerful enough. Also, make sure that your payload is aerodynamically stable on its own before you try to launch it; if it's unstable it'll flip out.
  21. ferram4
    First, you should try looking at some of the craft included with FAR; some of them are SSTOs. It's quite possible that your designs are becoming unstable as they drain rocket fuel and the CoM moves backwards. As for getting a good top speed with jets, first, make sure you're using the turbojet engine, not the basic jet engine; the latter doesn't make much thrust beyond Mach 1. Second, make sure that you climb steadily up to the proper altitude and speed; you will not reach top speed on jets as quick as you are accustomed to. Third, make sure your vehicle is properly streamlined with highly swept wings; unswept wings and short, fat fuselages generate far more drag than swept wings with thin, long fuselages. Fourth, make sure that the rocket thrust vector passes through the CoM; make sure that the fuel drains in the way you expect it to. Fifth, make sure that the CoL isn't too far behind the CoM; this can make trimming the vehicle at supersonic speeds difficult. There are also the suggestions in the readme file, but I assume that those didn't help if you're coming here. Pictures will help a lot in diagnosing whatever problem you have, so please post those if you want more specific help.
  22. ferram4
    You should try talking to the Bobcat guys about tweaking things to make it FAR-compatible. The origin would have to be moved for it to work, and that's something only the guys making the assets will be able to do. They'll have to change it to meet the aforementioned requirements for FAR to work properly, but I think they'd like to have more inter-mod compatibility and it is probably a small change compared with what they've already done. Try giving them the changes you made and requesting FAR compatibility; I'd be happy to help them out if they need clarifications on anything.
  23. ferram4
    @asmi: There are a few problems I can suspect: Is the part origin at the center of the wing root? If not, this is a problem. Is the wing attached through a stack attach node or a surface attach node? It should be using the latter, which FAR uses to get some information about how the wing is oriented. If this is all set up properly and there are still problems, try changing the sign on the "Up X" value; FAR could be placing the Aerodynamic Center of the wing in the wrong place. If the right conditions aren't met, then FAR will cause some very weird things to happen.
  24. ferram4
    The engines are way overpowered compared to real-life engines; they're comparable to the thrust produced by rocket engines. I actually think they should drop a bit further, but it just seems wrong anytime I do that. Also, while the stock parts are "heavy" compared to real life airplane parts, that's because the stock parts are mostly chock full of fuel, while the cabin of a jet transport is notably not chock full of fuel. The stock wings seem to be lighter than they should be as well.
  25. ferram4
    I'd guess that one reason is that you now have significant thrust vectoring, which probably accounts for most of the changes. The next possibility is that the elevators being closer together helps give them more control; the original design would have allowed pressure to "spill" from one surface to the other through the space in between them while the redesign makes that less of an issue. Finally, the reduction in the tail chord would make the control surface a larger percentage of the tail, increasing their effectiveness. A thing to keep in mind is that at low angles of attack at supersonic speeds the lift coefficient of a wing is proportional to the angle between the airflow and a line connecting the leading edge and the trailing edge of that wing, while the cambering effect doesn't do anything to change lift at supersonic speeds. That means that a tail that is mostly control surface is a better choice for supersonic speeds while a tail that is mostly non-moving can be better at subsonic speeds. Also, I don't think there's a way to get finer control of the default angle than 5 degrees without going into the craft file and messing with things there.
×
×
  • Create New...