Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @ZenoEval: Alright, good to know the issue (if it's even in FAR) isn't getting fixed except by luck then. @Van Disaster: It depends. Trailing edge separation is a thing that can occur, and it's generally the preferred way of stalling a wing, since it tends to be more gentle than leading edge separation. But no, a wing part stalling will not stall the parts in front of it. @baldamundo: It's there, but no, it is very unlikely to have anything to do with the issue you're looking at in support. FAR does not produce tons of garbage every few seconds unless it is commanded to recreate all of its aerodynamic data on a regular basis by other mods.
  2. ferram4
    @Vegatoxi: Well, part of it might be that you installed FAR incorrectly or that you're using mod parts that still make use of the stock aerodynamics. There should be no arrow on the CoL with FAR installed, and you have one, so you've broken something horribly. @Van Disaster: Mach number is more likely to have an effect than dynamic pressure. Possibly what's happening at lower speeds is that you've got more inertia relative to aerodynamic forces so you're reaching a higher AoA and getting some stalling on one of the control surfaces. @ZenoEval: That was an old bug that was fixed awhile ago. I have been unable to reproduce those results in my install regardless of what I try, so unless you can provide a simple, FAR-only-with-no-other-mods save that can reproduce the issue on the most recent version of FAR, I'm going to consider this to be either already fixed or an issue that cannot be reproduced.
  3. ferram4
    It's a stock bug that has been fixed by FAR as much as is possible for FAR to fix it. Unfortunately, I don't have control over how heat is transferred between the "skin" section of parts, which is where the problem occurs; since the problem occurs when that "skin" section has too small an area and mass, FAR automatically sets the minimum to whatever stock would set. If that results in things breaking, well, then that's a really rare case, because I haven't seen it happen in any cases that weren't reproducible in some form of large random temperature fluctuations in stock. Take Claw's bugfixes, scream at Squad to fix their game, scream at Squad to not roll out major changes to game mechanics in a minor patch. None of this is under my control, unless you want me to turn off overheating entirely.
  4. ferram4
    Confirmed the bug, current dev build has some quick fixes to it. Hopefully that helps a bit.
  5. ferram4
    Alright, cool; there were two bugs here, actually, and I got both of them. One reduces variation in drag properties due to very small overall cross-section changes, the other fixes negative sonic drag due to sudden drop-offs near the ends of the vehicle. Dev build on master branch has the fixes.
  6. ferram4
    Yeah, so something broke horribly, but I need the craft that caused the bug and full reproduction steps.
  7. ferram4
    Alright, so first off, since you're using the win64 unfixer, I have to assume that means that you're on win64, so after this, no further support from me, because that might be the cause of your issues for all we know given how messed up it is. But no, FAR does not need any special extra information above the stock resource intakes. It works with stock and has no MM patches or anything specifically for those modules. So if it requires Interstellar, then something Interstellar does breaks the stock intake module. If the bug doesn't require Interstellar, then the intake parts (which i note, you still haven't bothered to mention which mod they are) are likely to be set up incorrectly. At this point, I can't see any issue on FAR's end, it looks more like something else is breaking the stock code.
  8. ferram4
    Really any vehicle? Even when there are no vessels or debris loaded that include intakes it throws from that function? Even on a new save where the only craft launched is a command pod? If not, which parts from which mod? This is what reproduction steps are for, to narrow those things down. Now, the mods that mess with intake air, are they deleting PartModules or transforms randomly? Which mods are they? You know a lot more about what's going on in your install than I do, so you're gonna have to tell me what you've got going on before anything can be handled.
  9. ferram4
    Then that needs to be handled on Baha's end; it needs to inform FAR when the shape of the mesh changes, because apparently it starts with the legs open. If it doesn't do this, FAR can't be blamed for assuming that it is exactly like every other part that doesn't require shape updates constantly.
  10. ferram4
    I'll note that the first exception that I can see is from KAS, so it may be something with that. I'll also note that you haven't provided any reproduction steps at all, so there's absolutely no hope of finding the cause of your issue. Especially since there is only one way that you're getting nulls from that particular function: another mod is going around deleting intake parts, intake PartModules, or intake transforms when they shouldn't be. That or preventing FAR from clearing that safely. Until you can provide reproduction steps, there's nothing anyone can do besides guessing wildly without having any clue of what's actually going on. Which doesn't fix issues.
  11. ferram4
    ...and logs?
  12. ferram4
    It is compatible, but will default to Earth-default properties there. Either you're using an old version of FAR, OPM is not set up properly period, or a third mod is interfering. In any case, you actually need to supply logs and mod lists to have any hope of getting any support whatsoever, just like everyone else has to.
  13. ferram4
    @Jovus: Well, I was able to reproduce the issue, which is very, very simple: DR is excessively punishing towards command pods if they have any bit exposed to the airflow, and FAR ends up exposing a little bit to the airflow through the one little piece of ladder on the side, but a lot more through the lip formed by not pushing it down closer to the part below it. Yeah. That ended up being enough to kill it when combined with the really narrow heat shield. You gave a way for hot plasma to get right up against the vehicle and then bad things happened.
  14. ferram4
    FWIW, I am tweaking some stuff that might provide an improvement. No idea how much it will be though, because it's one of those things that requires evil bitwise operations to let me remove a bunch of memory, along with any bugs that might result from that, but if it works I should reduce memory usage to ~60% what it is currently. The current dev build (on the master branch) has that in there, so if you wanna try dancing with the devil and nitpick with him about exactly how much memory you can use, go ahead and try. No warranties on this one though.
  15. ferram4
    I don't see anything in there that would point to FAR being the cause, unless it happened to occur during a disintegration or many-debris-staging event combined with extremely high memory usage, which could lead to an out of memory error. Those are the only crashes that ever occur in KSP, so that means that the difficulty is in finding the mechanism for it... Given the huge number of mods that you have, the memory leaks in the stock game, and the relatively low amount of memory that you have, it's quite likely that your game is attempting to allocate too much memory. You can try reducing the number of background processes to free up some memory to work with (assuming you're using 64-bit Linux) and reduce the number of texture-heavy mods that you use to free up memory, but other than that, there really isn't anything that you can do. There isn't much else I can do, I've already removed the most common causes of FAR introducing sudden OOM errors, so... I think you just have too many mods. Yeah, it can happen on Linux too.
  16. ferram4
    So, two suggestions: The first is that the 40mm probably should have a small explosion where the shell hits. And should probably have a more imposing sound when firing. I dunno, maybe it's historically supposed to sound like a spitballgun and bounce like a bullet. The second is that the textures can probably be condensed a little bit. It looks like the Hispanos both use the same texture, as do the Breda-SAFATs and the non-pod MG151/20s. The ammo boxes and the bombs have similar, but not identical textures for the lettering, and those could probably be condensed as well, but that would require more effort; basically, separate out the lettering portion for a texture (or section of a texture) for each of those, but use a common texture for the rest. They're all very pretty, but unnecessary RAM usage reduces the amount of greater prettiness that can be included.
  17. ferram4
    Probably would be best working off of something like this. Annular radiator at the front (reference; choose either the left or middle diagrams, probably the middle would look cooler if you can justify the work to make it distinct) and cowl flaps all around it like on a radial engine. Bulbous spinner on front, propeller with 3 blades and slightly more than 3x times the widest diameter of the engine casing. 6 exhausts from the inline engine down each side of the block, slightly below the centerline. Massive air-gulping engine intake on the right side, near the back of the engine, slightly above the exhaust pipes, merging into the fuselage somewhat behind them. As for performance, the current AJE dev build does have configs for the Jumo 213A (low altitude) and the 213E (high altitude) if you want to try and pull some good performance data out of those. It should be somewhere in-between the current 211D and R-2800 for takeoff thrust, but with power and thrust steadily decreasing / staying relatively level as altitude increases until hitting the critical altitudes and switching supercharger gears, unlike most engines steadily increasing power until critical altitude. Thrust at speed should be above-average due to impressive exhaust thrust + radiator Meredith effect characteristics to counter the propeller becoming less effective. Also, thanks! Also, minor nitpick that now I can't unsee after having seen it: the hub of the R-2800 does not spin, and it's kind of noticeable with the blade pitch connections exposed there.
  18. ferram4
    Hey Lack, I've been working up AJE configs for a bunch of the prop engines in here, and I was wondering if you could put together an extra prop engine: something akin to the Jumo 213s that powered the Fw 190 Ds and Ta 152s with the radial radiator at the front. It's just a really cool design; any chance you'd be interested in making one?
  19. ferram4
    I think that the min alt setting should be required to be at least 600m rather than allowing the 150m minimum. With the 150m minimum, pretty much all planes need to be turnfighters so that they can avoid slamming into the ground during a dive or evasion since they're allowed to get so low. Problem is that if someone decides to set the minimum to 600m independently of everyone else to avoid that, everyone who does go for the 150m minimum can chew up the 600m climber's rear ends with no competition. But yes, the AI is scarily good at deflection shots now.
  20. ferram4
    Oooh, purty. I request the 37mm American M4/M9/M10 cannon (whichever version you think is best) and the Russian Nudelman-Suranov NS-37 cannon so that I can have P-39 Airacobras, P-63 Kingcobras and Yak-9Ts with massive derp-cannons firing through the propeller.
  21. ferram4
    I think there's a point to make here that people aren't noticing with stock joints: where does the most wobble occur? Is it between equal-sized parts, or does it occur when you have lower-mass parts sandwiched between higher-mass parts? If it's the former, then it's a design choice. If it's the latter, it's the physics engine not being designed to handle those larger mass ratios and not having joints set properly between parts to account for that. Now, guess which one KJR is designed to handle and fix?
  22. ferram4
    @deadok: Well, then it's still in the old wing code, and it isn't going to be fixed until the entire overhaul. Nothing I can do. @FreeThinker: Those two issues are obviously unrelated, since the error that you've posted has no effect on physics, it's only calculating it for the purposes of the GUI, hence it being in FARGUI. Now, the next question is how things are going wrong; the intake and engine both run on IntakeAir like all the other stock atmospheric parts, correct?
  23. ferram4
    Yes, if you somehow manage to rush to open the FAR GUI, switch to the Stab Deriv tab, and rush to press the button, you can theoretically beat the voxelization. Except if it actually returned a value, that means that voxelization actually occurred, so nothing went wrong there. It doesn't look like the issue is with FAR, it looks like it's some weird order-of-operations thing involving pWings. Ideally, it will be gone when the wing overhaul happens, so any time spent diagnosing it will delay replacing the entire model anyway.
  24. ferram4
    In my experience the current BDArmory AI evasion is actually a death sentence for the evading fighter. Planes evade, but blindly and with no concern for the energy they're losing or where the opponent they're evading is going. I've seen planes with much more energy extending away from a slower plane suddenly go insane and bleed off all their speed because that slower plane got a single shot off and triggered evasion... and then the was-slower-but-not-anymore plane caught up and destroyed the target plane. I've seen other planes panic themselves into the ground after a near head-on at low altitude, and I've seen planes that should have simply continued the turn in the direction they were going "evade" back into their pursuers guns. Whoever gets guns near enough to fire first nearly automatically wins the engagement, because the other one will be too busy panicking rather than actually trying to delay dying, let alone attempting to gain a reversal. The only time this doesn't happen is when the chasing fighter bleeds off so much energy that it falls below the minimum altitude set in the AI and it stops pressing the attack to climb out of that and the reprieve lets the other fighter switch things up. Older BD AI with current better-than-real-life prop engines seems like it could be tweaked to do BnZ, but current AI with real-life prop engines are stuck turnfighting, lawnmowering and making things easier for their opponent.
  25. ferram4
    @ZobrAA: I need reproduction steps and a full mod list of only the mods that need to be installed to create the issue. I cannot reproduce it at all with FAR alone, and the current code makes it impossible for an exception to occur where it says an exception is occurring unless something reaches in to what FAR is doing to set something null. There are only 4 objects that can be null in that function, and all 4 are created and given references at the same time, and all 4 are reset to null at the same time within FAR itself; this points to something else interfering somehow. How, I have no idea, but I need a lot more info than just a log.
×
×
  • Create New...