Jump to content


  • Posts

  • Joined

  • Last visited


479 Excellent

Profile Information

  • About me

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @NerteaReluctantly, I think you should go with my patch. I know I'm coming in like a wrecking ball after ProgorMatic did a lot of work. I wish I'd seen his earlier posts. I fully agree with this: I've only updated the existing patch to add new parts, kept functions separate, consistently with what they were before, and still do not touch dry masses. I use MKS, but I prefer to have this patch merely enable SSPXR to play with it in a reasonable way, rather than have the presence of MKS override the character of SSPXR parts. There is also already an MKS patch which modifies extensible/inflatables to use material kits, still leaving total deployment mass unchanged. Altogether, the lighter footprint of the old patch is preferable. It's true that the balance for the old patch isn't self-consistent, and I haven't fixed that balance. I'm open to a balance pass and changing the performance of individual parts, but without changing dry masses, crew capacities, or roles of the parts . Again, @ProgorMatic, I'm sorry for not having this conversation more than two weeks ago.
  2. Whoa, okay, so now I have reviewed @ProgorMatic's patch. This is a huge departure and overhaul from what was previously here, adjusting part masses to simple integer tons, adding recyclers to habs, flattening habs categories into the same 1-ton, 2-ton hab, and 4-ton options across the variety. I'm not saying that's wrong, but it is aggressive in how it touches everything. It will definitely change ships in flight that are using the previously existing patch, which I left untouched, only adjusting the new parts to be similar to the old parts. I think we ought to get feedback from other users as to what they want. Do you want a patch that wholly brings SSPXR up to the way MKS habs operate? Or do you want an extension of the previous patch that leaves the old things in place and only brings new parts in line with them? I'd prefer my option, but I'm just a creature of habit. ProgorMatic's patch is definitely streamlined and easy for planning missions. There are aspects of it I like. Overall, I'm uncomfortable with it. Sorry to change my answer to you so quickly, but I didn't realize you were essentially providing an entirely new patch instead of a simple update to accommodate the new parts. But I'm just one voice in the crowd. Can others please reply and say what you'd prefer? Maybe test them both out? Edit: Also just want to add an apology to ProgorMatic for not seeing that you'd posted a week before I did that you were looking at adding a USILS patch. Whatever concerns I have with it, it would have been more productive to discuss them back when you were very clear about how you were planning to overhaul things.
  3. @ProgorMatic I didn't realize you were working on a patch. It seems like you're putting more thought into it than I did, so I'll defer to your patch. (edit, see reply further down the thread) However, I think you should still add something for Tholos (copy and modify my entry, if you like), since it's sensible that it adds some habitation multiplier like any cupola module. A ship with a dome is easier to live in than one without, right? I haven't reviewed your patch (edit, now have reviewed, see further in the thread), but one thing I tried to keep in mind is that the 5m parts may have significantly more volume than their 3.75m counterparts, often 4x as much, but rarely are they more than about 50% more mass. So, my guideline was to keep in mind relative performance per mass and crew capacity, and give a slight edge to the 5m part. But then I just made up a number that sounded okay that fit those boundaries. If you're already keeping performance per mass in mind, that's great, and I have nothing more to add. As for the PAS-G 'G4RD3N', @Arrowmaster it is three times heavier than the similar part, USILS_Greenhouse_MiniCupola, from USILS and about double the output. So it is less overpowered than what USI-LS includes to boot. Like I said, the numbers for most things were already inconsistent, so I was mostly looking at existing similar things and going from there. Abandon consistency, all ye who enter here. Edit: Crap, no, I did miss a decimal place! I just updated my pull request, if you want to keep playing with it. That cupola is now more sensible.
  4. I know you were addressing this to @JadeOfMaar for what he was doing for TACLS, but I realized my intent wasn't clear either. I've made a pull request now.
  5. In the CTT patch for WOLF, there's a typo where @PART[WOLF_Transporter]:NEEDS[CommunityTechTree] { @TechRequired = advlogistics } should be advLogistics, as it's case sensitive. I've been losing my mind trying to figure out why the transporter computer won't show up in my game, finally found it.
  6. I haven't seen where somebody else has submitted an updated config for ULI LS, so here is mine. These numbers are roughly pulled out of my backside, approximately scaled to the increased mass and crew capacity of five meter parts, plus the 1.25m cupola greenhouse. If somebody else has already taken care of this, please disregard. Google Drive Link to cfg This is a separate file, and the individual parts would need to be copied and pasted into the right sections in SSPXR-USILS.cfg . This does not include any changes to any other USI or MKS specific patches.
  7. Treebeard says, "we never go anywhere unless it is worth taking a long time to go there."
  8. I liked this. Sorry you found it a nightmare. You can do small rotations to keep the parts from clipping. I suppose if Nertea followed your suggestion, I could do the same rotations to get it to follow the shape again. I do miss the conformal deploying radiators being sized to reject enough heat for the reactors they fit.
  9. 30° is too much in most cases, but it can happen. A ground source broadcasting below 30 MHz can have multiple reflections off ground and ionosphere, going around the horizon for thousands of kilometers. For sources outside the atmosphere, at a shallow angle much of the signal will bounce off the ionosphere, for the same reasons things bounce internally, before ever getting a chance to do this. There are exceptions. Above this frequency range, there's little ionospheric interaction, you pretty much need line of sight. Below 1 MHz, you can get a few effects from diffraction around terrain itself, without atmosphere. For just passing through atmosphere, which has an index of refraction slightly different than vacuum, you would expect very slight bending. Planets without significant magnetic fields that can't retain the same kind of ionosphere will also have much less effect. So, now that I'm chewing on this, picking 0.9 sounds both good and very unrealistic to me.
  10. If it could be determined from the atmosphere on a per frequency and angle basis, with some internal reflection due to ionospheres, you'd probably get a wide range of values. You'd also have dead spots from signal being refracted or reflected away at certain incident angles. Lacking that, picking 0.9 sounds good to me!
  11. I've seen weird things like that with decal mods.
  12. 5m habitables from SSPXR, 5m hydrogen tank for afterburning on Asimov, then a 5m squat fissionables fuel tank (which is only 31% more fuel than 2.5m long tank) with 5m to 3.75m adapter for engine makes way more sense than adapting 5m to 2.5m then back to 3.75m, especially if they're using the same texture space anyway. We're also not talking about anything that's outside the realm of other FFT TWR or dV, and large dV enables all kinds of mission profiles either outside of normal transfer windows or high energy transfers to OPM planets. Y'all aren't imaginative enough. Edit: I'm not careful enough. An Asimov drive core pushing an 85 ton payload will only use ~48 fissionables for an entire 5m hydrogen tank, providing ~49k dV. A squat 5m fissionables tank would have ~800 fissionables left over after that, which would provide ~39k dV after that. Using reaction products mode isn't sensible for heavy payloads. I should go buy a hat so I can eat it.
  13. Any chance for fissionable fragments part variants like their 2.5 m counterparts?
  • Create New...