Araym

For those that already put the concern about some B9PartSwitch errors, and as a stop-gap measure untill BDB will update the Apollo/Saturn parts to new models (at that time, the Apollo patched here will be outdated), I kind of brute-forced myself into the MM patches provided bt BDBINC... It kind of worked, in 1.12.2: (... only shown here some of the colors available: everything is there as original present) The only B9PartSwitch error that I have still to iron out is related the last line in the above error picture ("Duplicated subtype name found ... etc etc... on part : Black"), but I reduced the probable cause to some Titan parts that I have still to check out. For those asking "why to bother for a pack nearly to be partially outdated", I'm planning (for personal use, so there will be no follow up for the public) probably to salvage some of the near-to-be-outdated Apollo parts, so I would have done this in any case. It's not a big deal for me. If anyone is interested, probably later in the day there will be a follow up, once I'll sort out the last errors remaining, with an usable link, provided also that further errors (based on other outdated parts/models, but not throwing out bold errors like the above) are not worked out (nothing is done by me on actual textures files) and that I do not use Texture Unlimited (so metal/shining parts will be probably not supported by my fixes, if anything is wrong, and left as originally in BDBINC: for the moment I was just focusing to removing the more evident errors on loading the game)

<Cue in your tipical "cine-journal" music, in (pre-)WW2 style> IT'S THE DAWN OF A NEW ERA! The renowned scientist and engineer Werhner Von Kerman demonstrated that "... burning inflammable liquids inZide a finely KonZtructed tube with an hole only on one Zide aKtually made Zhe thing fly!!!" [cit.] He named all the things related to it "rocket science", and his contraption as "Akkrekate A2 rocket". (... we heard rumors about an allegedly A1 version, but detractors of the genius Von Kerman himself are just pointing that he was setting up a gas stove and, accidentally, punctured the gas tank, barelly surviving the subsequent "unexpected explosion" but, in stroke of geniality, figuring the basis of the new science and immediately baptize the tank as "his first rocket") (Somewhere on Kerbin, starting a new career...) ("Somewhere" because I was clicking on random launch option and, in perfect kerbal way, I'm not sure which launch site I chose, but it was not the default one for sure)

Oh-oh-oh! I didn't noticed! Thanks! Arayms runs to download, to go then into a extensive check/fix of KSRAirports (... they need a bit of work...)

I see new suit, I then run to "download". I feel your problem: 2.30AM here... and no sleep at all. Thankfully KSP exists.

Thanks for the answer. I'm not worried by adding my own: I guess that an intensively study of the missions already included will guide me in "duplicate" them with new airport parameters (locations and such). Beside your own GAP airports, I kept tracking and using these: (I will eventually add some of my own, but none are ready at the moment, waiting to have KerbalKonstruct sorted in 1.12 to work for creation/edit of new bases - I admit I'm too lazy to make a separated 1.11 install just for that) I was just curious about the right way to integrate them, and you have pointed out the way.

Little question (sorry if it was a repeated one): in case of adding more airport (modded or custom made) will those be found and used by the contract pack, or are mission hardcoded only for KerbinSideRemastered bases? (I have a lot of extra modded aiports based on KSR assets and I was thinking to develope some of my own, mostly)

Yeah for both! (I have a memory shortage about the right name for the "MESA") Dunno if it's my install, or probably myself typing some wrong terms in the searchbar (or probably I failed to be accustomed to the new parts, that I didin't see them ) Thanks for the answer. Definitely not a big issue (generally everything fix by itself on launch, or reloading the craft/ leaving and returning in the VAB), but as said (at least for me) most of the time I found the bug appearing is when, in my various options clicks, the "autodeployment" was turned on before removing the door. Other kind of "random option clicks" (with or without the door present) seemed rarely to bring out the problem.

