DoktorKrogg

The construction ports are being deprecated. Removing the category from the config prevents them from showing up in the VAB/SPH while still allowing the parts to remain in-game without breaking existing vessels. The functionality they provided has been grafted onto the stock docking ports instead.

Updated Discord link: https://discord.gg/FNBwUXRgX8

And just to be clear, my comment re: vague feedback was not an implication that vague feedback had been made but rather an attempt to offer guidance to would-be commenters on what's helpful and what isn't. So we're good.

We'll probably mark the ports as "legacy" so that they don't randomly disappear from existing craft and bork people's saves. So they'll still technically be in the game, they just won't show up in the VAB/SPH anymore. I'll also probably make it so that if you have a vessel with an old construction port, you can dock it to the matching stock port. In other words, there won't be a difference anymore between stock docking ports and construction ports. They'll all function like construction ports. And any previously welded ports should be a non-issue. Once construction ports have been welded, they cease to exist. As far as the game is concerned, the two vessels become one as if it came that way from the factory.

Just FYI: we'll likely be deprecating the construction ports in a future update and just using module manager to add the functionality they provide to the stock docking ports.

RE: WOLF hoppers... they haven't really been balanced against MKS. They just output 1 tonne of stuff per day per WOLF unit of the resource which was very much intended as merely a starting point to get WOLF out into the wild. We plan to re-examine everything in MKS/USI-LS/WOLF/Karbonite/etc. soon to make sure things are working as intended and well balanced since there have been a lot of changes the past few years. So if anyone has specific feedback on that topic, we'll entertain it. "A 2.5m life support hopper should output enough Supplies to feed X number of Kerbals because Y" is an example of specific, helpful feedback. "Part X is OP" is an example of vague, less-helpful feedback.

RE: science, funds and reputation from WOLF... there is a tab in the game settings specifically for WOLF that controls these values as well as resource abundance. We went with generous default values for the reasons @Terwin surmised. CTT requires a lot more science than stock and we also see WOLF as more of a late-game technology where the remaining nodes in your tech tree are likely to be the expensive ones where every bit of science helps (at least with CTT anyway).

This question has come up before and it has been discussed internally. I think for us to change the current behavior, we would need to see that restricting crew point transfers is causing problems. From my own testing so far, I haven't found this to be the case. I may change my mind at some point as I play with it more but for now I think restricting crew point transfers helps us avoid complexity and some other potentially unintended consequences. On a related note, we're looking at making it possible to transport Kerbals around in a WOLF-like way for an upcoming release (i.e. not crew points but the actual Kerbals themselves). More details to come on that as we get closer to actually having something to show off.

Depends on what you mean by "break". We aren't planning to remove anything, only add. We may deprecate some things in the future like planetary logistics but it isn't on the chopping block just yet. EPL hasn't had "official" support for several years now. That said, we haven't done anything or plan to do anything that precludes the use of EPL (or GC for that matter). We are planning a fairly major update to Konstruction that will include a part fabricator (think 3D printer) that works with the new stock inventory system and ground and orbital shipyards for building entire vessels. We're introducing new resource chains to support those new mechanics but they extend the existing resource chain, not replace it. Worst case, we'll introduce some new things that may make you want to change your strategy but it won't mean that the MKS base you spent 50 hours building will suddenly stop working. You may decide you want to dismantle parts of it and if so, we've got you covered there too as we're adding a part recycling mechanic to Konstruction that will give partial refunds of the new resources in addition to MatKits. So there is no "bad" time to dive into USI mod land. We have numerous things in the pipeline right now that we haven't even announced yet. If you want to wait until we're "done" with USI mods for KSP 1, you'll be waiting a long time.

It's a different but related system. The orbital shipyard (and eventually a similar ground-based system) will allow you to select vessels you have created in the VAB/SPH and build them in-situ. So where Konfabricator is more like a 3D printer for individual parts, the new shipyards will build fully assembled vessels/bases/whatever. The way that KonFab and the shipyards are related is that they both will use some new resources that we're introducing (i.e. Alloys, Electronics, Prototypes, Robotics and Synthetics).

