Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @ninjaweasel: Those numbers are correct. In fact, I've seen higher terminal velocities for heavier launch vehicles. I think you're just expecting the atmosphere to be made out of pudding rather than air like it really is. Perhaps you need fewer boosters? @Renegrade: Yeah, supersonic drag of wings got changed to account for 3D effects and sweep better, which means that drag is lower. It's expected, I simply haven't nerfed the engines to hell like I should have. Next update will have thrust nerfed a bit to balance it. @LostOblivion: I think (don't quote me on that) that 0.24.1's changes will probably save the crafts, but I'm not sure, having (obviously) not had the opportunity to test it myself. I'd say upgrade, but make a backup of your save and crafts just in case. @mdgates: I see you take this far more seriously than I do. I only use those tools when I'm flying a decent test rig (built only using the CoM and CoL indicators) and find it lacking in some way, which, while it involves more crashes and hair-raising landings, is certainly faster and more entertaining than judging by the numbers all day.
  2. ferram4
    Let's say you have a bloc like this: @PART[decoupler_ftr_4m] { CoMOffset = 0, 0, 1.12183 } If you add :FINAL to the end, it'll run in the last group, like so: @PART[decoupler_ftr_4m]:FINAL { CoMOffset = 0, 0, 1.12183 } Things in the FINAL group will still be done alphabetically inside that group, but they'll end up being the last set applied.
  3. ferram4
    @MainSailor: It is possible to cause the issue if you are using a lot of other mods that change PartModules or if you constantly add new mods that change the behavior of existing parts, changing the number of PartModules. This is caused by a stock bug in the PartModule loading code that was added in 0.24 and it is out of my control completely. Basically all the hotfixes have been code for me to try and work-around the bug and remove as many situations that could cause it, but I can't do anything. Honestly, 0.24 dropped a week too early and really should have stayed in experimentals longer to fix this and other issues, but the hype was too much. We'll have to wait for 0.24.1 to hopefully fix it. @andrehsu: Aware of it, that's because it not only doesn't include any of the keywords in its title to load either of the shielding modules, it'll need the cargo bay one since it doesn't act as a fairing. @dshriver: Where is your output_log.txt? Post it, or I can trace that back to a bug. Anyway, NEAR and FAR doesn't do anything to crafts once they're off-rails, so the lag is likely due to something else entirely.
  4. ferram4
    @WestAir: You do not need that much engine. Also, as Dragon01 mentioned, get rid of the fins at the front; have you ever seen a throwing dart that had the fins at the back? Look at real life rockets and aerodynamic designs and look at the differences between them. @SnappingTurtle: It doesn't matter how you build them out, the wing interactions are based on absolute position in space of each wing part.
  5. ferram4
    @DaMichel: I know that there is an error for the payload fairings, but not for the cargo bays. I'll look into it further. @IronStar: That should not be an issue, as I fixed that bug before uploading v0.14.0.2. That is very, very strange. @WestAir: Why would you even consider using RCS for a rocket during ascent? Anyway, it sounds like you have a stability issue, and you should really post a picture of your rocket so the problems can be diagnosed. Personally, I suspect you're flying with too high a TWR; anything above 1.6 is asking for trouble, and it's very easy to reach high TWRs for the early launches, so you'd want to use the thrust limiter on the engines to keep things in check. @Jasmir: Known issue. Use launch clamps and stage them and it'll work fine.
  6. ferram4
    @seraphx2: KSP used to have a different designated official place for all those things, Kerbal Space Port. It was hindered by a terrible search system and a bloat of pointless files, making it utterly useless as a place to search for mods. I see no difference with Curse, and I see no reason to support something that has the same exact problems as the previous system. @IronStar: There are no error in your log. I see no reason why the Flight GUI should fail to appear. I have never seen any situation where it has failed to appear. I have seen situations that required multiple clicks of the stock AppLauncher button (and I know what causes that) to bring it up, but it has always been available short of flying a vehicle that lacks a command pod / probe core, and that is as it is supposed to be.
  7. ferram4
    That's less the effect of proper aerodynamics and more the effect of the rocket equation. I wouldn't be surprised if that rocket had 5000 m/s of dV all packed together, since you've basically got no significant empty mass to speak of. Yes, the stock aerodynamics are bad in that they will somehow suck up more dV than gravity will, but you need to be aware of what you're doing. A booster with no payload is about the worst measure of this possible.
  8. ferram4
    Well, for one, with a SJE, we can have thrust drop with altitude. It's not just about the mass that could be brought in through the inlet, it's about the pressure rise in the compressor. In order to keep thrust constant with decreasing air pressure the pressure ratio would have to increase as the plane gained altitude; to maintain the same thrust at 15 km as you can get at sea level would require a 20 fold increase in compression ratio. Considering that most realistic high-speed jets already have a compression ratio of 13:1, you'd boost that to 260:1, and the best we have in real life is around 40:1, for commercial turbofans that have very limited operating conditions. We can also have fuel consumption handled properly.
  9. ferram4
    That's just the insides of the GameData/FerramAerospaceResearch folder... download everything and use it to replace the innards of the old FAR folder.
  10. ferram4
    Technically, 57 kN is the max non-afterburning thrust of the J79, so it is a pretty good figure. I always preferred the F-4, because adding more engine always makes things better. And the graphs in only show Cd, not ref Area, though that can be calculated on the next tab (and I should bring it over to the graph tab as well).
  11. ferram4
    That is due to an error that resulted in improper placement of the aerodynamic center for wings at M > 1. Basically, I screwed up badly there; it was fixed for some dev versions that were still compatible with 0.23.5. You should be able to fix it using the version from this particular commit.
  12. ferram4
    @Aethon: Consider all the reasons that you are afraid you won't be able to go back to stock; the root cause of all your fears is also the thing that tells you to install NEAR. Take your mouse pointer; download this mod. Strike down the stock drag with all of your hatred, and your journey towards the dark side will be complete! (Okay, not really. This is NEAR, not FAR we're talking about.) @Renegrade: Do you know what the maximum static thrust of a J79 is? It's 79 kN (with afterburner) and that drops off quickly as it accelerates (due to ram drag). It comes back later when the ram pressure increases the power of the engine, but that's the real-life max thrust of the engine that powered the F-104 and the F-4. This game's stuff is really overpowered. D = Cd * RefArea * Q. Technically, the definition of Cd is Cd = D / (RefArea * Q), so you're just using the rearranged definition.
  13. ferram4
    @KerbMav: You can ignore the planform shape, high / low, and sweep angle. You can't ignore angle of attack, dihedral angle, or any other angles between the flat surface and the flow. @Ruedii: It is, but not by that much. @Renegrade: Heh. Supersonic drag almost doubles the drag on the vehicle. Yeah, this is a difficult balance to do. Maybe I should just increase the reference area for NEAR and see how many people complain about rockets flipping. On the other hand, it's a good data point that you really can't ignore supersonic effects without things getting stupid.
  14. ferram4
    You would be able to read the notice in the forum thread that says that it's bundled, as well as including a link to the ModStats thread for more info. The only way it would be "too late" is if you started the game, ended, then started again. At that point, you had plenty of time to change the ModStats settings. It kind of doesn't make logical sense to send a report when the game closes anyway; that would prevent reports from being sent when the game crashes. Much more logical to send it when the game starts up if the report exists, and that only happens after the first time it runs. Hence, that's why it waits until the second time you load the game, long after you had the chance to change things, before it sends any data.
  15. ferram4
    @People with the camera flying away bug: This does not sound like a FAR issue to begin with, since it implies the CoM is being placed wrong, and FAR doesn't do anything to part mass. Nevertheless, reporting without the output_log.txt makes it impossible to diagnose your problems, even if they aren't with FAR. @Tsuki: That would work, but it would require a full physics simulation to function properly, since you would need to account for changes in the craft's orientation due to aerodynamic forces. Further, aerodynamic systems tend to become chaotic if they aren't highly stable, which would make the selection of a small timestep somewhat necessary to handle it. @IronStar: There is no reason that the FAR GUI should conflict with KW. There is no reason that a plugin should conflict with a pure part pack ever. Further, I use KW and haven't ever seen that happen. Based on the errors in the log, it appears that you have failed to install FAR correctly, as it is not finding the necessary config files. Ensure that you have 3 FAR*.cfg files in the FerramAerospaceResearch directory, that FerramAerospaceResearch is inside GameData, and that KSP is not installed in any folder which the operating system might fail to grant it the proper permissions. @falcon2000: That does not sound like a FAR issue, unless the decouplers are only falling apart at high dynamic pressures and at very high drag coefficients, in which case it is intended, as parts cannot take very high drag forces without failing in reality. If there are any actual issues, without an output_log.txt I cannot help you.
  16. ferram4
    @Northstar1989: Thick wings have no benefit in FAR compared to thin wings at subsonic speeds because both wing types are simulated as the same thing, with the same stall angle, both at the very limits of what can be achieved from moderately thick wings. They already stall with the lift coefficient of moderately thick wings, (~1.6), and so making thickness affect performance won't make thick wings any better, it will simply make thin wings worse. And besides that, wing thickness doesn't matter in FAR anyway. They're all the same thickness as far as the code is concerned. For your Duna plane, you probably want to look more into high AR wings instead of focusing on thickness, since that will provide much better L/D performance than what you're currently seeking.
  17. ferram4
    @camlost: The new AJE solver should allow more accurate determination of efficiency and thrust at not-full-throttle thrust, and will also simulate transient effects inside the engine. As a result, the spooling up won't be done from outside, it will be an intrinsic part of the engine simulation. As a nice consequence of that, multiple spool engines can be simulated as well. A further consequence of modelling transient effects is that compressor stall / surging is a thing that can happen, which should make for a fun time for users. Probably also going to include a realistic startup sequence as well, so engines that get shut down will either need to draw ElectricCharge to run a starter to get them running or will need a sufficient amount of air being rammed in the front to get it going. The plan (that I have so far) is that this will allow procedurally generated jet engines rather than requiring purely outside definitions. I've done stuff similar to this for school, at least on the scale of what AJE currently does. I found a paper talking about using a transient model to model the performance of a J85, so I'm going to look into rebuilding their model and use that, but probably with some changes to make it easier to use / less accurate, but faster / less likely to explode if given bad inputs. @Renegrade: Get something around stock-ish performance, I guess, though err on the side of working better with larger vehicles. I'd prefer the basic jet to kind of be useless above ~300 m/s though, since it's not really a supersonic engine, but I suppose to balance that it should have much better static thrust.
  18. ferram4
    Intakes no longer run on stock drag, because for some reason the engine body parts now have fuel in them, which means that they'll make a ton of drag due to the extra mass from the fuel. Parachutes are still running on that. If you want to, go and mess with the numbers yourself (there's a MM config in the NEAR folder with the changes) and find something that seems right. I don't have the time to do that, I'm working on some stuff for AJE and being prepared for more bugfixes for NEAR + FAR.
  19. ferram4
    You're correct, though the aerodynamic considerations are less about losing dV to drag (that's not a big deal really, total drag losses are about ~100 m/s, only 300 m/s for the worst vehicles, compared to the stock 1000 m/s) and more about keeping the rocket stable (big draggy stuff at front with lots of mass at bottom == launching a rocket-powered arrow backwards). Procedural fairings tend to help with that, since most of the payloads you launch aren't that aerodynamic really. You're looking at a dV of ~3200 - 3500 to orbit and an initial TWR of somewhere between 1.2 and 1.6. Any higher than that results in stability problems normally. Also, you need to start the gravity turn slow and early (not 10 km straight up and then yank over, that's not a gravity turn) in order to keep the rocket from becoming unstable. Keeping at terminal velocity isn't a concern anymore, since you'll lose control long before you get there. That's about it. Make your rockets look like rockets and they should fly like rockets.
  20. ferram4
    @TheReaper: Could you post a link to that? I'm not finding where you posted the output_log.txt and repro steps. @Kerdan: That is not a bug, that is intended behavior. The extra separator messes up the location of the CoM and CoD sufficiently that it is not stable in the configuration that you think it should be in. The stability of the mk1 pod is very delicate, and adding other parts can change its behavior drastically. Once again, not a bug, intended behavior. @123nick: Only for wings, just like FAR. Payload fairings and cargo bays still need to proper info in their titles to be detected, but that functions as well.
  21. ferram4
    @TheFireRodan: They will, but only if the shape they are shielding is draggier than the equivalent fairing shape. Basically, going and place fairings over a nice, aerodynamic shape just makes things worse because you're increasing the surface area drastically. Only add fairings for payloads that require them. @Woodstar: FAR appears on the new stock AppLauncher by default; you will need to switch an option in the debug menu in the Space Center to switch back to the Toolbar. As for ModStatistics, if you delete the ModStats dll that will remove it from FAR, though you would be much better served by just setting disabled=true in the config ModStats directory, which would be permanent instead of the temporary fix you're going for. If you delete ferramGraph.dll FAR will not run. Do not delete that dll, it has nothing to do with ModStats and has been in FAR since v0.4, many, many KSP versions ago.
  22. ferram4
    No, as that field is currently private in FARControlSys. I can make it public for the next update though.
  23. ferram4
    Yes, I am aware of how efficient thick wing sections can be for subsonic flight well below the critical Mach number. However, the data you're showing is for airfoils alone, which means that it does not include the effects of finite wing sections, which will dominate drag effects and hide virtually all of the benefits from thickness effects. Further, FAR does not simulate camber within a single wing part at all due to the fact that not only is camber useless for supersonic lift, but it also raises the question of determining which way the wing should be cambered, which is not necessarily trivial. Overall, FAR already allows you to reach the lift and drag of thick subsonic wings at low Mach number flight, because those wings are closest to the optimum possible and FAR's analysis that ignores thickness effects for subsonic flight already brings things close to the optimum.
  24. ferram4
    @Da Michel: I'll make sure that I didn't package the wrong version. That would be bad. @IronStar: The camera issue is not a FAR bug. That is due to another one of the mods you have installed and you should check those first. I suspect a similar issue might be causing the issue between sandbox and career, unless you can replicate the issues using the exact same craft file for both. In any case, not providing an output_log.txt means that nothing can be done about your bug report. @Aedile: Yes, that's why ModStatistics is set up as a separate dll rather than being integrated into the main dll like InstallChecker and CompatibilityChecker are. You would disable it far more reliably by simply setting it to disabled in the config file, but I understand why you'd rather go with that method. It will not affect how FAR performs, but you will have to remove the dll every time you update FAR or another mod that packages it. @Kamuchi: That's very odd. Try the version that DaMichel linked from github. @Northstar: In practice, in real life there is little difference between the thickness of the wing and how much lift you get from it (assuming the same angle of attack and camber) until you get near stall. At that point, thinner wings will have much more sudden stalls than thicker wings (the difference being leading edge versus trailing edge stall). In general, anything with a thickness greater than ~12% chord will have its peak lift dropped severely by early onset of trialing edge stall while anything thinner than ~12% chord will have its lift dropped severely by leading edge stall at much lower AoAs. FAR doesn't bother with this, since it's kinf od complicated to figure out and would make procedural wings a de facto required mod. All wings are set up as 5% thick, with whatever shape is ideal for either subsonic or supersonic flight.
  25. ferram4
    @Nereid: No, because NEAR assumes that there are no compressibility effects to make it simpler. Mach number is always 0 with NEAR. @Everyone having lag and weird CoL issues: Make sure you're using NEAR v1.0.3 and then makes sure to follow the instructions in the OP for dealing with messed up craft files. @Everyone dealing with turbojet shenanigans: Alright, so then the plan for next time will be to nerf all the jet engines to 1/3 their current thrust, which should put them much closer to "realistic" than they currently are to start with. Given the size of the vehicles people are launching, you should be getting stuff like that, I mean, you've got more engine on some of these than the F-4, "with enough thrust anything flies" had. So nerfs will be in the next update, don't worry, I'll give you exactly what you're asking for. @TheReaper: That is unhelpful, since you're not saying what's broken. For everyone els,e this is a good example of how not to make a bug report.
×
×
  • Create New...