• Content count

  • Joined

  • Last visited

Community Reputation

713 Excellent

About DStaal

  • Rank
    Capsule Communicator
  1. The main point of using machinery was to offset mass - if don't need it for that, then we can approach things a different way. Mostly just mentioning because I had included it, and it would have been a 'resource' as far as that spreadsheet goes. But yeah, either a table here or update this table: https://github.com/DanStaal/KPBStoMKS/blob/feature/Life-Support/Parts_Table.md Which I setup as a work-in-progress table. Whichever works best for you. There used to be a way - though from looking at it I think it's either unused or depreciated entirely in the current version of MKS. I decided to give the 'Planetary Control Module' 2km - but not PL, which remains a Central Hub exclusive. Yep, doing the .version file and changelog off the Release branch is the idea - that way we can play in the Dev branch. And do think the download should probably have the 'GameData -> KPBStoMKS' hierarchy - but I don't think Github should have it. Github just has the KPBStoMKS folder, and putting that in a 'GameData' wrapper is part of the release process. That keeps git clean of 'extra' folders, and makes it simpler to keep track of, IMHO. (And I expect making a .version file is super easy - how else can you get dozens of lazy mod makers to include it? )
  2. A quick check of numbers, and I think KIS is computing the volume of the 'bounding box' - so the total length, times the height at tallest, times the width at widest. Assuming the tapers add 0.8m to each end, you get the KIS numbers from RoverDude's numbers. The KPBS parts are closer to filling out the whole rectangle, so for the non-deployable ones you can work with the KIS numbers as a general guideline. (There's probably a way to work out the exact fill percentage.) I did have one resource storage listed on my table: Machinery. That was the 550. But it sounds like the mass problem won't be as bad as we thought it was. Thanks for running things through. I can't focus on this to well at the moment, but it sounds like we're in decent shape. Oh, and thanks @dboi88. I have no idea why I couldn't get that to work for me; that looks pretty close to what I had...
  3. Yep. Known oddity with how KSP handles things, and how USI-LS handles things. Don't worry about it really - the effects aren't being applied until you bring physics into range, and when you bring physics into range your EC production is updated.
  4. I've always really liked the 'Quadrapoodle' from the Taurus mod. (The mod itself is somewhat out of date, but there's a set of patches in the thread.)
  5. This type of thing is a common enough error that for the most common classes, I have a script that auto-scans anything added to my GameData folder to check. ':FOR' is badly named, and people tend to think of it with the common meaning of 'for when $x is satisfied', instead of 'this part is for $x'.
  6. I look forward to them. As for the animations: If it were just a stand-alone animation, I suspect there would be no problem. But in this case an animation deploys *only* when something else happens: The crew capacity increases, an IVA is changed/added, some resources are consumed, etc. That's where I think the problem lies. However, I'd admit I didn't do a very thorough investigation - I just tried the two most obvious MM options, and found that while the resources were consumed and other changes appeared to occur, the animation didn't play. Feel free to poke if you want.
  7. ?? The most common monopropellent in the real world is hydrazine, with H2O2 being a decent second place - both are typically fed over a catalytic bed into the thrust chamber. Even RCS thrusters tend to run on one of those (H2O2 being more common in that usage) or variant LFO mixes like monomethylhydrazine/nitrogen tetroxide. Compressed gas might be useful for a cubesat or something, but you aren't going to get much dv out of it in a large-scale use. (Unless of course you're using it in a non-space application - where you can recompress gas between thrusts.) As I said, that was just the first I found recently. I believe I remember reading about one a while back that used a platinum (or similar) catalyst to encourage the reaction - Assuming that's a real catalyst, the only fuel the cell needs is H2O2. As far as I can tell, it's likely these have a higher power output - but you'll have to replace the aluminum block in them occasionally. Either way, the point is that if you're storing an unstable chemical you can get it to break down, and if you know what you're doing you can get that breakdown to output energy in a variety of ways, and monopropellents tend to be very unstable chemicals.
  8. Can you ping-pong back and forth? (From the end, replay the animation backwards so things don't magically appear - they get replaced.) (Just an idea...)
  9. And that has stopped us before?
  10. Ok, did a pass on the logistics. I think I've got it, but I'll be playing around a bit to test. Anyone else is free to do so as well - Sometime soon I'll update the readme, changelog, version, and put out a stage-1 release unless people spot any glaring bugs.
  11. Which actually brings up a question I have: Would it be possible to put in a limiter (that is: A slider you can adjust) for the processing rates for the modules that can have their efficiencies increased by Kolonization? The thought here would be that you might want to run a base or site at the 'rated' output, so that your heat-rejection/power/resources are adequate to the task, at least until you build out.
  12. So: The supplies are expired, but they're in the grace period before they die.
  13. It's not that complicated: Two jobs, with three days of overlap per week. Both are basically 'be on call and available - and we'll pay you when you actually do something', but one is on-call at the computer and the other isn't. Well, the last release of my integration pack was 0.9.1. I'd actually think stage 1 should be '1.0.0 beta', and stage 2 should be '1.0.0' - with the actual patches from stage 2 being integrated into KPBS, to replace it's current USI-LS patches. I'm not sure how well KSP-AVC would support that versioning scheme however. I haven't looked at how it handles this. (But yeah, I figured it was probably pretty easy - I just haven't had time to look at it myself.) I wasn't necessarily thinking a 'new' part - just adding it to either the ISRU or the Workshop. (I was actually leaning towards it being the Workshop - then in stage 3 we have it swap out for the actual production.) I'm going to investigate for a bit whether MM can just add the Machinery requirement by itself, or whether we would need to have a full different block. If it's the latter, I think adding in the converter is the cleaner option, requiring less maintenance long-term. If it's the former, then it's less confusing to players to not have to deal with the resource unless it's a common resource, and the parts would only be slightly overpowered when MKS isn't installed, which could even be rectified by adjusting the mass in a conditionally applied patch.
  14. That sounds like it's just typical KSP catch-up mechanics - though it might be possible that EL could try to put it's catch-up later in the queue so it can get the produced RocketParts.