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

[danfarnsy]

Nertea's mods make my KSP world go round. These are in an ongoing game in 1.7.3 I started last year.

Fuel anchorage at 2,000 km orbit, with docked fuel tanker, Kerbin-system personnel transport, and MHD test ship:



Gas-core nuclear explorer waiting at Duna for return window:



Thanks for everything!

[Nertea]

On 8/9/2020 at 6:40 AM, DeadJohn said:

If I underatand that correctly, reactors will dynamically reduce power to meet demand. That sounds great, with less micromanaging of xenon/argon/lithium ships.

Will radiators be activated/deactivated automatically to match the reactor's changing demands?

Will that automation work during a timewarp? Full reactor power at the start of timewarp to fill batteries, then scale back to run whatever laboratories and SCANsat sensors are turned on.

 

The automation supplied will be limited in scope - the reactor will run at a power level to supply demand. If a lot of power is required, it will run highest possible capacity until that power is no longer needed. If less power is required, it will run at that power level (though will respect a minimum power level). 

Automating radiators is way out of scope, would require another DBS-like solution.

On 8/9/2020 at 2:08 AM, SilentWindOfDoom said:

I thought there was something wrong with my install when I couldn't find those swanky NFE batteries I was used to seeing but after manually downloading it (opposed to relying on CKAN) I guess i missed the art pass! it might be worth putting a disclaimer on  the IMGUR links in that they might not match the parts currently in the packs.

Been meaning to redo those but I have much better things to do. Plus I want to redo the NFE reactors so been waiting for that. 

[Jimbodiah]

Great stuff, as ever!!! 

[FlyingCardboardbox]

Hi all,

TLDR  up front: Has anyone made any Realism Overhaul config files for the plasma thrusters from Near Future Propulsion, like the Charon model? 

 

I am switching from the ignorant bliss of SMURFF +RSS to a KSP build based around RO and Principia. I am keeping the parts pack mods I like (Firespitter, Near Future suite, Cryo engines, Kerbal Atomics, Extraplanetary Launchpads, etc). I am however not using Interstellar Extended for the moment. Therefore the Community Tech Tree in my career game is largely unmoved when getting to electric engines, Probes before Crew or not. 

The HERMes 12.5 kW Hall thruster, and other electrostatic ion engines have nice configs in RO to showcase their realistic TWRs of .001- .003 give or take. However, it is not until two tech nodes later, at Specialized Plasma Propulsion costing 4000 science that Ad Astra's VASIMR engines appear. Soooo.. I could take the time to try to write configs for myself or move the VASIMR engines forward in the tech tree. I could also just use the non RO MPDT engine like Charon and throttle it waaaay down below its ridiculous 47,300 N of thrust. The Charon model seems to be done after Princeton's test unit, and there are no MPDT's based on Japan's 1996 Space Flyer EPEX experiment. From https://en.wikipedia.org/wiki/Magnetoplasmadynamic_thruster, 200 Newtons is a reasonable expectation for the size of lithium thrusters that are currently being tested. 

I find MPDTs very intriguing and perhaps could be the engine of choice for interplanetary tugs and more. So if anyone who is experience at making config files would like to help me in this endeavour, let me know!  I look forward to hearing what people have to say. 

[Fulcrum]

 

Hi all,

Excuse me for my english, but i don't speak this language very well.

I have a problem in my "advance menu parts" in KSP 19.1.

The NFLV menu are duplicate, sometimes when i launch the game, it add another menu, but not always. it's the same thing with OPT.

In the "PartCategories.cfg" in "KSP/gamedata/squad/partList", i delete these duplicated sections but one after one they come back each time i launch the game.... so i don't understand.

If you have a solution to resolve this problem, thank you for your help.

Edited August 14, 2020 by Fulcrum

[Emilius73]

A giant RAPIER with a supersonic thrust of nearly 4,000kN?

 

TAKE.

MY.

FUNDS.

[iteranthypatic]

Hey Nertea, I have a weird issue. I have installed the Near Future Methalox mod, but I can't see any Methalox engines in the tech tree. 

Here's my full list of mods,