I glanced at the issues you posted on GitHub. Hoppers aren't meant to be moved around. So doing things like docking a hopper to an orbital station, connecting it a depot and then undocking it will assuredly result in unpredictable behavior. Same in reverse (i.e. connecting to a depot and then docking the hopper to a station afterwards). This all has to do with how KSP keeps track of vessels and the parts connected to them. It's also possible there are some bugs. Hoppers are the one thing in WOLF that I personally haven't done much testing with yet. One thing that I think would help us help you is if you could give more detail in terms of what you're trying to do and what you expect the end result to be. That will give us a better idea of whether you're trying to do something we didn't design the system to do or if this is actually a bug.

Which is why MKS isn't going away and why we provided hoppers in WOLF. We definitely envisioned players mixing and matching pieces of WOLF and MKS. If WOLF is meant to replace anything it would be Planetary Logistics and Orbital Logistics, but certainly not all of MKS. Everyone has different ideas about what is and isn't "fun" in KSP. I think the USI suite is in a really good place now in terms of offering different options for different playstyles and we've got even more in the pipeline. Stay tuned!

RE: the conversation around refueling vessels at the destination in order to get free transport routes in WOLF, @RoverDude and I discussed that at length during development and agreed that if you've taken the time to build out the MKS infrastructure necessary to support refueling at the destination, then you're still playing in the spirit of MKS/WOLF. So we don't see this as an exploit. Getting a bunch of extra payload by docking at a massive station is a bit exploit-y but the cargo crates will address that issue. In general, we aren't super worried about "exploits" because KSP is a single player game. There are myriad ways to cheat in KSP. It's trivial to hack your save file to give yourself a bunch of credits or drop a drill at the KSC to extract RareMetals, fill a kontainer and recover it for massive profits, for instance. If that's how you want to spend your time, so be it. The only person you're cheating is yourself.

The resources are based on the availability/abundance for that resource in the stock resource system. If you're playing with a mod that changes the availability and distribution of resources, then that's probably the explanation. We do "blacklist" some resources on the starting planet (ExoticMinerals & RareMetals for now) to give players a nudge off the starting planet and onto other bodies in order to do the full WOLF resource chain.

It's fairly easy to hack yourself some extra resources via your save file. If you're handy with a text editor, you can make the edits manually (just do a search for "WOLF" in the save file). If you're not comfortable doing that, check out the KML mod for editing save files: Removing parts from WOLF is non-trivial. It would mean a) keeping track of all the parts that have been added to WOLF and bloating the save file and b) possibly causing a cascade of failures if you remove a part that had outputs being consumed by other parts. That's one of the reasons we added the planner to the WOLF window. I understand where you're coming from though. We all have whoops moments and WOLF isn't very forgiving. If you have suggestions on ways to mitigate the facepalm moments, we'll certainly consider them. It's also useful for us to hear folks' impressions of how WOLF plays when coupled with other popular mods. Doesn't necessarily mean we'll do anything about it, but still helpful when it comes to future planning.

Not true. The values for InputResources and OutputResources are the actual values used by WOLF. I know this because I wrote the code for WOLF and because I also just tested it to make sure I'm not going crazy. Making that change is not, however, retroactive. The only way to change it retroactively would be to manually edit your save file.

Not sure what you have in mind in terms of a setting but it's unnecessary in this instance. A ModuleManager patch for the TransportModule part to change the value of the OutputResources node in the WOLF_ConverterModule would do the trick.

By KCT I assume you mean Kerbal Construction Time. If so, then we have no plans to officially support that mod. I see that as another example of a mod that aims to make KSP more of a simulation than a game and that just isn't really the focus in USI. Like I said in regard to transport routes in WOLF, I'm happy to provide hooks in Konstruction for other mods to inject their own behaviors (like introducing a delay between queuing up a vessel to be built and actually spawning it in game). It would fall on the maintainer of Kerbal Construction Time to actually make that mod "Konstruction-aware" though and do all the work of managing the build queue, providing a UI for it, etc.