As always, I'm having a blast "testing" the new parts (my applause to @CobaltWolf and the entire BDB's "team" working on it)... ... now a couple of question, just out of curiosity: If I remember correctly, the old LEM descent stage worked as a "decoupler", for the munar take-off of the Ascent stage. It seems that it has lost this ability, in the new one: is there a planned, specifi, decouple for it (maybe I didn't find it around), will it gain back the "decoupler ability" or will it be paired to use any, generic, BDB decoupler??? (missinging to have found a specific part, I'm playing it with the generic BDB 0.625m decoupler) Wheeeere is the "camera/scientific payload" doors on the descent stage, near the ladder (from where the hystorical "one small step" was filmed), as seen here ??? Am I the usual, dumb, myself not finding the option to have it active (I just only found the switch between the H and J type model) or are we still in an early model available, and that will come "soon™" in later development??? ... please do not tell me that, for simplicity, it was scrapped... Weird "visual bug" on the VAB (as noticed on the version I downloaded around 10 hours ago... dunno if, in meantime, "new" versions were placed on the github) : ... when happened to me to switch between the various SM option for the payload bay (... shielded/not shielded... automatic deplyment or not... various type of storage set-ups), putting the door back generated this, untextured, "pink" version of the shield. I'm not sure about it, but it seems to happens only if the "autodeployment" option was turned on, the shield removed (as, for example, to set something in the payload) and then the shield turned on. It's just a glitch in the VAB (at launch it return textured... and also return textured if exiting/reentering the VAB), but it's worth a mention. (I tried various "random set of clicks", and it seems to me that it happens only in the case that the shield was removed meanwhile the "autodeployment" was turned on) Worth mentioning that I have, among a lot of other mods, "Universal Storage 2": if the additional option is triggered by an MM patch, could it be maybe a weird interaction after patching (if it went unnoticed in other mod set-ups)??? Drop me here, eventually, a PM, if it could be useful to have extra infos about it (... KSP log files or anything) if that could be useful to point out the error (my HUGE modded instal could have some involvement, eventually, but it could be worth to study if it is a direct behaviour of the part itself, or any interaction with other mods)