000_ClickThroughBlocker 
001_ToolbarControl 
B9PartSwitch
 Chatterer 
CommunityCategoryKit 
CommunityResourcePack 
CommunityTechTree 
ContractConfigurator 
ContractPacks 
CryoEngines 
CryoEnginesNFAero 
CryoEnginesRestock 
CryoTanks 
DMagicOrbitalScience 
DecayingRTGs 
DeployableEngines 
DynamicBatteryStorage 
HeatControl 
HideEmptyTechTreeNodes 
KAS 
KIS 
KSPRescuePodFix 
KerbalAtomics 
KerbalAtomicsLH2NTRModSupport 
KerbalEngineer 
Kerbalism 
KerbalismConfig 
KronalVesselViewer 
MarkIVSystem 
MechJeb2 
ModuleManager.4.1.4.dll 
ModuleManager.ConfigCache 
ModuleManager.ConfigSHA 
ModuleManager.Physics 
ModuleManager.TechTree 
NearFutureAeronautics 
NearFutureConstruction 
NearFutureElectricaNTRs 
NearFutureElectrical 
NearFutureExploration 
NearFutureLaunchVehicles 
NearFutureMethalox 
NearFutureProps 
NearFuturePropulsion 
NearFutureSolar 
NearFutureSpacecraft 
ReStock 
ReStockPlus 
RealPlume 
RealPlume-Stock 
RestockRigidLegs 
SCANsat 
SmokeScreen 
SpaceTuxLibrary 
Squad 
SquadExpansion 
StationPartsExpansionMetal 
StationPartsExpansionRedux 
TriggerTech 
UniversalStorage2 
WaypointManager 
WildBlueIndustries 
XenonHallThrusters

Any help would be appreciated! As I'm not quite sure what's going on.

[hemeac]

1 hour ago, iteranthypatic said:

Hey Nertea, I have a weird issue. I have installed the Near Future Methalox mod, but I can't see any Methalox engines in the tech tree. 

Here's my full list of mods,

000_ClickThroughBlocker 
001_ToolbarControl 
B9PartSwitch
 Chatterer 
CommunityCategoryKit 
CommunityResourcePack 
CommunityTechTree 
ContractConfigurator 
ContractPacks 
CryoEngines 
CryoEnginesNFAero 
CryoEnginesRestock 
CryoTanks 
DMagicOrbitalScience 
DecayingRTGs 
DeployableEngines 
DynamicBatteryStorage 
HeatControl 
HideEmptyTechTreeNodes 
KAS 
KIS 
KSPRescuePodFix 
KerbalAtomics 
KerbalAtomicsLH2NTRModSupport 
KerbalEngineer 
Kerbalism 
KerbalismConfig 
KronalVesselViewer 
MarkIVSystem 
MechJeb2 
ModuleManager.4.1.4.dll 
ModuleManager.ConfigCache 
ModuleManager.ConfigSHA 
ModuleManager.Physics 
ModuleManager.TechTree 
NearFutureAeronautics 
NearFutureConstruction 
NearFutureElectricaNTRs 
NearFutureElectrical 
NearFutureExploration 
NearFutureLaunchVehicles 
NearFutureMethalox 
NearFutureProps 
NearFuturePropulsion 
NearFutureSolar 
NearFutureSpacecraft 
ReStock 
ReStockPlus 
RealPlume 
RealPlume-Stock 
RestockRigidLegs 
SCANsat 
SmokeScreen 
SpaceTuxLibrary 
Squad 
SquadExpansion 
StationPartsExpansionMetal 
StationPartsExpansionRedux 
TriggerTech 
UniversalStorage2 
WaypointManager 
WildBlueIndustries 
XenonHallThrusters

Any help would be appreciated! As I'm not quite sure what's going on.

@iteranthypatic, that patch for the Methalox engines is for the pre 2.0 Launch Vehicles engines which are now deprecated, so that is why you are not able to see them.  Nertea does not have any engines in his current NF set that support Methalox.

[iteranthypatic]

6 hours ago, hemeac said:

@iteranthypatic, that patch for the Methalox engines is for the pre 2.0 Launch Vehicles engines which are now deprecated, so that is why you are not able to see them.  Nertea does not have any engines in his current NF set that support Methalox.

