ferram4

Members
  • Content Count

    3,132
  • Joined

  • Last visited

Everything posted by ferram4

  1. Update to version 0.15.9.1 "Liepmann", now with voxel-model based aerodynamics! ALL USERS: NO LOGS OR REPRODUCTION STEPS = NO SUPPORT CKAN USERS: PLEASE READ THIS FIRST Users who put issues on Github are awesome. Please consider being awesome. Original Review: Aerodynamic Failures: Building a spaceplane and talking about editor GUI stuff: Features Shape-Based, Vessel-Centered, Aerodynamics - Long, thin shapes drag less than wide, flat shapes, and smooth changes in body width reduce drag. The shape of the vessel as a whole, not individual parts, controls drag, so shape the vessel as you see fit. Emergent Fairings and Cargo Bays - The voxel model method FAR uses allows for the actual shape of the vehicle to play a role in how lift and drag are applied. Build a hollow shell, and close it up, and everything inside it will be protected from the airflow as it should. Wing Effects - Realistically adjusts lift based on wing position and configuration: wingtips lift less and drag more than wing roots. Stall - Passing the critical angle of attack suddenly reduces lift and greatly increases drag. Can put planes into tailspins, flat spins, and cause crashes. Mach Effects and Area Ruling - Lift and drag will vary as expected with Mach number. Supersonic planes will need to properly area rule themselves for optimum flight characteristics. Body lift - All parts lift: a fast enough brick will fly, if not that well. Download: Get v0.15.9.1 "Liepmann" from SpaceDock! Get v0.15.9.1 "Liepmann" from Github! Official FAR Craft Sharing Thread Post your crafts there, not here, please. Violators will have their posts moved by moderators, and will have everyone very annoyed with the additional workload for both moderators and me. The FAR wiki at GitHub The source at GitHub Shader and art assets licensed All Rights Reserved Source code and binaries licensed under GNU GPL v3 Part.cfg changes powered by sarbian & ialdabaoth's ModuleManager plugin. Interface with stock heating system and other mods interacting with the physics system powered by sarbian, Starwaster and myself's ModularFlightIntegrator Toolbar powered by blizzy78's Toolbar plugin. Installation: Copy the GameData and Ships folders into the KSP root directory and merge them with the existing GameData and Ships folders. Make sure that you copy over everything in the GameData folder. Serious issues will occur unless this is done. Changelog: FAQ - Common Questions and Solutions to Common Problems What does this mod do that stock KSP doesn't? Stock KSP calculates drag as a linear combination of the drag properties of a vehicle's parts, with some interaction changes to handle some of the most obvious aerodynamic interaction effects. FAR instead calculates the drag from the vessel shape as a whole, resulting in a more realistic model of aerodynamic drag and body lift. In addition, FAR accounts for wing shape, rather than just overall area like stock KSP. Finally, thanks to the overall vessel model, FAR can account for things like area ruling, where the vehicle's area cross-section must vary properly in order to fly at supersonic speeds (well, without MOAR BOOSTERS, in any case). I don't like my rocket coming apart under heavy aerodynamic loads; how can I turn it off? In the Space Center scene FAR has a debug menu that can be accessed to mess with a large number of the parameters. Under the "cheats" section of the first tab there is an option to disable aerodynamic failure. Does this plugin work properly with other mods / part packs? Sure; FAR figures out what the properties of the part should be based on its dimensions and some basic aerodynamic assumptions. If you use a mod and suspect that it causes unrealistic behavior, search the thread to see if it has been brought up / addressed by the latest release; if it hasn't, feel free to bring it to my attention. The only exception is with wing parts, which are more complicated and currently must have their properties specified manually. Does this plugin make payload fairings and cargo bays work properly? Yes, it will support any and all fairings and cargo bays. Even those that you make out of completely unrelated parts, so long as you close up the shape. In fact, to FAR, there is little difference between the inside of a closed fairing and the inside of a fuel tank part; they're both just as internal to it. I can't seem to turn off the Flight Assistance Systems... what's going on? In the Flight Assistance GUI every button that is pressed activates a control system; when none are pushed down no control systems are active. I suspect that you've actually created a poorly designed craft and that you're attributing aerodynamic forces that you're not used to dealing with to non-existent control inputs. Do I need ModuleManager and/or ModularFlightIntegrator? Yes; they are used to properly apply aerodynamic properties to stock wing parts and to interface properly with the game's physics system. Not using them will cause FAR to not function. I'm using the win64 KSP build and I am still too outraged to read the topic title or changelog, please mock me. Very well, I shall. Haha, silly person. Anyway, win64 is now unlocked for the foreseeable future. If it turns back into the crashtastic support-heavy nightmare it was, the lock may return, but I do not anticipate the need to do that.
  2. Tired of rockets collapsing when physics initializes, but it would be fine if physics didn't start with a jerk? Irritated launch clamps can twist your rocket apart when physics starts for no apparent reason? Need more joint stiffness because you're playing Real Solar System and the stock joints just don't cut it? Then you need KERBAL JOINT REINFORCEMENT! Lessen the effects of physics glitches and get back to designing rockets to handle flight, not to handle the forces applied when the game loads. EXCITING FEATURES! Physics Easing Slowly dials up external forces (gravity, centrifugal, coriolis) when on the surface of a planet, reducing the initial stress during loading All parts and joints are strengthened heavily during physics loading (coming off of rails) to prevent Kraken attacks on ships Launch Clamp Easing Prevents launch clamps from shifting on load, which could destroy the vehicle on the pad Increase stiffness and strengths of connections Larger parts will have stiffer connections to balance their larger masses / sizes Sequential parts in a stack will be connected with a stiff, but weak connection to add even more stiffness and counteract wobble Stiffen interstage connections Parts connected to a decoupler will be connected to each other, reducing flex at the connection to reasonable levels Stiffen launch clamp connections Less vehicle movement on vessel initialization Warning: may cause spontaneous rocket disintegration if rocket is too large and over-constrained (far too many launch clamps; their connections will fight each other and give rise to phantom forces) Option to make connections fail at lower forces to maintain difficulty in launching More documentation and changelog available in the README file. Download v3.3.3 from SpaceDock! Download v3.3.3 from GitHub! Source code at GitHub Licensed under GNU GPL v3 Changelog: v3.3.3 Features --Recompile against KSP 1.3, ensure CompatChecker compatibility with 1.3 v3.3.2 Bugfixes --Fix multijoints breaking IR joints and any other exempted parts from moving v3.3.1 Bugfixes --Fix a critical bug involving unphysical forces applied to vessels on load / unload of other vessels and SOI switches v3.3.0 Features --Recompile to fix for KSP 1.2 --Update method of handling multi-part-joints to ensure compatibility with Konstruction mod --Removal of old symmetry-based multi-part stabilization due to ineffectiveness in all situations to reduce overhead --Implementation of new vessel-part-tree leaf-based stabilization for greater stability on space stations and other convoluted shapes v3.2.0 Features --Recompile to ensure KSP 1.1.3 compatibility --Change multi-part-joint system to stabilize space stations and similar vehicles with very large masses connected by very flexy parts v3.1.7 Features --Recompile to ensure KSP 1.1.2 compatibility, especially within CompatibilityChecker utility v3.1.6 Features --Update to ensure KSP 1.1.1 compatibility --Minor optimization in joint setups --Remove B9 pWings from stiffening exemption, as it is unnecessary v3.1.5 Features --Updated to be compatible with KSP 1.1 --Very minor efficiency improvements in physics easing and stiffening of joints --Fully exempt EVAs from all KJR effects --Update config parameters to function with stock fixing of never-breakable joints bug v3.1.4 Misc --Fixed issue with .version file and compatible KSP versions v3.1.3 Features --Update for KSP 1.0 v3.1.2 Features --Added code to slightly stiffen connections between symmetrically-connected parts attached to a central part; should reduce some physics weirdness BugFixes --Fixed issue where undocking was impossible. v3.1.1 BugFixes --Fixed a serious lock-to-worldspace issue involving multipart joints and physicsless parts v3.1 Features --Set multipart joints to account for large mass ratios in choosing which parts to join --Set Decoupler Stiffenning to require the connection of immediate decoupler children to stiffen things even further BugFixes --Fixed a decoupling issues with multipart joints --Fixed multipart joint lock-to-worldspace issues --Fixed some issues on loading very large, heavy parts v3.0.1 BugFixes --Fix some issues involving multipart joints --More null checking for situations that shouldn't happen, but might v3.0 Features --MultiPart joints: weak, but stiff connections along a stack that will add even more stiffness without making the connection cheatingly strong --Proper, guaranteed application of stiffened properties, regardless of stock joint parameters --Updated default config values for greater sanity --Refactoring of code for sanity BugFixes --Longstanding issue with radially-attached parts that were larger than their parent are now fixed --Many NREs from bad events or bad states now avoided v2.4.5 Features --KSP 0.90 compatibility --Include some extra checks to prevent errors from occurring v2.4.4 Features --KSP 0.25 compatibility --Update CompatibilityChecker --Shutdown functionality if CompatibilityChecker returns warnings v2.4.3 --0.24.2 compatibility v2.4.2 --0.24.1 compatibility v2.4.1 Bugfixes: --Included JsonFx.dll, which is required by ModStats --Relabeled ModStatistics.dll to allow simple overwriting for ModStats updates --Fixed buttons being added to toolbar after each flight v2.4 Features --Ensured compatibility with KSP v0.24 v2.3 Features --Updated attach node reinforcement to use properties closer to stock joint performance, but stiffer. --Decoupler and clamp stiffening increased in strength for use in Real Solar System --Removed unused config values v2.2 Features --Updated to function with KSP ARM Patch (KSP 0.23.5) --Removed inertia tensor fix, as it is now stock --Main stiffening / strengthening is now disabled by default due to stock joint improvements --Decoupler stiffening is now disabled by default due to stock joint improvements Bugfixes: --Vessels can no longer become permanently indestructible v2.1 Features --Reduced extent of decoupler stiffening joint creation; this should reduce physics overhead --Code refactoring for additional performance gains --Removed physics easing effect on inertia tensors; was unnecessary and added more overhead --Workaround for the stock "Launch Clamps shift on the pad and overstress your ship" bug that is particularly noticeable with RSS --Clamp connections are stiffer; now allowed by above workaround Bugfixes --KAS struts no longer break on load v2.0 Features --Full release of proper inertia tensors! Massive parts will feel more massive. --Full release of greater physics easing! Landed and pre-launch crafts will have gravitational, centrifugal and coriolis forces slowly added to them, reducing the initial physics jerk tremendously --Launch clamps are now much stiffer when connected to more-massive-than-stock mod parts --Tightened up default joint settings more --Decoupler Stiffening Extension will now extend one part further if it's final part is much less massive than its parent / child part --Added Majiir's CompatibilityChecker; this will simply warn the user if they are not using a compatible version of KSP Bugfixes --Fixed an issue where joints were not strengthened during the physics easing v2.0x2 Features --Added more elaborate physics easing; joints are given wide range to flex that are then tightened up and gravitational + rotating ref frame forces are cancelled out to allow internal joint stresses to be resolved prior to loading the rocket --Tightened up the default joint settings a lot Bugfixes --Fixed an issue where non-zero angular limits would force parts to be oriented in the wrong direction. v2.0x1 Features --Fixed part inertia tensors; heavy, large objects should now "feel" more massive and their connections should behave better. Thanks to a.g. for finding this one. --Launch Clamps are slightly stiffer --Removed improper stiffening for stretchy tanks that was added in v1.7; given the ability to stretch stretchy tanks, this shouldn't be necessary Bugfixes --Fixed an issue where non-zero angular limits would force parts to be oriented in the wrong direction. v1.7 Features --Added ability to calculate connection area based on volume instead of connection area; intended to handle very, very large vehicles that the standard settings cannot --Some more tweaks to the default joint parameters to stiffen things --Extra stiffening for stretchy tanks; a better solution is in the works, but this should help for RSS Bugfixes --Fixed an issue where decoupling could lead to extra stiffening joints being deleted from non-staged decouplers during decoupling / partial crashing v1.6 Features --BreakStrengthPerUnitArea will not override large breakForces; this is intended for building things using I-beams and structural elements Bugfixes --Fixed decoupler-dockingport combination parts from causing strange disassembly when undocking v1.5 Features --Updated to KSP 0.23 --Joint breaking strength can now be set to be dependent on connection area, so large part connections can have realistically large strength; on by default --Vessels are further strengthened for the first 30 physics frames after coming off rails or loading; this helps prevent jitters during intialization from breaking things apart Bugfixes: --Fixed launch clamps not being clamped to the ground after staging --Fixed an issue where the Kraken would throw launchpads at craft in orbit v1.4.2 Bugfixes --Fixed an issue that would allow more wobble to exist than it should have --General tweaks to reduce wobbling further v1.4.1 Bugfixes --Fixed an issue where maximum joint forces were calculated incorrectly --Fixed an issue where docking could cause exceptions to be thrown and cause lag v1.4 Features --Changed calculation of surface-attached connection area to be more accurate Bugfixes --Fixed an issue where lots of wobble would occur between stack-attached parts of very different sizes v1.3 Features --Better solution for failure to apply decoupler ejection forces --Will not apply stiffening to parts below a given mass; mass can be changed in config --Properly updates on docking Bugfixes --Fixed a serious issue where launch clamps would lock the ship to the surface v1.2 Features --Workaround for stock KSP bug where struts would prevent decoupler ejection forces from being applied Tweaks --Reduced default maxForceFactors to be more reasonable levels BugFixes --Fixed serious issue where struts would not properly disconnect --Fixed serious issue where decouplers would not function properly v1.1 Features --Stiffness of joint no longer erroneously dependent on breakForce / breakTorque --Decoupler stiffening function made more comprehensive BugFixes --Fixed an issue where radial decouplers would not be affected by by further decoupler stiffening --Fixed an issue where decoupler further stiffening would cause Nulls to be thrown when attached to physics-disabled parts --Fixed an issue where procedural fairings would be locked to the rocket --Fixed an issue where Infernal Robotics parts would not function --Temporary stopgap measure: stiffening not applied to pWings to prevent ultra-flexy wings Known Issues --Decouplers create no detach force with extra decoupler stiffening enabled Same issues as strut attachment bug v1.0 Release FAQ I still think that win64 is disabled, fix this! This isn't a question, but win64 is no longer locked based on the apparent stability that I've noticed in testing. It will be relocked if and only if it proves to be crashtastic just as before and the support workload grows to the levels they were at previously. Currently I do not anticipate the need to relock on win64 at any time in the future.
  3. This is a little project I started up after becoming frustrated at seeing KSP slow down even with CPU usage only at ~27%. The intent is to create a simple dependency that plugin authors can bundle (much like ModuleManager) that can be used to handle multithreading within KSP while maintaining sync with Unity's various functions (Update, LateUpdate and FixedUpdate). With this utility managing the worker threads, plugin authors don't need to worry about synchronizing-based issues and will only need to create thread-safe code in order to make good use of multithreading. Further, due to the way it is implemented, it will allow plugin authors to start a task at the beginning of one of the Unity loops and end it at the very end of that loop; i.e. you can start a physics-related function at the beginning of FixedUpdate, let it run in another thread, and then it will sync up with the Unity thread at the end of FixedUpdate. Which means you don't have to stick to the main thread to keep things running in real-time as opposed to lagging by a frame. Demonstration and Experimentation Pre-Release for Modders Only Source License This is currently a work-in-progress and is certainly not ready for public release, given that it has not been heavily tested. However, the above version is available for any interested modders to try playing around with, and I certainly welcome feedback on this. Functions to register with KSPTS: object PreFunction() { //Do stuff that isn't necessarily thread-safe //example: getting state for a PartModule that requires lots of Unity functions return someObjectFromPre; } //This is the stuff we want somewhere other than the main Unity thread object ThreadedTask(object someObjectFromPre) { //Do stuff that is thread-safe in parallel with main KSP thread //example: doing aerodynamic calculations on data passed through using someObjectFromPre return threadedTaskOutputObject; } //Runs after the threaded task is finished in main Unity thread; optional function used to do something with data void PostFunction(object threadedTaskOutputObject) { //Do something that isn't necessarily thread-safe with the output of ThreadedTask //example: taking results of aerodynamic calculations and applying forces to the relevant Part }//Runs first in main Unity thread; optional function used to set up data for threaded task A note: the pre- and post-functions are not strictly necessary, since data can be accessed across threads, but it makes things cleaner and provides a place to run not-thread-safe code that is necessary for interfacing with Unity / KSP. Example of how to use these sort of things With the current state of this in mind, are there any plugin authors who would be interested in using something like this / sees related features that they'd like / thinks they have a better way of doing X, Y, or Z / thinks my naming scheme is bad and should change to something else?
  4. The Colliders Strike Back ------------------ What it does: This disables an optimization / improvement made early in KSP's history that disabled all intra-vessel part collisions. Parts will not collide with themselves (to avoid issues with landing gear or cargo bays that are dependent on this functioning well), but will collide with other parts on the vessel where they previously did not. Part-clippers beware! This can be used for experiments into the nature of collisions, avoid issues with payloads clipping through payload fairings / cargo bays, and general mayhem. Download v1.0.1 from KerbalStuff!Download v1.0.1 from Github! Source at Github Licensed MIT Warning: This has the capacity to destroy any vehicle that includes part clipping as an integral part of the design. Any and all vehicles launched / created before this was installed may spontaneously explode if they are dependent on intra-vessel collisions being disabled. It will also make part-induced framerate drops and time slowdowns a lot nastier, due to the extra expense of all the collider calculations. You have been warned.
  5. 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.
  6. 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.
  7. @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
  8. ferram4

    WW2 BAD-T III - BDAc AI Dogfight Tournament

    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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. @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.
  16. Kerbal Isp Difficulty Scaler Tired of being able to reach orbit with tiny rockets? Annoyed that pressures greater than 1 atm don't decrease your engine's Isp? Want Isp to control your engine's max thrust, not fuel flow? Like FAR and realistic aerodynamics, but wish that it didn't unintentionally decrease the size rocket you need to get to orbit? With Kerbal Isp Difficulty Scaler, you can change that by decreasing / increasing the Isps of all engines in your game, increasing / decreasing the size of the rockets you need to get anywhere. EXCITING FEATURES! * Define IspPresets, which allow you to make the following changes: Vac Isp Multiplier - How much the vacuum Isp of the engine is scaled; >1 makes engines more efficient than stock, <1 makes them less efficient than stock Atm Isp Multiplier - Same as above, but at 1 atm (Kerbin Sea Level) Extend Curve to Zero Isp - Choose whether to have Isp bottom out at 1 atm or continue decreasing until it hits 0 (does nothing if Isp increases with atmospheric pressure) Thrust Corrector - Choose whether to have thrust vary with Isp while fuel flow remains constant (as it should) or keep the stock constant thrust with variable fuel flow Thrust Corrector Options - Can have engines rated for vacuum (creates rated thrust in vacuum and less on the pad) or rated for atmosphere (creates rated thrust on pad and more in vacuum) based on Isp and/or thrust Isp Cutoff - Isps above this will be considered "vac-rated" while Isps below this will be considered "atm-rated"†Thrust Cutoff - Rated thrusts below this will be considered "vac-rated" while thrusts above this will be considered "atm-rated"†* Select a different Preset for each saved game! * Compatibility with Kerbal Engineer and MechJeb; it still takes 4.5 km/s dV to get to Kerbin orbit in the stock game, and it still takes 3.5 km/s dV to get to Kerbin orbit with FAR installed! * Automatically works with all simple part-only mods! * Default Presets, including conversions that require real-life mass ratios and conversions to handle FAR's lower drag! †If both Isp and thrust cutoffs are set the engine must have an Isp below the Isp Cutoff AND a thrust above the Thrust Cutoff to be "atm-rated"; this means only low-efficiency, high-thrust engines will be "atm-rated" (based on your definitions of "low" efficiency and "high" thrust) Known Issues: Isps do not update in the VAB / SPH Parts List; this does not affect Kerbal Engineer or MechJeb calculations and those plugins will produce correct dV / Isp numbers Note: To avoid possibly exacerbating any of the win64 KSP build's instability inherent issues, this mod will disable itself if run on a win64 build of KSP. Download v1.4.2 from Kerbal Stuff!Download v1.4.2 from GitHub! Link to older versions Licensed under GNU GPL v3 FAQ I'm using the win64 KSP build and KIDS doesn't seem to be functioning. What gives? Due to the instability of the win64 KSP build, KIDS will disable itself on that build. This is to ensure that any issues caused by the win64 build can be definitively traced back to it. KIDS is not supported on the win64 build, and you are encouraged to use either the win32 build or to switch over to linux, as both of those builds are much more stable.
  17. @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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. Small update to v3.3.2, should make IR and other exempt parts not become inflexibly rigid with multijoints enabled.
  24. 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.
  25. @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]