Jump to content

blowfish

Members
  • Posts

    4,559
  • Joined

  • Last visited

Everything posted by blowfish

  1. So basically, all the unique/complicated parts But you're right that the RD-170, 180, and 191 basically share scaled version of the same turbomachinery. That might reduce a bit of the work in modeling them...
  2. It's a little difficult to control, but it's manageable, even in FAR. Just don't deviate too far from prograde, particularly near Mach 1.
  3. Hmm ... it seems that reloading the game database through ModuleManager's interface causes the engine clusters to disappear from the editor. Perhaps something needs to implement ModuleManagerPostLoad() so that the appropriate things can be refreshed on a GameDatabase reload?
  4. They're all on Github, and installable via CKAN. If I decide to put mirrors somewhere else, it will be for redundancy's sake.
  5. Provide logs (follow the first link in my signature if you don't know how to do that, but logs should accompany pretty much any support request)
  6. I can definitely submit a PR, but I probably won't have time until the weekend, and then I'm not quite sure when (cluster configs to do too). But no rush. On the Delta IV mount, yeah, I just mirrored the part of the geometry without the extrusion - it's currently mirrored along the 45° axes.
  7. Thanks for providing logs! There is currently a bug that Shadowmage is aware of where the tank types don't load properly if CommunityResourcePack is not installed. The workaround for now is to install CRP. If you don't wish to use the LH2 patches with that, you can remove the LH2 patch in SSTU (though I highly recommend using LH2 - it results in much more sensible rocket designs!).
  8. Thanks. So I got bored tonight and butchered a couple of your engine mounts: Any interest in actually using them? They don't actually require any texture modifications. And yeah, I know there's a generic shroud already, but it just bothers me to have an engine without any turbopump exhaust in a hole that wide. I guess an alternative would be a version of the generic shroud with a smaller opening (just move the verts inward :P) Speaking of the generic shroud, I found an oddity with its geometry: it seems that each arg segment is actually two coplanar segments. Based on the UVs I think they could be merged without harming anything.
  9. @Hodo Clicking one of the KK buttons doesn't bring up a base selector?
  10. Would it be possible for you to say exactly which RL-10 variants you based the stats on? It seems like there are a lot.
  11. Ok, let's try to keep it civil @Beetlecat I think you're right on both counts but the issue was already resolved so there's probably no need to drag it out. @Table While responses from actual project members (me) should of course take priority, there's no reason not to accept responses from others, and that includes interpreting the meaning of what others said. It is quite difficult to convey your intentions in text and Beetlecat was correct that I had no intention of being rude. There's enough noise in this thread as it is, let's try to stay away from meaningless arguments.
  12. Again, sure, it's doable, but not something I have the skill, time, or motivation to do correctly. Recoloring isn't quite as simple as you might think. But feel free to take a stab at it yourself if you feel the need
  13. @jonnyt21 I just checked and CKAN now looks at Github for FAR so it can be installed normally now. But if you already installed manually then it might be complicated to switch - I think you might need to uninstall RO, then remove FAR, then reinstall - in my experience CKAN tends to blow up when a dependency for something already installed just disappears, but I don't know for sure. One of the CKAN devs might be able to give more info on this.
  14. @jonnyt21 CKAN will usually recognize mods you have installed manually. In this case, you would need to install FAR first then use CKAN for the rest (be sure to refresh CKAN so it recognized that FAR is installed).
  15. Thanks for providing logs. It looks like you don't have ModuleManager installed. SSTU requires it.
  16. It's not. The UV mapping is completely different
  17. Sure, it's possible to create a different set of textures for anything, but is that really something that's worth spending time on (not that I would anyway - I'm a terrible texture artist).
  18. @barfing_skull See the OP: old mk1/2 parts have been moved to the legacy pack.
  19. I didn't mean to be rude, sorry. Don't take it personally - I just see so many trivial requests every day that it seems like no one actually bothers to try and find things themselves before posting.
  20. It's in the OP and my signature. Is that not enough?
  21. It would have to be a code fix in IFS. Perhaps you could report this in that thread?
  22. Nothing has been removed, only moved to the legacy pack Everything is on Github.
  23. The precooler cools air entering the engines, not the skin. And yes, re-entry happens much higher than the final leg of the air-breathing ascent. But that doesn't change the fact that most of the heat is experienced at higher mach numbers - the power dissipated by drag is roughly proportional to v3, but only linearly proportional to density. And the air-breathing ascent is actually pretty low in the atmosphere for the speed (it experiences up to 64 kPa of dynamic pressure!) During re-entry, it weighs very little, yes, but that has no effect on the shock temperature it experiences at a given mach number, it just means it can slow down faster. Yes, atmospheric heating in KSP is scaled up a lot because in reality, you'd barely have to worry about heat in an earth-like atmosphere going at mach 6-7 (re-entry on Kerbin). Which means that inevitably, parts start to overheat near mach 5 lower in the atmosphere. Sure, but I'll trust that their numerical simulations are probably pretty reasonable.
  24. All the required dependencies are included in the HX download and CKAN is aware of them.
×
×
  • Create New...