• Content Count

  • Joined

  • Last visited

Community Reputation

290 Excellent

About Dragon01

  • Rank
    Flight Director

Recent Profile Visitors

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

  1. Dragon01

    [1.5.0-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.
  2. Dragon01

    [1.5.0-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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. You're back? How about a D12 update? The community kept it working, but an official update would be nice. Also, Mk2 should be remade into stock shape for the next B9. IIRC, they said that somewhere in this thread.
  13. Dragon01

    [1.1.2] Realism Overhaul v11.0.0 May 8

    Unless Ferram finishes his wing code overhaul for the next update (unlikely, there's still a lot of work to be done there), there will be no aerodynamics changes. It'd be pretty much the same, the dimensions of the two are very close. I remember B9 HL parts being once scaled to the Shuttle, but I'd prefer to have them more like large cargo plane parts.
  14. Can't wait for the update. Until Squad remakes its rocket parts, this is absolutely essential.
  15. Now that 0.90 is out, how about some nice looking OMS pods? Not like the ones now in SXT, I'd love to see something more boxy and larger (fitting with the new fuselage system). An orange 5m ET (preferably modular, so SDHLVs can be made with it) would also be nice. Basically, a bunch of Shuttle parts would be just the thing for the next SXT.