The Skyhawk Science System - a new, realistic tech tree for KSP, now including Kerbalism support - [v1.1.1 - "For Science!" 8/11/22)]

[Gupyzer0]

4 hours ago, Shadow Wolf TJC said:

After taking a brief look, it seems like the tech tree doesn't have any new nodes, which is a bit disappointing, at least for me personally.

Nonetheless, I have no real complaints (especially since I have yet to try out Kerbalism myself, since I'm still new to modding for KSP in general). I am curious as to if you have plans to publish your mod on CKAN.

Indeed no new nodes in the tech tree. had some extra nodes in a previous version but decided to keep the SSS ones, just don't have enough time to make a full tech tree from scratch. Currently waiting for BDB upcoming 1.14 update featuring a revamp of the Atlas so I can finally add nodes for "balloon tanks".

CKAN? not right now, I might make a dev post here sometime in the future.

Right now I'm just testing/adding some stuff, it needs polishing and testing.

For example, I made new patches for the Mercury, Gemini, Skylab & Apollo but only have tested Mercury and Gemini and a Skylab mission (including wetlab) with Apollo, haven't done a Mun mission with Apollo or used things like the Lunar Shelter or the S-IV wetlab for Venus (Eve) flyby. Also did some tests with the shuttle here and there . . .

It needs lots of testing/balancing and I'm getting close to that point of posting in the dev section so I can get some help  but I just feel this mod it's not competent enough yet.

BTW I'm also working on a contract pack using RP-1's contracts as a base.  -> https://github.com/Gupyzer0/Spacelines_Progression

[Shadow Wolf TJC]

25 minutes ago, Gupyzer0 said:

BTW I'm also working on a contract pack using RP-1's contracts as a base.  -> https://github.com/Gupyzer0/Spacelines_Progression

Looks interesting.

That also reminds me of a project that I've worked on starting a month or two ago, and while it looks to be in a workable build, I haven't yet bothered to publish it on CKAN (partly due to inexperience with uploading mods, but also partly due to concerns about violating some kind of licensing agreements). The project in question? Trying to adapt the old Planes with Purposes mod for Real Solar System (and potentially other planet packs that replace the stock Kerbol system, and move the Kerbals' homeworld to another planet, such as the Galileo Planets Pack), though due to dissatisfaction with how the mod was structured, I ended up adding a bunch of text meant to help players in designing their aircraft/spacecraft to be, say, more controllable in flight under various conditions (such as at high altitude, or when travelling at high supersonic speeds), and making the contracts easier in some cases (such as allowing for more non-air-breathing engines for spaceplane design) and harder in others (such as requiring players to land back at KSC safely instead of anywhere on the homeworld).

[Shadow Wolf TJC]

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.

[Aelfhe1m]

6 hours ago, Shadow Wolf TJC said:

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.

What's missing is an after patching clean-up to remove the flag before part compilation (the warning in the logs is harmless)

Add:

@PART:HAS[#SSS_Tier[*]]:LAST[zzzSkyhawkScienceSystem]
{
	!SSS_Tier = delete
}

 

[Shadow Wolf TJC]

@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.

[Shadow Wolf TJC]

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.

[Shadow Wolf TJC]

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:

1. 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.
2. 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.
3. 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).
4. 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.

[adriangm44]

I’m having an ick about something and I can’t figure out the rules or the cfg where I may be able to solve it.

Let’s say a random capsule crewed pod: The Apollo Crew Pod, normal 3 seated capacity. Playing with Skyhawk Kerbalism btw. It has automatically all the life support resources needed for kerbals to live inside: Food, Water, Oxygen. I don’t know if it contains anything else by default. There has to be a rule that makes it have all those resources, but I can’t find it.

The reason why I want to find the rule, is so that I can also add the Crew Dragon pod from Tundra Exploration (called Rodan or so). This capsule doesn’t seem to be affected by the rule, as you have to select the resource pack with a b9tankswitch preconfigured option.

If you go and try to pick the “best one” you will find yourself with a “Life support” one, it has Food, Waste, Water & Waste Water.

But no Oxygen, why that call? It makes me mad cause Kerbals can’t survive without oxygen hahahaha. The only way is to add separate tanks, I’m sick of that. I want to add this part to the rules that apply other command crewed modules such as the Apollo Pod.

Any help please?

[Shadow Wolf TJC]

It's been a while since I last posted an update, but I think I'm currently going to be on hiatus for an indefinite period of time, until interest in KSP comes back to me again. However, I did already perform another test with the tech tree, and I have some results:

 

1: Even after updating Skyhawk's stock tech tree patch to account for items found within the Community Tech Tree in addition to the stock tech tree, I was still noticing that some items remained within Community Tech Tree nodes (which I'd assumed were supposed to be cleared out fully, and then deleted). Perhaps some other mods were still trying to add techs to stock and/or Community Tech Tree nodes late in patching?

• Possible solution: Perhaps it's not enough to change tech tree nodes before Module Manager loads the other files? Perhaps an additional round of tech-tree patching, this time around the end of patching, would also be needed?

2: I've also noticed that some mods, such as the Flying Saucers mod, were also adding their own tech nodes.

• Possible solution: These kinds of mods that add in their own tech nodes may need their own mod-specific patches which either move all those techs to one or more of Skyhawk's own tech tree nodes, or alternatively, said tech nodes may instead be kept around, with Skyhawk only changing some of their prerequisites.

3: I've noticed that some mods had scripting that would create duplicates of existing parts that had certain tweaks, such as engines that were burning a different type of fuel, or intakes that, instead of sucking in regular old oxygen (from planets such as Kerbin or Laythe), could only suck in air from certain planets (like Eve or Jool), and were not being moved to more proper tech nodes by Skyhawk, which seemed to rely extensively upon moving individual parts to their proper tech nodes.

• Possible solution: I was already thinking about adding in some further patching that, instead of manually moving individual parts to their proper tech nodes within the Skyhawk tech tree, would've auto-detected parts with specific functions (such as being an engine, a probe, a battery, a fuel tank, etc.), and like with the stock tech tree auto-adjustment patching, would've automatically sorted them to specific tech nodes. However, I also have reason to believe that such a feature would've also possibly worked on these auto-added parts?

 

I don't know when I'll come back to KSP, so I hope that others would be able to try out these kinds of changes on my behalf.