[1.12.5, and prior] SIMPLEX Resources 1.14

[SkyFall2489]

20 minutes ago, theJesuit said:

You know what?  Yes!   Probably.  It is just the time...

I'm thinking IFI (maintained by LGG), and Snacks are the two to support in this endeavour.  Not MKS as it is quite complicated and was designed specifically with CRP in mind.

Time in front of the computer is quite limited currently, and there are a bunch of updates stacked up.  I also had an idea which I'm bashing out in spare time at work which I'm about to write a development post for.

So, yup?   Maybe sometime over the next month?

If you go for USI-LS without MKS, you could just add in the definitions for Fertilizer, Mulch, and Supplies (or patch USI-LS to use simplex's resources), and change the ISRU patch to use HydrateOre instead of Ore.

[theJesuit]

1 hour ago, SkyFall2489 said:

If you go for USI-LS without MKS, you could just add in the definitions for Fertilizer, Mulch, and Supplies (or patch USI-LS to use simplex's resources), and change the ISRU patch to use HydrateOre instead of Ore.

Any coding suggestions to that effect wod be appreciated.  The issues are also if mks looks for CRP in its own patching.

[SkyFall2489]

27 minutes ago, theJesuit said:

Any coding suggestions to that effect wod be appreciated.  The issues are also if mks looks for CRP in its own patching.

NOT MKS, USI-LS. USI-LS works without MKS in a simplified way, but still works. It needs USI tools as a dependency, but not USI Core.

MKS is an incredibly complex mod that would be very hard to support with such a major change to the game like SIMPLEX Resources.

[theJesuit]

32 minutes ago, SkyFall2489 said:

NOT MKS, USI-LS. USI-LS works without MKS in a simplified way, but still works. It needs USI tools as a dependency, but not USI Core.

MKS is an incredibly complex mod that would be very hard to support with such a major change to the game like SIMPLEX Resources.

Ah.  I understand.

[theJesuit]

Working on some tweaks and rebalancing.  The main tweak is the SMX tiny ISRU.  I'm going to make it a HydrateOre/Saturate to LiquidFuel to balance the Oxidizer only miniISRU so that with SMX you can process the HydrateOre/Saturate to LiquidFuel, in the same technode, but need different drills.

[theJesuit]

Still slowly working on this next update.  I'm adding a couple of fission reactors, inspired by NearFuture Electrical, but NOT requiring NearFuture Electrical.

Using the NCS adapter and CubicOctoStut models and using some rescaling, a 1.25m and 2.5m fission reactor that will produce ~30EC/s and ~180EC/s.  There will be a requirement for heat dissipation, and they will work using a ISRU converter module, with INPUT of NuclearFuel and output of EC and NuclearWaste.

The heavy ISRU will be able to convert RareOre to NuclearFuel.  Not sure yet how I want to deal with NuclearWaste.  Possibly 50% more much power to convert it back?

Both reactors will have high EC storage too.

Simplex Kerbalism will allow these to operate in background in the same way as it does with the NearFuture Electrical.

I'm hoping to make a slight retexture for the NCS adapter model to put a nuclear symbol trefoil on the side to make it look obvious.

[theJesuit]

Updated.

New nuke reactors in place.  Enjoy.

[UltraJohn]

There's a problem with one of your configs. Specifically SIMPLEXResources - CryoTanks.cfg on line 40 contains a misuse of the keyword :FOR

[theJesuit]

Yup.  

5 hours ago, UltraJohn said:

There's a problem with one of your configs. Specifically SIMPLEXResources - CryoTanks.cfg on line 40 contains a misuse of the keyword :FOR

Yup.  When i get a chance I'll sort it. Maybe even this weekend RL permitting

[theJesuit]

On 8/19/2023 at 8:58 AM, UltraJohn said:

There's a problem with one of your configs. Specifically SIMPLEXResources - CryoTanks.cfg on line 40 contains a misuse of the keyword :FOR

Fixed.  Updated!  Thank you!

[JonnyOThan]

Installing SimplexResources, CryoTanks, and Near Future Construction together causes a fatal b9ps error.  The bug is in SIMPLEXResources - CryoTanks.cfg:

// Near Future Construction
// ----
// @leonardfactory: cleanup to remove eventual CryoTanks support from NF Construction
@PART[truss-octo-01,truss-octo-02,truss-hex-01,truss-hex-02]:NEEDS[CryoTanks&NearFutureConstruction]:AFTER[NearFutureConstruction]
{
	!SUBTYPE[LH2Cryo] {}
	!SUBTYPE[LH2OCryo] {}

	// TODO: Add CryoFuel B9PS subtypes since NFC adds them only if CRP is installed.
}

There's a missing @MODULE node there.

 

These patches could probably be more robust if they just targeted any part with a b9ps module that has a subtype that uses cryotanks tank types, right?

Edited January 10 by JonnyOThan

[Bimo1D]

Hi! Here is russian localisation file for ur mod
https://drive.google.com/file/d/194f9Gybwwd0im8ilsSkKZA_TaHZD6FAD/view?usp=sharing

[Shadow Wolf TJC]

I'd also like to mention that, apparently, SimplexResources - CryoTanks B9PS.cfg tries to modify the B9 Tank Type "ht2_02" from HabTech2 with empty brackets, which I have reason to suspect is causing the "ht2_02" tank type to become "undefined", causing a fatal error, which causes KSP to crash.

 

!B9_TANK_TYPE[ht2_02]:NEEDS[HabTech2]		{	}
// Check this NEEDS as it used to be FOR
@PART[ht2_questPod]:FOR[HabTech2]
	{	@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[tankSwitch]]
			{	@SUBTYPE[02]
					{	@name = Air
						@tankType = KSAir
						@title = #simplexresources_air
					}
			}
	}

For the time being, I've commented out the line with the empty brackets, though if any more such fatal errors pop up, then I may have to uninstall this mod.

[Aelfhe1m]

1 hour ago, Shadow Wolf TJC said:

!B9_TANK_TYPE[ht2_02]:NEEDS[HabTech2]		{	}

The exclamation mark at the front of that line tells Module Manager to delete the element it refers to. If there aren't other patches that replace the ht2_02 tank type with something else in part definitions then that would be a problem.

EDIT:

Actually looking at this further I think it might be the following line that is more of a problem. Mods should not be using FOR clauses for other mods. That FOR[HabTech2] should be changed to a NEEDS[HabTech2] or AFTER[HabTech2] (it depends on how HabTech2 itself is configured. 

Edited March 28 by Aelfhe1m

[Shadow Wolf TJC]

12 hours ago, Aelfhe1m said:

The exclamation mark at the front of that line tells Module Manager to delete the element it refers to. If there aren't other patches that replace the ht2_02 tank type with something else in part definitions then that would be a problem.

EDIT:

Actually looking at this further I think it might be the following line that is more of a problem. Mods should not be using FOR clauses for other mods. That FOR[HabTech2] should be changed to a NEEDS[HabTech2] or AFTER[HabTech2] (it depends on how HabTech2 itself is configured. 

Interesting. Thanks for the information about what that line was supposed to do.

I'll consider replacing that FOR with NEEDS or AFTER, and then trying to load the game once more, before having to consider uninstalling the mod.

By the way, I'm only recently starting to learn how to develop mods for KSP, but I don't know where to find an in-depth guide on how to make mod patches like these. Any idea where to look?

[JonnyOThan]

2 hours ago, Shadow Wolf TJC said:

Any idea where to look?

https://github.com/sarbian/ModuleManager/wiki

[Aelfhe1m]

4 hours ago, Shadow Wolf TJC said:

Any idea where to look?

In addition to the official documentation linked by @JonnyOThan, you may also find this thread useful:

 

[Shadow Wolf TJC]

Much appreciated, both of you! @JonnyOThan @Aelfhe1m 

Anyways, I tried making the suggested changes to the code, but it seems I'm still experiencing crashes. However, I'll try one more time, this time commenting out all of the code that makes changes to the HabTech2 mod.

--- B9PartSwitch - Fatal Error ---

Fatal exception while loading fields on module ModuleB9PartSwitch on part
	Exception while loading fields on module ModuleB9PartSwitch on part
	Exception while loading fields on subtype PartSubtype 02
	Exception while loading field tankType on type B9PartSwitch.PartSubtype
	No tank type named 'ht2_02' exists

Please see KSP's log for additional details

The code looked like this at the time:

!B9_TANK_TYPE[ht2_02]:NEEDS[HabTech2]		{	}
// Check this NEEDS as it used to be FOR
@PART[ht2_questPod]:NEEDS[HabTech2]
	{	@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[tankSwitch]]
			{	@SUBTYPE[02]
					{	@name = Air
						@tankType = KSAir
						@title = #simplexresources_air
					}
			}
	}

As you can see, I changed that FOR out for NEEDS, but it still resulted in a crash. Maybe HabTech2 is more dependent on ht2_02 than any of us might've believed?

Edited March 29 by Shadow Wolf TJC
Forgot to add in log messages.

[Aelfhe1m]

@Shadow Wolf TJC There are two parts in the HabTech2 mod that use ht2_02 tanks. The patch you list only fixes one of them. Try this - if I got it right it should fix both (untested):

!B9_TANK_TYPE[ht2_02]:NEEDS[HabTech2]		{	}
// Check this NEEDS as it used to be FOR
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[@SUBTYPE:HAS[#tankType[ht2_02]]]]:NEEDS[HabTech2]
{
	@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[tankSwitch]]
	{
		@SUBTYPE:HAS[#tankType[ht2_02]]
		{
			@name = Air
			@tankType = KSAir
			@title = #simplexresources_air
		}
	}
}

 

[JonnyOThan]

3 minutes ago, Aelfhe1m said:

@Shadow Wolf TJC There are two parts in the HabTech2 mod that use ht2_02 tanks. The patch you list only fixes one of them. Try this - if I got it right it should fix both (untested):

!B9_TANK_TYPE[ht2_02]:NEEDS[HabTech2]		{	}
// Check this NEEDS as it used to be FOR
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[@SUBTYPE:HAS[#tankType[ht2_02]]]]:NEEDS[HabTech2]
{
	@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[tankSwitch]]
	{
		@SUBTYPE:HAS[#tankType[ht2_02]]
		{
			@name = Air
			@tankType = KSAir
			@title = #simplexresources_air
		}
	}
}

 

A few notes: [*] is unnnecessary since you’re filtering by modules.  NEEDS[Habtech2] is unnecessary as well, although it may improve performance when habtech2 isnt installed.  But once patches are cached it won’t matter.  The @MODULE patch should filter on subtypes rather than moduleID.  And finally the inner patches should probably have ,* in case there’s more than one affected module or subtype.

[Shadow Wolf TJC]

Alrighty then! I'll apply these changes, and then tomorrow, I'll go and see if KSP would no longer crash because of this mod. Thank you kindly, @Aelfhe1m and @JonnyOThan.

For now, I'd say good night.-{zzz)

[theJesuit]

Thanks @JonnyOThan, @Aelfhe1m and @Shadow Wolf TJC,

Haven't had time to kerbal this year really so I'm hopefully able to offer a patch soon to include this fix.  

Thank you @Bimo1D for the translation!