theonegalen

Gorgeous. I need a new computer.

These are some of my favorite parts, so I would love it if you maintain the mod. My Tech Tree placements, however, are dependent on people using unmanned before manned, so I don't think it would be good idea to integrate those into the base mod.

I have configs to modify their tech tree placements in that mod. I would do the same with these. What's your suggestion?

I have also made configs for Making History and Engine Ignitor, as well as a couple of others. @linuxgurugamer, would you like those?

It would be a shame! I will be keeping to his design as much as possible while still making it a useful IVA for RPM/MAS users.

That vertical Mk2 cockpit (KN-7) is probably the mod cockpit I'm most looking forward to designing an RPM/MAS/ASET interior for. I'm thinking something that just screams civil aviation in the early 1950s. They aren't MM cfgs, they're drop-in replacements. If it's alright with @Mecripp, I'll include them in the next version of Warbird Cockpits and UBM Extended as MM configs.

UBME is currently only for UBM. The errors were revealed after MM was updated to display errors when configs specified too many passes (usually using :FOR alongside :BEFORE or :AFTER). The configs had always been in error, but the errors were only displayed on startup after v. 2.8.1 of Module Manager, IIRC.

Then I would submit a bug report to SQUAD along the lines that expandable modules don't work in "expand your station" contracts. Also, I recommend CC and Bases and Stations - it's a great contract pack.

The ModuleManager errors are a known issue that come from the original SETI configs using a lot of :FOR statements that they really shouldn't be. These errors shouldn't keep the mod from working as advertised, although the changes to the part cfgs in 1.5.x will necessitate either a new mod, or a new version of my UBM Extended mod.

I always thought previously that redoing UBM from scratch would probably be more effort than it was worth, although that could be changing now that Squad is updating parts with new part names. Yemo's ARR license very much makes that process extra laborious, because I can't actually copy anything I do from what he wrote. Honestly, though, I know how you feel. I tried several different trees after it became clear that UBM wouldn't be actively developed anymore, but none of them felt quite right for how I play the game. I expect I will always use UBM in one form or another. I've been playing 1.4.5 while slowly updating UBM extended for the last several weeks, and you should all be seeing the fruits of that labor before too long. However, I'm going to give the Simplex tree a quick try in 1.5.1, probably this week. It looks very interesting, although it doesn't have Community Tech Tree or as much mod support as I would like. I haven't wanted to get into changing too much about UBM and the way it handles Tech progression, except and what makes sense for adding more mod support, so I doubt I will move a lot of 0.625 meter parts around. SXT adds some of those into the early game, and the next version of UBM Extended will include configs for those parts as well. As for how Tech Tree mods work, most of them are .cfg file based, and depend on Module Manager. In each part's .cfg file, there is a line where x is a tech node name. If you look in the .cfg files in UBM Extended, you will find code like this: Module Manager basically modifies the part cfg files during asset loading while the game opens. The quoted code tells Module Manager to find the part with the name RetroMk1Inline and modify its .cfg to place it in the Early Aviation tech node added by UBM, but only if Airplane Plus and SXT are not installed. The reason I added the NEEDS statement here is because airplane plus and SXT both have early 20th Century-styled cockpits that I prefer to be in early Aviation, with the Retro Mark 1 inline cockpit later if those mods are installed. Much more detailed information on how module manager works, and it's syntax, is available here: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax

I'm doing rather well, actually. I actually had some time to play KSP in the last several weeks, and my band played a pretty successful show at a convention this last weekend. Now I just basically need a couple of days off that I can actually spend at home and throw into finishing up the final 1.3.1/1.4.x version. Also, for my car to stop throwing me new problems that have to be fixed. Thanks for asking. :-)

I have never found any conflicts, but whenever I'm troubleshooting a problem with a mod, I find it's best to first try a clean fresh install of the mod that seems to be the problem by itself in an otherwise stock KSP folder. If it works then, then I start going through my other mods and seeing if combinations do strange things. Good luck. If you do find a conflict, I'm sure we'd all like to hear about it.

IIRC, the last time I downloaded SSPR from spacedock, Near Future Props was included in the download. Check under the game data folder in the zip file you downloaded.

Are you using only stock contracts, or are you also using Contract Configurator, Bases and Stations, etc? If the latter, I believe that you will need to contact @nightingale and whoever is maintaining Bases and Stations these days in order to make sure those contracts are compatible with the expandable modules.

Is near future props installed? Sounds like that might be your problem. Because I can guarantee you the IVAs are some of the most well produced and gorgeous IVAs that I have ever seen in Kerbal Space Program, when they are correctly installed.

That album is years old and out of date. IVAs are fun barrels of monkeys to play with, if barrels of monkeys came with real live monkeys that were angry about being stuck in a barrel for a while. EDIT: however, they are extraordinarily fun to play with, and give a great feeling of accomplishment once completed.

Thanks indeed, @severedsolo! I will make sure to use that in the next version. Might release a "last version for 1.4.5" with the old ones at the same time.

Sorry this took so long to get. My phone is my only internet access right now. https://docs.google.com/document/d/1GL1BBQ0pjRox018NDhZCc31_4fLWOqqSTHaUQ3CaOgM/edit?usp=drivesdk Drop the code into a .cfg file somewhere in your gamedata folder.

the code to make it work is included in your config files, but it has been commented out. I removed the comment marks, and it seemed to work properly. I haven't checked to see see which other landing gears that might also be true about.

I was about to click the "Report Post" button when I saw this in my subscriptions feed.

Huzzah!

Hey @Snark, I got the variant switching to work with the bare/tankbutted Part Overhaul engines yesterday. I had to fiddle with the models to make it work (allowed under the Part Overhauls license, thank Squad!). The configs currently build off of your configs from here. I know your license permits it, but I wanted to check that you were ok with me uploading standalone configs (with :NEEDS[!MissingHistory]) based on yours. I'd just hate to have someone install both mods and end up with two copies of the tanks. I'm trying to think of how it would be easiest to prevent doubling the download size / memory usage, but I don't want my mod to be dependent on Missing History. EDIT: or maybe I could submit a PR to Missing History that changes your configs to have :NEEDS[!PorkjetTankbuttSwitcher]. Might actually work better that way.

It should, as far as I know. I used to use a 2.5x rescale myself, until I discovered I had to remove half my mods to achieve the blazing fast framerate of 15 fps. The only thing you might want to check are the configs in the Tweaks folder, because some of them might conflict with SMURFF. I don't plan on abandoning UBM Extended.

Feel free to take a little time and enjoy yourself in KSP! All work and no play makes abandoned mods, and more importantly, frustrated and burned out creators.

I worked on the APP and SXT configs today. Also started integrating Engine Ignitor support for everything included with UBM Extended. I also made the Porkjet part overhauls work with the stock mesh switch to swap out the clean versions with the tank butt versions. The config is currently dependent upon having Missing History installed, but I guess I could set up a standalone version. Not sure how much interest there would be in that sort of thing, since we are probably getting brand new versions of all of those tomorrow (?) with 1.5.