@Poodmund, @modus, @OhioBob Thanks to all of you, for the answers. I guess that, for the moment, I will keep CBK out of my game (I'm not in the vein to have an install it only for Career with it, not sure even if it will work, because, often I test/build my career missions, aestetically, on sandbox, and having different enviroments kills this for me). I'm not so fond to mess with the "antenna range", not only, as advice, for the risk of bugs, but also because it mess with the actual setting on the cfg files (I'm more inclined, eventually, to "fix" some antennas here and there, eventually, on part basis, adding "more powerful ones" in the late career by some "extra" ones, cfg edited, than changing everyone by a "flat bonus"). That and the addition of the J2X shold also work around the ranges on the esxtreme distance of OPM... I searched here some advices just because I thought, eventually, to beef up the DSN strenght by stock menu settings, but that someway destroy the early career game... ... but also I'm conflicted, because I'm working on an "artistic" project, where I want to recreate some kind of parallel to real life rocket story/cold war (in a kerbalized way) and, in real life, there are very few needs for "space relay systems" (... we actually reached pretty far away in space, with probes, and just by a powerful Earth array of comunications, directly pointing to each probe mission, rather than bouncing around to relays - my mind goes to probes alike the Voyager ones, or the New Horizon, all of them pretty far away and, surelly, not counting on so many space relays) I will see in a couple of tests, probably (I did some maths early, on the antenna range problem, but for easy life I adopted in my game "Antenna Helper", to also have in game an immediate calculator, rather than, every time, switch out to some spreadsheet and calculator). In any case, thanks again for your ideas and answers, that for sure helped me, if not finding an immediate solution (I will see with some practice the best way for myself) at least bringing a bit of clarity on my mind. The lack of CBK, for me, is more of an annoyance on antenna ranges, because I used it also to build extra levels on a lot of other buildings (playing mostly after "replicas" of actual launches, I found for myself to changing, sometime, the part counts and/or weight-dimension limits of VAB-SPH and launch pads/runway, to add a bit of more steps rather than the only 3 stock levels) and that is another bummer factor for not having (for the moment) it working on 1.12

Little "mixed topic" to any using OPM (but I find it could be held here, as the issue seems confirmed and I feel that any advice related to OPM is a bit of a strech posted anywhere else): as some could be aware off, "Custom Barn Kit" (that is kind-off needed by OPM, to have a 4th Tracking Station upgrade to reach the added planets with stock antenna) seems to bug, not actively detecting the "max level upgrade" for buildings in any game mode that do not use the upgrade function itself (Sandbox and Science mode). As I encountered the bug itself in Sandbox, but have yet to start (again) a Career, I'm searching advices from other OPM users: As I removed Custom Barn Kit from my install, has anyone tried to change, eventually, the stock "antenna range" and "DNS power" menu, to someway have enough reach to get to the OPM planets in Sandbox and/or Science mode, but also not overpowering them too much? Which settings are you using??? Has anyone news if Custom Barn Kit is actually working correctly with OPM and any Career mode? ... having just recently returned to KSP, and working out a new 1.12.2 install, I was wondering that if CBK is actually working in Career, I could have 2 separate istance of KSP, one for Sandbox gameplay, and one, with OPM for Career... Any other possible advice that could work for OPM, waiting a working CBK... (I'm probably going to add, as work-around, the J2X antennas, that have enough reach to get the outer system, but at the same time I would like to have "a bit more power" into the stock antennas, without using always such big ones for anything going in deep to the added planets) Thanks in advance.

Confirming the overall bug that affects the upgraded buildings to act as not upgraded at all, in all the game modes that do not need the mechanics (so Sandbox and Science mode). As I have yet to start a whole Career mode, I would like to ask to the fellow kerbonauts if the same behaviour is also present in this mode (... once reached the max levele, the building not acting accordingly) just to figure out if I could, eventually, use it in that mode alone (I was thinking to make a replicated game install, with CBK, ONLY for when I play Career).

Thanks for the answer. I'll put your cfg in my game, to have a nice "extra".... ... having a LOT of modded parts (so A LOT of different Labs, other than the stock one), I just created a little variation, to make it works, as a "catch-them-all": @PART[*]:HAS[@MODULE[ModuleScienceLab]] { ... all the above code... }

Hello, fellow Kerbonauts After a LONG time (my latest continuous, gameplay on KSP was around 1.9....) I made my return on the kerbal scene. Thanks an A LOT better PC, now, I can also enjoy to add a lot of fancy stuff that, previously, I was unable to use, alike a lot of visual mods. In the process, I added TUFX, and I'm totally blow out by the immense possibility of the post processing: I donwloaded here and there a lot of profiles (the more, the merrier) to have an ample selection and eventually find those that I could, in the end, like more... ... but obviously, my core idea is, then, to build my own ones. My problem is, then, the abbundancy of options available, so I was guessing if, somewhere, a kind soul could have build some sort of basic wiki/guide where a total noob alike me could learn some "ropes", rather than try to figure out them by random messing with them. Thanks in advance for any answer or guide.

21.8GB is my "final" installation. I have generally more than one, trimmed HEAVILY down, just for the "testing" that I need each time: generally I have secondary installation, for example, for "graphic visual testing"... one for pre-viewing any mods that add new parts (to check if I like them, before switch them in my "final" one)... and then one or more for troubleshooting/balancing between different mods/any needs could possibly arise, just to have some sane loading time. Up to now, I just found 2 solid boosters referencing textures from KSP up only to 1.8. I made a post about them in the SXT releas thread

I'm not an actual "super fan" of too many MM patches, to the point that, probably, I will do an extensive rework of any file I'm using in an "hardcore" mode alike yours, in the future. I'm back to KSP after a long absence (I was basically bored to have, mostly, the need to contiously change/update mods to the latest version, as I was doing more "coding and patching" than actually playing, to the point that I'm relived that 1.12 will be the "final version": aside minimal, future, patches, the game is finally finished and mods will settle) and I'm just making a list/check of all the thing that I want in my own version. ... but on my end, the MM-patches are the last of my problems: yes... they take "some time" to load, but done it once, MM is generally going to loads the parts from its own cache... ... the problem is after then: I have so many mods installed that (even if my pc is not a super-latest pc gaming, it is not a bad one for sure: I made it for be sure to be above any KSP mod needs I will ever have) is the UNITY needs to keep EVERYTHING pre-loaded that keep my startup time infinite... and that is not so much different if the game has to read the filse from dozen of single cfg, or from the bigger, single, MM-cached list. Just for your reference (counting not only part mods, but also visuals, planetary systems, and all the"extras" that I like) up to now, my GameData folder is 21.8 GB... that is A LOT of bytes to pre-load... ... hardcoding most of the MM patches in actual, final, cfg versions could eventually save me one minute or two, of the dozen that my KSP version need, anyway, to pre-load.

