DeliriumTrigger

If I knew the first thing about programming I totally would offer to take over maintenance and tackle some of the nagging bugs this has on 1.12. But I don't, so I'm just waiting like everyone else for Shadowmage to return or for someone to take up the torch.

From what I understand after searching the thread, System Heat is a dependency, but if I go into the difficulty settings and disable it, that means that BDB will fall back to its old boil-off mechanics. If I'm doing this anyway, can I just remove the System Heat mod, or will that break stuff? Not seeing much point in having the mod installed if I'm not using it since the only thing it's doing is adding to my load time and RAM usage.

Shot you a PR with Benjee10_MMSEV and SSPX greenhouse configs.

While I can understand why you'd have no interest in trying to figure out problems with this mod combined with Parallax, in my testing it seems to work okay, at least with recent versions of Parallax.

I have been slowly chipping away at this when I have time. Rough estimate I'm like 60% of the way there, I've got the scaling looking correct, colors seem okay though maybe they could use a little more tweaking. At this point I'm still in the "make them look right from orbit" phase. Then I'll be landing to make sure sunsets look right and stuff. Main issue I'm having is with sunlight terminators and getting them to look right, like for instance on Kerbin there should be a reddish tint but there just isn't. I'm kind of learning while I go so it's a lot of trial and error and progress is slow going. Anyone with experience with this kind of stuff that would like to help, I'd sure appreciate it.

I don't know what else to say but WOW.

These look great and I hope you didn't allow that rude individual who I won't bother naming to convince you otherwise. Glad I stumbled across this thread, giving these an install now.

Looks interesting, I'm about to start an MKS playthrough, I'll give this a try and let you know how it goes.

Hey everyone, I don't know if anyone else is still using this mod. But I'm drawn back to it from time to time and usually use it as an excuse to play some planet packs that don't have updated scatterer configs and run best on older versions of KSP. Anyway, one thing that has bothered me for a while is that the USI-LS patches have been out of date for ages. So, for myself and anyone still using this mod, I decided to spend an hour or so fixing that. I have submitted a pull request to the repo, you can grab the updated cfgs from there and drop them in the SSTU/ModIntegration/USI/USI-LS directory. These patches update all relevant parts to add USI_SwapController, USI_SwappableBay, and USI_Converter modules, and changes the old Life Support and Habitat modules to the new USILS_LifeSupportRecyclerSwapOption and USILS_HabitationSwapOption so they work on newer versions of USI-LS. Where necessary to add life support or habitat values, I used values from other similar parts that I could find configs for (3 person crew module recycler percentage the same as 3 person crew pod from Near Future Spacecraft, for instance). These values may not be balanced but I won't know until I really dig in and give them a test, which I intend to do over the next week or two. For the SSTU Hab parts, all I really did was a quick find/replace job to make them all work, I didn't change any of the already existing values. I can't speak to the balance of this patch since I tried to keep it as close to original as I could. I'll have to explore that further in my own testing, but I do welcome feedback and will make adjustments if anything is wildly out of balance. In any case, I figure having a patch that works, even if it's a little unbalanced, is better than having a patch that's outdated and doesn't do anything.

When installing Extraplanetary Launchpads v 6.99.1 or 6.99.0 (for 1.9.x) through CKAN, it is reporting that the zip files are not valid, CRC mismatch. Could be happening for other versions as well, I only tested these two. Downloading 6.99.1 manually works fine, the zip file opens okay, contents appear as they should be. Not entirely sure if this is up to CKAN to fix or not, but in the interest of awareness spreading I'm reporting it here as well as on the CKAN github issues page just in case it's outside of CKAN's wheelhouse. EDIT: Well, it seems I was a bit premature here. While the zip appears to open okay, attempting to copy the contents into gamedata throws up this error: So it appears the zip is actually corrupted and CKAN is doing what it's supposed to. I'm sure this is low priority, since its for an older version of KSP. I would use 1.12 but the planet pack I'm using really works best on 1.9. Not asking anyone to jump to it and fix the old download, I can just try compiling from source, but when time is available, the corrupted zip files should either be replaced with not corrupted ones or the affected versions should be pulled from ckan entirely since they don't work. It's also worth noting that I only tried downloading 6.99.1 and 6.99.0 from ckan, and only tried extracting 6.99.1 myself. There may be other older versions that are affected by this, worth looking into. Edit2: 6.8.3 downloads and installs fine.

