[v1.0.0] The Skyhawk Science System - a new BDB-focused tech tree

[CessnaSkyhawk]

Just a reminder for anyone who's tried out the tree at all - please consider leaving a comment on the github issue with your thoughts. It'll really help me with developing the last parts of the tree. If you don't like/want to use github, you're welcome to also comment here instead.

EDIT: Wooo fifth page!

Edited December 18, 2021 by CessnaSkyhawk

[RKunze]

On 12/14/2021 at 7:17 AM, CessnaSkyhawk said:

If you’re willing to make a PR [for Modular Launch Pads] I’d be more than happy to take it!

Done.

I also noticed that you pushed back Kerbalism support back to after 1.0, which puts me into a bit of a quandary: I really want to start playing with the new tech tree, but I absolutely do not want to give up Kerbalism. Would you mind if I tried my hand at enough Kerbalism support to get an early game going (up to maybe tech tier 4 or 5)? And could you share a bit about what you have in mind for Kerbalism support so that you maybe can reuse that preliminary work later on? My idea for a first stab at Kerbalism would be to drop the science stuff into the science branch (Duh ) at approximately the same tier where it would go in the Unkerballed Start or Probes Before Crew trees.

[CessnaSkyhawk]

1 hour ago, RKunze said:

Done.

I also noticed that you pushed back Kerbalism support back to after 1.0, which puts me into a bit of a quandary: I really want to start playing with the new tech tree, but I absolutely do not want to give up Kerbalism. Would you mind if I tried my hand at enough Kerbalism support to get an early game going (up to maybe tech tier 4 or 5)? And could you share a bit about what you have in mind for Kerbalism support so that you maybe can reuse that preliminary work later on? My idea for a first stab at Kerbalism would be to drop the science stuff into the science branch (Duh ) at approximately the same tier where it would go in the Unkerballed Start or Probes Before Crew trees.

Alright - thanks for the PR - I'm getting organized to ideally process them sometime today, but we'll see how irl stuff works out. As for Kerbalism, I'm honestly not sure exactly what's going to happen with it right now - it's definitely going to be pretty different from standard Kerbalism in some pretty major ways, but I haven't decided exactly how yet - science experiments in particular will be somewhat different that what you're used to with it. When I say post 1.0, ideally it shouldn't come out too far past whenever 1.0 officially releases. I've just decided that if 1.0 is ready before the Kerbalism portion is finished, I'll release it without waiting, and then add in Kerbalism after. 

[RKunze]

31 minutes ago, CessnaSkyhawk said:

As for Kerbalism, I'm honestly not sure exactly what's going to happen with it right now - it's definitely going to be pretty different from standard Kerbalism in some pretty major ways, but I haven't decided exactly how yet - science experiments in particular will be somewhat different that what you're used to with it.

OK (and looking forward to it).

I'll probably hack up something in the mean time just so I can start playing, but I won't polish it up for a PR then.

[CessnaSkyhawk]

8 minutes ago, RKunze said:

OK (and looking forward to it).

I'll probably hack up something in the mean time just so I can start playing, but I won't polish it up for a PR then.

Alright - I’d recommend checking out hecmac’s KTT Kerbalism patches if you need some inspiration. They’re pretty thorough 

[CessnaSkyhawk]

Got some good news for everyone! I've finished nearly all the issues on my beta checklist, and will be ideally releasing a second beta prerelease sometime in the next day or two. From there, I'll probably let it sit for a week or so to try and catch any last minute things, and then, unless there are any huge upsets or unexpected mishaps, I should have 1.0 out by the end of the year! 

[MoeKitsune]

1 hour ago, CessnaSkyhawk said:

Got some good news for everyone! I've finished nearly all the issues on my beta checklist, and will be ideally releasing a second beta prerelease sometime in the next day or two. From there, I'll probably let it sit for a week or so to try and catch any last minute things, and then, unless there are any huge upsets or unexpected mishaps, I should have 1.0 out by the end of the year! 

