Jump to content

Shadow Wolf TJC

Members
  • Posts

    52
  • Joined

  • Last visited

Reputation

13 Good

Recent Profile Visitors

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

  1. IMO, being able to land ANYWHERE on the homeworld safely instead of back at the KSC would've gone against the spirit of this mod's focus on reusable spaceplanes by making these missions little different from the stock game missions, where a traditional rocket design would've likewise sufficed, with a command pod that would've been designed to be jettisoned and land back into the water or on the surface without any form of guidance. It was for these reasons why I opted to modify those missions, plus the interplanetary missions, with objectives to land the command vehicle back at the KSC safe and sound, either as a spaceplane or as a SpaceX-styled tailsitting lander.
  2. While looking at StockScienceSupport.cfg to get a feel for how I'm going to tackle the Community Tech Tree's integration, I realized that the whole thing was, besides being organized based on tier and a top-to-bottom order on the stock tech tree, a largely disorganized mess. (I would've rather preferred to order everything based on category, such as construction, communications, or probes for example.) In addition to integrating the Community Tech Tree with Skyhawk Science System in a way that made as much sense as possible, I also ended up basically restructuring the Stock Tech Tree integration in a way so as to accomplish the following goals: So that the early half of the tech tree, up to around tier 8 or 9, would be almost guaranteed to contain at least 1 part from stock KSP + expansions, mostly by spacing out the techs better, while the latter half would've been better serviced by integrating the Community Tech Tree within it. So that the tech tree would be better capable of handling whichever new parts modders add, that would require either the Stock Tech Tree, or the more expanded Community Tech Tree, namely by rearranging it based on best guesses as to which tech nodes modders would most likely want to add their parts in order for them to be balanced in both Science and Career modes. So that the tech tree could be further refined in a later round of patching to better sort categories of parts into their designated tech tree branches (such as moving solar panels, radiators, communicators/relays, and probes from, say, the electrical tech tree branch, into their respective tech tree branches). So that Skyhawk Science System wouldn't need to be as dependent on Bluedog Design Bureau as it is claimed to be (according to CKAN), and could instead opt to mark BDB as a strong recommendation instead of as a dependency. Although this revised tech tree is just a rough draft for now (with oodles of comments thrown in), and although it's been designed to expect a later round of patching to better sort parts into their proper tech tree branches (which I'll need to figure out a way to accomplish said feat), I've decided to give everyone a sneak peek of it by letting them download it from here.
  3. Those few snippets may not have been of apparent help to you, but to me personally, they were enough for me to find out WHERE the problem was located. Nowhere in my hundreds-of-MB-sized .log file (admittedly due to stress-testing my KSP game by having so many mods installed, though regardless, since you had taken too long to come up with a reply, that .log file was, alas, most likely overwritten in a later session) would I necessarily know WHAT the problem was specifically, let alone HOW to fix said problem. All I had learned was WHERE the problem originated from, and like the eager programmer that I was (though admittedly, I'm new to KSP modding, though not to modding in general), I had gone out to do the following: According to those snippets that I had provided from my .log file, I immediately realized that it was a problem with one of the contracts, so I checked to see which mod had any contracts named "KerbinOrbitalTelescopeDeployment" and "MunOrbitalTelescopeDeployment", and I quickly found that both originated from within this mod here, within the file directory "MunSeeker/ZZZ_RadioTelescope/MunSeeker_ZZZ_RadioTelescope_Contracts.cfg" to be more specific. Once I had found out where the problematic contracts were located, I did a bit of routine digging, with the variables "targetBody" and "Orbit" as my leads, and soon enough, I noticed that targetBody was set to either "Kerbin" or "Mun", both of which would've obviously ceased to exist if using a system replacer mod like RSS. (Note that I was also dealing with other contract mods that were bugging out at the same time, including Planes with Purposes, Oddiseo Corp Contracts, and Research Bodies, and as it turns out, they too weren't designed to deal with stock system replacement mods either.) For RSS, I had initially opted to simply replace any instances of "Kerbin" with "Earth", and any instances of "Mun" with "Moon", though that was meant only as a temporary solution until I could figure out a way to replace those via patching. However, I had later discovered that, if "HomeWorld()" was used in place of "Kerbin", and if "HomeWorld().Children().First()" was used in place of "Mun" (thank you History of Spaceflight for providing me with examples of contracts that would work, even when using a system replacer mod), then perhaps even those patches wouldn't have been as necessary. In short, I recommend the following changes to "MunSeeker_ZZZ_RadioTelescope_Contracts.cfg": Replace any instances of "Kerbin" with "HomeWorld()", and any instances of "Mun" with "HomeWorld().Children().First()", except within descriptions If you wish to dynamically reference Kerbin, Mun, or any other celestial body within in-game text descriptions, regardless of which solar system the player is starting out on, then what you could do is, instead, replace any instances of "Kerbin" and "Mun" with "@/targetBody". Though I've probably lost the .log file, I've instead decided to provide a modified version of "MunSeeker_ZZZ_RadioTelescope_Contracts.cfg", which can be downloaded here.
  4. Well, I finally took a look at the tech tree with Skyhawk Science System installed, along with multiple other mods, including the following: KSP Interstellar Extended Blueshift ESLD Jump Beacons Stockalike Station Parts Expansion Redux Far Future Technologies Flying Saucers Cryogenic Engines Cryo Tanks CryoEngines Extensions HabTech2 TAC Life Support Rusty Star Rockets Sandcastle Near Future Solar, Propulsion, and Electrical Nehemiah Engineering Orbital Science AtomicTech Inc. Junkyards Kerbal Atomics Pathfinder Kerbal Planetary Base Systems USI Kolonization Systems Airships Photon Sailor Silly Photon Drives Firespitter Keridian Dynamics SCANsat Procedural Parts Procedural Fairings Modular Rocket Systems Tweakscale Unlimited And many more... Most notably, Bluedog Design Bureau, the mod that was claimed to be a dependency of Skyhawk Science System, was not among any of the mods that were installed. Guess what happened? Although a handful of early tech tree nodes were empty (which could be automatically removed if using the Hide Empty Tech Tree Nodes mod), the Skyhawk tech tree seemed perfectly fine without Bluedog Design Bureau installed, as I had expected. Thanks to StockScienceSupport.cfg, Skyhawk Science System was already doing a good job at reassigning the stock KSP's parts' tech requirements, along with numerous other parts that likewise depended upon the stock tech tree, including the procedural parts mods, plus the Cryogenic Engines and Cryo Tanks mods, which Skyhawk Science System included specific mod support for. Nonetheless, there were some issues encountered regarding the tech tree, particularly when it comes to dealing with mods that are either dependent on the Community Tech Tree mod (such as KSP Interstellar Expanded) and/or make their own changes to the stock tech tree (such as Flying Saucers). For starters, I'm disappointed that Skyhawk Science System never bothered to include support for the Community Tech Tree mod, not even something basic like it had for the stock tech tree. That kind of basic support would've likely saved the developers a bunch of work needing to add support to certain mods, like KSP Interstellar Expanded (not to mention that it would've likely made a bunch of specific mod patches that Skyhawk Science System redundant). I'm currently working on a few fixes regarding compatability with the Community Tech Tree mod, and by extension, any mods that would require it as a dependency (especially KSP Interstellar Extended). Hopefully, they'll be ready for upload.
  5. @Aelfhe1m Oh? So there's no need to keep that variable around after KSP has been successfully loaded? Alrighty then. I'll also add in the cleanup code.
  6. Small update: I've been taking a bit of a break in-between KSP playtesting sessions installing a bunch of mods, getting crashes to desktop, uninstalling said mods until the game could load again, and watching YouTube videos in the meantime, but I think I've figured out what was causing these kinds of errors to keep popping up within my .log files: [WRN 04:37:28.696] PartLoader Warning: Variable SSS_Tier not found in Part As it turns out, it stems from the Skyhawk Science System mod, and I suspect that it's due to a lack of a failsafe within ScienceTiers.cfg. To remedy this, I've opted to add such a failsafe of my own: @PART[*]:FIRST[zzzSkyhawkScienceSystem] { %SSS_Tier = 0 } Afterwards, I've opted to replace any instances of this below the failsafe: %SSS_Tier with this: @SSS_Tier so that SSS_Tier values could be overridden as needed. I hope to do more testing later on to see if these changes would work as intended.
  7. Besides myself, I'm sure plenty of others would've been eager to see something like that. Oh, and speaking of system replacers, I've been thinking about how one might successfully develop a mod that would've restored the Kerbolar System to its vanilla glory, even with other system replacement mods like Galileo's Planet Pack present. For now, here's what I believe one would've needed to consider: This mod would've likely needed to have been loaded after all of the other system replacement mods had been loaded, yet ideally, would've also been loaded before such mods that would've made various changes or additions to the stock Kerbolar System as, say, E.V.E., Scatterer, various mods that require Kerbal Konstructs (such as Launch Sites Appended or Kerbin Side Remastered), any universe-wide rescale mods designed to resize the stock Kerbolar System, plus other modded celestial bodies (such as any of these old configs for the old Sigma Dimensions mod), or such planet packs as OPM, MPE, QuackPack, Sentar Expansion, or Revamped Eeloo to name a few. The option to make Kerbin the home world once more instead of whichever planet is supposed to replace the home world. Perhaps the Kerbolar System would've been made to revolve around either whichever star system would've replaced it, or around a supermassive black hole, which other community-developed star systems, including the ones from the system replacer mods, would've also been made to revolve around, in order to serve as the center of a galaxy or star cluster? (Then again, perhaps both options could've been made possible, with, say, the former option being the default option due to how simpler it would've been to design, whereas the latter option would've been better suited towards a more ambitious project, that would've used patching to build upon former option?) Although I believe the first three design considerations should've likely been enough for many (if not the majority) of the system replacer mods out there, it might not necessarily work as smoothly when dealing with system replacers that change the whole Kerbolar System whilst keeping all of the original names, such as JNSQ for example. Under such circumstances would mod-specific patches be needed to be able to keep those modded stock-planet-alternatives along with the stock planets themselves, such as renaming these modded planets to, say, their original names backwards (such as, say, "Nibrek" in place of "Kerbin" for example), or adding a tag next to their name (such as, say, "JNSQ's Kerbin" for example). That's all that I can think of at the moment for designing such a mod that would've addressed this bothersome common trend of modders designing their own planet packs to replace the stock Kerbolar System, making all of these system replacer mods mutually-exclusive as a result of such sloppy quick-and-dirty and/or self-centered mod design practices. (Personally, I'm surprised to find that such a mod hadn't been made as of yet.)
  8. @rrty44 Could you specify what kind of radiation needs to be researched exactly? Otherwise, you'll just have to make do with some mod suggestions based on certain assumptions that I'll be making. For example, I'm aware that both Bluedog Design Bureau and FASA add Geiger Counters that can be used to gather science, much like thermometers, barometers, or crew reports. However, if you want to broaden your radiation scans to include not only harmful ionizing radiation (like alpha, beta, and gamma radiation), but also spectral radiation, like infrared, ultraviolet, x-ray, and radio waves for example, then in addition to BDB having you covered once again, I'd also suggest taking a look at Tantares. Oh, but if you're just looking for science experiment data files for other mods to use, then I'd recommend checking out Skyhawk Science System. (Oh, but CKAN lists BDB as a dependency for Skyhawk Science System, perhaps even an unwarranted, unnecessary dependency that, IMO, should've been listed as a recommendation instead.) Oh, and if you find BDB, FASA, Tantares, or any other parts mods to be too big for your liking (especially BDB, which is over 2 GB in size), then ask yourself this: Who's there to stop you from surgically pruning your downloaded mods of unwanted parts? (BDB was apparently designed to have folders full of parts pruned if the mod is too big for your needs. Personally, I'd only want to keep the science experiments, probes (which come with science experiments on them), and engines, and discard the rest.)
  9. @Jcklemme After some further digging on CKAN, I've spotted a few extra mods that you might also want to take a look at: Birth of Time Planet Pack (Non-Homeworld-Switching Config) Ethereal Frigus: A Planet Between Duna and Dres ExtraKerbin Moons FOMALHAUT Gene's Star Remaster (Possibly Outdated?) Heracleitus Jeb Far Away Kerbal Galaxy Revamped (Quite Possibly Outdated!) Kerbol's Humble Neighbouring Stars Kronkus Magica and Hornet Planet Pack Mirrotist System Muniant Neidon Plus Oberon: Moon of Jool Revamped Eeloo: New Moons and Atmosphere Sentar Expansion (Very Old, but Not Necessarily Outdated) Starlight Systems Pack Strange New Worlds The Third Mun The Vulture System Titania: A New Moon for Kerbin Trent: Moon of Eeloo Valor Planet Pack Revived Veen: Moon of Eve Xamion: A Planet Far Beyond Eeloo Xen's Planet Collection Revived Hopefully, none of these would conflict (too much) with anything else within your long list of mods that add to the stock Kerbolar System (or the stock system itself). I'll also throw in an extra mod, though I have my doubts about its compatability: Linbol System Rebirth Oh, and I've just lodged a stern complaint against the development team behind GEP to finally add support for the latest version of Scatterer (or at least delist it as a conflicting mod on CKAN). It's been long overdue that that antiquated planet pack do some work to remain relevant alongside later-developed, yet more finely-designed, mods like Kcalbeloh. Oh, and besides, when manually installed outside of CKAN, it looks like GEP would've worked alright with the latest updated versions of Scatterer anyways, as hinted at within this post.
  10. I'm getting awfully tired of having to choose between this old classic of a mod or a bunch of other mods that work with the latest versions of Scatterer. Therefore, I humbly sternly, with great concern for this mod's future, request demand insist that this mod finally update its planets to be able to work with the latest versions of Scatterer (even if it might involve porting over older Scatterer functionality to the mod itself for use on its own planets only), including on CKAN (which still lists modern versions of Scatterer as a conflicting mod), or else I fear that this mod would have to be passed up (that, or I'd have to request a patch that would make it compatable with the latest versions of Scatterer).
  11. @Jcklemme Quite the impressive selection! I'm hard-pressed to recommend any additional planet packs to complement all of the others here. Perhaps Corelian, Dreskiller Base, and Grannus Expansion Pack could all be considered?
  12. Correction: Not necessarily all interstellar system mods are fully compatable with mods like OPM, MPE, or QuackPack, especially when they force the Kerbol system to orbit another celestial body, which takes the star of Kerbol's place as the "Sun" in the data files. @MYKori_Rosales Like I've stated before, be on the lookout for any mods that would also force the Kerbolar System to orbit any other celestial body (such as a supermassive black hole, like the one featured within the Kcalbeloh mod), ESPECIALLY when they do so by making another celestial body (usually within the mod, such as the titular black hole named Kcalbeloh) take the Kerbolar System's sun's place in the data file, and may or may not bother adding a custom star named Kerbol in order to move the vanilla KSP planets (plus some other supported mods' planets, such as from the Outer Planets Mod in Kcalbeloh's case) in orbit around this new star. If you notice that some celestial bodies that were supposed to be orbiting within the Kerbolar System (whether it's vanilla planets like Kerbin, Eve, Duna, or Jool, OPM planets like Sarnus, Urlum, or Neidon, QuackPack planets like Blas, Jot, or Cind, or MPE planetoids like Crokslev, Edas, Ervo, Geito, Havous, LintMikey, Mracksis, Soden, Vant, or Zore) are not orbiting within the Kerbolar system, and you notice that the star of Kerbol is orbiting something else, then chances are that at least one of your interstellar planet packs (such as Kcalbeloh, the Event Horizon Planet Pack, or some other mod(s) that add(s) 1 or more new star systems (especially supermassive black holes) to explore alongside the Kerbolar System) might be at fault for unwarranted messing with the structure of the Kerbolar system.
  13. I don't know how to upload to GitHub, so I hope that uploading the mod here instead would be acceptable.
  14. A bit of a forewarning: As of now, the mod doesn't seem to be compatable with any mods that replace the stock Kerbolar system, such as Galileo Planets Pack or Real Solar System. To remedy this, for starters, I'd recommend replacing any instances of "Kerbin" with "HomeWorld()" (and also find ways to replace the other planetary bodies, such as the Mun and Duna, in an adaptable way), so that the contract configurator mod can auto-detect where the homeworld is located (along with other nearby challenge-appropriate worlds). If you'd like, I could try uploading my mod changes onto the cloud for others to download and see for themselves (especially if they have Real Solar System installed).
  15. A bit of a forewarning: As of now, the mod doesn't seem to be compatable with any mods that replace the stock Kerbolar system, such as Galileo Planets Pack or Real Solar System. To remedy this, for starters, I'd recommend replacing any instances of "Kerbin" with "HomeWorld()" (and also find ways to replace the other planetary bodies, such as the Mun and Duna, in an adaptable way), so that the contract configurator mod can auto-detect where the homeworld is located (along with other nearby challenge-appropriate worlds). If you'd like, I could try uploading my mod changes onto the cloud for others to download and see for themselves (especially if they have Real Solar System installed).
×
×
  • Create New...