Seeing the same thing after installing this mod.

Ok back with another update. Don't go on some crazy bug hunt, thanks to the unity profiler and JonnyOThan we figured out that the performance problem had nothing to do with texture switching and everything to do with re-rooting my craft to a procedural part. It was just incidental that every time I added a part or changed something in the PAW, KSP was creating and destroying a copy of the entire craft, and the TU error would fire.

Lol yeah I guess I was misunderstanding. I never really noticed a tech gap but I am playing on a smaller scale, had access to the KSC science since I'm using USI LS and MKS instead of Kerbalism, and have a pretty varied assortment of engines to choose from. Most of the parts I've been using, at least for the lifter stage have been from SSTU since they look the part and I can cluster them without increasing part count. Not on the list of 'supported' mods but it has CRP support (i think?) so it slots right in. The early Merlins from that mod come maybe a little early (tier 1) but I'm guessing you're using the ones from Tundra since you're talking about a gap and them being OP, in SSTU the early Merlins are comparable to Reliant/Swivel. In any case I didn't end up using them much since I was able to blow right past them largely due to the extra science I was able to get w/o kerbalism. Don't have an answer to that one, sorry!

I think that may be a Kerbalism thing, if I'm remembering correctly. Considering how much of a jump a 3.5x rescale can be in difficulty, and if you're wary of installing specialized early game parts, you might consider using something like Contract Reward Modifier to boost the science rewards associated with contract completion. Another mod that came to mind between my last post and this is Knes. It does have some early game sounding rocket type stuff, including a pod where you launch a cat on a sounding rocket but it's also got Ariane replicas and a small lifting body shuttle. Something to consider.

Taerobee is a great mod for early game sounding rockets that helps bootstrap your fledgling space program. You get an aeroshell, a small control unit, an early parachute (put it under your science instruments, the bottom node acts as a decoupler) and a few solids/early liquid fuel engines/fuel tanks. And while I don't want to suggest using it in a cheaty way to completely bypass tech tree limitations, I find that tweakscale used in moderation to add a step between .625m and 1.25m parts (.937m?) can be a huge help if you really need it. Personally on my 2.5x rescale save I didn't find it necessary, but on a 3.5x rescale it might help bridge the gap. Using Career Evolution as my contract pack and the Strategia "local science" strategy I was able to gather up enough science to get things rolling just by landing my sounding rockets in different biomes, launching from both the launchpad and runway, and by throwing together a small rover as soon as I got rover wheels to grab some temperature and atmo pressure readings from around the KSC.

Re: my last post. I would just edit that, but I'm gonna bump for visibility in case anyone else has the mods in question installed and feels like checking to see if this is just a issue with my particular install or affecting everyone. After trying all the stuff above and taking a break to let the problem simmer, and noticing that the error wasn't firing with a new craft, I decided to rebuild the craft that was throwing the error from scratch with the console open and wait for the error to show up. This narrowed down the problem to Procedural Fairings and TU, but strangely enough, only the fairing bases. The bases have their default light and dark coloration, and then a TU recolor option. With the default colorations, once the base is placed, the error will fire every time I update a part. Doesn't matter if its adding or removing a part, changing the size of a procedural tank, adjusting the height of a decoupler shroud, or changing the contents of a tank. Every interaction with the craft throws that error and has a massive lag spike associated with it. If I switch to the TU recolor option, the error (and the lag) goes away. I'm not sure whether this is a TU problem, a Procedural Fairings problem, or a "screw this guy in particular" problem. The fairing base seems to cause TU to throw the error, but I'm not sure whether the massive lag part of it is PF or TU or just my particular assortment of mods. So I will leave that for you @Shadowmage and @pap1723 to sort out. If either of you need more info from me just ask, happy to provide. In the meantime I'll just have to remember to recolor my fairing bases.

