SpacedInvader

Ok, so if I want my config to supersede everything else (this is my personal tweaks package) I should name the mod folder something like zMyTweaks? Or is it the config file name that matters?

New question, is there a way to supersede a ":FINAL" modifier from another MM config? I've tried using ":FINAL" as well as ":AFTER[X]" in mine, but neither seem to work to override another mod's ":FINAL".

How hard would it be to adapt this to create a procedural radiator for KSPI?

This is sadly true... I'm a little bit of a perfectionist, which reminds me, I am making some progress on the Jovian system, though not as fast as I'd like due to lots of RL activity.

Shipping with instructions it will be then. Thanks for the info.

I don't mean I want to actually edit the files, but rather configure them after the fact through module manager, basically creating a temporary configuration through the MM config while leaving the mod's actual files untouched.

The Earth and the Moon should both be part of the basic RSS download from the OP. My planet pack for getting other orbital bodies without Planet Factory is also somewhere in the thread, though I'd have to do some looking to find the right post for a link. I think at some point we're planning on putting that pack up on the OP.

Is there a way to edit another mod's settings config file through a MM config? I'm currently working on a TACLS MM config that will give it units that make sense, but part of the requirement to make it work is that the consumption and production rates for it's units will also have to be edited. I am planning on offering the config for public use, so that means I've either got to find a way to change those settings through the MM config or deliver the MM config with a set of instructions on what values to set where. Any help would be appreciated. Thanks.

I don't really mean using the autopilot to fly the whole launch, just to give you the right time to launch. For the Moon, I set it as target, then click launch into target plane followed by engage autopilot. This will warp you to the right moment to launch with about 20 seconds countdown remaining. I then disengage the autopilot take manual control, launching on a heading of 90° which should put you on or very near the plane of the Moon. I will warn you that the dev build from about a week ago didn't do a good job of this, so to be sure you're launching into the right plane, zoom out to map view before launch and double check that your ship is centered on the orbit line of the Moon. Nope, azimuth is exactly what you want. You want the arcsin (that sin-1 on most scientific calculators) of the cos of your target inclination divided by the cos of your latitude. So, for the ISS's 51.6 inclination from the cape, you would do cos(51.6) / cos(28.5), which is 0.621148 / 0.878814 = 0.706800. Arcsin(0.706800) = 44.98° or 135.02° if you're going south, meaning that to launch into the ascending arc of the orbit, you'd launch on a heading of 44.98° and for the descending arc (not sure if those are the right terms) you'd fly heading 135.02°. Now, the rest of the page helps you figure out things like when to launch, including how much lead time to give yourself so you end up at the correct inclination and also the correct orbital plane. Again, the launch into plane mode of MechJeb helps a lot here, though it won't calculate the lead time for you, so you've either got to do that yourself or you've got to carry some extra dV to correct your inclination after reaching orbit.

For this, Google "Launch azimuth" and check out the orbiter wiki page on the subject. There is math involved, but it is pretty straightforward. For the Moon, the inclination is ~-28.4, and to get into the right plane, mechjeb's launch into plane of target mode is invaluable. PS: Sorry for no hyperlink, I'm on a phone right now and it's a PITA to make it work right.

http://forum.kerbalspaceprogram.com/threads/29862-0-23-Procedural-Dynamics-Procedural-Wing-0-7

I'm off for the next few hours, but here's a thought... compare stock DRE loss and dissipation values to the ones in the DRE tweak for RO. Maybe we can use the difference between those as the multiplier to make PP heatshields conform to RSS?

As far as I can tell, the only thing it breaks it the check to make sure you've got Real Fuels. If you've got RF, then the result should be the same, just manually. As for it being and LOD bug, you'd be correct there and I brought this up there before I brought it up here. I just wanted to make sure the fix was presented here in case anyone else came searching for it without prior knowledge. Regarding the code snippet you posted, I figured it might have something to do with that, but there isn't exactly documentation about what changing that does. Should I increase it to improve performance, or decrease it, and by how much?

I've got another question / bug. If I tweak a PP part while other parts are attached to it, it often transpires that some of the other parts' attachment nodes get move around so that they end up floating in space. I've only experienced this when tweaking the length of parts as of yet. I've done some searching in the thread and not found anything similar to this so far, so I'm hoping someone might know whats going wrong so I can avoid having to rebuild sections of my rockets over and over again because I tweaked something below.

Sorry for quoting myself here, but I've figured out exactly how to fix the blurry textures just in case anyone has this same issue. Apparently, LOD doesn't like the way certain parts are either created or deleted based on certain mods being in the GameData folder. I'm guessing this is because LOD does its pass before module manager, so it never assigns the textures to the new parts after they have been created later in loading. Commenting out all of the "NEEDS[X]" commands (leaving PART of course) has fixed that issue. Now, on a different note, does any adjustment need to be made to make the heatshield work correctly with an RSS/RO scale game? I've been trying to use it, but it keeps blowing up very early in the reentry process using an almost identical reentry profile to one that works perfectly fine for the stock DRE heatshield of the same size with the RO tweaks...

