danfarnsy

We are talking about ongoing development. Your textures are good, and they'd be a good addition to the mod, particularly if we can get the editor part count down by using a mesh-switch mod dependency. If you want to make a pull request or send me things directly, I'll be happy to incorporate it. For anybody who is worried about this breaking their save games, I'll keep the current parts as legacy for a while, whenever this plan rolls out.

Alright. We got your request, and we'll revisit it later. While there isn't a better thread for this tangential discussion, there is a better time. Right now, I'd like to keep discussion focused on the immediate issues of a 1.1 release, which means squashing NullReferenceExceptions rather than renaming resources.

Yeah, waiting and using Wayland's code makes the most sense at this point. The main reason I haven't been waiting (don't worry, master branch is untouched) is because it will pay off later, even if it's redundant now. We learn things better when we work for them, right? It will also be good to see what is different in his "small modifications" versus the direction I've been taking.

Point taken. I'll keep it in mind as a point of realism, though lithium hydroxide is now typically a backup to regenerative systems which dump the CO2 to vacuum. I think electricity consumption in TAC-LS models this sufficiently well, as do waste canisters which store it for later reprocessing/recycling. I don't think we're in a good position to look at overhauling this mechanic. I'm also not convinced that adding lithium hydroxide, amines, sorbent beds, and so on would contribute in a meaningful way to the gameplay. I'll be open to discussing this more once we've got our legs under us, but right now it's a distraction from our present purpose: getting a reliably maintained release. I don't want to discourage your input or anybody else's. I just need to focus on the more immediate issues of taking on a project that is, frankly, a bit intimidating.

At the least @WaylandSmith would have needed to update some namespace references. Or at least I had to for it to build. And with it built and compiled, I still have to make some changes to get it functional, as I mentioned above. Sorry, folks, release will still take a wee bit of time unless Wayland pops his head in again.

I'll be happy to incorporate your pull request. I don't have a time estimate yet on when that will happen, though it's clear you've been waiting for months. Leaving aside your numbers (regular atmosphere is ~21% oxygen), respiration depletes oxygen content in the atmosphere and increases carbon dioxide, while ignoring nitrogen. It's oxygen we have to replace in a spacecraft and carbon dioxide we have to filter out in order to retain atmospheric balance. It's not about providing new atmosphere but replacing the part of atmosphere that our bodies are turning into CO2. I'm glad you've got Wayland's branch. Without it, I was patting myself on the back for getting the project to build and run, and then I was figuring out how to replace RenderingManager, since it was throwing a bunch of NREs. I figured it was worth the learning experience.

TAC-LS and USI-LS are incompatible systems. Aside from that, the rest of the USI suite of mods can work well with TAC-LS, and they have included MM config files to support TAC-LS. That means you can use the habitation and agriculture components in UKS to produce TAC-LS resources. If those configs fall out of date, it's easy enough to create pull requests on the USI side. Most compatibility is handled through mod-manager patches/configs. That can be done either on the TAC-LS side or through creating pull requests for other mods, but usually not both (to avoid creating conflicting configs). It is important to me that it remains friendly to as many mods as possible and keeps a narrow and well-defined scope.

Found it. It's a few commits behind Taranis's current release version, so we bring that up to current, grant additional write access on that fork to a couple of dedicated contributors/managers, and use the master branch for future releases of TAC-LS. Looks like a good starting point to me. Like I said, I'm still familiarizing myself, but my current fork is here.

That's a correct assumption. I got that much working locally, and I'm working with the git extension in VS to figure out how to clone, edit, and commit properly, as I've previously only been using the clunky web interface.

Realism Overhaul cats want to host this on the RO repo. How exactly will that work, in terms of write access, branches, etc.? And how does RO's workflow usually go? Are most contributors running their own forks and then submitting pull requests, or are they given direct write access and use separate development branches which they then merge? Is the intent to host TAC-LS directly in the RO repository, or will we have it be its own entity within the larger network of RO-associated projects? I may have misunderstood @NathanKell on this point, so I'd like to have clear expectations.

@NathanKell, @Zyx Abacab, @WaylandSmith New thread is here. It is a development thread until we have a release available, and then I will start that up and manage it as well. Let's please move discussion there. As for locking this thread, I'll let NathanKell or a moderator make the call on that one, since it's not mine.

Thunder Aerospace Corporation Life Support (TACLS) update and development Mod License: Attribution-NonCommercial-ShareAlike 3.0 Creative Commons License TACLS originally by Taranis Elsu TAC Life Support is under new management in conjunction with the Realism Overhaul team! We are glad for the opportunity to keep this great mod alive. We are also very grateful to @TaranisElsu for creating TAC Life Support. Our hats are off to him. What is TACLS? TAC Life Support is a mod which adds food, water, and oxygen as requirements for survival in space. Go without support for too long, and your Kerbals die a non-fiery death! Included are parts with storage for food, water, oxygen, waste products, as well as some recyclers for oxygen and water. It does not include support for growing food, but there are many mods which play well with TACLS to provide this functionality. While this thread held a brief caretaker spot as a release thread until our bigger release was going, it is now a dedicated development thread. Please find the release thread here. Source Development Plans: I intend to keep the scope of this mod narrowly focused on life support and building on the present mechanic. I would like to improve a few things: Better background processing of electric charge consumption MM-friendly configuration and settings Adding switch functionality (container contents, textures/meshes) along with parts overhaul to reduce editor clutter Working with @TMS for improved part models and textures. We'll discuss this in detail, but we're now ready to do so. 3.75m parts (next update for sure) Additional suggestions for features are welcome! We can't guarantee they'll be integrated, but we're always open to good ideas. ----------------------------------------------

I've contributed to RPM and other config updates for B9 aerospace. Programming-wise, I have breadth but not much depth: C/C++, Java a long time ago, plus the typical physics department tools: Mathematica, Matlab, etc. So I understand what most things are structurally, I just need to learn the formalisms, syntax, and oddities about C#, which I'm already jumping into. I'd love to get @WaylandSmith involved too. He indicated he wasn't interested in maintaining the mod. I don't know what that translates into in terms of occasional contributions. Soon.

Sounds great! It will make the learning curve easier to have you guys to ask questions, and it will spread the load around so no individual has to get bogged down (or be a single point of failure that sinks the mod). I like it.

I am glad to see Taranis had some continuity in place and that your experienced team is willing to take this on. I also understand your interest and reliance on TAC-LS. Interoperability with RO, as I said above, is a key part of this mod. So, out of respect for @TaranisElsu's intent as well as respect for the great work you do, if you have somebody else from your team who you think will be a better point man, I'll step aside. I know you're not telling me to step aside, and the license is permissive, but this is pure respect and deference on my part. I would also love to take on this project and work/plan with you so TAC-LS continues to be a great mod meeting the needs of RO while being able to stand independently as a solid life support mod for the wider community.

I like this suggestion.

Yeah. The current patch provided by @WaylandSmith is great. I'm trying to look at the future of the mod, because a lot of external support is likely to disappear if other mod makers see there's nobody at the helm. It's already happening. I'd like to reverse that trend. As important as it is to know a mod works now, it's just as important to anticipate that the mod will continue to work later. Here's my design intent: 1st priority is the stuff underneath the hood which has made TAC-LS awesome and which can stand a few updates for background processing. I'd like to do that as seamlessly as possible so it doesn't disrupt anybody's games. I start new career saves all the time, and having mods break them so I have to start over doesn't bother me much, but I know it's a big deal for a lot of players. 2nd priority is maintaining effective distribution and support, including CKAN. Unless Realism Overhaul has kicked TAC-LS to the curb, CKAN will be essential for the future of this mod. 3rd priority is streamlining parts and reducing clutter. This is already done in part with Modular Fuel Tanks, a few TAC-LS specific patches/mods, Tweakscale, Procedural Parts, etc. I want to keep support for these other mods up to date. I also would like to add a dependency in terms of a switching mod (B9 partswitch, Interstellar Fuel Switch, or Firespitter), so the organic part count for TAC-LS can be reduced. I do not intend to get rid of the Hexcans. I do intend to make it as easy as possible to get rid of them and as harmless as possible for your part count if you keep them. Licensing will remain the same. Once I get something up and running, I will create a new release thread with hosting on Spacedock and Github. I'm still on the fence whether to update the name ("TAC-LS continued, expanded, community edition, reborn, etc."), but I'm leaning toward "no." @Zyx Abacab, thank you for offering to help. I'll likely take you up on that, as well as hit up a few other mod authors for tips.

Yes, I know he said that. Welcome to the forums!

Okay, it's time for this mod to pick up a caretaker. I volunteer as tribute. I'm going to have a steep learning curve, so it's not going to be updated quickly, but I hate to see this great mod die this slow death. There are even some good ways to improve it, starting by borrowing some background processing features from @ShotgunNinja's Kerbalism. Balance of resources, integrating other mods' ISRU channels, integrating well into Realism Overhaul, and maintaining a strict life support design focus are the biggest priorities. That isn't a criticism of any other life support mods, but simply a recognition of the intent and purpose of TAC-LS. Of course, making everything work is going to come first. I have programming experience in C/C++, but not with C#. As a disabled veteran with limited work, I also have some time on my hands. If anybody feels they are better situated and wants to take this on, please post and let me know. Otherwise, I'm pressing forward.

For the same reason that some mod authors chose to disable their mods in 64-bit windows (e.g. FAR) or to disable running in a version of KSP it wasn't specifically built for (e.g. Kopernicus), I completely understand CKAN being very careful/strict about what they allow users to do or install. The simple fact of the matter is that many users mess things up or think they know better and then come and blame mod authors and ask for support when they failed to follow installation instructions. Just yesterday I was reading some USI mod thread where a user had deleted USI Tools because he thought it was just for developers and he wasn't interested in it. I agree in principle with the points made regarding allowing users the freedom to do what they will and own the responsibility for it, but the reality is that many users will not own the responsibility for it. They come and complain and ask for support, and usually the first stop is not the CKAN thread, but the mod authors. The purpose of CKAN is to reduce the overhead associated with maintaining mods. That is sometimes broken in the versioning and metadata which doesn't reflect the actual state or prerequisites of the mod. Sometimes this is the mod author's fault, sometimes not. Issues have been exacerbated by the recent KSP updates, and they'll settle down. For what it's worth, I am opposed to having CKAN become more flexible in letting you break your game on your own (that's what manual installation is for, and all my mods are manually installed at the moment), but it would be worthwhile to have more safeguards in place on the metadata. Perhaps we need more transparency about who maintains the NetKAN file, and have CKAN have obvious links for mod entries about where to get support for CKAN installed mods, and require that to be included before a mod is included/indexed on CKAN. There are a lot of middle men in this process of trying to make it easier for users, but most users are unaware of the middle men, aiming straight for the mod author when something goes wrong. Then it's a lot more fingers being pointed than problems being solved. Even if we can't eliminate needless confusion, we can reduce it. I don't know what we can do for users who think, "I was elected to lead, not to read," but we can at least make the information more obvious and transparent.

When the next B9 update goes out, any NullReferenceExceptions pointing to DRE's ModuleHeatShield should be gone. That was ancient stuff and has been updated to use current DRE modules. That said, once it's available, we could use feedback/adjustments for how the parts actually perform with DRE. In particular, paying attention to how B9 engines perform would be helpful. I haven't really tested it, and I don't have plans to do so. This goes for any other DRE and B9 users. If you are familiar with config files and DRE and you'd like to make pull requests for adjustments after this next update goes out, please feel free to contribute.

The issue briefly showed up again with your updated .dll in a fresh install of FE 2.5.1 (though it waited this time until I placed a root part). Removing and then reinstalling some other mods (which didn't fix it yesterday) seem to have made it go away. Which is weird. Yesterday when I was troubleshooting, there was a Connected Living Space NRE, but removing CLS didn't resolve the issue in the editor (which is why I didn't mention it before). Today, when the issue briefly showed up again, the NRE was again pointing to CLS. I removed CLS, and the issue was resolved. Then I used a test install with just FE (with your linked .dll), MM, and CLS, and the issue would not reproduce! Then I put CLS back in my big unwieldy installation, and the issue also did not appear again! So near as I can figure, today's hiccup was a leftover cache/config issue from yesterday. If the issue shows up again, I'll be sure to test thoroughly. In the mean time, I think it's fixed! Thanks! Normally, I'd have just uninstalled FE and lived without it, but I really hate digging through the utility page when all I'm looking for is batteries.

I've got two weird bugs going on with FE that I'm trying to narrow down. I'm running KSP 1.1.2, Windows 64 bit. Under FE 2.5.0, with KSP 1.1.2 and MM 2.6.24, nearly every non-stock category disappears (except for Extraplanetary Launchpads, which is odd that it sticks around EL doesn't use FE... a clue?). Also, KSP doesn't properly exit from the main menu and I have to force it to exit. I wouldn't suspect this second part to be a FE issue except that it goes away when this version of FE is not installed. Here's the screen capture for this case. Using your updated dev .dll (from both simply replacing the .dll from FE 2.5.0 or from completely downloading your dev master folder and copying the contents of /GameData), I have an entirely different set of issues. All the editor categories now show up properly, and the game no longer has any issues with exiting from the main menu. But as soon as I click on one category, the game throws a NRE and the editor pages cease updating when I click on any additional categories. That is, if I click on "structural" items first, it update the parts list on the side with the structural elements, but then clicking on "fuel tanks," "engines," etc. no longer updates the parts list and it still shows structural parts. Here is the relevant excerpt from my log: And here is the log itself. How weird is that?

I'll submit a PR. Starwaster just replied, and I've got appropriate stuff for updating the DRE MM patch.

Thanks for the heads up. I've dropped into the DRE thread to see if I can get some pointers on fixing B9's DRE MM patch (its contents look like they need updating).