Solving this problem is non-trivial. It would mean adding a bunch more code to check for the types of fuel used on the vessel, tracking fuel burn, creating multiple types of TransportCredits and determining which ones were used to complete the route (i.e. what if multiple fuels were used along the route?), what to do about stages that are jettisoned along the way (which type of TransportCredit does that cost?), etc. Ultimately this boils down to "is KSP a simulator or a game?" and everyone has their own opinion on that. @RoverDude and I tend to fall on the "it's a game" side of that argument and gravitate more toward approximation vs. ultra-realism because it makes our lives easier and lets us get more stuff out the door in our limited free time. If someone wants to make a more realistic transportation system that ties into WOLF, I'd be happy to answer specific implementation questions (by "specific" I mean don't ask me "how do I make a mod?" ). It's already fairly extensible and we're open to accepting PRs like @TheSuMa mentioned to make private methods protected, etc. to improve the extensibility. I'm not categorically opposed to this idea but I'm also not convinced that it is an essential feature. Ultimately it sounds like you're suggesting an "oops" button but getting your crew capsule back from the Mun full of science only to realize you forgot to put a heat shield on it for re-entry is 2/3 of the "charm" of KSP. Planning and executing a "perfect" mission in KSP after 1,000 poorly planned/executed missions is one of the greatest sources of satisfaction (for me anyway). On the other hand, I'm not a fan of tedium. If I get to a point in my own saves where transport routes are a source of continual boredom, then I'll probably change my tune. I haven't hit that point yet though. As mentioned previously, we are working on a new way to handle the payload portion of transport routes (i.e. having WOLF cargo crates with a fixed mass that will be used for the payload calculation instead of using the vessel mass at the end of the route). This should make the payload a lot easier to plan and not a guessing game like it is now.

We are indeed working on a new system for building vessels in-situ and it will live in the Konstruction mod. It will use MatKits and SpecParts along with some new resources (and corresponding converters for them in MKS and hoppers for them in WOLF). The new resources were necessary to account for things like gravioli detectors whose mass is very low but cost is very high. Otherwise you could just dump a crate of MatKits on the runway, pump out a bunch of gravioli detectors and recover the vessel for a substantial profit. A big difference between our system and systems like GC is that vessels will instantly spawn nearby. Our reasoning is that the "build" time is baked into the assembly of the resources themselves. We don't see the simulation of a build process as being "fun" since you can (and most times would) just time warp through that part of the process anyway. It's still in development and all of this is subject to change at any time but that's where things currently stand.

We wanted to be able to unit test the plumbing to prove that it was sound before dropping it into the game. It's a fairly common pattern with Unity to just dump all your code in a MonoBehaviour and call it a day but you can't instantiate MonoBehaviours outside of Unity. So we needed to decouple as much of the code as possible into POCOs and only use MonoBehaviours where we needed hooks into KSP. We're pretty happy with where WOLF ended up. It's given us a platform that will let us spring off in multiple directions with new, interesting gameplay options that we're already working on!

Routes only cost TransportCredits if there is a mass loss between Point A and Point B (i.e. fuel was burned, stages were jettisoned, etc.) It's entirely possible to setup free transport routes.

You need to leave something for people to complain about...

Atlas parts, WOLF, a non-broken light globe, no more wonky textures, so many other little fixes that I've forgotten half of them already... Gonna be a massive update. Oh, big change to drills too. Multiple drill heads have gone away and all the overheating issues along with them.

It's not possible with nuclear reactors. To piggyback on what @RoverDude said, a fully fueled and appropriately sized nuclear reactor will last years or decades in some cases but not indefinitely. You would have to go with solar, a fuel cell, Karbonite generator or something along those lines if you want a completely hands-off base. Even so, if you're also playing with USI LifeSupport, then you'll have to hop back to each base periodically anyway to let their supplies replenish. I hate to keep teasing this but one of the goals of WOLF (coming soon™) is to address the constant babysitting required in MKS/USI-LS. If Kerbolar-wide colonization is your goal, then WOLF will be your jam.