Excellent! I'm assuming the last few things are mod support related.

[RKunze]

15 hours ago, CessnaSkyhawk said:

Got some good news for everyone! I've finished nearly all the issues on my beta checklist, and will be ideally releasing a second beta prerelease sometime in the next day or two.

Great news!

I've seen the reaction wheel nerf you put in, it's almost the same as the one I have (had, now, i just removed it after wondering why reaction wheels  suddenly had no torque whatsoever - well that's what happens if you nerf them twice ).

My version does one thing different than yours, though: It doesn't nerf reaction wheels in air breathing engines, because apparently some helicopter engines use ModuleReactionWheel to simulate the cyclic rotor controls (haven't seen one of those yet, though, I just stoleborrowed my reaction wheel nerf from somewhere on the forums).

[Gordon Dry]

I got a similar reaction wheel nerf in my personal zFinal folder:

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.05
		@YawTorque *= 0.05
		@RollTorque *= 0.05
		
		@RESOURCE[ElectricCharge]
		{
			@rate *= 0.5
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel],@MODULE[ModuleCommand]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.2
		@YawTorque *= 0.2
		@RollTorque *= 0.2
		
		@RESOURCE[ElectricCharge]
		{
			@rate *= 0.5
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel]:HAS[@UPGRADES]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@UPGRADES
		{
			@UPGRADE,*:HAS[#PitchTorque]
			{
				@PitchTorque *= 0.05
			}
			@UPGRADE,*:HAS[#YawTorque]
			{
				@YawTorque *= 0.05
			}
			@UPGRADE,*:HAS[#RollTorque]
			{
				@RollTorque *= 0.05
			}
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel]:HAS[@UPGRADES],@MODULE[ModuleCommand]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@UPGRADES
		{
			@UPGRADE,*:HAS[#PitchTorque]
			{
				@PitchTorque *= 0.2
			}
			@UPGRADE,*:HAS[#YawTorque]
			{
				@YawTorque *= 0.2
			}
			@UPGRADE,*:HAS[#RollTorque]
			{
				@RollTorque *= 0.2
			}
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel],#mass[>1]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= #$/mass$
		@YawTorque *= #$/mass$
		@RollTorque *= #$/mass$
		
		@RESOURCE[ElectricCharge]
		{
			@rate *= #$/mass$
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel]:HAS[@UPGRADES],#mass[>1]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels,!UnmannedTech]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		@UPGRADES
		{
			@UPGRADE,*:HAS[#PitchTorque]
			{
				@PitchTorque *= #$/mass$
			}
			@UPGRADE,*:HAS[#YawTorque]
			{
				@YawTorque *= #$/mass$
			}
			@UPGRADE,*:HAS[#RollTorque]
			{
				@RollTorque *= #$/mass$
			}
		}
	}
}

You even could make it subject of a tier upgrade in one or two more tiers for a slightly less EC/s in the first and a slightly more torque in the 2nd upgrade.

[Kwebib]

@CessnaSkyhawk found a typo in your SAS upgrades patch. SASServiceLevel should be set to 1 in this upgrade, right?

UPGRADE
{
	name__ = sss_SAS1
	techRequired__ = control3
	SASServiceLevel = 0
	moduleIsEnabled = true
}

 

[CessnaSkyhawk]

2 hours ago, Kwebib said:

@CessnaSkyhawk found a typo in your SAS upgrades patch. SASServiceLevel should be set to 1 in this upgrade, right?

UPGRADE
{
	name__ = sss_SAS1
	techRequired__ = control3
	SASServiceLevel = 0
	moduleIsEnabled = true
}

 

Nah, that's intentional. There's four levels of SAS. 0 is just standard SAS, 1 is prograde and retrograde, 2 is radial and normal, and 3 is maneuver + target tracking. I only wanted to have three steps in my upgrades (basic sas, prograde/retrograde/radial/normal, and maneuver/targets) so in order to do that, I just skip 1.

[CessnaSkyhawk]

Hey guys! Sorry for the lack of activity these past few days. My holiday season has been a bit hectic, and I've also been side-tracked by another interesting KSP projects that I might be looking into in the new year, but I haven't forgotten about SSS. Expect some big news from me with the next couple of days about it! 

[RKunze]

@CessnaSkyhawkI have a possible balance issue with the two probe cores in the starting node, but I'm not quite sure if I should report it in the balancing issue on github because a) it's with my hacked-up Kerbalism testing support and b) it may have been intended.

My main issue is that the integrated science antenna on the sss_SoundingRocketCore is extremely weak: Its maximum bitrate ends up at 127 B/s with Kerbalism, and the first (and only) experiment at the starting node - the telemetry report - produces 750 KB of data. Transmitting this would take roughly 1.5 hours, and flight time for the first flight is only a couple of minutes with a hard crash at the end and no chance whatsoever of recovery (because no chutes in the start node). That means you can only get less than 1% of the science per flight with the sss_SoundingRocketCore, making it essentially useless (and slapping on  a SurfAntenna aka "Communotron 16" does not help either because the antennas are not combineable).

And the other starting choice - the  restock-drone-core-0625-1 - could in principle support getting an in-flight telemetry report (the SurfAntenna has a data rate of 2.2KB max which is just about enough to transmit one telemetry report on the first flight), but it runs out of electricity about halfway through the transmission...

If you intended the first choice in the game to be between a therotically excellent first probe core (the 100 units of EC alone make it worth while well beyond the first couple of flights) with abysmal comms which renders it almost completely useless, and a more expensive but weaker core with a working comms option but not enough electricity, then you are really evil (and I salute you for it ). If not, I'd recommend to either rebalance the data rate of the sss_SoundingRocketCore internal antenna to something around 1.5 - to 2 KB/s (making it weaker than but comparable to the SurfAntenna, and still needing two or three flights to get a full telemetry report back with either choice), or dropping it altogether from the probe core and just require an external antenna on the first craft in order to transmit science data (but this would make the sss_SoundingRocketCore a bit overpowered IMO at 100 EC combined with the 2.2KB/s transmission rate from the SurfAntenna).

And as a side note, I think the reaction wheels should be dropped from both cores at the start node because at least in my opinion, reaction wheels feel rather too advanced for the starting node in your tree (maybe put them back in one or two nodes down the flight control path as an upgrade?)

Edited December 26, 2021 by RKunze

[CessnaSkyhawk]

Big News Everyone!

Skyhawk Science System V1.0.0 - "Cleared for Takeoff" is OUT!

Thread

THANK YOU SO MUCH to everyone who helped me in the development of the mod. I never would have finished this if it wasn't for your support!  Here's to a successful release!

 

 

59 minutes ago, RKunze said:

@CessnaSkyhawkI have a possible balance issue with the two probe cores in the starting node, but I'm not quite sure if I should report it in the balancing issue on github because a) it's with my hacked-up Kerbalism testing support and b) it may have been intended.

My main issue is that the integrated science antenna on the sss_SoundingRocketCore is extremely weak: Its maximum bitrate ends up at 127 B/s with Kerbalism, and the first (and only) experiment at the starting node - the telemetry report - produces 750 KB of data. Transmitting this would take roughly 1.5 hours, and flight time for the first flight is only a couple of minutes with a hard crash at the end and no chance whatsoever of recovery (because no chutes in the start node). That means you can only get less than 1% of the science per flight with the sss_SoundingRocketCore, making it essentially useless (and slapping on  a SurfAntenna aka "Communotron 16" does not help either because the antennas are not combineable).

And the other starting choice - the  restock-drone-core-0625-1 - could in principle support getting an in-flight telemetry report (the SurfAntenna has a data rate of 2.2KB max which is just about enough to transmit one telemetry report on the first flight), but it runs out of electricity about halfway through the transmission...

If you intended the first choice in the game to be between a therotically excellent first probe core (the 100 units of EC alone make it worth while well beyond the first couple of flights) with abysmal comms which renders it almost completely useless, and a more expensive but weaker core with a working comms option but not enough electricity, then you are really evil (and I salute you for it ). If not, I'd recommend to either rebalance the data rate of the sss_SoundingRocketCore internal antenna to something around 1.5 - to 2 KB/s (making it weaker than but comparable to the SurfAntenna, and still needing two or three flights to get a full telemetry report back with either choice), or dropping it altogether from the probe core and just require an external antenna on the first craft in order to transmit science data (but this would make the sss_SoundingRocketCore a bit overpowered IMO at 100 EC combined with the 2.2KB/s transmission rate from the SurfAntenna).

And as a side note, I think the reaction wheels should be dropped from both cores at the start node because at least in my opinion, reaction wheels feel rather too advanced for the starting node in your tree (maybe put them back in one or two nodes down the flight control path as an upgrade?)

When I originally made the part, I kinda forgot to consider the effects it would have on Kerbalism . It was basically designed to be able to transmit the telemetry report in stock, and only that... What I'm currently leaning towards is that when I do the official rebalance, I'll probably have two seperate cores - a heavy one with a built-in chute and lots of power, and a light one with a bit less power but a transmitter, and I'll try and balance the experiments around them better so its a lot more sensical!

[RKunze]

37 minutes ago, CessnaSkyhawk said:

I'll probably have two seperate cores - a heavy one with a built-in chute and lots of power, and a light one with a bit less power but a transmitter, and I'll try and balance the experiments around them better so its a lot more sensical!

Sounds very good.

Speaking of Kerbalism, from browsing around the early tree I got the impression that the "Configurable Unmanned Experiments" that Kerbalism puts on all probe cores by default don't really go well with the specialized cores from BDB. And I rather like the idea idea of having to use different purpose-built  probe cores for different experiments/missions especially early in the game instead of just using one (or at most a few) fully reconfigurable standard parts as the core for almost all probes (those highly reconfigurable probe cores always remind me a bit of real live, standardized cubesats - and we did get those only in the last couple of years).

What do you think of removing the general purpose "Configurable Unmanned Experiments" from the specialized DBD probes and only keep a Kerbalismerized (is that even a word?) version of the original BDB experiment(s) on those cores, and keep the Kerbalism "configurable experiments" only on the the more generic stock probes (maybe shift them to later in the tree as well)? 

[Morphisor]

A little question about the reaction wheel nerf: how does it interact with Mandatory RCS if both are installed?

Edited December 27, 2021 by Morphisor

[RKunze]

2 hours ago, Morphisor said:

A little question about the reaction wheel nerf: how does it interact with Mandatory RCS if both are installed?

I'm not 100% sure (I don't use MandatoryRCS), but according to the MandatoryRCS sources, it will "double-nerf" the reaction wheels and you'll end up with 0.0005 to 0.001 times the original torque (depending on the MandatoryRCS settings).

Support should be easy though, simply don't apply the reaction wheel nerf when MandatoryRCS is installed.

If you have Mandatory RCS, can you try out replacing GameData/SkyhawkScienceSystem/Patches/Control/ReactionWheelNerf.cfg with the code below and report back if it works?

@PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeAtm]]]:NEEDS[!MandatoryRCS]:AFTER[zzzSkyhawkScienceSystem] {
	@MODULE[ModuleReactionWheel] {
		@PitchTorque *= 0.01
		@RollTorque *= 0.01
		@YawTorque *= 0.01
	}
}

 

[Morphisor]

20 minutes ago, RKunze said:

I'm not 100% sure (I don't use MandatoryRCS), but according to the MandatoryRCS sources, it will "double-nerf" the reaction wheels and you'll end up with 0.0005 to 0.001 times the original torque (depending on the MandatoryRCS settings).