I am getting major lag in the VAB any time I add a part or change something in the PAW, and when it happens this error is spit out in the log: ERROR: Could not locate TextureSet for MODEL_SHADER from global cache for the input name of: From what I've gathered from a google search for this error, this is related to Textures Unlimited. Anyone have any idea what's causing it, or better yet how to stop it? It's making the game intolerable to play, doing anything in the VAB takes 5x+ longer than it should because I have to wait for this lag spike to end. I really don't want to have to scrap this playthrough or uninstall TU, but I don't see how I can continue when I can't even build a rocket without having to wait 3 seconds every time I add/remove a part or touch anything in the PAW. Here is a link to the full KSP log. Edit: Just to give more info, some troubleshooting steps I've tried: 1. Used VSCode to search for MODEL_SHADER in gamedata folder. References to modulemanager.configcache, Shaddy, and SSTU. Deleted modulemanager.configcache to let it rebuild. No joy. Tried removing Shaddy since it has TU configs for restock solars and they were on the craft in question when the lag hit. No joy. 2. Searched for TexturesUnlimited in gamedata with VSCode. Found this: 3. Created a new KSP install with TU, the above listed mods and their dependencies to see if I could reproduce the error. No Luck. I'm at a total loss. Also pretty bummed out about it. My save was going so well, and I'm really happy with the selection of mods that I have installed, with no urges to add or remove anything. I didn't notice this problem before today, I suppose it's possible that it was lurking in the background and I only noticed it today, but I can't think of anything that I've changed that would have made this present itself today. The only change that I made was switching my colonization parts from Pathfinder to USI-MKS since I'm about to build a Minmus base and decided to go with what I'm familiar with instead of trying to learn a whole new colonization thing. I don't think either of those mods even interact with TU in any way to my knowledge. I can't say that I've experienced *no* VAB lag in this save, but this is an exceptional amount of lag and it appears to have come out of nowhere. It's basically unplayable and I don't know what to do now. Seriously, any help is appreciated, even if it's just pointing me in the direction of something I may have overlooked in my modlist (which is in the KSP.Log)

Getting a lot of exception spam in VAB with latest updates from CKAN. (2.4.7.1 for TS and TS redistributable, 2023.03.18 for Uberpaket) [EXC 13:56:53.666] DllNotFoundException: An Add'On Support DLL was not loaded. Missing Interface : TweakScaleCompanion.Frameworks.Waterfall.Integrator.Notifier KSPe.Util.SystemTools+Type+Find.ByInterfaceName (System.String qn) (at <58fb44557e3d487fa13c42bddbc423e1>:0) TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.InitModule () (at <7ab0c92a96a8421f8c4fe15c3118811b>:0) TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.Update () (at <7ab0c92a96a8421f8c4fe15c3118811b>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Full KSP log here. Rolling back to the last release for the time being. If you need any more info from me just let me know.

Did something change in this mod that makes the camera continue moving after you press zoom in/out, or move the camera? It used to just move and stop when I let off the button and now it's continuing to float. If that doesn't describe the issue well enough, last time I used this mod the camera had SAS on. Now it has no SAS. What gives? Edit: Nevermind, I figured out that pressing 2 turns that off. Still, now I have another issue. I used to be able to set a position on the ground, then tap Home, and the camera would be on the ground, looking at my vessel. Now I hit Home, and the camera is floating above the rocket, and no amount of moving it with the keyboard control gets it anywhere close to the position I set. I don't know what changed, but I've been using this mod for YEARS and never had these issues. What is going on?

