[1.12.x] Near Future Technologies (September 6)

[Jognt]

On 8/16/2020 at 6:34 PM, R-T-B said:

Just FYI, I got some helpful help with the above syntax, and it is now generalized in case Nertea needs to add more modes to b9partswitch or something.

Final result that will ship with Kopernicus:

@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
    // This cfg will enable KopernicusSolarPanels
    // to allow support for multiple lightsources
    // 
    // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node
    // That will stop Kopernicus from changing the behaviour of SolarPanels
    @useKopernicusSolarPanels,* ^= :F:f:
    @useKopernicusSolarPanels,* ^= :A:a:
    @useKopernicusSolarPanels,* ^= :L:l:
    @useKopernicusSolarPanels,* ^= :S:s:
    @useKopernicusSolarPanels,* ^= :E:e:
}

@PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL
{
	// Hijack the first ModuleDeployableSolarPanel
    @MODULE[ModuleDeployableSolarPanel]
    {
        @name = KopernicusSolarPanels
    }
}

//B9PartSwitch support
@PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleB9PartSwitch]
    {
        @SUBTYPE,*
        {
            @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]]
            {
				@IDENTIFIER[ModuleDeployableSolarPanel]
				{
					@name = KopernicusSolarPanels
				}
            }
        }
    }
} 

Thus, to turn off panels, one need only have a cfg like follows:

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]
{
    %useKopernicusSolarPanels = false
}

That is all.  Thanks for helping me learn the in's and out's of KSP's MM syntax.

I’d replace :FINAL with :LAST[Kopernicus] to honor the “Please don’t use FINAL in distributions.” request. (LAST is effectively the same but allows for modifying modifications down the road.)

On 8/16/2020 at 7:09 PM, TranceaddicT said:

See, caaaafffffffiiiiiiinnnne.

I operate from the position that :FINAL is a conditional best left solely for the end-user unless absolutely necessary (see TweakScale).  If a mod is going to host a MM patch, it should be via :NEEDS.

