• Content Count

  • Joined

  • Last visited

Community Reputation

22 Excellent

About AloE

  • Rank
    Observe, Explore, Listen, Collaborate

Contact Methods

  • Website URL

Profile Information

  • Location Switzerland
  • Interests Multi Observer Discovery & Exploration driven Collaboration, Current & Historic Human Earth Missions, Education.

Recent Profile Visitors

712 profile views
  1. are you willing to share your .craft file for this vessel (either via a google drive or drop box or KerbalX link) ? you may already know where to find the .craft file, but just in case not, it is likely located in the SPH folder in your game save in the main Saves folder = KSP-->Saves-->[your named save]-->Ships-->SPH (rather than in the main Ships-->SPH folder). I would like to see this behavior in action & study the parts in use so easiest for me to do that if I have the .craft file...thanks!
  2. Excellent...Thank you...I will try these out & also these configs as an example make it so much more clear the part config instructions...& I will attempt to do the process on some other parts. Thanks again! I am curious to see your images of what you are the easiest way I have found to post & image is to upload the image to & then copy the "direct link"...then paste that link into your post...this forum automatically converts it to an can use a 'spoiler' to hide it like i do below or make a 'table' to limit the picture's size in the post (it goes full size when people click on the image)... click to see example in image below:
  3. @dkavolis might be able to offer insight as to your 'only control deflect 'question. Also, in case your search did not find it, there is a bit more clarification of these values and how to figure them out in the Final Results at the end of the tutorial at github FAR wiki on Deriving FAR Values:
  4. If you worked on additional parts & are willing to share the FAR configs you created that would be both fun & helpful for me to see if I and some others I see posting recently can learn how to do this as well...thanks! unfortunately indeed the dropbox links are still broken...anyone happen to have a screenshot or a save of the page from when these links worked (or better than me at finding old dropbox content)? [Fitting]( [Swept Wing approximation](
  5. you can try the workaround & follow the active discussion about it at the MM forum topic
  6. yes, thank you...that appears good for the bulk parts approach especially by mod pack...note that MM does not produce a cache if it logs an ERR (also, I use KSP 1.4.5 but for anyone using 1.6 there seems to be some trouble with MM & parts & mods due to a Squad change/issue: proposed workaround ) The FAR wiki has some very interesting descriptions, but I have not found a discussion of 'parts' or what happens when they fall off a craft, etc which in part reinforced my recently popped 'voxels are everything bubble' I would greatly appreciate your current assessment regarding how FAR handles: a part that uses ModuleLiftingSurface, but is mostly or completely 1) inside fuselage or 2) mostly surrounded by parts that use FARWingAero? e.g. FAR ignores the lift/drag of the part, or SQUAD lift/drag values mess with FAR calculations, or otherwise makes the FAR approximation less good, or completely breaks FARs calculation process? or? heavily overlapped parts that both use FARWingAero...I frequently see this when people create a specific shape from squad or other fixed shape parts...such that literally 3/4 of one wing shape may be inside of a 2nd or 3rd wing shape (i.e. not a B9 'procedural wing') related is how does tweakscaling a part affect FAR calculations? when heat or aero stress break off or explode off a part of a FAR craft, conceptually, how does the FAR model for that craft change in voxel craft shape? plus removal of the lost part(s) FARWingAero influence on the overall craft FAR calculations? or? at the moment my focus is on the few parts most commonly used in our environment that have the ModuleLiftingSurface module. I needed a way to easily identify these few parts while building (or deconstructing) craft in SPH. DebugStuff works very well for that so that is why I described & offered that as another option. i am hoping that more & more FAR users become interested in making & sharing corrections for at least their most frequently used/favorite parts so that at least the best/most useful parts in various mod packs work well with FAR's 'calculation process'. (I use many mod parts packs so the MM cache is full of parts that still use ModuleLiftingSurface but at the moment most of those parts are not used for FAR projects since I have found changing mods packs for different projects to be too time consuming. I already manage 4 different 'project environment' GameData folders: Trappist -1, RSS/Principia, Stock KerbalEDU lessons, & FAR hope is to work out a process by which when I identify a part we really need with FAR, I can do whatever is needed to get that part working better with more of a 1x1 approach which is likely all I will be able to handle for now....) Thanks for your insights & efforts!
  7. thanks for the clarification...indeed also a concern of mine that I am looking forward t understanding & figuring out how to do we check up on a given part's effect on the over all lift & drag, etc data...for example, ZLM-Master has some interesting craft at KerbalX useful for testing purposes with FAR & particular the Rafale B - Demo Edition uses 4 of a single connector part from AirplanePlus that shows up using ModuleLiftingSurface rather than FARWingAero...the part is mostly embedded into the wing is it just ignored by FAR as if it does not exist from a lift & drag perspective or does having the ModuleLiftingSurface module called by any part in the craft break something much more serious & thus the associated symptom question what does having even a single part that uses a ModuleLiftingSurface change the blue aero overlay ball to one with arrows really mean...i.e. is the approximation made just a bit less good or does it make a big change to the FAR questions emerging from the interesting insights from the related conversation at GitHub: FAR & AirplanePlus Connector that uses MLS rather than FARWingAero
  8. OK...Thank I will use DebugStuff to look for parts missing FAR modules...especially will keep an eye out with regards to APP parts: DebugStuff used to check a part's FAR modules FAR DebugStuff
  9. indeed I very much appreciate your current improvements thus value your focus there instead...very much looking forward to your & @Booots work leading to FAR support in Kerbal Wind tunnel! Still I find amusing just imagining what some of those 'few' might actually do with a ground effect model even if was 'contained' to be only active in a very flat 'test' location like a pole ice day far in the future:
  10. at GITHub: @dkavolis sounds like I may need to dig through parts...if am i understanding correctly now that FAR will still place voxels around a part even if it has no FARWingAerodynamicModel ? ( In other words, even if the debug voxel view while building the craft in SPH for example looks great around a craft, I still may have used parts using ModuleLiftingSurface rather than only ones patched to have the proper FARWingAerodynamicModel so i can not use the voxels as an easy check for making sure all the parts I am using have the FARWingAerodynamicModel config ? ) @theonegalen Such APP wing configs sounds very helpful...i would be grateful to try those out!
  11. Once Kopernicus Expansion Continued ( KEX-RegionalPQSMods ) makes a release for 1.5.1 then I speculate SLIPPIST-1 might also work with 1.5.1: The other dependencies already have 1.5.1 versions...this post above might help you sort out the needed dependencies at that point...
  12. also, interesting conversation regarding turbofan performance in general in AJE starting with this post at AJEEX forum page
  13. fyi...AJE Extended Configs is working on an issue that appears to have some similar symptoms that I encountered with turbofans in 1.4.5 with AJE & AJEEX configs for AirplanePlus turbofans...details in this issue report at git. @dreadway2 especially if you are using the AJEEX configs with AJE, the J85 & related are not currently working see the git issue report above for details.
  14. AloE

    KerbalEdu updated to 1.4.5e882

    @MarkZero be stirring in the back of your mind for when TG projects come back around to Kerbal again:: @ShadowZone reports a rather serious memory issue with 1.5.1, with much better performance in 1.6: Memory issue in 1.5.1, 1.6 much better Also, @raidernick indicates that RO is targeting 1.4.5 (yes!) & then 1.6 (skipping 1.5.1):
  15. Indeed the transform to exclude from FAR is 'foreceIndicator'...DebugStuff really is a useful tool!...thanks again for bringing it to my attention!