Thank you so much! That explains that. I wonder if I could update the patch somehow... But I'm worried that it might be against Nertea's wishes. Perhaps this is how he wants it to be played? I love his creative choices and I'd like to respect them. 

[hemeac]

3 hours ago, iteranthypatic said:

Thank you so much! That explains that. I wonder if I could update the patch somehow... But I'm worried that it might be against Nertea's wishes. Perhaps this is how he wants it to be played? I love his creative choices and I'd like to respect them. 

I have had a similar idea and the question seems to be asked at least every other week.  Nertea's comments from earlier note that the current batch of engines in Launch Vehicles are based on Kerolox engines, so (coming from a non-engineer) from a realism perspective it may make more sense to patch the engines from his cryogenics mods which are based on hydrolox.  In terms of maintaining his creative choices, I think he is understanding that his mods are complementary to other mods and I would view your patching the parts as akin to downloading a methalox engines pack.  You can always keep the original engines and when patching, duplicate the parts.

[Nertea]

4 hours ago, iteranthypatic said:

Thank you so much! That explains that. I wonder if I could update the patch somehow... But I'm worried that it might be against Nertea's wishes. Perhaps this is how he wants it to be played? I love his creative choices and I'd like to respect them. 

The patch hasn't been updated because the long term goal is to remodel the methalox engines and put them as models in another mod. Been taking longer to get to that than I would like though

[R-T-B]

Hello @Nertea,

Sorry to bother you as I know you are extremely busy.  But I thought you should know, Kopernicus is nearing release of it's 1.9.1 variant at CKAN, and your mods currently are unaware of this change to it's solar panel logic.  Basically, we hijack the actually solar panel module now to override some solar math.  Sadly due to multistar support being tricky and requiring a full method override in one case, this change was required despite knowing it would be less "clean."

You can view the relevant cfg here:

https://github.com/R-T-B/Kopernicus/blob/dev191/build/GameData/Kopernicus/Config/SolarPanels.cfg

an issue report relevant to your mod (closed because we cannot fix) here:

https://github.com/R-T-B/Kopernicus/issues/21

If there is anything you'd like done on our side, you can tell me and I'll consider it.  But I have a feeling this is a change that should be simple to understand.

If you know of any other solar mods broken by this change, feel free to link to this post.

Edited August 16, 2020 by R-T-B

[Nertea]

52 minutes ago, R-T-B said:

Hello @Nertea,

Sorry to bother you as I know you are extremely busy.  But I thought you should know, Kopernicus is nearing release of it's 1.9.1 variant at CKAN, and your mods currently are unaware of this change to it's solar panel logic.  Basically, we hijack the actually solar panel module now to override some solar math.  Sadly due to multistar support being tricky and requiring a full method override in one case, this change was required despite knowing it would be less "clean."

You can view the relevant cfg here:

https://github.com/R-T-B/Kopernicus/blob/dev191/build/GameData/Kopernicus/Config/SolarPanels.cfg

an issue report relevant to your mod (closed because we cannot fix) here:

https://github.com/R-T-B/Kopernicus/issues/21

If there is anything you'd like done on our side, you can tell me and I'll consider it.  But I have a feeling this is a change that should be simple to understand.

If you know of any other solar mods broken by this change, feel free to link to this post.

Thanks for letting me know. This can be fixed by a relatively simple MM patch. Personally I would prefer that Kopernicus ship such a patch and handle the curation of it as they are causing the break in the first place.

As a specific note, this breakage occurs because the switchable solar panel targets ModuleDeployableSolarPanel. If it is changed, when Kopernicus is installed, to target the appropriate module, everything would be fine. The line in question is here.

Edited August 16, 2020 by Nertea

[hemeac]

40 minutes ago, R-T-B said:

Hello @Nertea,

Sorry to bother you as I know you are extremely busy.  But I thought you should know, Kopernicus is nearing release of it's 1.9.1 variant at CKAN, and your mods currently are unaware of this change to it's solar panel logic.  Basically, we hijack the actually solar panel module now to override some solar math.  Sadly due to multistar support being tricky and requiring a full method override in one case, this change was required despite knowing it would be less "clean."