Hi, @linuxgurugamer Thanks (as always) for all you efforts to keep one of the thousand mods, that you adopted, alive for modern KSP. Coming by from the discussions of another couple of mods fighting with all the textures hidden in the "zDeprecated" folder, and during a general check of any, similar issues (that you resolved by the creation of the genuinely simple-but-amazing scripts that go fishing them automatically) I noticed, sadly that, a couple of parts are referring to textures not even in the game anymore. It's not a complete list, but only about those that I found up to now: "SXTCastor30" solid rocket booster (in the needs of textures from Squad's "solidBoosterBACC") "SXTSize2SRB" solid rocket booster (in the needs of texture from the "MassiveSRB") are both refering to those present in KSP only up to v.1.8.xx For later KSP version, even if technically the parts are loaded, they obviously show up with messed visuals, as the textures present in game are mapped totally differently. Your scripts, sadly, are not helping, as the file naming reference is actually the same, but the actual texture is not. There is not really a "simple solution" for it, rather than having the original texture files from a version prior or equal to KSP v.1.8 and, manually, copy-paste them in game. On a personal level, I already sorted out the problem (I have all the KSP version needed... actually I have them up to v.0.17 archived ), but I understand that could be more of a problem for a future STX "public release" to plunge in Squad owned assets, even if outdated (... even if, technically, there are plenty of "vintage part collections" that are simply redistribuiting old Squad files)

Sadly, even if more than capable to "fiddle with KSP" in its own "cfg - sort of software" language, I'm not capable to write a single, real, line of coding for script alike the one made for STX. Even if it could be simple to check the STX source, make some changes to the original coding and recompile it for M2X - and M3Expansion too, as parent mod, I do not even know how to, then, recompile it to an actual, working, script.... I'm more the kind of guy just capable of "brute-force" the solution by manual copy/paste... By the way: even SXT is not totally perfect... I found a couple of STX parts that are referring to textures not even in the game anymore (one of the mods that I needed to fix, on my end, by searching Squad assets in old KSP versions) - namely (up to now) at least 2 solid boosters that are in needs of textures present in pre-1.8 KSP versions

