• Content count

  • Joined

  • Last visited

Community Reputation

25 Excellent

About Tonas1997

  • Rank
    Rocketry Enthusiast

Profile Information

  • Location Crying in a corner, complaining about not having enough RAM

Recent Profile Visitors

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

  1. Understandable, I just think it would be cool to have a bit more engine variety (for example, there are 7 Merlin variants and no european ones).
  2. Will you be adding european engines like the Vulcain series and the HMB-7, Aestus and Vinci upper stage engines?
  3. Tonas1997

    [1.4.2] Contract Configurator [v1.25.0] [2018-04-15]

    Ok, this is somewhat of a silly question, but here it goes: I'm playing on a career 1.3.1 save and, obviously, I have Contract Configurator installed alongside every 1.3 compatible contract pack. My issue is that a few contract types seem to lack any contractor, which means EVERY contract of a given type will be offered by the same agency - for example, CleverSat contracts are always offered by the Astronomical Survey Society. Now, I know this isn't exactly a serious issue, but I'd like to change it so that (for example) a typical "put a new satellite in orbit" contract could be offered by any existing agency in the game - including the Squad ones that already do that for the part testing contracts. How can it be done?
  4. Tonas1997

    [1.4.x] TweakScale v2.3.12(Apr-16)

    I already fixed the problem (and by "I" I mean a forum user on the RealFuels thread) by disabling mass scaling on RF's side.
  5. Which version should I use for a 1.3.1 install?
  6. Tonas1997

    [1.3] Real Fuels v12.2.3 July 30

    Yup, that worked perfectly. You sir/lady just made me a very, very happy player. The dry mass of the engine whose mass didn't scale whatsoever still suffers from said bug, but it doesn't bother me much (considering the fuel tanks capacity DOES change with scale).
  7. Tonas1997

    [1.3] Real Fuels v12.2.3 July 30

    Oh my god, that worked! The Atlas (and most other engines) can now be scaled down without reaching negative mass values! There are a few exceptions, however: - Engine clusters still suffer the negative mass bug. I guess it has something to do with those configs using different modules, which aren't affected by your patch. - As predicted, engines that include fuel storage will still be problematic... but in a different way: scaling them won't result in any mass changes whatsoever (forgot to notice if that happened with a full or empty fuel tank).
  8. Tonas1997

    [1.3] Real Fuels v12.2.3 July 30

    As requested, here's the ConfigCache file. The bug happens with, basically, every single engine in the game that uses both mods (there are a few exceptions - namely RCS thrusters from B9). If it helps, here's a folder containing the TS, RF and part configs for an engine which does trigger the bug.
  9. Tonas1997

    [1.3] Real Fuels v12.2.3 July 30

    Thanks for the answer! So I guess the only way to stop the bug from happening would be to disable engine mass adjustment on RF's side whenever Tweakscale is present, right? Or is it more complicated? ...I assume either option would (at least) involve a full recompile of RealFuels.
  10. Tonas1997

    [1.3] Real Fuels v12.2.3 July 30

    Has anyone found a way to fix the incompatibility between Tweakscale and RealFuels? I'm playing on a 1.3.1 save that uses both mods, and downscaling an engine will sometimes cause its mass to become negative; attempting to launch a vehicle with such a part doesn't usually end well (to put it mildly...). This bug is well-known, but I couldn't find a fix yet... Any ideas?
  11. Tonas1997

    [1.4.x] TweakScale v2.3.12(Apr-16)

    Anyone knows if there's a fix for the Tweakscale/RealFuels compatibility problems for 1.3.1? Resizing an engine will, sometimes, change its mass to a negative number, causing the craft to either float on the launchpad or be broken apart. Apparently, it's a well known bug (and there are a few issues on GitHub that mention it), but I haven't found any patches that fix it...
  12. That goes after @PART[*] and before HAS[@MODULE[ModuleEngines*]]:FINAL, right?
  13. Is there a way to exclude a certain part - based on its name - from undergoing a Module Manager patch? Basically, I have a couple of ISP scaling patches that force me to build real-life sized rockets in stock KSP, but one of my part mods (Real Scale Boosters) already does that for its own engines. Which basically means that, as of now, they completely suck, since they are being scaled-down twice. More specifically, I want this config: @PART[*]:HAS[@MODULE[ModuleEngines*]]:FINAL { // @description = This is working @MODULE[ModuleEngines*] { @maxThrust *= 2 @atmosphereCurve { @key,0[1, ] *= 0.4 @key,1[1, ] *= 0.4 @key,2[1, ] *= 0.4 // @key,4[2, ] *= 0.4 } } } to NOT be applied to each and every part beginning with RSB*. Is it possible?
  14. Tonas1997

    [1.4.3] Kopernicus (Release 2) - May 6

    Thanks for the reply, I did as you said and the lightning seems much better now! I still have a couple of questions, so just out of curiosity: 1- What would happen if I set the derivative values of each key in the curves to 0? Would the lightning fade linearly with distance? 2- What's the differece between ScaledIntensityCurve and IntensityCurve? Is the first one related to the map view or something?
  15. Tonas1997

    [1.4.3] Kopernicus (Release 2) - May 6

    Hi, I've been struggling with some configs for my interstellar playthrough, and though about coming by to see if anyone could help me (or point me to the right forum). I'm finishing configuring a modpack on 1.3.1 (Kopernicus 1.3.1-3) which is built around the RSS planet pack, down-sized to the stock scale with - you guessed it - SSRSS. Adicionally, the pack includes the Constellations mod to add some interstellar objectives and extend the lifetime of my playthrough. DISCLAIMER: for some reason, I installed the 1.2.2 version of RSS, but got it working perfectly anyways. So yay! The problems began when I added the Constellations mod. As per its forum thread, the creator took an hiatus and the mod won't be updated to 1.3.1 anytime soon. Like RSS, the mod also runs perfectly fine on a 1.3.1 build... apart from one thing. It was made at a time when Kopernicus used a single value to define star brightness, making far-away systems shine on Earth - and other planets - with the strenght of a thousand fusion bombs. Kinda like this. So, being the smart poodle I am, I decided to reverse-engineer some configs from a 1.3.1-3 compatible planet pack (KSS, by the way) and manually add the curves to the Constellations configs. And that fixed the problem to an extent. The solar system planets no longer receive any significant light from other star systems. But THOSE systems still suffer the "overshine" from the Sun itself (which makes sense, because it is still using a single-value brightness instead of a curve). So, once again, I added the curves to the Sun.cfg located in GameData\RealSolarSystem\RSSKopernicus (which already lacks a large number of properties, for some reason). It went from this: @Kopernicus:FOR[RealSolarSystem] { // Sun Body { name = Sun cacheFile = RealSolarSystem/RSSKopernicus/Cache/Sun.bin Template { name = Sun removeProgressTree = false } Properties { useTheInName = True description = The Sun, a G2V main sequence yellow dwarf. radius = 696342000 gravParameter = 1.32712E+20 ScienceValues { } } ScaledVersion { solarLightColor = 1.0,1.0,1.0,1.0 } } } To this: @Kopernicus:FOR[RealSolarSystem] { // Sun Body { name = Sun cacheFile = RealSolarSystem/RSSKopernicus/Cache/Sun.bin Template { name = Sun removeProgressTree = false } Properties { useTheInName = True description = The Sun, a G2V main sequence yellow dwarf. radius = 696342000 gravParameter = 1.32712E+20 ScienceValues { } } ScaledVersion { Light { sunlightColor = RGBA(255, 255, 255, 255) IntensityCurve { key = 0 1.5 0 0 key = 6799908000 1 0 0 key = 13599810000 0.65 0 0 key = 27199614000 0.5 0 0 key = 108798480000 0.1 0 0 key = 1.7407752E+12 0.05 0 0 key = 2.25E+12 0 0 0 } scaledSunlightColor = RGBA(255, 255, 255, 255) ScaledIntensityCurve { key = 0 1.5 -4.411826E-07 -4.411826E-07 key = 1133318 1 -3.750053E-07 -3.750053E-07 key = 2266635 0.65 -1.470609E-07 -1.470609E-07 key = 4533269 0.5 -1.890783E-08 -1.890783E-08 key = 1.813308E+07 0.1 -8.753626E-10 -8.753626E-10 key = 2.901292E+08 0.05 -9.807578E-10 -9.807578E-10 key = 3.75E+08 0 -2.945654E-09 -2.945654E-09 } IVASunColor = RGBA(255, 255, 255, 255) IVAIntensityCurve { key = 0 1.5 -4.411826E-07 -4.411826E-07 key = 1133318 1 -3.750053E-07 -3.750053E-07 key = 2266635 0.65 -1.470609E-07 -1.470609E-07 key = 4533269 0.5 -1.890783E-08 -1.890783E-08 key = 1.813308E+07 0.1 -8.753626E-10 -8.753626E-10 key = 2.901292E+08 0.05 -9.807578E-10 -9.807578E-10 key = 3.75E+08 0 -2.945654E-09 -2.945654E-09 } sunLensFlareColor = RGBA(255, 255, 255, 255) luminosity = 680.272 sunAU = 123599840256 brightnessCurve { key = 0 0.005 0 13 key = 0.01 0.105 0.5 0.5 key = 1 0.6 0.5 0.25 key = 5 3 0 0 key = 10 3 0 0 key = 50 2 0 0 key = 200 2 0 0 } } } } } Now, extrasolar planets no longer receive any light from the Sun - as intended - but, unfortunely, the solar system's planets suffered the same fate. Even at midday, and with blue skies, the Earth seems to be in a state of perpetual twilight, with barely enough sunlight to cast shadows. Sorry for not having screenshots - will provide some if needed. I assume this can be easily fixed by adjusting the curves on my edited Sun.cfg to achieve the stock brightness values, but I don't know which values I should change. Any ideias?