You can view the relevant cfg here:

https://github.com/R-T-B/Kopernicus/blob/dev191/build/GameData/Kopernicus/Config/SolarPanels.cfg

an issue report relevant to your mod (closed because we cannot fix) here:

https://github.com/R-T-B/Kopernicus/issues/21

If there is anything you'd like done on our side, you can tell me and I'll consider it.  But I have a feeling this is a change that should be simple to understand.

If you know of any other solar mods broken by this change, feel free to link to this post.

@R-T-B, I think the issue is that the SolarPanels.cfg needs to also be able to change the ModuleDeployableSolar Panel identifier within any ModuleB9PartSwitch Module which modifies the ModuleDeployableSolar.  I don't have time to test, but this config might be a way to test, this adds equivalent B9PS to the OX-stat, but have altered so it is using KopernicusSolarPanels.  Think this could be used to create a generalized patch.

Spoiler

@PART[solarPanels5]:NEEDS[CommunityTechTree]:AFTER[zzzKiwiAerospace] // OX-STAT 0.3 Sec, Fixed
{
	MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = cellSwitch
		switcherDescription = #LOC_NFSolar_switcher_cell_title
		affectDragCubes = False
		affectFARVoxels = False

		SUBTYPE
		{
			name = Basic
			title = #LOC_NFSolar_switcher_cell_basic_title
			descriptionSummary = #LOC_NFSolar_switcher_cell_basic_summary
			descriptionDetail = #LOC_NFSolar_switcher_cell_basic_detail
			primaryColor = #5d7682
			secondaryColor = #5d7682
			addedCost = 0
			addedMass = 0
			
			defaultSubtypePriority = 1

			MODULE
			{
				IDENTIFIER
				{
					name = KopernicusSolarPanels
				}
				DATA 
				{
					chargeRate = 0.35
				}
			}
		}
		
		SUBTYPE
		{
			name = Advanced
			title = #LOC_NFSolar_switcher_cell_adv_title
			descriptionSummary = #LOC_NFSolar_switcher_cell_adv_summary
			descriptionDetail = #LOC_NFSolar_switcher_cell_adv_detail
			primaryColor = #2d373c
			secondaryColor = #2d373c
			
			addedMass = 0.00125
			addedCost = 26
			
			
			defaultSubtypePriority = 0
			
			MODULE
			{
				IDENTIFIER
				{
					name = KopernicusSolarPanels
				}
				DATA 
				{
					chargeRate = 0.455
				}
			}
		}
		
		SUBTYPE
		{
			name = Concentrating
			title = #LOC_NFSolar_switcher_cell_concentrating_title
			descriptionSummary = #LOC_NFSolar_switcher_cell_concentrating_summary
			descriptionDetail = #LOC_NFSolar_switcher_cell_concentrating_detail
			primaryColor = #000000
			secondaryColor = #000000
			
			addedMass = 0.00425
			addedCost = 83
			
			
			defaultSubtypePriority = 0

			MODULE
			{
				IDENTIFIER
				{
					name = KopernicusSolarPanels
				}
				DATA 
				{
					chargeRate = 0.6125
				}
			}
		}
	}
}

 

 

[R-T-B]

1 hour ago, Nertea said:

Thanks for letting me know. This can be fixed by a relatively simple MM patch. Personally I would prefer that Kopernicus ship such a patch and handle the curation of it as they are causing the break in the first place.

That's fair.  As long as it's as simple as a modulemanager patch on a per-broken-and-relevant mod basis, we can do that.  We'll get on it.  The above looks to be a good starting point.  I'm woefully understudied in modulemanager syntax, so I'll have to spend a day reading about it, but after that no issue at all.

 

EDIT:  Wow, that is simple syntax actually.  Would something like this work?

Spoiler

@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[Basic]
        {
            @MODULE
            {
                @IDENTIFIER[ModuleDeployableSolarPanel]
                {
                    @name = KopernicusSolarPanels
                }
            }
        }
        @SUBTYPE[Advanced]
        {
            @MODULE
            {
                @IDENTIFIER[ModuleDeployableSolarPanel]
                {
                    @name = KopernicusSolarPanels
                }
            }
        }
        @SUBTYPE[Concentrating]
        {
            @MODULE
            {
                @IDENTIFIER[ModuleDeployableSolarPanel]
                {
                    @name = KopernicusSolarPanels
                }
            }
        }
    }
}

