Araym

I'm not a very expert on FAR (I tried in the past, but not using it recently): if FAR still patches wings, ailerons and aerodynamic parts like in the past, it could be very likely the fact that it removes a lot of the stock "deflecting" modules, change them to its own. So, with FAR installed, it could be that KAL-1000 cannot recognize the FAR modules related to deflection. (It's just an educated guess, as said I do not have FAR in my game, recently)

Interesting naming (... immediately noticed, from a very "italian" perspective). ... è un sigarone bello grosso, per essere abbinato ad una "zona non fumatori" Very curious about the content of that very big fairing, now.

Aside some "poster images" (as shown a couple of post prior) of some quality, the development of my Saturn C-8 version 2, nicknamed "Nova" (kitbashed mostly using the in-development new Saturn/Apollo parts from BDB) had various hic-ups, mostly related to being "overengineered" for the very survival of some of the parts involved. After a series of dress rehersal, simulations and whatever was deemed necessary (a.k.a. "hit that revert button again!!") finally the design was deemed sound enough to be launched. These are the first batch of images of "Apollo IV": after being left on Kerbin, by Jeb, Bill and Bob that took a trip to The Mun with the previous iteration of the same design (go past some pages to see it, developed with the old parts from BDB), landing at Armstrong Base with the Apollo II mission, Valentina has decided to run an "all female crew" for this flight, with her as "Commander Pilot", Linlas Kerman as "Technical Engineer" and Virfel Kerman as "Scientist Specialist". These are the images released to the public, that show the major interesting moments from launch to Trans Munar Injection... Val, Lin and Vir are now quietly resting, enjoying the quiet trip on the transfer orbit. More news, probably, later, about the rest of their mission...

Reusable S-1C?????? GIMME THAT! (well... actuallly I can already build it )

Thanks for the recognition After a long time not playing KSP, now with a decent PC under me, I'm trying to "upgrade" the game not only with all the part mods that I always liked to have, but also with all the visual mods that I never dreamed of: aside "EVE", "Scatterer", updated visuals (basically "Astronomer Visual Pack", with some slight changes and personalizations) I started to play around "TUFX", for post processing. After downloading some presets, to study what I could like, I started to blend them in my own ones. It's surelly worth the effort. Aside that, when I try to make some pictures, I always look to some real life references, to try to imitate them: even in the past, when I just had a potato-pc (... example here: a 2015 screenshot, taken from an horrible 2008 celeron laptop, compared to the original that ispired it, took from one of the links in my signature that I keep just for sake of nostalgy): Now, for sure, I can have "better results"... (And not only in visuals: the above old screenshot was taken playin in "still images x minutes"... now I can run all the above fancy set up, and still have a framerate misurable in decent "frames x seconds" even with such big monstrosities of rockets)

Yeah... I have to keep the rocket leveled to the top of the launch base, end not "fit inside" the hole as it should be a Saturn V. The weirdness (unless the latest dev. branches from BDB have changed heavily some F1 engine stats, so that now is generating more heat) is that the very, same first stage (aside some cosmetic new part added, with me starting again to use Procedural Fairings) is that I used basically the same first stage of a previousversion built with the actual BDB release (not dev) and it never blew... I love to build "unconventional rocket derivation", and using parts not totally the way they are meant, so I slightly adjusted the maxtemp, knowing that my "engineering ideas" could "overstress" parts not meant to be used as I do. It was just unexpected. (Side idea: even if meant to be a "Saturn V launch tower", maybe the base could be made, in future, with some switches to give it a larger base hole, for a bit of more "kerbal engineering" of rockets not properly in the Saturn V scale dimension: more kerbal awesomeness could be used, if there could be a switcher for a flame hole a bigger, as not-default option: My Saturn C-8 is roughly 8-8.5 m with the engine skirt, with the base first stage made with a random 7.5m tank I have from an old mod... ti's "bigger" but still "Saturn-alike" enough that could have been plced in the same tower-style... even if the one I'm using is definitely "taller") Beside: ... even if they are meant to be paired to a "someway realistical scale" of a Saturn, and the exception made for the old BDB one (soon to be dismissed) was done just cause of its popularity, please do not remove the "longer" swing arm (meant for smaller rocket) option: yeah... those are not "hystorical", but being made for a rocket with more "stock-ish dimensions", they fit perfectly when using parts that follow the 0.625 scale, for builders (like me) that love to use the "saturn style" tower, but with tanks not directly meant to be actually Saturn replicas. Aside that: there is no particulary needs for a rework, even with the new BDB, Saturn, that is "almost" big enough: a little snudge with the translation tool in the vab, once placed the swing arm meant to be for a "larger diameter" Saturn V (at 64% scale), can bring the swing arms perfectly on the tank skin, without any gaps where they connect to the tower (all the swing arms have enough thickness at the base to be moved a bit even "forward", toward the rocket)