For "myself" I do often even "worse" than simply copy some texture (... I basically "rewrote" my entire game... ahahahahah in search of an "impossible balance" between stock and mods, nothing is safe). But even doing that, I generally make my changes thru MM just because, eventually, I can revert/change (keeping them organized) my own, not caring if in the meanwhile I eventually copy/paste/install new versions (And in this case, I needed just "one copy" for each texture, that could then be addressed for multiple parts by my MM patch... also by themself, the patch could be just temporary: once the original mod is eventually updated to "its own way" to deal with the texture problem, I just need to fiddle with MY files, not its own folders) Put in case that I re-install a mod over my modifications, if them are done as MM patch, they are indipendent... The problem here is that, "for myself", I actually moved the files needed, made my patches (... I have a "Squad_MM" folder where I put my personal changes to stock parts, that I'm using to store the missing textures), then thought to offer them to "everybody", just changing the paths to those available in a "stock install" (... so pointing to the "zDeprecated" folder), not knowing that the game itself DO NOT load these folders (until I tested the "to the public version" of the patches) ... I just thought to "be helpful" for other peoples, but failed. I cannot "re-distribuite" squad owned textures, technically - even if in a lot of mods they are minimally changed and reused - so... well... I basically commented out the part related to "use my patches" (as they are actually not working as they are wrote) but basically added the comments about "what is needed to do" to make them work, they are still useful at least to actually find them with their folder addres... then is it just matter to "copy them" outside and do a little adjustment to my patches and/or place them, with minimal name changes, in the mod folder itself. I prefer the "external folder" route + MM patch, rather than put them directly in the mod folder, because: 1. I do not need to make multiple copy of the same texture; 2. sometime they need to be renamed, accordingly to the part needs, as the blank placeholder texture, that could be eventually overwrtten by an accidental copy/paste of the mod itself in a latter moment (I'm not new to have lost my changes when, by chance, I had to reinstall/move things, as clumsy as I am ); 3. if I find a more "elegant" way to repair things, I can eventually "share" to other people that are suffering similar problems like mine, avoiding them the time spent by myself in resolving issues (also pointing out the problem and eventually an actual solution to the mod author itself, that could then grab my patches and modify it officially) Example unrelated: ... I found some similar "errors" in other older mods that I keep alive for myself... Being "old", they are eventually even referring to textures not even present anymore in the game. I have no problem to take the needed textures/assets from older KSP releases (I basically have ALL the KSP versions since 0.17 in my own pc... probably I could find, not well archived, even more older ones, having bought mine since v.0.13/0.14) and add them to the latest version for myself... but I (technically) cannot redistribuite those "solutions" because they are plunging in "Squad owned textures/assets" (even if they are old... even if it's tollerated, as a lot of mods keep alive "old parts", basically copying/pasting the original Squad ones).

I guessed it... ... the only alternative is manual move the needed files outside (I did it) or make a little script that, automatically, move the needed files (something alike was done for STX, that has a small bak file that fishes for the zDeprecated textures).

BAD NEWS! Even if my MM patch, to change the model textures, are pointing to the right ones, somehow KSP is not really react to the part in "zDeprecated" folder. Dunno if its ReStock acting weird on my install, some typos made by me or the base game behaviour that avoid to load textures in those folder. As VERY ROUGH workaround, for myself, I simply took the needed textures, copied out of Squad folder in one of my own creation, and adjusted my above patches accordingly (with the new custom folder address, rather than the "Squad/zDeprecated/..." one). Obviously, that way, no need for any restockwhitelist.

BAD NEWS! Even if my MM patch, to change the model textures, are pointing to the right ones, somehow KSP is not really react to the part in "zDeprecated" folder. Dunno if its ReStock acting weird on my install, some typos made by me or the base game behaviour that avoid to load textures in those folder. As VERY ROUGH workaround, for myself, I simply took the needed textures, copied out of Squad folder in one of my own creation, and adjusted my above patches accordingly (with the new custom folder address, rather than the "Squad/zDeprecated/..." one). Obviously, that way, no need for any restockwhitelist.

You can add the list I did above to the original whitelist, eventually: I prefer to keep my edit in a separate file/directory, just in case (... a new install, in which I install from the release zip... a new release only partially resolving issues... me, being dumb, forgetting of some of my adjustment and overwriting original files...)

Are you using ResStock? (the first thing that could mess with Squad texture loading) EDIT: Yeah: a file is missing in the "whitelist" needed, if using ReStock. Added in the above message by me, so it still easier to find

Some textures are missing after some model swapt by Squad (namely: new docking ports from 1.12.2, but also a lack of update to past engine rework, as Mk3Expansion still uses the old deprecated textures)... For the part "M3X_size1adapter" (folder: "GameData/Mk3Expansion/Parts/FuelTank/mk3size1adapter") it lacks the placeholder "Mk3Adapters.dds" file: copy/paste it from any other Mk3Expansion tank nearby... it's just a placeolder texture needed then to kick the swap to the Squad texture itself by the part cfg file... All the other issues (waiting an update) are resolved by a nameless volunteer (a.k.a. "me") that has prepared some fast MM patches for 1.12.2 A "basic" ModuleManager patch file is needed to be created, plus a second whitelist file in case of ReStock users, complementary to the one already in the mod, to avoid eventually Restock itself will mess with texture loading (my list are ADDING the missing texture in a new whitelist: the old one is still needed!!!). Place them anywhere inside "GameData" folder (I made a "Mk3Expansion_MM" folder, to have them separated by the mod itself, but easy to find and be erased when it will be updated): Create a M3X_texture_fix.cfg file (mandatory for everyone) and copy/paste this code, to have the updated texture folder paths: @PART[M3X_Heavyprop] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/HeavyProp/Model texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Jet Engines, Squad/Parts/Engine/jetEngines/Jet Engines texture = model000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk3Expansion/Parts/Engines/HeavyProp/rotordisc } } @PART[M3X_Linearaerospike] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/LinearAerospike/Model texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = model004, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_ConcentricAerospike] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/ConcentricAerospike/Model texture = Mk3Fuselage, Squad/Parts/FuelTank/mk3Fuselage/Mk3Fuselage texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_CLEAVER] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/CLEAVER/Model texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters texture = Mk1Structural, Squad/Parts/Structural/mk1Parts/Mk1Structural texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Turbojet_Emissive, Mk3Expansion/Parts/Engines/CLEAVER/Turbojet_Emissive texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = model004, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_serviceBay] { !MODEL{} MODEL { model = Mk3Expansion/Parts/FuelTank/ServiceBay/ServiceBay texture = Mk3Fuselage, Squad/Parts/FuelTank/mk3Fuselage/Mk3Fuselage texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = ServiceBay, Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay texture = z-400BAttery000, Squad/Parts/Electrical/z-400Battery/model000 texture = model001, Squad/Parts/FuelTank/RCSTankRadial/model000 texture = RadialTanks, Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks texture = RadialTanks_N_NRM, Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks_N texture = ksp_r_xenonTank_diff, Squad/Parts/FuelTank/xenonTankRadial/ksp_r_xenonTank_diff } } @PART[M3X_StackDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/DockingPorts/Stack texture = Mk3CargoBay, Squad/Parts/utility/mk3CargoBay/Mk3CargoBay texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters } } @PART[M3X_InlineDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/DockingPorts/Inline texture = Mk3CargoBay, Squad/Parts/utility/mk3CargoBay/Mk3CargoBay texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 texture = model001, Squad/Parts/FuelTank/RCSTankRadial/model000 } } @PART[M3X_AligningDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/AlignedDockingPort/Model texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 } } ... then, create also a new M3X_revised.restockwhitelist (safe net for ReStock users... not needed for anyone not using it) to have added the missing texture in a new whitelist (I prefer to have it in a separate file/folder, to find/remove it easily when the mod will be updated: DO NOT ERASE the one provided by the mod!!! This is a complementary file to it) Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004.dds Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000.dds Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000.dds Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks.dds Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks_N.dds Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay.dds Let me know if anything else is missing (I could have, eventually, overlooked something). Enjoy and Space Safely! EDIT: At least for me, those patch are not totally working: the textures in the various parts present in "Squad/zDeprecated" folder are the needed one for make the patch work, but (at least for me) probably a combination of ReStock and some basegame rules, does not allow them to be loaded: I moved them out in a folder of my creation, adjusted the above patches accordingly, and the problem seem resolved, but, obviously, it's a workaround that has to be done on per player basis,, each instalment of the game, manually. Sorry if you are in the same situation, with missing textures, even after my advised patches...

Some textures are missing after some model swapt by Squad (namely: new docking ports from 1.12.2, but also a lack of update to past engine rework, as Mk2Expansion still uses the old deprecated textures)... ... but tankfully, (waiting an update) a nameless volunteer (a.k.a. "me") has prepared some fast MM patches for 1.12.2 A "basic" ModuleManager patch file is needed to be created, plus a second file in case of ReStock users, to avoid eventually Restock itself will mess with texture loading. Place them anywhere inside "GameData" folder (I made a "Mk2Expansion_MM" folder, to have them separated by the mod itself, but easy to find and be erased when it will be updated): Create M2X_texture_fix.cfg (mandatory for everyone) for the updated models/textures @PART[M2X_LinearAerospike] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Aerospike/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = mk2adapters1m, Squad/Parts/FuelTank/mk2Adapters/mk2adapters1m } } @PART[M2X_MATTOCKv2] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/MATTOCK/Model texture = mk2adapters1m, Squad/Parts/FuelTank/mk2Adapters/mk2adapters1m texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Jet Engines, Squad/Parts/Engine/jetEngines/Jet Engines texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M2X_Turboprop] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Turboprop/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Hammer000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk2Expansion/Parts/Engines/Turboprop/rotordisc } } @PART[M2X_Servicebay] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Utility/ServiceBay/ServiceBay texture = z-400BAttery000, Squad/Parts/Electrical/z-400Battery/model000 texture = mk2CargoBay, Squad/Parts/Utility/mk2CargoBay/mk2CargoBay texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = ServiceBay, Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay } } @PART[M2X_AligningDockingPort] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Turboprop/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Hammer000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk2Expansion/Parts/Engines/Turboprop/rotordisc } } @PART[M2X_ShieldedDockingPort] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Utility/DockingPort/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = dockpitportstd, Squad/zDeprecated/Parts/Utility/dockingPort_v1/model000 texture = light1, Squad/Parts/Utility/spotLightMk1/light1 texture = light1_em, Squad/Parts/Utility/spotLightMk1/light1_em } } Create M2X_revised.restockwhitelist (safe net for ReStock users... not needed for anyone not using it: ADD IT MANUALLY to the existing restockwhitelist or, for safety, create a new file only with these files, to complete the ones missing by M2X itself) (UPDATED for some other missing: copy it again if you have not the latest one) Squad/Parts/Utility/landingLegLT-2/landingLeg.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004.dds Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000.dds Squad/zDeprecated/Parts/Utility/dockingPort_v1/model000.dds Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay.dds Let me know if anything else is missing (I could have, eventually, overlooked something). Enjoy and Space Safely! EDIT: At least for me, those patch are not totally working: the textures in the various parts present in "Squad/zDeprecated" folder are the needed one for make the patch work, but (at least for me) probably a combination of ReStock and some basegame rules, does not allow them to be loaded: I moved them out in a folder of my creation, adjusted the above patches accordingly, and the problem seem resolved, but, obviously, it's a workaround that has to be done on per player basis,, each instalment of the game, manually. Sorry if you are in the same situation, with missing textures, even after my advised patches...