Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    As an answer, the current code is licensed GPL, but several of the icons are not, making the entire distributable ARR. Now, that means that you don't need my permission for the code, but the icons for the debug voxels and the little applauncher thingy would need to be removed if you decide to fork and distribute it. Also, that's then your problem to fix issues in, not mine. Yeah, I'm working on it, just a little busy with life. I just want to be sure not tremendously terrible happens in some weird edge case I didn't think of yet. If you've got any work towards making sure things work, it's better to make a PR to the FAR repo on github, which helps things along. Easier than duplicating work, and there's always the chance that your code catches an issue that mine doesn't.
  2. ferram4
    Hey everyone, sorry it's been awhile, but v0.15.9.1 "Liepmann" is out with a couple bugfixes for KSP 1.3.1. Getting compatibility on KSP 1.4.x will still take some time, but this is necessary for Realism Overhaul to get released, so here it is. Changelog has the juicy details, as always.
  3. ferram4
    @kerbini: That almost certainly means that the shell is impacting the antenna and breaking it. So not a FAR problem; there aren't any aerodynamics going on there. @steve_v& @dubdubak: Most likely that means weird transform shenanigans. I'll look into it, but unless it's something I can trivially separate out it won't be fixable on my end. Science fantasy mods doing fantasy things tend to be... difficult to deal with. Would one of you guys be kind enough to make an issue on the FAR github so I can keep track of it? You guys know the details of what to cause it. @dlrk: I've been holding off until closer to an RO 1.3.1 release so that I'm sure that the whole thing is stable with whatever changes happen there. Unfortunately, that ended up getting hit with Valve time... I'm somewhat reluctant to rush out an official release though because I don't think it'll take too much to get things set up for 1.4 but I'm somewhat afraid of a FAR update setup where I have FAR release for 1.3.1 -> FAR release for 1.4 -> FAR bugfix for 1.3.1 to help with RO. I'm probably just paranoid though. Anyway, yeah, I am looking at what it'll take
  4. ferram4
    I'm not sure, I think it depends on who blinks in the head on. If the Tytonids blink, then they're at risk of being at a temporary energy disadvantage that will get them destroyed. If the BTs blink, then they'll likely burn up all their energy in maneuvers and end up being easy pickings.
  5. ferram4
    Nothing I can fix, considering the "issue" is that Trajectories is calling FAR's aerodynamic simulations to predict in-atmosphere flight. It's already about as optimized as I can make it, but there's no way for me to optimize another mod increasing the aerodynamic calculations by x100 every frame for future predictions. I mean, I can "fix" it by preventing the functions that Trajectories calls from actually doing anything and returning 0, but that would defeat the purpose entirely.
  6. ferram4
    How... that's strange, considering I copied the FAR stuff for release from the github repo. Must not have grabbed the one after the last-minute .version fix. Well, once the metadata gets updated for CKAN it'll be fine.
  7. ferram4
    Alright, so FAR v0.15.9 "Liebe" is out. It includes 1.3 compatibility, some mod interaction fixes, and localization support. Also includes volunteer-provided German, Russian, and Chinese translations. Anyone who wants to help contribute to more translations is welcome to, and I apologize if anything isn't translated correctly, I only know English myself.
  8. ferram4
    Alright, KJR v3.3.3 is out. Should be good for all versions of KSP 1.3.x, only weird thing was making sure CompatibilityChecker still worked and didn't do anything stupid, because for some reason it thinks that the game build is 0.1.3 rather than 1.3.... Anyway, no other changes, everything otherwise looks good.
  9. ferram4
    Believe it or not, complaining that something needs an update doesn't make it update faster. In any case, my attention has been slightly distracted by real life, then FAR, so I haven't focused on this quite as much. I do have a working build of KJR together, the only thing delaying a release is that there were some reports of IR compatibility issues that I wanted to be sure were taken care of, and it seems like they are. I'll see about getting the info right and getting an official version out in a day or two.
  10. ferram4
    I have no idea, this is something that shouldn't occur unless you've changed some settings to make it happen. If I had to make a wild-ass guess, it would be your antivirus being some kind of crazy-obsessive thing, but if that's not it, I dunno what to tell you.
  11. ferram4
    @RazorFang95: Based on what you've said, the only thing I can think of is that your computer is not allowing FAR's background voxelization process to run. I don't know what kind of locked-down settings you have on your machine, or what your machine is also doing that doesn't allow it to give up a few cores to run those processes, but that's what it sounds like is happening. Nothing I can fix, it's your settings that need to change. @bckspstuff: 1) You don't do anything for lifting bodies of any kind. Nothing, nada. The only reason the modules are still on the pods is that no one told me they were added, and so I didn't remove them. FAR doesn't remove those modules universally on the principle of, "well, even if the stock modules are completely and horribly wrong, if FAR isn't replacing them with wing modules it's safer to leave them there. It's not like they'll be misused to hack things together that shouldn't be hacked together, right?" So, me being naive and expecting things done right. 2) Stock engines have pitifully small gimbal ranges, well below real life. This means that rockets have very little gimbal control authority in KSP by default, far less than is necessary to fight the standard aerodynamic instability of most rocket designs. The speed setting is to make the gimbals move smoothly rather than jerking, which can cause the shakes and make rockets come apart very quickly. 3) So long as the part isn't a blade and is at least somewhat part of the aerodynamic fairing of the propeller, it's okay. It's the propeller blades and the transparent blur-disk itself that can't be voxelized. @Vladokapuh: Whatever works, but I'm not sure exactly how you're slowing down something that's going at least half the speed of sound on the runway. Frankly, it sounds like your plane is just too damn heavy if you need all that speed to land it safely. If I had to guess, going slower causes it to fall out of the sky and bellyflop into the ground due to a lack of lift, but going as fast as you are gives it too much lift, so you need to slam it down to give it a chance to not immediately take off again. I'd say, make it lighter / more wing and add more pitch authority; come in slower, with a higher AoA. Then, you shouldn't risk bouncing back into the air so much and you won't need to land so fast.
  12. ferram4
    @Avedis: There is no problem with ModularFlightIntegrator, as I've never seen that issue with FAR in KSP 1.2.2. If you're trying to run FAR on KSP 1.3 though, you're out of luck, because it hasn't been updated for that yet. There's still work to be done. Also, FAR v0.15.8.1 "Lewis" is out for KSP 1.2.2, which has the water crash bug and a minor display issue with the flight GUI button fixed. This is not for KSP 1.3, this is a patch to keep things running smoothly, especially since it might take some time for RO to catch up to 1.3.
  13. ferram4
    Revoxelization always happens once the craft is loaded, and as far as FAR is concerned, there is no difference between a craft that has just been loaded and was already existing in a save and one that was just launched. Make an issue on github to make it easy to track and include the save file and the craft file responsible.
  14. ferram4
    Stop trying to make FAR work on 1.3. I'm still looking at some development tweaks in 1.2.2, possibly another patch release shortly so that RO doesn't have the splashed-down unpacking crash bug that was mentioned earlier. I haven't even looked at a 1.3-compatible MFI yet. Actually, I haven't even downloaded 1.3 yet.
  15. ferram4
    As always, it's a compromise. A nice slender von Karman ogive is the best drag-wise, but is going to produce a lot of body lift and is a pain to manufacture. A slender cone is easier to manufacture, but is worse drag-wise and will still produce tons of body lift. A bi-conic is a good compromise drag-wise between the ogive and cone, but still the body lift issue. A flat, unfaired end is very good at minimizing the body lift, but is terrible for drag purposes. Still bad from a stability perspective, probably likely to break up under drag. More stout versions of everything have more drag, less body lift. It always just turns into what you can get away with. There's enough variety in fairing shape that I don't think that the specifics of shape matter too much in the grand scheme of things, at least for rockets. For planes though, von Karman ogive because drag is so much more important. I thought it was implied with lift being caused by going slightly off axis and it being unstable, but yes, that's the more explicit form of what's going on.
  16. ferram4
    Get the most specific reproduction steps you can, ideally ones that create the issue reliably all the time (if you can't, most of the time) and then post a copy of the save file that causes this. Post it all on Github so it's easier to track and I'll look into it. Probably something coincidental though. Most crashes are memory related and I'm not sure how this could result in some memory access or memory allocation error. Post a copy of the craft file and make a Github issue for it. In addition, if other mods are required for this craft, simplify it down to the point where only the mods absolutely necessary to cause the issue are involved and then list every single mod needed. If you don't do this, I can't guarantee that I can reproduce the issue considering how variable designs can be. Your theory violates conservation of angular momentum as well as basic Newtonian relativity, because boiled down to its basics, it says, "so long as there's a high enough force in this special direction, any forces in a different direction placed anywhere else will not cause the object to rotate." Fortunately for us, physics is more completely consistent than that, and any forces applied anywhere will cause the vehicle to accelerate and rotate, regardless of which direction or the magnitude of any other forces. Hooray for simple vector addition. Anyway, the problem is that your rocket is aerodynamically unstable. All rockets, unless they have very silly large fins will be aerodynamically unstable. This is not because of drag, but because of lift: the nose of the rocket produces a huge amount of lift when the rocket is angled off of its velocity vector, even slightly. As it turns out, the lift produced by the rest of the rocket is much smaller than the lift produced by the nose, so more lift is produced ahead of the CoM, so it becomes unstable. So the standard solution is careful control + active control through thrust vectoring to keep this under control. You're not flying through a hurricane, you're just manually flying through the same stuff that real rockets do, but probably with a sub-optimal design for handling the aerodynamic forces. So, without seeing your rocket (seriously, post a picture; being unnecessarily stubborn about this doesn't help), I'll make a big guess: it's got a huge fairing at the top, and not much pitch and yaw control. So lots of lift from the nose, not much thrust vectoring to counter it. So either add more thrust vectoring control, add giant fins, or make the fairing smaller.
  17. ferram4
    No, this is actually me derping up and CKAN is actually doing things right. I didn't set the .version file right and so it was limited to KSP 1.2.0. I think I should be able to get it changed to be KSP 1.2.0-1.2.2 and everything should be fine, it just might take some time to get that taken care of. I've made a PR to fix the metadata, no idea if I did it right or how long it'll take until it's merged, but I'll go and fix this issue since it's my fault in the first place.
  18. ferram4
    Small update to v3.3.2, should make IR and other exempt parts not become inflexibly rigid with multijoints enabled.
  19. ferram4
    What is happening development-wise is that things appear to be stable enough to be finished, but then someone reports a new bug and I have to take time to address it, like the one a few pages back mentioning that it would not work with the most recent MFI and MM. That looks to be a result of the dev build built for MFI 1.2.3 instead of 1.2.4 and that's a quick fix. Yes, development is still happening, it's just delayed due to personal life stuff. Sorry about not being around. Oh, also, FAR v0.15.8 "de Laval" is out now. That name may be familiar to you. Anyway, there should be a very quick update whenever 1.3 comes out, since not many changes should be necessary.
  20. ferram4
    @VentZer0: So I believe that it is a legitimate FAR issue, but I don't know how long it will take to fix because it's heavily related to the way that FAR tries to model lift (which is to say, the model it uses right now is very approximate). I'm not sure exactly what's being tripped with shifting the leading edge slat around, but I'm pretty sure that what's happening with the launch rail is that the wing is detecting that it is there, but assuming that it is the size of a fuselage bit (like most parts are) and so the wing is being treated as if it's closed on both ends. So better lift slope, stalls at a higher AoA, much more aggressive stall behavior in general. I've been trying to work on a replacement, but most of the work has to be spent on figuring out wing geometry. KSP vehicles are pretty flexible in terms of what they can be which makes separating out useful information difficult to do. Much more difficult than a flight sim where the geometry data can be input by a human and the most complicated stuff is the aero. No idea how long this will take, but probably once I get it figured out implementation will be fairly straightforward; I know what I want to do for the aero, I just need to figure out the geometry code first. [snip]
  21. ferram4
    @VentZer0: Since you're asking, no, FAR doesn't change the atmospheric pressure or temperature. No reason to, it's close enough to reality and it breaks interacting with planet mods like RSS. Because the flaps function through KSP's action groups, you must set them to work with an action group. I'm not going to add a bunch of code to rebuild the action group system for arbitrary bindings because that's way too much work to be useful. That said, the default bindings can be changed in FAR's space center menu, because those bindings are annoying to set. Those function perfectly as far as I am aware with FAR alone and if there is a conflict I have no idea how I would fix it on my end considering the small amount that FAR does to set those, so if that does not work, take it up with the other modders. Yes, FAR changes the water behavior. In particular, it applies the same drag and lift coefficients as in air but with the density scaled properly for water vs. air (read: 800x). As it turns out, moving on water at pretty high speeds like that (for water, remember) can result in very bad things happening, particularly if you try to drift around. Also, I'm confused by your second paragraph, considering it directly contradicts your first on water behavior. The first paragraph is complaining that FAR applies water forces that are too high for what you feel they should be. The second is saying that it applies forces that are too low for what you feel they should be. So which is it? Everything gets the same scalar, so at this point I don't know what you're talking about.
  22. ferram4
    @GBry: You mean issue #165, which should have been fixed on @Shadowmage's end, IIRC. There should be no issues with that now. @Jagzeplin: "Easy to install" means literally, "find the right place, download a bunch of files, and place them in the correct location." Which is why keeping the location secret is the barrier to entry, because it is literally the only thing preventing everyone from using it. Fortunately, people are good and realize the value of keeping this on the down-low for now. Alright, news update: an actual release should be ready soon, the only remaining thing I want to do is some more irritation involving the AppLauncher button, because changing everything to share a single button for a mod as intended (and as required now) doesn't play well when it toggles multiple variables, so I'm currently waiting on getting it to update its on/off state right. Small, but irritating. There should be no more serious bugs in the latest build, yell at me if you find any.
  23. ferram4
    @Cratzz & @FirroSeranel: If you have actual bugs, provide logs and full reproduction steps. I can't do anything with reports like this. Cratzz, I don't think there's any wrong behavior with yours just from the report. It sounds like the difference between a stable overweight plane with too little pitch authority and a barely stable (or even unstable) overweight plane where the instability helps it pitch up. FirroSeranel, If there's an error, I need the logs. I don't think it has anything to do with DestructionEffects though, considering there isn't a way for me to get particle effects as a mesh to voxelize. If that were the case, the flight characteristics would have changed very drastically as a result. As for engines, for airbreathers FAR models this pretty well as an effective reduction in area for the path of intake air with an approximation for the increased drag from throttling down those. FAR doesn't try to handle that for rocket engines due to the difficulty in getting real data for what's happening with those engines.
  24. ferram4
    The situation with body lift is that wings make lift much better than bodies do at low speeds and low angles of attack unless the body is really, really wide. Nothing has changed on the body lift side of things.
  25. ferram4
    Alright, so since blowfish's responses were too passive-aggressive for people, allow me to be more directly aggressive to anyone complaining about "read the past few posts" replies: You realize that the only reason these news-related posts get buried is because half of the posts on the last page are people asking for news updates when there was one right near the bottom of page 522... and the posts that made the most recent one 523 were asking for news because they didn't read a few posts above. Forums are not particularly good for searching for resources, but they are exceptionally good at getting time-related context for what's going on. Make use of that. Or even just look at posts on my profile, since that's a lot faster. The big problem with constantly responding to "update when pls?" posts with just the same stuff is that inevitably the "update when pls?" posts swamp the news posts and bury them even worse than is already happening. Stop breaking things. Anyway, news-related thingamabobs: the irritating copying buttons have been fixed, and now I need to look into the issues with MTA Stockalike cockpits. Normally voxelization breaking wouldn't faze me too much, given that it tends to point to unclosed colliders or something, but this one involves exceptions being thrown in the code which indicates something bad breaking. Still need to track that down and fix it since it might point to something more serious than limited problems with that one mod. So unless something big comes up , one last issue to fix.
×
×
  • Create New...