EDIT:  The above works for me, anyone see any issues with it?

Edited August 16, 2020 by R-T-B

[Streetwind]

On 8/14/2020 at 2:25 AM, FlyingCardboardbox said:

Has anyone made any Realism Overhaul config files for the plasma thrusters from Near Future Propulsion, like the Charon model? 

I tried to do this, once upon a time. Maybe three... four years ago? I forget.

Anyway, as I was unfamiliar with the details of the RO suite, I asked in the RO thread for thoughts on what I would have to look out for/keep in mind to produce something that works with all the mods in the suite, and that RO players would enjoy. The result was that, after asking twice, I got absolutely zero reaction. Other conversations were happening around my posts, but not one person as much as acknowledged that I had written anything at any point. This led me to figure that there was no interest at all in electric engines in RO - and to be fair, the prospect of miniscule accelerations was probably pretty daunting. Not sure if any method of thrust under time warp higher than x4 existed back then. BetterTimeWarp for example certainly didn't.

To sum up, I dropped the effort before it even really got started, and never tried again. As far as I know, nobody else ever attempted this either (but then again, I've not paid close attention to RO).

[iteranthypatic]

8 hours ago, Nertea said:

The patch hasn't been updated because the long term goal is to remodel the methalox engines and put them as models in another mod. Been taking longer to get to that than I would like though

@Nertea It takes as long as it takes. And that's okay! I hope I didn't make you feel guilty or anything. I can wait. I'm sure others can too. I'm not going anywhere

Also, may I just say that I love your art? It's absolutely beautiful. I would seriously consider selling posters or merch of it. And o'lordy what would I give to make something that amazing.  

[Nertea]

8 hours ago, Streetwind said:

I tried to do this, once upon a time. Maybe three... four years ago? I forget.

Anyway, as I was unfamiliar with the details of the RO suite, I asked in the RO thread for thoughts on what I would have to look out for/keep in mind to produce something that works with all the mods in the suite, and that RO players would enjoy. The result was that, after asking twice, I got absolutely zero reaction. Other conversations were happening around my posts, but not one person as much as acknowledged that I had written anything at any point. This led me to figure that there was no interest at all in electric engines in RO - and to be fair, the prospect of miniscule accelerations was probably pretty daunting. Not sure if any method of thrust under time warp higher than x4 existed back then. BetterTimeWarp for example certainly didn't.

To sum up, I dropped the effort before it even really got started, and never tried again. As far as I know, nobody else ever attempted this either (but then again, I've not paid close attention to RO).

In the past (idk about now), RO has focused on surface to orbit and a limited amount of recreation of concept missions. I don't think we were in that bucket. At one point I provided NathanKell with a whole set of hypothetical performance numbers for realisticish versions of the engines and got a similar reaction of ambivalence.

8 hours ago, iteranthypatic said:

@Nertea It takes as long as it takes. And that's okay! I hope I didn't make you feel guilty or anything. I can wait. I'm sure others can too. I'm not going anywhere

Also, may I just say that I love your art? It's absolutely beautiful. I would seriously consider selling posters or merch of it. And o'lordy what would I give to make something that amazing.  

Thanks! I should probably add something to the OP or similar though.

[R-T-B]

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.

Edited August 16, 2020 by R-T-B

[TranceaddicT]

1 minute ago, 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]]
{
  @MODULE[ModuleDeployableSolarPanel]
  {
    %useKopernicusSolarPanels = false
  }
}

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

I'm just waking up, so the BCL (blood caffine level) is notoriously low, but I think that :FINAL should to be :NEEDS[JNSQ].

[R-T-B]

2 minutes ago, TranceaddicT said:

I'm just waking up, so the BCL (blood caffine level) is notoriously low, but I think that :FINAL should to be :NEEDS[JNSQ].