So I'm not sure if this has been asked about at all, but what would the chances of getting a version of this put together for the real solar system mod?

So I recently found this asteroid mod which seems like it would be an interesting way to build up an asteroid belt for RSS and get rid of the asteroid vacuum effect that RSS has, but I'm curious if there is really any reason for this just yet. From my poking around, it seems that other than one shot per class science experiments and messing around with base building, there just isn't that much worthwhile to do with them, meaning putting them into RSS might be wasted effort. What are your thoughts about this?

+1... This would be fantastic

Has anyone ever gotten around to making a full B9_Aerospace / B9Aerospace (trying to make this searchable for other people in the future.. I've always thought the 3 character search limit was stupid) config for both the engines and the RCS? I'm starting to play around with spaceplanes and having to use Monoprop is kinda dissappointing.

The black textures seem to be the result of improper transparencies with TGA and PNG files. I have had the same problems on and off with certain parts (most notably the ALCOR) and haven't had much luck getting rid of it. That said, for a while with v3 (not 3.1 of LOD) and having converted those textures to TGA, everything was working fine. Then with the 3.1 update and the changes to TGA loading, it went back to being black. Basically my only recommendation is try rolling back to v3 and converting the offending textures to TGA and see what happens. As for the issues with RF versus MFT, the way the configs are written, the original parts default to the ones which include MFT and then only switch to the ones with RF if RF is present instead of MFT. I'll bet if you delete MFT and install RF, you'll get the same issues I was having. Also, this only applied to PP as the rest of the procedurals don't have this kind of code in their configs.

Ok, so I've managed to figure out why procedural parts and LOD weren't playing nice together. The lines like "NEEDS[RealFuels&!ModularFuelTanks]" in the PP configs that only enable certain parts when certain mod configurations are in place were causing the problem. I'm guessing that LOD was loading the part textures before these instructions were executed, which caused LOD to load the textures for parts that ended up getting removed and replaced by other parts which weren't in existence when LOD did its pass, causing the parts to load without any proper textures. Commenting out the lines fixed the issue, but I'm wondering how hard it would be to get LOD to either load after MM has made all its modifications, or for it to make two passes to verify everything is correct after MM.

So I know the recommendation right now is to switch to procedural parts, but that's not really an option for me just yet as Load on Demand doesn't seem to be compatible with it yet (textures load and stay extremely low resolution), so in the meantime I'm stuck with StretchySRB. Anyway, I've got a bug that just won't go away... I like to use conic tanks on the bottom of cylindrical tanks to create a fueled adapter when I'm using an engine of a smaller size than the tanks above it, anyway, occasionally when I do this, igniting the engine from that stage shoots the engine and the conic tank its attached to straight up through the rest of the rocket, and out to about 500m in from of the rocket where it catches and starts flying around randomly like its on a bungee cord and dragging the remains of the rocket along with it on a wild ride. This seems to happen most often after I've removed and then reattached large sections of the rocket (adding a new engine to my payload for example), and the only way to be sure its fixed is to delete the offending conic tank (and usually any that exist below it) and then rebuild the rocket below. My guess is this is something to do with the way the nodes between the two tanks are interfacing, but I can't be sure as I'm not really sure how that actually happens at a technical level. If anyone else has experienced this and / or knows of a fix, I'd really like to hear your input. Thanks. EDIT: Ok, so I figured out finally why PP wasn't working for me and have since fixed it so I'll give PP a try now and hopefully I don't have this issue there.

For me this was already off. Turning it on corrects the issue, but I'm guessing I lose all of the benefits of MJ's brain at that point...

Ok, so I'm about halfway done with my module manager config for TACLS integration and I'm at a point where I've got a couple of options on how to proceed and would like a little input. The first possibility is to have the TACLS config have all of its own parts (created through referencing the originals with some edits, not by copying models) with TACLS's unitless amounts, which for an oxygen block would be about 84.15 (average human breathing ~550L/day with 46284L in the tank). In this version I would also need to alter the resources so the US Core would use something like LO2 and LH2 to signify that they are in liquid form while also preventing those 46284L from throwing the TACLS balance completely out the window. The other option would be to convert the US Core amounts to match what TACLS would be, while then also scaling the usage rates for the fuel cell to keep them in line with what is already established for this mod. I think option 2 is the most succinct / least complicated way of doing the integration, but I have concerns that the game will accept an input resource rate of ~0.00006/sec. Option one means more extra parts the game has to load and for users to sort through, but it would preserve the original numbers much better, plus I would include a TACLS converter that would give an appropriate conversion from liquid oxygen to TACLS oxygen units so your LO2 supply could be cut into to give you more O2 in a pinch. I also have plans to include a water purifier, carbon extractor, and maybe even a waste compactor since I keep reading things that hint that the shuttle had such a device. Anyway, I'd like your thoughts on all of this, keeping in mind that this is still just a stopgap measure until the proper TACLS pack is released.

Turn off angle snap and it should work perfectly. I had the same problem and that fixed it for me.