You're absolutely right. I shouldn't have said JNSQ.  (That's just my current focus.)

I believe it should be :NEEDS[Kopernicus].

Pass specifiers like FIRST/BEFORE/FOR/AFTER/LAST/FINAL are separate from conditional specifiers like NEEDS. Though AFTER functions like a NEEDS too. 

There is no reason to ship a mod with a patch that has NEEDS[thisMod] because it’ll always be true. NEEDS is for patches distributed in a way where it is uncertain if the conditional mod is present. 

[R-T-B]

2 hours ago, Jognt said:

I’d replace :FINAL with :LAST[Kopernicus] to honor the “Please don’t use FINAL in distributions.” request. (LAST is effectively the same but allows for modifying modifications down the road.)

We've discussed that internally and decided that since those lines are only there to enforce the behavior of the solar panel disabling parameter, to leave it alone (it was done originally by the Kopernicus devs who came before us, actually).

Any modification to that property would lead to undefined behavior anyways, is my logic.  Or am I misunderstanding?  Since this is the second time that was suggested, I am open to changing it to a :LAST in next release.  I'd just need good reasoning to do so, and I'm listening.

Edited August 21, 2020 by R-T-B

[Lisias]

4 hours ago, R-T-B said:

Any modification to that property would lead to undefined behavior anyways, is my logic.  Or am I misunderstanding?  Since this is the second time that was suggested, I am open to changing it to a :LAST in next release.  I'd just need good reasoning to do so, and I'm listening.

We are facing a dilemma between what should be done, and what must be done.

Ideally, :FINAL should be reserved to end-user patches. However, there's nothing on MM that allows similar feature to Add'Ons.

Take as an example All Tweak: it aims to be a Quick&Dirty solution to add a flat out, minimalist TweakScale patch to every part that is not patched for TS yet, ergo, it  must be the last thingy being patched on every part - otherwise it could be stomping the toes of something that would be willing to path that part.

Right now, using :FINAL allows Koppernicus to ensure that all parts using Solar Panels could be patched to have Kopernicus Solar Panels instead, including Add'Ons that doesn't knows about it. You change it to :LAST[Kopernicus], and then only Add'Ons those names came before Kopernincus on the (alphabetically sorted) list of Add`Ons wil be patched. Anything later will not.

Not using :FINAL would be better, but we need to have something to fulfill the feature first. And it doesn't need to be, necessarily, a new feature on Module Manager (besides ideally it should be). A gentlemen's agreement where everybody would follow a protocol would do.

How about a directory called "zzz", where Add`Ons could insert their own "final" patches, and everybody agrees on not changing anything but what's strictly necessary? This way, you could replace :FINAL with :LAST[zzz/Kopernicus] and get the same result.

[R-T-B]

4 hours ago, Lisias said:

We are facing a dilemma between what should be done, and what must be done.

Ideally, :FINAL should be reserved to end-user patches. However, there's nothing on MM that allows similar feature to Add'Ons.

Take as an example All Tweak: it aims to be a Quick&Dirty solution to add a flat out, minimalist TweakScale patch to every part that is not patched for TS yet, ergo, it  must be the last thingy being patched on every part - otherwise it could be stomping the toes of something that would be willing to path that part.

Right now, using :FINAL allows Koppernicus to ensure that all parts using Solar Panels could be patched to have Kopernicus Solar Panels instead, including Add'Ons that doesn't knows about it. You change it to :LAST[Kopernicus], and then only Add'Ons those names came before Kopernincus on the (alphabetically sorted) list of Add`Ons wil be patched. Anything later will not.

Not using :FINAL would be better, but we need to have something to fulfill the feature first. And it doesn't need to be, necessarily, a new feature on Module Manager (besides ideally it should be). A gentlemen's agreement where everybody would follow a protocol would do.

How about a directory called "zzz", where Add`Ons could insert their own "final" patches, and everybody agrees on not changing anything but what's strictly necessary? This way, you could replace :FINAL with :LAST[zzz/Kopernicus] and get the same result.

I'm not opposed, but I just learned ModuleManager syntax and that is quite a bit outside my domain to implement.

[Lisias]

49 minutes ago, R-T-B said:

I'm not opposed, but I just learned ModuleManager syntax and that is quite a bit outside my domain to implement.

On a rule of thumb, don't use :LAST[Kopernicus]. It will not work for you, you need to replace every single Solar Panel on the game by Kopernicus ones, and not only the ones from AddOns those name is less than "Ko". (MM applies patches on alphabetical order on each phase).

And you really need to replace every single Solar Panel on the game to use Kopernicus, because since you are extending the stock Solar Panels class, the ModuleDeployableSolarPanel will be ignored on all parts and any part not patched will simply not work anymore (and Kopernicus will end up taking the heat, because by uninstalling it that parts will work again).

If in doubt, stick with :FINAL . it's safer for now.

[Guest]

TBH, :FINAL makes more sense here. There's no reason for any mod besides Kopernicus to patch the solar panels with the Kopernicus solar panel module, and that way it will incorporate any tweaks to the solar panels made by anything else. 

Let's not treat  "no :FINAL in mods" as dogma to be strictly adhered to. It's appropriate to use in few cases, this being one of them. The end user who wants to mess with the panels can take care to put the custom :FINAL patch before Koperniucs, so that it'll be applied before.

[Jognt]

5 hours ago, Lisias said:

On a rule of thumb, don't use :LAST[Kopernicus]. It will not work for you, you need to replace every single Solar Panel on the game by Kopernicus ones, and not only the ones from AddOns those name is less than "Ko". (MM applies patches on alphabetical order on each phase).

And you really need to replace every single Solar Panel on the game to use Kopernicus, because since you are extending the stock Solar Panels class, the ModuleDeployableSolarPanel will be ignored on all parts and any part not patched will simply not work anymore (and Kopernicus will end up taking the heat, because by uninstalling it that parts will work again).

If in doubt, stick with :FINAL . it's safer for now.

FINAL is safe, yes. But LAST exists to fix the race to FINAL. The LAST pass happens after all of the other passes have alphabetically been completed. 

14 hours ago, R-T-B said:

We've discussed that internally and decided that since those lines are only there to enforce the behavior of the solar panel disabling parameter, to leave it alone (it was done originally by the Kopernicus devs who came before us, actually).

Any modification to that property would lead to undefined behavior anyways, is my logic.  Or am I misunderstanding?  Since this is the second time that was suggested, I am open to changing it to a :LAST in next release.  I'd just need good reasoning to do so, and I'm listening.

LAST probably didn’t exist when FINAL was chosen. 
 

I recommend moving this to the MM topic though. There’s more knowledge there and we’re threadjacking the NF thread at the moment. 

Edit: Let's go here:

 

Edited August 22, 2020 by Jognt

[Souptime]

Hey @Nertea, I got an idea for the next update on NF spacecraft (I know you say its complete its an idea and maybe some mod makers could use it):

The MK3-4 or MK1-4 "Posiedon" Orbital Command Pod

Named after the father of orion it  has 100 monopropellant and a small battery from 2.5 bottom and 1.25 top

Fits 3 or 4 kerbals in it and could have a 3.75 meter variant with added monopropellant and battery

Black and white variants plus maybe more lander parts since you have pods why dont connect the pods with some landers like the blue moon, altair and that cool dynetics lander (Again im not asking its just an idea)

Edited August 29, 2020 by Souptime

[WarriorSabe]

I just realized my NF stuff is a few versions behind; do the latest releases of them still work in 1.8.1?

[TranceaddicT]

5 hours ago, WarriorSabe said:

I just realized my NF stuff is a few versions behind; do the latest releases of them still work in 1.8.1?

The newest versions are all listed as KSP 1.8.0-1.10.99

[Nertea]

17 hours ago, WarriorSabe said:

I just realized my NF stuff is a few versions behind; do the latest releases of them still work in 1.8.1?

I haven't really tested but all except NFLV should be ok. The fairings in that mod might be an issue. 

[WarriorSabe]

Another question: Is there a chart of the heat generation of each of the nuclear reactors?

I have Kerbalism installed so basically all coreheat modules are automatically removed to avoid issues (and DBS seems to disable itself so I can't check there either), and I don't want to put SystemHeat into my main save in case it breaks something, but I still want to have the correct amount of radiator capacity for how much heat is supposed to be produced.

[CDSlice]

3 hours ago, WarriorSabe said:

Another question: Is there a chart of the heat generation of each of the nuclear reactors?

I have Kerbalism installed so basically all coreheat modules are automatically removed to avoid issues (and DBS seems to disable itself so I can't check there either), and I don't want to put SystemHeat into my main save in case it breaks something, but I still want to have the correct amount of radiator capacity for how much heat is supposed to be produced.

If you have Kerbalism installed all bets are off as to what the reactors do, Nertea has never provided support for that config. Your best bet would be to ask the Kerbalism folks since with Kerbalism installed the reactors are basically Kerbalism reactors with Nertea models.

[WarriorSabe]

10 hours ago, CDSlice said:

If you have Kerbalism installed all bets are off as to what the reactors do, Nertea has never provided support for that config. Your best bet would be to ask the Kerbalism folks since with Kerbalism installed the reactors are basically Kerbalism reactors with Nertea models.

Oh, that's not what I mean. I know what Kerbalism does, it makes the reactors not produce any heat whatsoever. But I want to pretend they're still making heat like they should and still put enough radiator capacity on

[TaintedLion]

So does the Near Future dialogue box in the VAB that shows electrical usage/thermal management not work for solar panels in JNSQ, since that changes the Sun? Is there a workaround for this, I'd like to see electrical usage for solar panels.

Also it doesn't account for things like Scansat scanning electricity cost, or lights.

Edited August 27, 2020 by TaintedLion

[Nertea]

17 hours ago, WarriorSabe said:

Oh, that's not what I mean. I know what Kerbalism does, it makes the reactors not produce any heat whatsoever. But I want to pretend they're still making heat like they should and still put enough radiator capacity on

There's no specific table but it should be pretty easy to scrape that info out of the configs.

4 hours ago, TaintedLion said:

So does the Near Future dialogue box in the VAB that shows electrical usage/thermal management not work for solar panels in JNSQ, since that changes the Sun? Is there a workaround for this, I'd like to see electrical usage for solar panels.

Also it doesn't account for things like Scansat scanning electricity cost, or lights.

There's an open issue to fix the Kopernicus issue in DBS. However I am currently without modding computer so it will have to wait. 

I don't manage other mods' integration with the mod, it's up to the other modder to cooperate with me to find a route. Lights I haven't done because they're minor and intermittent, if you want this added please add an issue in the DBS repo and I will do it sometime

[Virtualgenius]

@Nertea I think there is a typo in one of the parts in NFLV as i couldnt find it but its in the active parts list in the folder it doesnt seem to show up in either configuration

// Near Future Launch Vehicles 1.0.0
// 5m to 3.75m adapter, flat

PART
{
    name = nflv-nflv-fueltank-adapter-5-375-4 
    module = Part
    author = Chris Adderley

should this be

// Near Future Launch Vehicles 1.0.0
// 5m to 3.75m adapter, flat

PART
{
    name = nflv-fueltank-adapter-5-375-4 
    module = Part
    author = Chris Adderley

 

This is the part i am looking for 

Edited August 28, 2020 by Virtualgenius

[Krymson Skorpyon]

I'm sorry if this has been addressed before - my forum search skills are pretty weak.  Where will I find documentation/guidance on incorporating hydroponics in my station and long-range-vessel designs?  Specifically, calculating what I need for Kerbal life support?  I run the Kerbalism addon, so I have to pay attention to such things.

Thanks!

Edited August 29, 2020 by Krymson Skorpyon

[NiL]

On 8/25/2020 at 2:00 AM, Souptime said:

The MK3-4 "Posiedon" Orbital Command Pod

Sounds mildly interesting from a gameplay perspective. A succesor to MK1-3? 

8 hours ago, Krymson Skorpyon said:

I run the Kerbalism addon

Perhaps you should ask in Kerbalism thread then

[Starseeker]

Downloaded the latest version of NF Solar for my modded 1.10.1 install, and I guess I was quite a few versions behind last I used it, because I just came across the new (well, "new") cell-type switching ability, and I just want to say: really good work! I'm especially impressed that you put in the work to make separate textures for each cell type for each panel, it must have taken quite a while!

Also, a question about said cell-type-switching: would it be feasable for another mod to make it so that, by default, only the regular cells option is available, and the others are unlocked through part upgrades from the tech tree? I'm planning out a custom tech tree, and I want to be able to have that be the case.

[hemeac]

11 minutes ago, Starseeker said:

Downloaded the latest version of NF Solar for my modded 1.10.1 install, and I guess I was quite a few versions behind last I used it, because I just came across the new (well, "new") cell-type switching ability, and I just want to say: really good work! I'm especially impressed that you put in the work to make separate textures for each cell type for each panel, it must have taken quite a while!

Also, a question about said cell-type-switching: would it be feasable for another mod to make it so that, by default, only the regular cells option is available, and the others are unlocked through part upgrades from the tech tree? I'm planning out a custom tech tree, and I want to be able to have that be the case.

That is pretty straightforward, I've done the exact same thing.  You can generalize this, but I chose upgrades based on the tier that the panels appeared in the tree, so in the end was easier to specify them individually.  Then just go through the partupgrade system.

Spoiler

@PART[nfs-panel-static-truss-1]:AFTER[NearFutureSolar]
{
	@MODULE[ModuleB9PartSwitch]
	{
		@SUBTYPE[Basic]
		{
		}
		@SUBTYPE[Advanced]
		{
			upgradeRequired = insertUpgradeNameHere
		}
		@SUBTYPE[Concentrating]
		{
			upgradeRequired = insertUpgradeNameHere2
		}
	}
}

 

 

[Starseeker]

Just now, hemeac said:

That is pretty straightforward, I've done the exact same thing.  You can generalize this, but I chose upgrades based on the tier that the panels appeared in the tree, so in the end was easier to specify them individually.  Then just go through the partupgrade system.

-snip-

Oh wow, it's really that simple of a patch? That'll make things so much easier!

Of course, I still need to finish planning out the tree, then figure out how to actually make it (and use the part upgrade system)

[hemeac]

5 minutes ago, Starseeker said:

Oh wow, it's really that simple of a patch? That'll make things so much easier!

Of course, I still need to finish planning out the tree, then figure out how to actually make it (and use the part upgrade system)

BDB makes use of the upgrade system with B9, so that will be a helpful reference.  Good luck with the Tech Tree  

[RandomKerbal]

On 1/24/2017 at 3:23 AM, Nertea said:

Near Future Spacecraft [1.3.3]  Last Updated August 2, 2020

May I ask why did you removed (or make them deprecated) the MP only fuel tanks? It was nicely textured and served as a vital component on my MP-engine powered ships.

[DStaal]

On 8/30/2020 at 12:15 PM, RandomKerbal said:

May I ask why did you removed (or make them deprecated) the MP only fuel tanks? It was nicely textured and served as a vital component on my MP-engine powered ships.

There was a discussion on it before it happened - it should be here a few (or a few dozen) pages back.  Basically:

1. Nertea didn't like the look anymore.

2. They were mostly excess parts.

3. Restock/Restock+ have similar parts.

4. They mostly weren't all that useful, or used.