Angelo Kerman

Actually, you could just straight up copy the 3.75m docking port's config file and drop it into your 1.2.2 save...

Glad you're having fun. And good to see you back!

Hm... The stock C7 Adapter is really close to that nosecone shape! I'm skipping the nosecone part. That means I'm turning my attention to a nicer looking 2.5m decoupler and probe core that match the Delta tanks. If I get those done before 1.3.1 is ready, then I'm kicking this release out!

Well, the current lineup looks like: DSEV: Tank Redux DSEV: Odyssey Two (Multipurpose Colony Modules remodeled and given a new home; Kopernicus) DSEV: Odyssey Three (NAUTILUS-X) DSEV: Final Odyssey (long range deep space parts)

With the tank remodeling nearly done, and BARIS finally stabilized, I can finally get back to what I was working on with DSEV. Here's a hint:

Only thing I can think of is to edit your save file and manually set partsCanFail to true.

The one thing that bugged me about th lander cans was a lack of adequate seating for their sise. Thanks for fixing that on the mk1 can.

OOOOO That is some really great stuff, thanks! I think I have enough info to dig around more and see what I can come up with. Thank you much!

Thanks for the feedback, but at this point in time, I want to let the dust settle and give people time to use the numerous configuration options before making further changes.

Ok, giving this another try. However... Latest release is 1.3.7: Fixed issue where parts on an unloaded vessel weren't being correctly declared fixed during a Tiger Team repair. Tiger Team repairs will optionally drop you out of timewarp once the research attempt is completed. See the Constants file to set the option. Fixed Tiger Team wording that appears upon a failed attempt. Tiger Team repairs now ensure that the repaired quality doesn't exceed the max quality. Slight increase to the base chance of a Tiger Team repair attempt to balance fun and frustration factor. Focus Vessel view no longer appears to report broken vessels that are in physics range. Added broken vessel screen messages for any vessel in physics range that isn't the active vessel and that develops a problem. Tracking Station view now displays vehicle healths based upon the enabled filter buttons. 1.3.5 When vessels break, you can now go to the Tracking Station and assemble a Tiger Team on the ground to try to resolve the problem. Think of the brilliant engineers who came up with a plan to save Apollo 13. It will cost Funds, Science, and time. You also need a working CommNet connection to the vessel (if CommNet is enabled). There is no guarantee of success. In fact, the odds of success are pretty low. If successful, your Tiger Team will fix the striken vessel without the need for an onboard mechanic or the need for Equipment. If unsuccessful, you can assemble another Tiger Team and try to come up with a fresh perspective. Look to the TigerTeam values in the Constants.cfg file to make the odds forever in your favor..

I am investigating making a part like NASA's https://en.wikipedia.org/wiki/Robonaut. Ideally, the Kerbal Robonaut will have the ability to repair wheels, run experiments and collect their data, and repack chutes. Many functions in KSP, such as ModuleScienceExperiment.DeployExperimentExternal() and ModuleParachute.Repack(), check for the presence of a kerbal with the required skill. I know how to programmatically generate a kerbal and add it to a part, but what I can't figure out is how to flag Vessel.isEVA = true, because Vessel.isEVA is read only. I tried adding a KerbalEVA part module to the prototype Robonaut part but that didn't help. I'm wondering if a dev like @JPLRepo is able to shed some light on how the game determines if the vessel is a kerbal on EVA, or ideally, if there is a way to bypass the skill check required to pack chutes and such. Calling ModuleScienceExperiment.ResetExperiment on a vessel that isn't the active vessel gives me an error, something to the effect that the event requires a powered vessel to accomplish. A similar error does not occur when calling ModuleWheelDamage.SetDamaged(false), so at least I can have the Robonaut change tires. The only thing that comes to mind would be to disable crew experience, but I don't think that disables crew skill. Any ideas? Thanks for your help!

And I can call these done: @adsii1970 Rest assured that the heights remain unchanged. My stretch goals are to create a 2.5m nose tank, and I'm debating making a decoupler and probe core that matches the Delta paint job. That, and retexture the quad coupler from MOLE to match the Delta tanks.

I finished DSEV's 2.5m "Delta" tank revamp: You can switch between orange and white. And I got most of DSEV's 1.25m "Moho" tank revamp done: The black stripes need some grunge work but they're almost done.

I'm still doing active development on it, but I'm just not making it visible on the forums, because I'm tired of the complaints. It's a mod that you have to work for to gain the benefits, and there's too many who aren't willing to do that and then come to the forums to complain. Given all the work I put into it, I wouldn't be at all thrilled to see someone take over.

The GitHub repo is still active, I just removed all the links to it in the thread. But if people download it and complain, I don't want to hear about it.

Ok, fair enough, I can convert some Titan tank models over to 1.25m Moho tanks, they're the correct heights.

No worries. For mesh-switching, I have a simpler plugin I did for the KSP Part Overhauls. You can find that code here and the release dll here. I am doing some revisions in the next couple of days so that the resource switcher can sync with the mesh switcher, and vice-versa. WBT also has mesh switching but it's overkill if all you want is resource and mesh switching. I might add in texture switching too.

Wild Blue Tools has done this since 2014... Sorry, that was a bit off the cuff. Take a look at WBIModuleSwitcher in Wild Blue Tools. WBT isn't well documented, but if you have questions I'll be happy to answer them.

Uh, not sure if there's miscommunication going on, but just in case, I'm not done modding KSP, I'm just done with BARIS. In fact, I just finished remodeling my DSEV 2.5m tanks...

Last up are the 1.25m tanks, which will become the Moho line. Here's what they look like now: I am thinking along the lines of this: They're sort of already there, but need an art pass.. The Moho tanks are going to be tricky, they are 1m, 2m, and 4m tall, respectively. Stock Size 1 tanks are 0.9375m, 1.875m, and 3.75m tall by comparison. I might have to deprecate the existing tanks and replace them unless I just keep the heights as is.

2.5m Delta tank revamp: done! I still need to revamp the quad coupler that I brought over from MOLE, and create the Delta Nose Tank, but the remodeled Size 2 tanks are now done. I am still aiming to be finished by KSP 1.3.1, I'm just getting more done that I originally thought.

Thanks guys, I really do appreciate the sentiments. I'll consider re-opening the thread, but when I get comments like [snip], it shows me that players aren't reading the manual despite having an extensive KSPedia and Wiki and in-game hints to read them. I knew from the start that BARIS' default settings wouldn't appeal to everyone- that's why it's the most configurable mod that I've ever made. My expectation was that players would give BARIS a try, learn how to change the settings, and then adjust things to their liking. If that didn't work, they could simply uninstall BARIS and move on. Unfortunately, not everyone shared that expectation, and complained when things didn't work the way they wanted to. I listed as much as I could, and changed a mod that was most definitely not beta, but I don't have time for people who aren't willing to RTFM- I've got other projects to work on besides BARIS. Thanks again for your support.

@eloquentJane I haven't flown to Duna is a very long time. This is great advice, thanks.

This is looking really good! Can't wait to try out the latest updates. Thanks for your continued development of the mod.