no, this is a generalized CFG for Kopernicus, needs JNSQ would make it only work with JNSQ...  FINAL makes sure those cfgs apply.

It's ok man, wake up. 

Edited August 16, 2020 by R-T-B

[TranceaddicT]

28 minutes ago, R-T-B said:

no, this is a generalized CFG for Kopernicus, needs JNSQ would make it only work with JNSQ...  FINAL makes sure those cfgs apply.

It's ok man, wake up. 

 

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

Edited August 16, 2020 by TranceaddicT

[R-T-B]

1 minute ago, 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].

I mean those lines are only telling it to obey the useKopernicusSolarPanels directive.

Why would one want to override that?  I don't see it, really.

[FlyingCardboardbox]

10 hours ago, Streetwind said:

I tried to do this, once upon a time. Maybe three... four years ago? I forget.

Anyway, as I was unfamiliar with the details of the RO suite, I asked in the RO thread for thoughts on what I would have to look out for/keep in mind to produce something that works with all the mods in the suite, and that RO players would enjoy. The result was that, after asking twice, I got absolutely zero reaction. Other conversations were happening around my posts, but not one person as much as acknowledged that I had written anything at any point. This led me to figure that there was no interest at all in electric engines in RO - and to be fair, the prospect of miniscule accelerations was probably pretty daunting. Not sure if any method of thrust under time warp higher than x4 existed back then. BetterTimeWarp for example certainly didn't.

To sum up, I dropped the effort before it even really got started, and never tried again. As far as I know, nobody else ever attempted this either (but then again, I've not paid close attention to RO).

I feel the same lol. I've posted in a few threads about this now and you are the first person to acknowledge it as other convos are ongoing EDIT: thanks Nert, didnt see your message initially! From my own deep dives into Princeton's academic papers and also NASA Glenn, it appears there is an academic rift between fuel choice. So before we even get into RO configs, to get the physics right, it might be a good look at doing a fuel switch compatibility for MPDTs to switch between a lithium-barium mixture and Hydrogen. The danger here is finding isp values for fusion-plasma propulsion like daedilus and not pure MPDT thrusters that have electricity fed to them. So integrating into Real Fuels/ Interstellar Fuel Switch or whatever strikes your fancy.

<Lithium> highest thrust, lowest isp and dangers of containment and ablative nozzle limits burn time

<lithium barium mixture> less corrosion to be almost imperceptable, slightly lower thrust/ efficiency

<hydrogen> this could be an unlockable switchable mode later in the tech tree. So you could run "Charon" on LH2 and get less thrust but 10,000s isp (to be conservative) rather than lithium's 2600s 

 

So from the graphs in Ohio Aerospace Institute and Princeton's papers respectively, (https://www.researchgate.net/publication/253713475_MPD_Thruster_Performance_Analytic_Models) (https://alfven.princeton.edu/publications/choueiri-iepc-1997-121)  the terminal voltage for lithium is a limiting factor for isp. And testing on earth with vacuum chambers, force stands, and glove boxes for safe handling of lithium limit the amount of mass flow rate. Princeton's PPL research seems to show that their highest sustained mass flow rate was 20 grams per second, and showed a greater than linear increase in thrust proportional to added propellant flow rate with constant operating voltage and amperage (electrical power). 

A lot of chemical RO engines have their reusability quantified as "ignitions remaining". This overall makes sense for chemical engines that burn for 2 minutes as boosters or 6+ minutes as sustainers. Chemical rocket limitiations aren't always dependent on ablative nozzles so much as turbopump wear and tear.  Lithium Lorenz force Thrusters like the "Charon" model would corrode the cathode within the presumed burn time of hours or so (given beamed power/ reactor on board supplies sufficient juice). So for RO, could it be done to limit burn time of the engine, rather than limit restarts? 

 

I used Better TIme Warp and reduced throttle settings to send a mothership to Titan in RO, but with reduced thrust came reduced power consumption, which made my long burn times unreasonable, as the ship was not designed to sustain that burn power consumption indefinitely. 

 

Thanks for reaching out!

Edited August 16, 2020 by FlyingCardboardbox
acknowledge Nert's post

[dlrk]

Are these updates working with 1.8.1?