Waterfall has an in game plume editor, and a fairly comprehensive wiki that explains how to add waterfall plumes to an engine, with lots of example plume presets for different fuel types already created that you would just need to 'fit' to the engine. If you're interested in adding Waterfall plumes to KW Rocketry I bet you could probably add them yourself faster than you can get a guy who's already maintaining a half a billion mods to do it for you

I am excited for colony building mechanics being a stock feature instead of a mod.

I'm kinda in the middle between minimum and recommended in terms of GPU, but since the gameplay footage I saw shows the game dropping to 20 frames per second when launching a 100 part basic mun rocket on a PC that far exceeds the recommended specs, I'm gonna go ahead and assume that my 2080 isn't going to cut it for my standards of playable.

the rock to the left of your rover is a stock scatter, and as such it won't have collisions. If that's throwing you for a loop you can turn the stock scatters off in the settings. Probably should anyway since there's really no need for them if you're using Parallax.

Okay! I have good news and bad news. The good news is that simply commenting out the Sun (read: barycenter) config entirely made the NREs stop, and while the sun is visible in game, it's also super tiny and only visible if you go out of your way to zoom in on it, so it looks correct for my purposes. Tested in both the release and dev build. The bad news is that I only found this out by commenting out that portion of my config outside of the game and restarting the game. Any time I edit the flares in game with the scatterer in game editor, it throws an exception and nothing actually changes. I'll spare you the full log, if you want it I can reproduce and provide but here is the relevant NRE that happens when I use the in game editor: Just to sanity check, I also tried just editing small bits of the config since I thought maybe the error was a result of commenting out an entire sunflare config, but the NRE still happens if I flip a 0.3 to a 0.7 on the intensity multiplier, change the aspect ratio, or whatever else. This is why removing configs one by one wasn't working for me, didn't test it by just editing the config outside of the game and restarting, and missed the NRE about the editor in the gigantic log full of NRE spam. I wrongly assumed that the problem with the editor was related to the other NRE spam when in fact it was an independent issue. As it stands I'm pretty satisfied with how things look, could stand to change a few things with some of the ghosts to clean up a little bit but going to chill on that until I can do it with the in game editor, since seeing immediate feedback will make that whole process much easier. If there's anything I can do to help out with the editor issue, let me know, happy to try some troubleshooting steps, test changes or send you screenshots from the debugger with my specific setup or whatever else you need.

That's great news, I'll build the dev branch tomorrow (well, today, but much later) and give it a whirl. Now that I know how to load up the plugin in debug mode, if I run into any problems I'll at least be a little better equipped to give you information that's a bit more helpful than a simple NRE. I admit that I was frustrated and inarticulate and the whole thing could have been handled better. I was grinding on trying to find *some* way to get this lens dirt gone for quite some time. Even offered to buy Jade lunch to fix the unity flare, assuming it was as simple as replacing that dirt layer with a transparent one, only to find that it was much more involved than that and that addressing it was going to be quite the undertaking. When you didn't address the NREs and then I loaded the in game editor just to find that it was an in-game text editor, it felt like a complete brush off, and even though that's totally fair since you don't owe me *anything*, I didn't handle it well. It wasn't you, it was just realizing that I was basically at the extent of my abilities and out of options, and I vented. Sorry for that. Didn't mean to imply in any way that you don't understand your own mod or anything of the sort, though I see now how that was how you took it. It was more an "well damn, if I've been banging my head against this wall for a week, and you just looked at the logs and don't see anything obvious, I'm *never* going to fix this" exasperated statement. I think the vent about the uselessness of the error message was valid, but also unnecessary, after all it's not like you designed the engine or how it reports NREs. To address the last bit, I did try using the in game editor to delete the sunflare config for Destiny as you suggested, and when I cleared it all out and reloaded the config, Destiny was still there in all of it's scattery glory. I don't know if *that* is a bug or just pebcak or what, but it's worth mentioning. At any rate, coming from 15+ minute load times on my full install, restarting KSP with less than 10 mods total isn't much of a bother at all so I'll start with your suggestion if I run into any more problems with the dev build and report my findings as best as I can. Thanks for your help