Great mod as ever... but... well... the latest release is giving me a bit of a problem: I'm used to build thic rockets, but my previous interation (I think using MLP 2.2.0) was perfectly fine with my 8x F1 Saturn C.8.... ... but with the latest this is happening: Launchbase burnt alive!

Some time ago, I made a "Saturn C8 recreation, for a direct approach for a Mun landing... ... as many could know about it, BDB is developing a new version of the Saturn V, so I took broadly the same ideas, ported with the new parts already developed. This time, is the moment for Valentina, and an all female crew, to ride "The Beast", version 2: Aside the little problem of the 8x F-1 engines destroying the launchbase at engine start, before I could releas the holds (with the whole service tower collapsing), a launch test gave me the possibility, probably, of get some of the best involuntary, screenshots that I ever took:

Fun mod to have for sure.... ... but the extra "KEMINI" experiment patches related to a good numbers of mod pods are kind off and outdated for KSP 1.12 (or more recent versions, past 1.9): BDB: the Gemini capsule patched is an outdated one (no more present in BDB from a while)... and no mention for the Mercury (that could receive some love alike the stock Mk1 pod) Tantares: it refers to the EXTREMELY OLD "Spica" (Gemini-alike) pod made by Beale, that later was actually adopted/modified/reworked in part or totally into BDB (so... geez if it's an OLD reference, being the BDB gemini capsule being reworked, since then, at least a couple of times). It could be changed eventually to the Tantares' Vostok (with the same stock Mk1 pod characteristics) WBI's MOLE pods: "Brumby" (the Gemini equivalent) is still there, but the second one mentioned in the patch has either changed part name in the latest versions, or removed entirelly Everything else "should" work as intended (aside to activate an optional file for Squad's MakingHystory, and have the KEMINI experiment also for the Squad's Vostok/Voshkod-alike pods), being mods that (if still available) are past the development phase and just maintained, with minimal modifications, to more recent KSP specifications (FASA, HGR, Corvus, K2... etc etc). Only extra rework should just focus, maybe, on a little better ModuleManager coding, as being absent for a lot of those patches any "logical syntax" to check if/when more correctly apply such patches to the mods.

(^_^) Thanks for the answer. I made a bit more of launches under my set-up and "kind of" understood (slowly) how to manage better the recovery, and also "reuse" parts from the Scrapyard inventory, if recovered "stock-alike" (FMRS method included in this). Basically, I totally missed Scrapyard's "inventory" tab at first, but slowly I'm starting to understand how to re-install "used parts", so partially I resolved my doubts. I was expecting more a way of "recover the whole stage" and find it in the KCT craft storage menu, but I guess that I'll survive even if it is not possible. That mostly resolve my question #2. (With practice I'm sure that I'll find my way to optimize the recovery/rebuilt phase at the best possible) Still, then, for any kind soul still around to help me, valid my first question: ... just to confirm if "Recovery Controller" is, as it seems to me, actually redundant with my set-up.

He merged my "older" version, with still remaining issues. I pushed to his Github the latest changes (placed on my github version after I noticed your issues)

They seems "identical" because I didn't changed any file name and/or folder structure, to further allow "compatibilty" for anyone that had the "original" one: it's not needed for the textures itself, and neither for the naming of the MM patches, as .cfg files. But the latter are VERY different, for some (namely, the Titan and Gemini parts) A LOT, and now, for anything else, for some logical switches that trigger the patches themselves and/or the coding that made the errors appears. That was done with the clear idea that anyone that had the "original", broken, version, could download mine and simply copy/paste them onto the old one, allowing the merge when/if prompt to do so, without much of an headache of lingering bad config left around.

You hit me hard in the nostalgic department, Angel... ... Kuzzter comics where some of the funniest kerbal story that, still, I remember. It heavily inspired my kerbal lore.

I still have to take a look at AirplanePlus parts, but my "educated guess" is that a lot of AirplanePlus propeller engines have a specific texture files that is used for the "rotating disk", and probably the base "texture switch" config added by TURD is working only on the main body of the part itself (and the blades when they are not spinning), but not catching back the "turning disk" original texture (I didn't see an equivalent "recolored" disk, for example) (P.s.: i'm not a dev of TURD... just a random guy that has a bit of experience of "customizing" KSP, to make some guesses) "Mk2Extended" and "Mk3Extended" make use of A LOT of stock textures, recycled from the most disparated Squad sources, even for their propellers, so it could be proably easier to redirect them to a new set, alike those needed by TURD, by their native setup

Do you use, by chance, "Restock"? Because it uses some "deepmasks" to, basically, mask any clipping part that could go thru an air intake, technically with the intent to hide such parts, and show only the air intake itself (basically using the same shader that are used when you turn on the internal view of a capsule) But it never looked right to me, obtaining exactly the effect described by you, to make all the masked area basically "see throught"/invisible If that is the case and you want to remove it from Restock, you have just to navigate to "... <...your install>.../GameData/ReStock/Patches/Aerodynamics" and delete the file "restock-intakes-depthmasks.cfg" If do you not have ReStock, you should then just search for other cfg that have the deepmask additional .mu model that creates the mask, for the part that show that behaviour. i found very few using it, aside restock, and generally is a patch thst is related to Restock, rather than a set directly on the main parg .cfg file (and generally only by mod that are in the ReStock team, so it easy to find) because it uses the module named "ModuleRestockDepthMask" (so in its MM patch, there is often a reference to ":NEEDS" related to restock itself

Daily "Araym noob questions to some modders, in his way to put together too many mods": I adopted all together "KCT", "Scrapyard", but also I was used already to have "Flight Manager for Usable Stages", "Stage Recovery" and "Recovery Controller". My Issues: it seems to me that I do not find anymore the ability to select what type of recovery I liked, brought by "Recovery Controller", during design. Is it because, now that I have KCT, the whole recovery process it is handled by it only? (Just to know, if "Yes", if I can remove it safely... one less thing is welcomed, as I'm starting to be used to the KCT process and I do not really care anymore about "RC") If its own rules are met (having parachutes/dV and capabilities to landing burn left/ etc etc), "Stage Recovery" is it working, in background, when I do not bother to fly back any spent stage. Also, if "FMRS" is used (to actually "skip back" to a staging point), I'm perfectly fine to "flyback" a stage to its landing. So... what is my problem? FMRS behave alike a "stock recovery" (just saving me back the money spent... as I was used), meanwhile I was thinking, now that I have also the KCT+Scrapyard combo, if there a way to actually store the recovered booster in the KCT storage (alike a main craft does), to be lately "merged" back only with the main craft (to cut building time) rather than "rebuild it as new" (that generally makes the production time longer) (On this matter, could I have missed some settings, or some set up I should turn on during building/prelaunch/launch phase?) Thanks in advance for anyone kindly to enlight this old soul.

Very weird because I hunted down most of the "possible causes" of B9PartSwitch to go crazy... ... but I guess it could be improved further. About my answer: Yes. I'm a bit of a cheeky old grumpy bas**rd. The error didn't happen to me, so, reading "BDBINC master branch", I assumed it was related to the "original" master branch, not a call to "Araym's master branch fixes". So i just wanted to have a bit of fun, if it was the case. (... as said: YES: I'm definitely a cheeky bad person ) In any case, there is space for further improvements, in the config files I left untouched: I had a conversation with some of the most well known mod makers that pointed me to some "unwritten rules" about MM patching, and I was already working in a "refinement" of the above coding, even more "fail proof". Give it a try (the url is the same above: https://github.com/Araym-KSP/BDBNIC ): it should resolve almost everything, at this point. Let me know if it works: I PROMISE a less cheeky answer, if you find still some problems... maybe... (... aside being an "old cheeky grumpy bas**ard", I'm also a "moody bas**ard", so my answer are often driven by my status of the moment )

<Araym looks above a couple of messages, where an entire page of this post is basically related to the very same problem> Fixing it? Naaah. "IM-POS-SI-BLE!" I didn't spend 2 days and I didn't made a github link, and a related post right 2 message above this one, to make public a fix for it.... No. I didn't. If only it wasn't in this page...

That is what I thought was needed, IN ADDITION to the original whitelist from Mk2Expansion. It actually works only for the first (needed) Squad/Parts/Utility/landingLegLT-2/landingLeg.dds Sadly, the game DO NOT load anything from the "Squad/zDepecated" folder, so my fix about the whitelist is pointless for anything else MY work around implies a bit of "work": I created a folder, in KSP's GameData, called "Squad_MM" I copied all the part in the folder "Squad/zDeprecated", in my new folder above (ending with a folder adress alike "<where is your install>.../GameData/Squad_MM/Parts") I removed ALL the .cfg files from each copied part to not have the game load the old, deprecated, Squad parts themselves, but just the texture (and eventually, if needed for future patches, also the 3D models) on demand I changed, from the big MM patch that fix the actual Mk2Expansion texture issue (above in one of my post), every texture that has "Squad/zDeprecated/Parts/.... <stuff>..." as address, with the newly created by me "Squad_MM/Parts/ <... stuff...>" (because now I have there the needed texture, available. You can change the final folder name, where you copy the old parts, as you like: it happens to me that I have just a folder named like "Squad_MM" where I store other ModuleManager patches related to stock parts, so it was handy for me. Just remember to adapt my big MM patch to YOUR folder address. I made, in the "Mk3Expansion" post, basically the same series of discussion: being "sibling" mods, I actually worked on a fix at the same moment, developing the very same issues at the same moment, and then comunicating the same, end result, on both threads. You can do the same "workaround" I proposed to you, now, here for the Mk2Expansion parts also using my original patches that for sure are still in the Mk3Expansion thread. Difference is that you do not need to copy again the texture (you have already done it) and you need just to grab the additional proposed whitelist (if it has any texture that is not in the "Squad/zDeprecated"... if not, you can skip it), and just adjust my MM patch for the Mk3Expansion in the same way I explained to you, here, at the #4 point, for the Mk2 (... my patches are build the same... ) In BOTH cases, DO NOT change/erase any original "whitelist" from any of the 2 mods: THOSE ARE NEEDED FOR EVERYTHING ELSE still working. Add mine in separated .cfg files, wherever you like, inside "GameData"

First of all, I'm very intrigued by this mod... ... but (there should be a "but", if I'm writing ) if I'm not a bother, I would like to ask a technical question: Provided that I play with "too much mods", so further problem could arise aside those that I'm going to consider here, how this mod works with modifications of Kerbin itself (mostly Kopernicus based one)??? I'm asking because, aside using an extended Kerbin system with stock+OPM, I play with a custom made Kerbin atmosphere (based from an xml table I found for modders willing to develope their own planetary pack) with data extrapolated by those present on real Earth, to rise Kerbin atmosphere from 70k altitude to 100km altitude It will everything adeguately scaled up by itself, taking in consideration the different "karman line" i have in my install???

Sooooo... ... no more "high bay integration", "random events" and such??? just the "risk to part fail" and "repair on the field"???? I kind like the idea to put in production each rockets (putting then importance to schedule it, also) rather than throwing craft after craft out... The idea of have to put effort in a production schedule+repairs (and those random events that could screw you over randomly) is actually the only thing that made me pick BARIS as a single mod that have everything together, rather than have to mix different mods to have similar functions Me sad ---- Ok... stupid "fake rant" aside: there will be a way to, at least, keep as "optional integration" BARIS, for the "production schedule" mechanics, but use everything else from the advanced options "EVA repairs", at least???

In an undisclosed location <... after a whole day (yesterday) spent to fix B9PartSwitch errors in BDBNowInColors... today I had fun with it....> a mock-up of the MOL (a.k.a. : "Misterious Orbital Laboratory" because our great rocket scientists have still to figure out what to do with it), a semi-secret effort to develope laboratories and space stations, was launched by a Prometheus III-C rocket, carrying on top a refurbisced, unmanned, Leo capsule. Discussions (started by a bunch of perfectionists) insued later: some point that we probably forgot a mysterious "Transtage" (... uhhmm... I don't know........ HEY GUYS!!! Is anyone again started to bring home rocket parts, to build fireworks????? HEY BILL!!! Do you know anything about this... uhm... what was its name?... "strange-stage"????) ... or maybe not, if we were testing the actual capacity to launch the planned station. But in any case. the capsule reentered safely (albeit we discovered later that a decoupling section was omitted and the whole assembly capsule+retrorocket section landed... well.. I guess we tested the parachute system... "Am I Right, BIll?!? Didn't you bring home another parts for your side projects, right???") and the mockup station is dangling in space, in orbit... we will see if use it for something, or simply deorbit,.....

FIXED! ... at least for the errors related to Gemini and Titan crafts (other problems could be derived by being developed from past/outdated models...) and for KSP v.1.12.2 ... Anyone interested, waiting eventually for the return of Drakenexh, could find it here: https://github.com/Araym-KSP/BDBNIC (Hit the big, green, button and download the zip: then put the GameData's content in your game's GameData folder, as any other mod) NOTES: This is an INTERIM FIX: I didn't adopted the mod, it simply happened that I made the fix for myself and I'm allowing anyone to download them (under the same, original, license) making them public. Aside the main, evident, bugs for the Gemini and Titan parts, I didn't made any change. No new texture, no eventual fixes on set-up that could be outdated by the time. BDB is going to be (soon™) updated, with new Apollo and Saturn parts: when that will happen, the color changes of the present Apollo capsule will be outdated and good for be scrapped. Do not be surprised once it will happen. You can, eventually, ask me for fix other errors, but that will, eventually, happen only on my free time and WITH NO COMMITMENT AT ALL!!! I could even tell, simply, "no", if in the future I will not be in the possibility! This is not a mod I'm mantaining: just a lucky "star alignment" brought me here and put me in the mood to deep my toes in fixing it. Said all the above, enjoy your recolors and Space Safely!

... and... ... in the end... ... ... ... I PROBABLY DID IT!!! The last error was a SUBTYPE duplicate for ONE SINGLE PART, that kept to slip between all my checks, focused more in finding some code syntax error or some bad placed definition in them. I had to re-organize the entire patch, tyding it to place all the SUBTYPES related to a single part (or serie of parts) all together, to then notice one of those was present TWICE for one part, messing with the B9PartSwitch logic. I'm running the final checks to be sure that everything is in order, then I will upload on the net the revised patches.

Fixing the recolored Titan parts is taking "a bit more" of the predicted time... (aside for a pause for dinner, I did nothing else than pestering with MM coding and figuring the needed improvements) I wanna die... I'm already dead, inside... BUT I WILL NOT SURRENDER MYSELF! " 'Cause when the goin' gets tough . . . the tough get goin'!" <Cue in John Belushi's "Animal House" movie soundrack>