Support should be easy though, simply don't apply the reaction wheel nerf when MandatoryRCS is installed.

If you have Mandatory RCS, can you try out replacing GameData/SkyhawkScienceSystem/Patches/Control/ReactionWheelNerf.cfg with the code below and report back if it works?

@PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeAtm]]]:NEEDS[!MandatoryRCS]:AFTER[zzzSkyhawkScienceSystem] {
	@MODULE[ModuleReactionWheel] {
		@PitchTorque *= 0.01
		@RollTorque *= 0.01
		@YawTorque *= 0.01
	}
}

 

Yeah I expected exactly that sort of thing after having a quick look at the SSS patch. Thanks for working that out, patch looks good.

I guess my point here would rather be, why should SSS include such a patch for something that's already done effectively by another mod? 

At the same time I'd suggest the 'realish fuels' renaming and boiloff patches to be made optional by default. It's easy enough to remove them from an install, but for the average user I'm not sure it will help.

To me, those kinds of patches are not necessary for the actual tree, but should be optional extras for those who'd prefer a more realistic flavour to the whole thing.

[RKunze]

24 minutes ago, Morphisor said:

I guess my point here would rather be, why should SSS include such a patch for something that's already done effectively by another mod? 

I guess for the same reasons why I did my own reaction wheel nerf instead of using MandatoryRCS: MandatoryRCS has some logic to only nerf the reaction wheels in some situations, but leave them on full torque e.g. in SAS stability mode and when the vessel is nearly at the target orientation. I even understand why it does that (to help with station keeping), but it feels like weird magic nonetheless.

