Zorg Posted March 5, 2021 Share Posted March 5, 2021 5 hours ago, zakkpaz said: https://drive.google.com/file/d/1Gg4yzHCAoVpWfZQpcNyywG_LQCOsC7Li/view?usp=sharing My knowledge of each cameras real world equivalent isn't the best so i mainly focused on scaling to the tech tree and making everything as unique as i could while still being useable. Cameras that would use film cameras they have no errors and little noise, and are higher res and, except for keyhole, use ether a 1:1 or 3:2 ratio like 120 and 135 film. the images aren't that large because I'm assuming people will want to post them somewhere. Pioneer 4 is crap for obvious reasons, I added a bunch of errors and noise but upped the resolution. The Keyhole cameras are mostly panoramic, except for KH-7 and KH-8 witch have squarish ratio and variable zoom, I know thats unrealistic but I wanted to give them some unique aspect. they also go from black and white to infrared as you move up the tech tree. The Ranger cameras are TV cameras so they are fuzzy and error prone with a 480p resolution. the block 3 camera is treated as 4 four cameras, one is panoramic to simulate the combined images of a row of cameras the other three have an filter so the can be combined for a color image. TIROS and the block 2 ranger camera are the same fuzzy 480p cameras, I wish there were more filters for Neptune cameras because scanlines would be great here. Mariner 10 has a color tv camera and a B&W one these are slightly clearer then Ranger's. The B&W camera is triple the resolution based on an article I read on how you can remove the color filter from a CMOS sensor to get a sharper brighter image, I'm pretty sure it doesn't work on a TV camera but whatever. Lunar Orbiter i mostly left as is, just with a bit more fuzz. it's a film camera with a scanner so i tried to put it in between the Film and TV cameras,. I created a config for the generic mid tech camera using the same setup but again i don't know how to use unity so it's in a .bak file. Nimbus is three cameras with red blue green filters, it would be really nice if neptune cameras included a fake Stereoscopy filter for this one. The Gemini recon camera is treated as two cameras, both film one is a zoomed in B&W camera the other is a slightly lower res color camera, I'm assuming a mission like this would have a mapping camera and a camera for publicity photos, again a stereoscopy filter would be nice. I haven't had much a chance to use OAO much so I just added zoom to PEP. I added cfg for Mercury and MOL as well but those don't actually do anything. i feel like I'm done but i make make further changes as i use them in game more Sorry about my punctuation/spelling Thanks! These seem mostly sensible, I havent had a chance to go through the files yet but I have a few suggestions based on what you wrote. Keyholes: I think all of them should be B&W (no infra red). And a continuous improvement in resolution from KH1 to KH9 with field of view narrowing. They should provide provide better resolution than other BDB cameras. Specifics KH1 something like 4:3 ratio KH4 and 4B should be panoramic KH7 and KH8 again 3:2 or 4:3 KH9 main camera, very Panoramic (and very narrow FOV) KH9 mapping camera (wider FOV similar to KH1 perhaps, and something like 3:2 or 4:3 ratio). KH10 MOL - correct transform name is CameraTransform (capital C unlike the others). B&W, highest resolution among BDB cameras, smallest FOV. Non panoramic. Not sure why mercury didnt work, that one is cameraTransform Mariner 10 - I am quite happy with the existing config. I think both main cameras should be identical so you can create stereo images after the fact. The resolution is higher than regular TV (the real thing was 700p, 9.6x12.35 ratio, 0.38° X 0.47° fov). It should be the best colour camera in BDB. Could change the res to match IRL and define a FOV, (FOV doesnt have to exactly match IRL). It could also get a zoom to account for the smaller wide optics that are above the main cameras, but not configured individually in game. Quote Link to comment Share on other sites More sharing options...
Pappystein Posted March 5, 2021 Share Posted March 5, 2021 (edited) An update, yesterday I announced my Agena Document. I have been collecting lots and LOTS of data. I am 4 word document pages into writing the article and I still haven't gotten to AGENA A yet. This is going to be a long process so please don't get your hopes up that I will be pumping article out daily starting today or tomorrow for that matter. I might be able to get the first chapter out by Monday. But no promises. I love how FOIA documents don't have to be of good quality to be held in secret..... Just reading some of these gives me a headache due to the repeated memographing then photocopying then scanning of a photocopy of a memograph! Heck Microfiche may have been involved in the process... the docs are so blury it is hard to tell.... or maybe I forgot my glasses again nope it is the docs themselves! An interesting conclusion can be drawn from my reaserch as is. Most of the side view drawings released publicly before say 1990 seem to have dimensional issues. They provide in-correct lengths for the Forward rack (what conceals the forward fuel tank dome and is below the Guidance Section) Now in BDB, the forward rack is in part on the fuel tank itself and in part on the GCU. The issue is there is about 8 inches missing.... or if we want to use the MON3 fueled Agena there is 16" missing (the fuel tanks are 8" longer for a MON3/NTO Agena) Now we have a part, the GATV Agena Battery, which is ABOUT the right size to replicate the rest of the missing forward rack... on Agena B. On Agena D it would only need a 4" slice... The Forward rack was included on Agena to fit the overflow from the GCU on the hand built Agena A and Agena B rockets. each rocket could have a completely different GCU from the previous due to each GCU needing mission specific hardware. Agena D with it's "digital" GCU using a couple basic integrated circuits instead of things like mechanical clocks, did not need this space. YES that means Agena B is about 4 inches longer than Agena D, if you ignore the engine. I want to be clear, I did this by looking at two stages side by side. I have not actually measured the photos yet... mostly because I am out of Toner for my printer (I won't make the mistake of measuring on my monitor ever again! ) With the longer engine bell on Agena D, they are back to the same length. Lazy people who didn't know better saw Agena B was ~24 feet long and Agena D was ~24 ft long and just copy pasted Agena D drawing (with the Agena B aft rack added)..... This is just ONE problem I have had to solve in the past couple of days during my research. we won't talk about how hard it is to pin down all the Bell Engine Company 8xxx Engines! Oh and don't ask what came first. 8096C or 8096L. You would guess the C but I think the L actually is 10+ years older of a design... The 8096C is basically an Agena 2000 engine proposal that was not chosen for Agena 2000. Now if I could just PROVE THAT! Edited March 5, 2021 by Pappystein Quote Link to comment Share on other sites More sharing options...
OrbitalManeuvers Posted March 5, 2021 Share Posted March 5, 2021 16 hours ago, Zorg said: The current ones were also done by a community member... ...who would never take offense at them being changed - they belong to BDB so please do what's best for the mod. The original configs were investigated as much as possible given the time I had, but there's undoubtedly room for improvement in lots of cases. Plus there have been some new features added to NeptuneCamera since the originals. Quote Link to comment Share on other sites More sharing options...
zakkpaz Posted March 5, 2021 Share Posted March 5, 2021 5 hours ago, Zorg said: Thanks! These seem mostly sensible, I havent had a chance to go through the files yet but I have a few suggestions based on what you wrote. Keyholes: I think all of them should be B&W (no infra red). And a continuous improvement in resolution from KH1 to KH9 with field of view narrowing. They should provide provide better resolution than other BDB cameras. Specifics KH1 something like 4:3 ratio KH4 and 4B should be panoramic KH7 and KH8 again 3:2 or 4:3 KH9 main camera, very Panoramic (and very narrow FOV) KH9 mapping camera (wider FOV similar to KH1 perhaps, and something like 3:2 or 4:3 ratio). KH10 MOL - correct transform name is CameraTransform (capital C unlike the others). B&W, highest resolution among BDB cameras, smallest FOV. Non panoramic. Not sure why mercury didnt work, that one is cameraTransform Mariner 10 - I am quite happy with the existing config. I think both main cameras should be identical so you can create stereo images after the fact. The resolution is higher than regular TV (the real thing was 700p, 9.6x12.35 ratio, 0.38° X 0.47° fov). It should be the best colour camera in BDB. Could change the res to match IRL and define a FOV, (FOV doesnt have to exactly match IRL). It could also get a zoom to account for the smaller wide optics that are above the main cameras, but not configured individually in game. I think you may have a point about the IR cameras, it's what they used IRL but trying it out it just doesn't look right. the resolution does increase but i've avoided narrowing the field of view to much because there's nothing to zoom in on. your ratios for keyhole are more or less what i've done KH-7 is around 3.5:4 KH-8 is 1:1, but I'm hesitant to go all the way down to 4:3 with KH-1 I'm pretty sure it produced panoramic images IRL and i plan to make the generic low tech camera and Mercurys periscope 4:3 anyway once i figure out unity. MOL, Mercury, TRIOS and the generic cams don't actually work, i haven't made the necessary edits in unity yet because i don't know how. let me do i little more editing base on your advise Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 5, 2021 Share Posted March 5, 2021 1 minute ago, zakkpaz said: I think you may have a point about the IR cameras, it's what they used IRL but trying it out it just doesn't look right. AFAIK KH7 and KH8 used a mix of different types of film including experimental ones, regular black and white, false colour infra red etc. But it kind of just *feels* wrong on these with the specific colour settings Neptune has. 9 minutes ago, zakkpaz said: your ratios for keyhole are more or less what i've done KH-7 is around 3.5:4 KH-8 is 1:1, but I'm hesitant to go all the way down to 4:3 with KH-1 I'm pretty sure it produced panoramic images IRL and i plan to make the generic low tech camera and Mercurys periscope 4:3 anyway once i figure out unity. Ok fair enough. Re Mercury periscope we dont really expect community contributors to mess with the models in unity (and it would require the source files most of the time anyway). Once you have revised configs let me know and I will see whats up with Mercury. 11 minutes ago, zakkpaz said: MOL, Mercury, TRIOS and the generic cams don't actually work, i haven't made the necessary edits in unity yet because i don't know how. As above. I'll take a look at those. The generic cams are due to be replaced (the advanced one already has been replaced by Mariner 10 standalone) so I dont think we will bother with adding camera transforms to them at this stage. Quote Link to comment Share on other sites More sharing options...
draqsko Posted March 6, 2021 Share Posted March 6, 2021 (edited) So I finally got everything working again. @CobaltWolf While the parts as a whole work in 1.7.3, SAF is broken in that version, unless Procedural Fairings is somehow affecting it in that version (only mod I can think of that would have any affect out of those I've installed, but I have the exact same mods in 1.8.1 and it's fine). The fairing bits are rotated 90 degrees, forgot to get a screen grab of it, but basically to tubed halves are turned on the pitch axis, they otherwise work normally. Just trying to update B9 and and SAF up to 1.8 versions would of course break things in other ways; half the fairing was there, half wasn't, in VAB and flight; but that was to be expected. So I'm not sure if you want to restrict the versions to after 1.8.1 for BDB packaged with SAF. But I can say this, it works with almost everything in 1.8.1. Because I really don't stop to think if I shouldn't, only if I can. I did have it up to 73k but it took a long time to load, we're only at 65k-ish now. Edit: Oops, I have more than that actually. I think I need help. Edited March 6, 2021 by draqsko Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 30 minutes ago, draqsko said: So I finally got everything working again. @CobaltWolf While the parts as a whole work in 1.7.3, SAF is broken in that version, unless Procedural Fairings is somehow affecting it in that version (only mod I can think of that would have any affect out of those I've installed, but I have the exact same mods in 1.8.1 and it's fine). The fairing bits are rotated 90 degrees, forgot to get a screen grab of it, but basically to tubed halves are turned on the pitch axis, they otherwise work normally. Just trying to update B9 and and SAF up to 1.8 versions would of course break things in other ways; half the fairing was there, half wasn't, in VAB and flight; but that was to be expected. So I'm not sure if you want to restrict the versions to after 1.8.1 for BDB packaged with SAF. But I can say this, it works with almost everything in 1.8.1. Because I really don't stop to think if I shouldn't, only if I can. I did have it up to 73k but it took a long time to load, we're only at 65k-ish now. Edit: Oops, I have more than that actually. I think I need help. We are close to a new release, compatibility will extend only as far back as 1.8.1 at most this time around. Quote Link to comment Share on other sites More sharing options...
draqsko Posted March 6, 2021 Share Posted March 6, 2021 12 minutes ago, Zorg said: We are close to a new release, compatibility will extend only as far back as 1.8.1 at most this time around. Yeah I mean the current release though. Am already on 1.8.1 and will probably move to 1.9.1 in a little bit. Need to spend a weekend blowing up some rockets because I spent a couple days figuring out how I broke my install going from 1.7.3 to 1.8.1. Not to mention the packaged DLLs for B9 (2.17) and SAF (1.11) won't work properly in 1.7.3 since they are compiled for 1.8.1. CKAN will install the right versions for 1.7.3 but SAF doesn't work properly, so you can't use the new fairing bases. But if someone tries the package off GitHub, it's going to break a whole lot of stuff because B9 and SAF both don't work properly at all. That's what I was reporting that builds with those two DLLs aren't quite working in 1.7.3, with a little less coffee in me than now. Otherwise I've got it running in 1.8.1 with 202 mods installed, and everything else seems fine. Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 (edited) 3 minutes ago, draqsko said: Yeah I mean the current release though. Am already on 1.8.1 and will probably move to 1.9.1 in a little bit. Need to spend a weekend blowing up some rockets because I spent a couple days figuring out how I broke my install going from 1.7.3 to 1.8.1. Not to mention the packaged DLLs for B9 (2.17) and SAF (1.11) won't work properly in 1.7.3 since they are compiled for 1.8.1. CKAN will install the right versions for 1.7.3 but SAF doesn't work properly, so you can't use the new fairing bases. But if someone tries the package off GitHub, it's going to break a whole lot of stuff because B9 and SAF both don't work properly at all. That's what I was reporting that builds with those two DLLs aren't quite working in 1.7.3, with a little less coffee in me than now. Otherwise I've got it running in 1.8.1 with 202 mods installed, and everything else seems fine. Updating the version restriction would mean cutting a new release anyway? And since we are as I said quite close to a new release I dont see the point of releasing a version with just a change to the .version file (from which CKAN reads the version data). We will not be supporting pre-1.8 installs anymore as mentioned. Edited March 6, 2021 by Zorg Quote Link to comment Share on other sites More sharing options...
Pappystein Posted March 6, 2021 Share Posted March 6, 2021 Gets up early and ignores looming fight with power company and NEST over them breaking my heating schedule. Looks for BDB stream. AWE Da! no stream? Sulks in corner viciously typing more on the Agena. YES IT IS A JOKE! Smile, Be happy it is a nice day (well except for my thermostat dropping the temperature down to 62 degrees when I only have a light weight blanket on!) FWIW NEVER enroll in "Power savings" plans via your thermostat and your power companies! They won't give up control and they break their promises of "you won't even notice it!" whoops sorry for the soap box. Back to furiously typing sounds and talking gibberish on agena! Quote Link to comment Share on other sites More sharing options...
draqsko Posted March 6, 2021 Share Posted March 6, 2021 1 hour ago, Zorg said: Updating the version restriction would mean cutting a new release anyway? And since we are as I said quite close to a new release I dont see the point of releasing a version with just a change to the .version file (from which CKAN reads the version data). We will not be supporting pre-1.8 installs anymore as mentioned. Didn't expect a CKAN update, as I said it'll pull the right DLLs for 1.7.3 so it doesn't break anything else. But the Git release will break updates if they download and install right from GitHub. It's labeled as 1.7.3 there and it is not compatible with 1.7.3 because it will break more than just BDB. Not even sure how it broke things but after trying to use the packaged versions of B9 and SAF in 1.7.3 I noticed all internal data transmitters were missing. So yeah, don't do that. Quote Link to comment Share on other sites More sharing options...
Guest Posted March 6, 2021 Share Posted March 6, 2021 I couldn't resist playing with the latest dev build. The new Waterfall exhausts are beautiful! Quote Link to comment Share on other sites More sharing options...
zakkpaz Posted March 6, 2021 Share Posted March 6, 2021 22 hours ago, Zorg said: Once you have revised configs let me know and I will see whats up with Mercury. I did a little more work, based what you said. https://drive.google.com/file/d/1yPfCTc-3O797m_CMiUBxe4b1cq4SmTeu/view?usp=sharing Keyhole cameras are all B&W and have increasing zoom as you go through the tech tree. Mariner is two identical 720x960 color cameras although I'm fairly certain they aren't setup for stereoscopy, you my want to check in unity to see if it's treated as two cameras, if it is I'd like have the Gemini recon camera changed to be like that. Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 58 minutes ago, zakkpaz said: I did a little more work, based what you said. https://drive.google.com/file/d/1yPfCTc-3O797m_CMiUBxe4b1cq4SmTeu/view?usp=sharing Keyhole cameras are all B&W and have increasing zoom as you go through the tech tree. Mariner is two identical 720x960 color cameras although I'm fairly certain they aren't setup for stereoscopy, you my want to check in unity to see if it's treated as two cameras, if it is I'd like have the Gemini recon camera changed to be like that. Thanks! 30 minutes ago, zakkpaz said: Mariner is two identical 720x960 color cameras although I'm fairly certain they aren't setup for stereoscopy, you my want to check in unity to see if it's treated as two cameras, if it is I'd like have the Gemini recon camera changed to be like that. Its definitely 2 separate transforms, one for each main lens. and the transforms are centered on the corresponding lens. I'll ask Cobalt about extra transforms for the Gemini recon camera since he has the files for that. Quote Link to comment Share on other sites More sharing options...
DasSkelett Posted March 6, 2021 Share Posted March 6, 2021 (edited) 5 hours ago, Zorg said: Updating the version restriction would mean cutting a new release anyway? And since we are as I said quite close to a new release I dont see the point of releasing a version with just a change to the .version file (from which CKAN reads the version data). We will not be supporting pre-1.8 installs anymore as mentioned. The version file included in the latest release zip correctly references a remote version file (with the "URL" property). It would suffice to simply update this online version file on GitHub and change the minimum from KSP 1.7.3 to 1.8.0, and CKAN will see this change and update the current metadata – no new release required. If required, we can fix the metadata of older releases as well, you'd just need to tell us which, Edited March 6, 2021 by DasSkelett Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 (edited) @draqsko Ok before I respond to DasSkellet re potential metadata changes can you please confirm a couple of things to me? 7 hours ago, draqsko said: Didn't expect a CKAN update, as I said it'll pull the right DLLs for 1.7.3 so it doesn't break anything else. 9 hours ago, draqsko said: While the parts as a whole work in 1.7.3, SAF is broken in that version, unless Procedural Fairings is somehow affecting it in that version (only mod I can think of that would have any affect out of those I've installed, but I have the exact same mods in 1.8.1 and it's fine). The fairing bits are rotated 90 degrees, forgot to get a screen grab of it, but basically to tubed halves are turned on the pitch axis, they otherwise work normally. Just trying to update B9 and and SAF up to 1.8 versions would of course break things in other ways; half the fairing was there, half wasn't, in VAB and flight; but that was to be expected. So I'm not sure if you want to restrict the versions to after 1.8.1 for BDB packaged with SAF. But I can say this, it works with almost everything in 1.8.1. Are BDB SAF fairings broken on KSP 1.7.3 if installed via CKAN? And if so what were the exact version numbers of B9PS and SAF installed? 7 hours ago, draqsko said: Didn't expect a CKAN update, as I said it'll pull the right DLLs for 1.7.3 so it doesn't break anything else. But the Git release will break updates if they download and install right from GitHub. It's labeled as 1.7.3 there and it is not compatible with 1.7.3 because it will break more than just BDB. Not even sure how it broke things but after trying to use the packaged versions of B9 and SAF in 1.7.3 I noticed all internal data transmitters were missing. So yeah, don't do that. In the underlined section are you talking about the github master https://github.com/CobaltWolf/Bluedog-Design-Bureau or this packaged release? https://github.com/CobaltWolf/Bluedog-Design-Bureau/releases/tag/v1.7.1 Edited March 6, 2021 by Zorg Quote Link to comment Share on other sites More sharing options...
draqsko Posted March 6, 2021 Share Posted March 6, 2021 40 minutes ago, Zorg said: @draqsko Ok before I respond to DasSkellet re potential metadata changes can you please confirm a couple of things to me? Are BDB SAF fairings broken on KSP 1.7.3 if installed via CKAN? And if so what were the exact version numbers of B9PS and SAF installed? In the underlined section are you talking about the github master https://github.com/CobaltWolf/Bluedog-Design-Bureau or this packaged release? https://github.com/CobaltWolf/Bluedog-Design-Bureau/releases/tag/v1.7.1 Question 1: Yes, they are turned 90 degrees on the pitch axis but otherwise functional. And CKAN installed B9PS version 2.11.1 and SAF version 1.5.1 for BDB version 1.7.1 on KSP version 1.7.3. Basically it installed the correct versions of each directly rather than the packaged versions from BDB. Question 2: The packaged release: https://github.com/CobaltWolf/Bluedog-Design-Bureau/releases/tag/v1.7.1, if you download the zip from there, open it and look, you'll see it has B9PS version 2.17.0 and SAF version 1.11.0. Bad things happen with those in 1.7.3 but they work in 1.8.1. Quote Link to comment Share on other sites More sharing options...
Adam-Kerman Posted March 6, 2021 Share Posted March 6, 2021 5 hours ago, Jack Wolfe said: I couldn't resist playing with the latest dev build. The new Waterfall exhausts are beautiful! in the masters branch or the waterfall branch? Quote Link to comment Share on other sites More sharing options...
Starhelperdude Posted March 6, 2021 Share Posted March 6, 2021 1 minute ago, Adam-Kerman said: in the masters branch or the waterfall branch? Waterfall branch Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 1 minute ago, Adam-Kerman said: in the masters branch or the waterfall branch? Just now, Starhelperdude said: Waterfall branch Please do not use the waterfall branch. Things will often be broken there since I am working with unreleased versions of waterfall itself. Waterfall is 90% implemented for liquid engines on the master branch. Quote Link to comment Share on other sites More sharing options...
Adam-Kerman Posted March 6, 2021 Share Posted March 6, 2021 3 minutes ago, Zorg said: Please do not use the waterfall branch. Things will often be broken there since I am working with unreleased versions of waterfall itself. Waterfall is 90% implemented for liquid engines on the master branch. mainly interested in the Plume for the LEM's Descent Engine.. Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 3 hours ago, DasSkelett said: The version file included in the latest release zip correctly references a remote version file (with the "URL" property). It would suffice to simply update this online version file on GitHub and change the minimum from KSP 1.7.3 to 1.8.0, and CKAN will see this change and update the current metadata – no new release required. If required, we can fix the metadata of older releases as well, you'd just need to tell us which, Thanks for the pull request, I've merged that now 16 minutes ago, draqsko said: Question 1: Yes, they are turned 90 degrees on the pitch axis but otherwise functional. And CKAN installed B9PS version 2.11.1 and SAF version 1.5.1 for BDB version 1.7.1 on KSP version 1.7.3. Basically it installed the correct versions of each directly rather than the packaged versions from BDB. Question 2: The packaged release: https://github.com/CobaltWolf/Bluedog-Design-Bureau/releases/tag/v1.7.1, if you download the zip from there, open it and look, you'll see it has B9PS version 2.17.0 and SAF version 1.11.0. Bad things happen with those in 1.7.3 but they work in 1.8.1. I've now marked the release page appropriately. 4 and half months after the last release, you are the only person to have reported this issue. You might be last BDB user on 1.7.3 (or at least the only one to report it). 1 minute ago, Adam-Kerman said: mainly interested in the Plume for the LEM's Descent Engine.. Apollo engines have not been configured yet. Quote Link to comment Share on other sites More sharing options...
OrbitalManeuvers Posted March 6, 2021 Share Posted March 6, 2021 New minor B9 error after grabbing Github today. Spoiler Quote Link to comment Share on other sites More sharing options...
draqsko Posted March 6, 2021 Share Posted March 6, 2021 34 minutes ago, Zorg said: I've now marked the release page appropriately. 4 and half months after the last release, you are the only person to have reported this issue. You might be last BDB user on 1.7.3 (or at least the only one to report it). What can I say, I'm old. Actually was on 1.7.3 for so long because I had a stable setup and BDB hadn't released until winter hit. Didn't catch a break with snow this year, fired up ckan and seen the new release. Everything looked good until I started building Vanguard and realized the issue with SAF. Then I did the crazy thing and tried to use the packaged versions. Then everything went upside down and figured a clean install would be faster than trying to fix anything. Spent most of the week on that given all the install a few mods, boot it up make sure nothing broke, rinse and repeat... for 202 mods. I do find all the ways you can break something though. I had module SPU start showing up on some parts, and I don't even have RT installed. Quote Link to comment Share on other sites More sharing options...
Zorg Posted March 6, 2021 Share Posted March 6, 2021 14 minutes ago, draqsko said: What can I say, I'm old. Actually was on 1.7.3 for so long because I had a stable setup and BDB hadn't released until winter hit. Didn't catch a break with snow this year, fired up ckan and seen the new release. Everything looked good until I started building Vanguard and realized the issue with SAF. Then I did the crazy thing and tried to use the packaged versions. Then everything went upside down and figured a clean install would be faster than trying to fix anything. Spent most of the week on that given all the install a few mods, boot it up make sure nothing broke, rinse and repeat... for 202 mods. I do find all the ways you can break something though. I had module SPU start showing up on some parts, and I don't even have RT installed. An older version of Research Bodies used to have :FOR[RemoteTech] which would activate RemoteTech compatibility configs in other mods even if RT is not installed (FOR brings a mod into existence as far as MM is concerned and should only be used by the mod in question not 3rd parties writing compativility). It was fixed at some point for KSP 1.8 or 1.9. We used to get a lot of reports on that issue, its probably your culprit. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.