Jump to content

Merkov

Members
  • Posts

    460
  • Joined

  • Last visited

Everything posted by Merkov

  1. I don't think we really need it. We should have plenty of hab parts. I like the thought though.
  2. Nice! Now I wish we had a version that's just a recreational facility.
  3. On mobile so can't reply very prettily. I like the sound of everything mentioned above. With respect to the garage PL comments of mine, that idea came from a time I asked RoverDude exactly what a part with PL was supposed to represent. The way I read his answer was that eventually PL will get a bit of a facelift and the parts will be like a shipping/warehouse type thing. Very voluminous. That's when I got the idea for the garage. Not happening anytime soon, but maybe happening soon-ish. Since we're waiting on updates beyond our control anyway, I think we might as well start throwing out rough ideas of what parts we want doing which conversions. We can maybe use your chart on page 1 as a guide (though we also have to think about Organics and ColonySupplies). That should give us an idea of whether we like the number of parts involved, and the number of conversions per part.
  4. Yeah, if we can find a way to de-incentivize spamming of efficiency parts, that would be ideal. As I said, I like the idea of K&K parts being able to be efficiency parts for MKS parts. If we go with our own sets of eTags, I honestly wouldn't mind if we make them either specific enough that spamming to cover them all becomes onerous, or make it so that spamming the parts themselves is just impractical (for example, if the Central Hub had a bay or two with switchable efficiency modes. Does a player REALLY want to spam Central Hubs just to get high efficiency bonuses?) I really like the looks of your four points. Just to make sure I understand the thrust of your last two points, I'm reading that as machines with Kerbal supervision build MaterialKits, Kerbals with machine assistance build SpecializedParts. Not that we're short on ideas, but if we wanted to work with our own eTags, we could do something silly like make eTags based parts (similar to how MKS does it) or on products (so, if all of your parts that produce MaterialKits have an eTag called "MatKits" or something like that). Then, we could even have a part that has multiple efficiency modes that you can swap between. Not that you're short on ideas or anything... Yeah, I think it makes sense that the central hub get another balance pass. People who 'get' MKS will understand why it has to be different than what we've already come up with. Unless I'm reading the timestamps wrong, the "ask" and "receive" were separated by 13 minutes. What a legend. One possible reason for having an automatic drill is that it could be used on a small outpost that only occasionally hosts crew (refueling base or something of the sort) or it could allow a player to set up a small, starter-style base with limited crew (i.e., nobody with the skills to man the drill) and still be able to get gypsum out of the ground at a half-decent rate. I'm partly thinking of RoverDude's recent comments about PL getting a change eventually so that Logistics modules become more like warehouses or garages. In that case, I could almost imagine a small base with a K&K garage, a MK1 hab, LF stuff, and a drill (either for gypsum/minerals for LS self-sufficiency, or maybe this is the only biome where you can find ExoticMinerals or something). That tiny base might only really need a Quartermaster to crew it if you have an automated drill, saving you an Engineer/Miner. Saving one crew member might not seem like a big deal, but maybe being able to reduce crew requirements by 50% (or not having to increase it by 100%, depending on how you look at it) would actually be useful in some circumstance. This line of thought of mine isn't completely thought out. For example, I know that in MKS, the automated refineries already push to PL, meaning you can do all of what I mentioned in that one hypothetical base PLUS refine resources that they are pushing without any kerbals at all. On the other hand, the automatic refineries only handle basic conversions, so as far as I can tell, there's no automated way to push things like Organics or ExoticMinerals around in MKS. Maybe we could fill a weird niche-usage case.
  5. I'm in the middle of a couple of weeks of basically not being able to get anything done ever, but I'm still watching the forum and GitHub. I like the idea of K&K parts working as efficiency parts for USI parts, mostly because efficiency parts don't have to be on the same vessel to provide their bonuses. This means that I can start a small base with a K&K Greenhouse Container, then eventually land an MKS base with a USI Ranger Inflatable Ag module beside it and have that greenhouse container be an efficiency part for the new Ranger base. Depending on how we set things up, we should (could? maybe?) be able to have parts that can have whatever converters we want, but be able to swap to being MKS-alike "generic" efficiency parts. Of course, this falls apart when we want a part to have multiple different/exclusive converters at once (like the greenhouse hab + supplies production thing we ran into). If I understand correctly, we can define whatever efficiency tags we want, and then parts can be efficiency parts for any tag, ours or MKS's, that we choose, right? Maybe the right thing to do is try to lay out exactly what parts and processes we want, and then see what efficiency tags would fit where. Another thing about efficiency parts is that in MKS, the biggest use for them is to make it so that older, more basic modules are not made obsolete by the addition of more powerful modules later. I don't think we're going to have as much of that on the KPBS side of things. We only really have the one form factor to work with, and I don't think our model really has as many "redundancies" (like Tundra parts that do what Ranger parts do) as MKS does. Random thought: I kind of wish I had thought about efficiency parts when we were trying to find a way for the Central Hub to provide a big boost to an existing base without it being able to be a base all by itself.
  6. Welcome to the forums! I am running all of the USI mods (including Karbonite) and CTT and can see the parts just fine. As I recall, the Karbonite scanner is placed in a pretty high tech node when CTT is installed. Are you sure you've unlocked them?
  7. Sorry, what do you mean when you ask what "affects" homesickness? If you mean how do you increase hab/home time to prevent it, then it's simply a matter of having many parts on your vessel that provide habitation bonuses. In a stock/USI-LS game, this mostly means the hitchhiker (which will consume EC and provide a large habitation bonus) and the cupolas (both stock and the mini USI ones, which add a habitation multiplier, increasing hab times even further). If you mean what effect does homesickness have on a kerbal, that is something that you can select from the USI-LS settings window by clicking on the green cube icon from the space centre scene. Here, you can pick all of the consequences for the various things that can happen to your kerbals, including when their hab/home times expire. You can pick from all sorts of penalties there. If you meant something else entirely, then nevermind this
  8. It's the former. As soon as your kerbals return the Kerbin, their hab and home timers are reset.
  9. I think we only got creative in two ways: the recycler containers, and our focus on floor space for habitation purposes. Unfortunately, the recycler container profile was a little restrictive, so we've made them more powerful than they *should* be volume-wise, but they are also much heavier. The alternative was going to be to make the recycling containers too weak to be useful. As for habitation times, we found that Nils' base parts tend to have a decent sized footprint, but they are only as tall as a kerbal needs. This means that they aren't terribly voluminous (compared to something spherical or cylindrical) but all of the space is useful living space; there aren't any awkward curves or anything. This is why we gave the base parts each a small hab multiplier. What I found was that the KPBS MK1 habitat would have less hab time than the Ranger mini hab even though they had roughly the same footprint. The mini hab, though, got very tall in the centre, so it had a higher volume. The MK1 habitat doesn't get nearly as tall, but it also doesn't lose the space around the edges either. Adding a small hab multiplier to base parts seemed to be a decent compromise. This reminds me: if we're using the USI deployment module and USI converter/other modules, does that mean that the deployable base parts can only use their functions once they have been deployed? I haven't actually played around with this any (since I am a slave to 'the rules') but it seems like something we should try to ensure.
  10. @Hofelinger if there is one thing I'm good at, it's talking! Cool. I don't recall reading much about efficiency parts. I'll try to get some research done into them, see what I can come up with. If we could somehow make expansion require several kerbals, I'd be okay with that and a much lower EC cost. I don't think that's doable without writing our on DLL. I mean, it's possible to argue that the base parts are very smartly designed to use some crank system or something, I think it's reasonable to assume that there is a decent amount of motorized assistance.
  11. Sweet. Those commit comments you have look perfect. I don't think there's any point in getting any more detailed than that. If you want more info, look at the commit. Does that mean that everything we want to push to Nils is done...? Off topic: for the stage 3 release, how do you feel about the greenhouse container getting a swappable efficiency part setting? Or does that just run us into the same problem as with the greenhouse config issue? I think we discussed this already, but cultivation in the greenhouse container doesn't make much sense to me, nor does swapping to such modes, since you'd have to access it from the outside, through a vacuum. I don't know exactly how the "efficiency part" mechanic is supposed to mean to work, but I think it might make sense that it doesn't need to change substantially to go from being a converter to supporting another. Maybe. I don't know how much EC 1 EC is, but I'm not sure if the EC required would just be a couple of drill batteries. Is there any power involved in the actual deployment of the base sides? They seem like they should be more massive than 1 kerbal can pull out on his or her own. Maybe I'm wrong.
  12. Okay, how would you like me to start? Should I make a new document in the USI_LS folder and just list changes? Okay. Still have no idea how much EC we should use. I suppose the big thing with EC is that whatever amount we decide on, you would need to have as much storage available, right? I don't think the DLL doesn't let you can't put 500 in now, and then recharge a bit and put in another 500 later. In that case, we have to decide how much EC storage we want to 'force' the player to have on the ground. Unless I'm blind, the only K&K battery is the 3K one? I'm almost thinking 1000 EC. That way, if you have a KPBS container rack with a 3K battery, the cost is trivial. If you're trying to do it with radial-attached z-100s, it isn't trivial. I think this rewards being somewhat prepared. You don't need any crazy resource chain, but you can't just use a pile of debris to set up your habitat and greenhouse. As an aside, I always loved the huge batteries that NFE adds, but never liked the rest of NFE. I actually made a folder called NFEBatteries in my GameData folder and just put the batteries in there so I can add them to my stations. My habit of doing things like that makes me wish that there was a huge KPBS battery, but I also don't think there's actually any need for one, I just have a problem. Edit: I just noticed that you renamed my silly refresher to scrubber. I'm going to be honest, in order to remind myself that this was supposed to be a low tech, low efficiency part, I was looking for the least scientific name possible for that thing. When I started playing with my own numbers, the spreadsheet I had saved was called "Febreze module". Scrubber sounds better
  13. Sweet! I have been rather stuck away from my own computer lately, so I haven't really done anything useful for a while. How specific do we want the changelog to be? Also, since the USI-LS specific tweaks are going into KPBS proper, how do we (or perhaps, do we) document those on our side? On the one hand, it seems weird to have two "mods" both listing the exact same changes listed, when really only KPBS will have the changes. On the other hand, Nils will likely put a "updated USI-LS configs (thanks DStaal)" sort of a thing, so maybe having a specific listing of what we have done on this side, while making it clear that the changes were merged directly into KPBS is the right thing to do? I like your idea of making the Workbench a handy way to deploy a part. The Workbenches each hold 200 MaterialKits. My thinking is: even if it shouldn't take a lot of "stuff" to deploy these parts, I'm not sure if I like the idea of being able to scrap a few solar panels off of a transit stage and suddenly having enough MaterialKits to deploy something. If I was to suggest a gameplay:realism balance suggestion, I'd probably go with 100 MaterialKits? You're still likely able to get everything you need by scrapping an entire transit stage, but it isn't completely trivial. I also don't think that 100 is overly onerous, either. Like you said earlier, gameplay-wise, there really isn't much difference between 1 and 100 MaterialKits.
  14. Yeah, they attach in the sense that they have attachment nodes, so they can be hooked together in the editor, same way two fuel tanks can be attached in the editor. Just to re-iterate, the issue with docking isn't going to be from CLS, but from Konstruction (if you don't recognize that mod name, you might have gotten it as a part of MKS, if you have that).
  15. Ah, I see. But it's just 5 extra moduley-bits in one config. I forgot to consider that my proposal makes agroponics the only version of supply generation that also includes hab, which is a bit weird. I didn't think adding 5 other modes would be a big deal, since it's just one config file and a bunch of spreadsheet work, but it looks a bit weird now that I look at it. As soon as I typed Ikea, it suddenly occurred to me that if important bits can fit in a Ground Construction DIY kit, they can fit into a base structure. The only thing I don't really know is how would one go about sealing this thing? Those joints have to be able to handle an atmosphere of pressure (from both the inside, on an atmosphereless world, and the outside, say on Eve) and not leak even if they are hit with debris and the like. Do the structures themselves have the sealing baked into the mating surfaces, and its just a matter of holding everything together with rivets? In that case, we're probably talking a lot of rivets, but JUST rivets. I'm thinking of airplane parts. Those things are COVERED in rivets.
  16. I don't think the hatches are why you're having trouble docking, I think it's the construction port that's giving you grief. They come from RoverDude's Konstruction mod. They can only dock with another construction port (that is, not a regular clamp-o-tron) and, if snap is enabled on one, then it must also be enabled on the other. If snap is enabled on both, then there are only certain orientations that will allow them to dock, which is somehow managed using the "angle" tweakable. If snap is disabled on both, then they should mate in any orientation. As for the hatches, I'm pretty sure CLS does not allow you to open hatches on docking ports that are not docked, since that would mean exposing the inside of your vessel to the vacuum of space.
  17. I still don't... quite... understand, but I am going to defer to you on this. I think I'm learning, but I'm still at the 'any day my computer doesn't catch fire is a good day' level of modding. This also goes with your comment just above this. I think mainly I just like RDs deployment method because it costs resources, but also requires a kerbal on EVA. I like the gameplay element of needing something to do the deployment vs just landing a K&K Science Lab and it autonomously deploying. Part of me wishes that it was a big number so that you actually have to have some prep work in place to deploy the parts. Then again, part of me thinks it should only be 5 because the modules are already mostly solid, so the parts are things like bolts and seals. Still another part of me thinks that most of your specialized equipment wouldn't be transported in the base parts itself, so the material cost should be higher... I'm all over the place. I think EC cost should be high for the reasons you mentioned above. I still don't know what that will mean, but it may depend on what we decide on for the MaterialKit cost. If these things cost 1/5 as many MaterialKits to inflate as a Ranger Hab or Ag module, maybe it costs 5 times as much EC? I don't know. The Hab and Greenhouse should probably have the same deployment cost, but I'm wondering if the Science Lab shouldn't cost SpecializedParts instead/as well. The idea being that your specialized scientific equipment isn't just crammed inside the module. (Then again, maybe KPBS is the kerbal version of Ikea and they're just really good at that.) I think a lab costing SpecializedParts to deploy instead of MaterialKits would also add a nice "stage 3 similar-but-different" to MKS feel, but that's just me. If I had to throw out a random number for the MaterialKits, I'd say 100. I can't defend that number, but that's what I'd come up with.
  18. Just a small FYI: On page 63 of the Kopernicus thread there is a bit of a discussion about Kopernicus-induced lag. Poodmund had a user test his base on Minmus as well as Eeloo. When the lag appeared on the Mun and Eeloo, but not Minmus, he had this to say: I have NO idea as to what that means, but I have a feeling you guys may be chasing a bit of the same bug. It may be worth having a quick scan of the Kopernicus thread. Maybe some of this info can help the guys there figure out what's going on?
  19. I'm confused. I listed 4 swappable functions that the second greenhouse would have (Mulch + Fertilizer = Supplies; Dirt + Water + Fertilizer = Supplies; Substrate + Water + Fertilizer = Supplies; Pure hab bonus; and efficiency part). If they were not swappable, wouldn't that mean 4 more greenhouses for a total of 6? Yeah, a small MaterialKits + EC cost seems like the right way to go.
  20. One option, though not a perfect one, is to mention it explicitly in the part description.
  21. I imagine one would be our current agroponics + hab. The other would swap between agroponics, dirt farming, substrate farming, maybe pure hab, and being a greenhouse efficiency part. I think Organics ought to be its own, later tech tier part.
  22. I'm a bit torn on this. If anything, my preference would be for a combination of 3 and 4, where we have 2 greenhouses. One is what we've got now, and one has swappable converters. I just think that we run the risk of having way too many greenhouse variants otherwise.
  23. It looks like you're missing the "URL" field in your .version file. Without that, AVC doesn't know where to look to compare the user's .version file with the most up-to-date .version file.
  24. Hey @cybutek, I have a quick question: What would it take/how difficult would it be for AVC and .version files to be able to recognize mods versions that only work with certain versions of mods, dependencies, etc.? I know that this is not a function of AVC at this time, but a couple of us are working on a mod/patch set that basically allows KPBS and MKS to play nicely together. We decided that our little interoperability mod ought to have a .version file because .version files and AVC are awesome. It occurred to us, though, that it doesn't really matter, for the sake of our mod, what version of KSP a player is running. What matters is what version of KPBS and MKS a user is running. Since AVC can already see what version of a mod you have installed through its .version file, how complicated would it be to implement a system where a .version file could reference another mod, and then have AVC confirm that the other mod's version is not outside of what is acceptable? Not being particularly computer-savvy, I don't want to come across as demanding features, but I am curious if such a thing would be feasible. Thanks,
×
×
  • Create New...