Dragon01

Members
  • Content Count

    3,640
  • Joined

  • Last visited

Community Reputation

294 Excellent

About Dragon01

  • Rank
    Flight Director

Recent Profile Visitors

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

  1. Read his post again, he's thinking of remaking it. Since the Energia is done, there are no other Russian rockets that exceed 2.5m (well, other than UR-700M, but see a few posts back with regards to that). And no, the improvement from having a higher texel density is not insignificant (especially in a mod already lacking in detailing compared to, say, BDB). The current N1 does look out of date, consistent texel density is a must.
  2. I would recommend against that. Inconsistent texel density can be rather noticeable (it certainly is now). N1 would be hit especially hard by this, since it ends at 2.5m or so. It might be preferable to instead split the rocket up. Model the engines separately and the N1 "ultra-large part" lineup would be reduced to two lower stages (preferably with integrated, adjustable engine mounts for maximum flexibility), with the 3rd being comparable to any other 3.75m stage. This would result in simpler large-diameter parts and would make alternate configurations easier. Of course, part count and vessel complexity would go through the roof, but that might be a good thing, since I feel that the old N1 completely failed to capture the sheer crazyness of the RL design.
  3. Could use thermal blankets (but then, almost every part in the mod could) and the radiators could be more white. Otherwise it's not too bad.
  4. I think you might be interested in this: This is a list of various "improved Soyuz" variants proposed over the years. Most of them never went anywhere, but to me, this screams "KSP". My proposal is to keep the "BDB-compliant" 1.5m Soyuz design and scale the spacecraft to it, while having the 1.875m setup as either a separate part or a variant. RD-0124 could have its skirt size changeable using the part variant system, as to work on either diameter. This could possibly be complemented by a 1.5m lower core with appropriate adapters, resulting in a nice, fully featured 1.5m lineup and a possibility to put the rocket together in any way one might want. Another variant, not listed here, is Yamal: Also a canceled project, but a cool one. The boosters would be 1.5m (same tank as the core, in fact). Engines on Yamal and most others are NK-33s, with the core also having the RD-0110R (a quad vernier derived from RD-0110) around it. Geos-Yamal, ex Yamal and Soyuz-M used RD-120, while Onega had the RD-191. The upper stage is typically RD-0124, except for the 3.7m ones, which are LH2 stages. There are three sizes in here, but for KSP purposes, I think that a single 1.875m size for "Soyuz-M" family would do just fine (none of them were ever built, anyway, except for Soyuz-2.1v).
  5. Dragon01

    [1.5.1-1 + Backports] Kopernicus & KittopiaTech

    For the record, this is a canned routine copied off the forum (if you look at the aforementioned file, there's an URL to the thread), not a bespoke, integral job. During the 64bit debacle batch utilities were written to more or less do the same thing a bit lower in the code. Removing this check should not affect anything else, aside from allowing it to load on a version that's actually incompatible, which goes without saying. Also, anyone capable of compiling from source should know that such hack jobs won't get any support. And how exactly is it better than MiniAVC at doing this? This routine doesn't actually prevent neither KSP nor specific saves from loading, so if the message is ignored (and it isn't any harder than dismissing one from MiniAVC), trouble is going to ensue anyway. It does only one thing MiniAVC doesn't, and that thing seems to be mostly good for generating angry messages on the forum. Now, if it checked compatibility, then it would be good. It doesn't. It compares version numbers and barfs if there's a mismatch, without any regard for actual compatibility or lack thereof. This is a problem for every mod ever that had this crock slapped into it. Oh, and unfortunately, most Steam users don't get to wait 2-3 days before installing the latest patch, thanks to an automatic update system about as flexible as Majorjim's version checker.
  6. Dragon01

    [1.5.1-1 + Backports] Kopernicus & KittopiaTech

    For the record, it's an easy fix for anyone capable of recompiling the plugin from source. In CompatibilityChecker.cs, replace this: #if !DEBUG return Versioning.version_major == version_major && Versioning.version_minor == version_minor && Versioning.Revision == Revision; #else return true; #endif with this: #if !DEBUG return true; #else return true; #endif This should kill this brain-damaged checker for good. It's the same crock that did 64bit lockouts, so if anyone's willing to get a bit more involved, the old 64bit unfixer could probably be adapted to deal with this (won't work out of the box, though). I mostly use Kopernicus for eye-candy (SVT), so I'm not going to go through the trouble myself, but should anyone come up with a solution, I can help testing. This thing was bogus back when it was introduced, and with the new release model (and general stabilization of KSP codebase) it simply needs to die.
  7. I seem to have forgotten a suggestion. A white texture variant for N1 would be really nice. Regarding scaling concerns with the N1, I have to tell you that a 1.5m Soyuz would be better scaled with N1 than 1.25m. IRL, Block D is 3.7m, which I already calculaed to come out as 2.5m in KSP scale (using Cobalt's method of scaling, 0.64%, then to the nearest KSP size). Block D was 2.5m last time I checked, so as long as the rest of the N1 is to scale with that (more or less the case), the 1.5m Soyuz would actually be a better fit for N1 (and Proton) as well.
  8. Beale asked me to post my suggestions here, so I'll make an exception from my usual policy of keeping away from the forum. 1. N1 upper stages need an overhaul, mostly engine related. Gimbal actuators, heat shields and, most importantly, correcting the expansion ratio (the nozzle model and textures could be more like this as well): 2. Block D engine overhaul. It could have been a very useful OMS/small upper stage engine, but the huge buttplate and a rather poorly designed RCS system (it can't roll and looks nothing like the real thing) make it useless in that role. I'd suggest making the plate a part of Block D, making a new RD-58 and adding Block-D style RCS as a separate part with an integrated decoupler (Block D could decouple its ullage and RCS motors): 3. Soyuz. 1.5m for both spacecraft and the rocket (well, the upper stage, at least). It would actually provide the best inter-mod compatibility, allow for 1.25m docking ports and a 3-Kerbal capsule. Alternatively (for the rocket, at least), instead of the currently flying base variant, make one of the proposed ones: 3.2m core would translate well to the 1.875m size, 3.5m and 3.7m parts could be scaled to 2.5m, resulting in a large array of parts. And good compatibility.
  9. Actually, I was thinking about asking you about that, in case DECQ didn't succeed in making KF wheels. The only problem, well, I was waiting for you to get KF working. However, that's far further off than I initially assumed. Retexturing them for Buran (painting the hubcaps green, mostly) shouldn't be a problem. The license seems fine. The nice thing about Buran is that its nose wheel is much further back, so with the setup we're using, it's a part of the cargobay, not the cockpit, unlike with Space Shuttle. As the cargobay can have an arbitrary orientation in Unity (and in 1.2, so can the wings), this removes a major obstacle (of course, the biggest one is getting the bloody things to work in first place...). You said you had them working under 1.1... If I could just have them+module setup you used, that would be all I'd need. .blend files would be good as well, just in case. The idea is to integrate them with MODEL nodes and use the new "default action groups" to ensure the gear doors open in sync with them, so if everything goes well, there'd be no need for messing around with the .blend.
  10. As much as I hate dealing with everything about the new forum, it seems like I have to post here (and no, that doesn't mean I'm back, just that new stock wheels screwed us by that much). As you all know, 1.1 broke the wheels, badly. Me and DECQ were hoping to use KerbalFoundries plugin to use its wheel solution. Now, with Lo-fi on vacation for "a few weeks" and the plugin still bogged down in Unity crap, it's clear that no replacement is forthcoming before the end of the year. Meanwhile, reworked Buran/Energia system (and some other things as well...) is nearing completion, while Space Shuttle System being ready for update since a long time. I think I have figured out a way to make stock wheel module play nice with the parts, but no such luck on figuring out the wheel setup itself, which is quite arcane. Thus I need to ask for a working (as in, can be tossed into KSP and used as a standalone part) models of Shuttle and Buran wheels. The more detail, the better (within reason), textures should be on the photorealistic side (though if providing those is a problem, DECQ may be able to texture the model as long as it's UVed). With neither me nor DECQ being able to figure the wheels out, and KF being far from usable, we're left with no other options. The author will, of course, get proper credits.
  11. Dragon01

    [.90] RealHeat: Heat Transfer 101! [WIP]

    Looking forward to it. Can there be some more information on how it works? A realistic heat system would be a wonderful addition to KSP. Not only reentry, but nuclear reactors, life support, engines... Also, I've recently had an idea: external and internal temperature (I assume there's only one value per part at this time). This would enable simulating insulation, for example. An insulated part would have it's internal temperature be much less attached to external one. This would be very important for things like cryogenic fuel tanks and heat management for crewed parts (a pod could heat up a lot on reentry, but inside, the temperature would have to stay lower).
  12. Dragon01

    Orion Enthusiasts: A little help please?

    Note, the Orion likely has two RCS systems. One for the CM, the other for the CM+SM combination. This is likely why it doesn't use the 6x forward ports for deorbit. On Apollo at least, the CM system used hydrazine monoprop, while the SM used MMH+NTO. You don't have to bother with balancing the RCS system on the CM, as it would only be used for rotation.
  13. I have an idea. What about some instruments that would have to be held right next to the surface? A good example would be the APXS: http://en.wikipedia.org/wiki/Alpha_particle_X-ray_spectrometer Another good options would be a sample drill and a microscope, as well as various spectrometers (like Mini-TES and MIMOS II). Those would give some utility to Infernal Robotics-based robotic arms. The pack could even contain arm parts, but in that case, it should probably be separate from the core mod.
  14. We're not in 0.90 until Firespitter is updated. Really, the number of mods that depend on it is astounding, and for a good reason.
  15. Nice Delta-K. Are you going to be getting this model in game, or making a new one? Also, I'd really love if HG-10B2 had a movable nozzle extension. You even modeled guide rails on which it moves. It'd reduce the intestage length somewhat and look really cool.