24 minutes ago, Morphisor said:

To me, those kinds of patches are not necessary for the actual tree, but should be optional extras for those who'd prefer a more realistic flavour to the whole thing.

Not sure here. As I see it, the whole tree is about a "more realistic flavour",...

Edited December 27, 2021 by RKunze

[CessnaSkyhawk]

All right - the Mandatory RCS issue should be fixed now. I had forgotten to account for it, as last I had heard it was having some funky glitches and I figured it wasn't working anymore. I have unsurprisingly not actually played very much KSP in a while, so I guess I was wrong... Thanks for the PR @RKunze

4 hours ago, Morphisor said:

At the same time I'd suggest the 'realish fuels' renaming and boiloff patches to be made optional by default. It's easy enough to remove them from an install, but for the average user I'm not sure it will help.

To me, those kinds of patches are not necessary for the actual tree, but should be optional extras for those who'd prefer a more realistic flavour to the whole thing.

4 hours ago, RKunze said:

Not sure here. As I see it, the whole tree is about a "more realistic flavour",...

I keep them on by default as they are in my opinion important to the overall point of the tree - the boiloff means there's an actual difference between hypergolics and kerolox, and the realish names just helps set the flavor imo. What I will do is make an FAQ on the main post, and as part of it, list how to disable both those patches.

16 hours ago, RKunze said:

Sounds very good.

Speaking of Kerbalism, from browsing around the early tree I got the impression that the "Configurable Unmanned Experiments" that Kerbalism puts on all probe cores by default don't really go well with the specialized cores from BDB. And I rather like the idea idea of having to use different purpose-built  probe cores for different experiments/missions especially early in the game instead of just using one (or at most a few) fully reconfigurable standard parts as the core for almost all probes (those highly reconfigurable probe cores always remind me a bit of real live, standardized cubesats - and we did get those only in the last couple of years).

What do you think of removing the general purpose "Configurable Unmanned Experiments" from the specialized DBD probes and only keep a Kerbalismerized (is that even a word?) version of the original BDB experiment(s) on those cores, and keep the Kerbalism "configurable experiments" only on the the more generic stock probes (maybe shift them to later in the tree as well)? 

Yeah, it definitely doesn't sit right with me, and also the overall intention of SSS trying to encourage people to try and use a larger variety of parts. I'm going to change stuff up one way or another.

And with that, I think I'm gonna close this thread just to keep all the discussion a bit more organized. If y'all want to follow up, could u do so in the main thread? I'm going to see about having this locked so that all the feedback is in one place.

 

[Gargamel]

Closed by request.