draqsko

Members
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

6 Neutral

About draqsko

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

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

  1. draqsko

    [1.3.1] Cacteye Optics Community Takeover

    Hardly miserable, or tedious, it gives my game meaning rather than run the same contracts over and over ad nauseam for the past year plus. Fortunately for you, you aren't required to use this mod to play KSP and some people might enjoy the current functionality, so requesting that some feature be configurable is preferable than asking to remove it entirely because you don't like it.
  2. draqsko

    [1.3.1] Cacteye Optics Community Takeover

    Personally I think it is more insane that you can throw up something in orbit in KSP and it lasts forever and a year without any maintenance. Or that you can point your telescope directly at the sun without any special filters and it doesn't cook off. But to each his own, which is why @icedown is making it configurable. I was just posting suggestions to ease your pain when using the current version of CactEye, if you so choose.
  3. Hope you aren't trying to do historical missions with those RT configs. Both the RT and the SETIRebalance configs have the same stats for the antennas, and I found that Mariner 1 and 2 are impossible. The ranger dish antenna has an RT range of 50,000,000 m (just past the orbit of Minmus in stock scaled systems) while the stock configuration has an antenna power of 2,000,000,000 which can easily reach Eve. The RT configs are balanced around stock antenna balance rather than actual historical uses. It's part of the reason I dropped using RT for the moment, the BDB RT configs need a serious rework if you want to do historical missions, both in range and data transmission rates (there's a few times I've had to allow partial transmission because the antenna can't even transmit the smallest experiment in one go on certain historic probes). To give you an idea how messed up it is, the Mariner 4 dish in stock BDB has an antenna power of 8,000,000,000 while the RT config has a range of 35,000,000,000 m. Using that ratio the range of the Ranger dish antenna should be somewhere around 9,000,000,000 m (which would reach Eve as long as its on the same side of the sun as Kerbin) instead of 50,000,000 m. So keep that in mind before you launch your Mariner 1 and 2 missions to Eve only to see them lose connection just outside Kerbin's SOI like I did. PS. Eventually I'll rework these configs myself if no one else does and submit a pr on github, but right now I don't want to commit to anything. Just bought a new house and while I'm taking a break right now from doing work around it cause it's too damn hot, I know I'll drop off the face of the Earth in a month or two once it cools down enough to work outside at least until winter sets in. I hate to leave people hanging by saying I'll do something, get halfway through it and then have to stop because of real life.
  4. draqsko

    [1.3.1] Cacteye Optics Community Takeover

    The only parts that should break from use over time and require service are the gyros, should turn them off when not actually using the telescope to observe a body that will prevent them from burning out too fast. The processors can explode if you point your telescope close enough to the sun, which makes Eve and Moho observations challenging but not impossible, do them on the dark side of Kerbin. Since the FungEye body doesn't have a closable shutter, it's wise to keep it pointed Normal/Anti-normal for an equatorial orbit or Radial-in for a highly inclined orbit when not in use so you don't accidently scan through the sun while turning to point towards a body for observations. I've lost a few processors learning that the hard way. And BARIS would need a MM patch to make it actually break parts in CactEye aside from the probe core and gyros. The processors and telescope bodies don't have resources or modules that BARIS can hook into. The probe core and gyros have the SAS module which BARIS will break. If you don't want your gyros to wear down over time, go into the part configuration files tele_gru1.cfg and tele_gru2.cfg and edit this part: Change lifeSpan part from 25 or 50 (gru2 is 50 for lifespan) to some huge number like 2500 or 25000. It'll still technically wear out over use, but that time limit will be virtually unreachable in normal gameplay since it only ticks down when you have the gyro active and the vessel in physics range. I wouldn't recommend deleting that line to make the lifetime infinite, since the dll will be looking for it and no definition might be treated as 0 lifespan which would break the part instantly on launch.
  5. The configs are really bad, the parachute unit has this: while the stock Mk1 parachute has this: The stock Mk25 parachute is 25 by way of comparison. So the parachute has the drag to slow down something as heavy as the Mk1-2 capsule to safe landing speed. Anyways there were other issues I found in the configs so here's the changes: Parachute.cfg These are just edits except data transmitter module, to bring it more in line with stock parts. You may need to tweak the dragModifier = 6, depending on how your descent goes. Higher will slow you down faster and result in a lower landing speed. 12 is the setting I used for 2.5x which has a much higher gravity well than stock but I used this for Corona which required an aerial recovery and therefore a really slow descent speed once the parachute opened. Either way, changing this will change how fast you slow down with full chute deployment. The other module like this named SEMIDEPLOYED is for when the parachute is in drogue deployment, if it doesn't slow down fast enough to fully deploy the chute before hitting the ground, tweak this setting up a little bit (I use 1 for 2.5x). ModuleDataTransmitter is needed for an internal antenna otherwise you won't be able to control the capsule, since the model has an antenna built into it, I felt it appropriate for that antenna to actually exist. CargoBay.cfg The CoP, CoL offset changes can be added into the part config after the node stack definitions. I had issues with ablator burning off and raising the CoM high enough that it would turn turtle, CoP and CoL offsetting prevents that. Thermal mass modifier is set for normal parts rather than cargo bay like thermal mass since this has built-in ablator, which cools the part as it burns off. Normal cargo bays need a higher thermal mass to protect the parts in them but this cargo bay should never get that hot to need it unless you actually run out of ablator. And if you run out of ablator, you should burn up rather than rely on the thermal mass modifier to keep from overheating. The change to ModuleCargoBay is needed however otherwise parts inside the cargo bay won't actually be protected, the ray casting starts at 0, 0, 0 and is hitting the floor of the cargo bay at 0, 0.0424, 0 before it sees any parts except parts attached to the floor that happen to clip some part of their model through it. PS. I'm still not entirely happy with the settings just yet, there's probably more tweaking involved but this should at least get you a functional return capsule. PPS. After making these changes make sure you delete the ModuleManager.configcache and ModuleManager.configSHA files so that MM loads the changes. If it loads from cache any change you make will not be recognized.
  6. Wild Blue Industries/MOLE/ExperimentResults/BaseandStationBuilding.cfg is only for a surface experiment, changing only that file will produce no resulting change for an orbital lab, it has to be landed on Kerbin, Minimus, or Mun per the situation requirements that I quoted. You could test overall functionality using the edit you tried but you'd have to try the experiment landed on the surface of Kerbin or one of the moons, not in space. MOLEModulesExperiments.cfg is the configuration file for orbital experiments, and you have to add it there to every experiment as well as you can see: There's other issues perhaps in the configuration for BDB as I stated earlier, I'm not familiar with how MOLE operates so I'm not sure if the entire config actually works. From what I can see comparing the BOW to the Hokulani it should work in theory since the configurations are nearly identical, other than the fact that WBI calls back to a template folder for the configurations of the templates while BDB has the templates in the compatibility file of the part. Either method should work equally well with Mod Manager for patching parts.
  7. That experiment only works while landed, if you scroll down a bit past the section you were editting you will see this part: Have to be landed on a body to perform the experiment, and it only applies to The other file in that folder, MOLEModulesExperiments is probably where you want to add in the OWS as a required part in orbital experiments. Also make sure you use the title of the part, so in the case of the Skylab OWS it would be requiredPart = Hokulani-OWS Orbital Workshop Not sure that will fix it though, there could be other issues in the configs and I've never used WBI MOLE so I'm not really familiar with how it operates. But that should at least get you started in the right direction. Also delete the MM caches every time you change a configuration file so that KSP actually loads the new configuration, sometimes MM will just load from cache and that will drive you nuts trying to debug something in configuration files.
  8. They would all be about the same diameter, the only difference is length and dead mass/instrument space really. And that difference is incredibly small for stock or 2.5x scale, using real life numbers: X-242 (which is what I think you based the original model on since it's a Vanguard apogee kick) total mass is 0.217 t, propellant weight is 0.193 t, thrust is 11.6 kN X-248 total mass is 0.239 t, propellant weight is 0.211 t, thrust is 13.8 kN X-258 total mass is 0.275 t, propellant weight is 0.235 t, thrust is 24.8 kN FW-4D total mass is 0.299 t, propellant weight is 0.275 t, thrust is 26.4 kN Star 13 total mass is 0.038 t, propellant weight is 0.033 t, thrust is 5.87 kN Star 20 total mass is 0.301 t, propellant weight is 0.273 t, thrust is 28.4 kN If you scale all of those down, there's really not much significant difference other than aesthetics. The only outlier is the Star 13, and your really tiny solid can be used for that (the one that's the same diameter as the Vanguard 'spin up' shroud attachment on the probe core) or the Pioneer kick motor, unless you need attitude control then the Staara 10 reduced in fuel load and thrust with micro RCS booms attached for pitch and yaw control will substitute nicely.
  9. The Staara 20 is way too big for the X-242, X-248, the Staara 10 is closer to the actual fuel load, thrust and burn times. The Staara 20 can be used for the X-258 and FW-4D but with those rocket designs, you get much more out of it than historical rockets did and the Staara 10 feels like a better fit for trying historical launch profiles. I know you can drive yourself nuts on the early rocket designs and have a million parts to actually build them all to historical accuracy so I'm not expecting you to make every single engine. Either way, deprecating the old model would be helpful so it doesn't instantly obliterate assemblies before they can be updated.
  10. Put the micro RCS booms with built-in MP tanks that BDB includes. All the Staara motors will easily accommodate them and that will give you guidance all the way to payload separation. You technically won't even need electric charge to use them other than the lack of probe control with the lack of EC. Also if you are OCD as myself, you can line up the thruster outlets with the slots on the engine shroud so when you lose your fairing you don't have MP blowing through a shroud (since KSP doesn't treat shrouds as shielding a component, soon as you eject the fairing, they'll start working). Same thing I'm currently using the Staara 10 LYC motor for, could you deprecate the old motor so it doesn't break subassemblies? That one particular motor is quite heavily used with tweaks to thrust and fuel load as an approximation of all the upper stage solids in early rocket launches. I use it as a placeholder for the X-242, X-248, X-258, FW-4D, TE-M-516, so it's quite a lot of rockets that actually have that part.
  11. I use them a lot, basically for any payload that just had to make it to space within a certain min/max altitude requirement. Also in 2.5x you'll need them for the early rockets to even get a payload into space (specifically Vanguard which is even borderline at that, if you don't use the 0.25 lever on SMURF or BDB's own SMURF configuration it won't make the historic orbital height in 2.5x). Yes, on the second question as well, since they are used in the Athena, Antares, Minotaur and others and those are very nice low cost to orbit disposable rockets (one half to one third the cost of an LFO rocket with comparable delta V). Basically anyone doing historic builds will be using those solids, doubly so if you are using KCT where construction costs can increase with needing multiple launch pads to launch simultaneous missions due to pad refurbishing, or using BARIS where the incremental changes between the early rockets can really help your finances since test benching and static firing can get expensive when starting a whole new rocket design. That's primarily how I play KSP, running a somewhat realistic space program, and your mod with the upper and lower stage solids allows me to leverage the other mods I use to fully realize that.
  12. @Tiankay Ok I can see your point with the ELT. But if a new one is created, it would be a good idea to split it in two with one tank slotting between the 360/380 and 860/880 and the other being the difference. Pretty much all the common tank sizes (1.25m, 1.875m and 2.5m) all have quite a few options either covered in stock or by this mod. However the 1.5m size is pretty much limited to the Delta parts, something around 500-600 in size would slot in nicely. I assume that quote you posted is from @CobaltWolf? If so, just because it has ribbing doesn't mean it'll always look terrible: I probably should have flipped that small tank above the LTT or put it on the bottom, but as you can see the ribbing doesn't really stick out. I think it depends more on how tight the ribbing is and how wide it actually is. It also helps when you do like I did here and match the ribbing up against another color instead of the same basic white tank texture. Another tank that doesn't look terrible with ribbing being in the middle of the rocket, but again it is bordered by the orange stripe with a darker grey below so it looks more like a transition to the adapter tank than a sore thumb even though the adapter tank doesn't start until the black stripe. Actually that white/light gray line at the joint sticks out more than the ribbing does.
  13. If the tanks are balanced around stock, then wet mass to dry mass ratio shouldn't change no matter how many or what tanks you add unless someone messed up with the dry mass. Obviously service modules aren't going to have the same ratio but just plain fuel tanks with LF/O should all have the same dry mass per tonne of fuel. Personally the only thing we really need is an extension tank to go on the LTTAT that will make up the proper length for the ELTTAT rather than a dedicated tank for ELTTAT. It would also be a bit more fitting for this part pack which tries to maintain a Lego like variety of parts to mix and match how you desire and it would slot right in between the 360/380 and 860/880 tanks giving users another option for the 1.5m class. PS Leave a message when you upload them to KerbalX, I always like to check out real world rockets other people make with these parts and to see how they would compare to ones I build.
  14. Delete the :FOR[SVT] in Kerbin's cfg file, it's overwriting SigDim's changes somehow. So far that seems to work for me. @Galileo Here's some information on this issue, perhaps you can suggest a better fix for now that users could edit into their files until you get a chance to update it (or if you like just suggest how you'd like it fixed and I'll submit a PR on github). Here's my Mod Manager cache with SVT 2.1.4 as installed (I cut out the bit between Material and Ocean to shorten it a bit, no real difference in that section anyways, just to show that something is being overridden since the position of SpaceCenter changes and loses it's rescaling and I believe that is the culprit for this bug): AtmosphereFromGround { outerRadiusMult = 1.028571428575 innerRadiusMult = 0.971527777774318 transformScale = 1.05714285715,1.05714285715,1.05714285715 } } PQS { Mods { SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } } Material ..... Ocean { Mods { SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } } } SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } } And this is what it is with :FOR[SVT] removed from the Kerbin.cfg file: AtmosphereFromGround { outerRadiusMult = 1.028571428575 innerRadiusMult = 0.971527777774318 transformScale = 1.05714285715,1.05714285715,1.05714285715 } } SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds radius = 18750 Resize = 2.5 } PQS { Material As you can see, somehow SVT is overwriting the changes SigDim is making to the radius for the SpaceCenter and likely drawing the textures too low due to that fact. That is literally the only difference I can find so far. This seems to be happening because SVT loads after SigDim, forcing it to load before SigDim resolves the issue. Edit: I think I have a better fix, at least temporarily for this issue. Change all the callbacks from SVT to rSVT in the config folder to maintain loading hierarchy. So, Change @Kopernicus:FOR[SVT] to @Kopernicus:FOR[rSVT] Change @Kopernicus:BEFORE[SVT] to @Kopernicus:BEFORE[rSVT] Change @Kopernicus:AFTER[SVT] to @Kopernicus:AFTER[rSVT] That will let it load before SigDim and then SigDim can modify it correctly.