Jump to content

[1.4.2] Kerbal Research & Development


-MM-

Recommended Posts

1 hour ago, Turin Malos said:

Something I'd love to see is SCANSat integration. Being able to use RnD to widen operational altitude windows and FoV would be awesome, especially the very short-range BTDT.

(ignore if it's already been said - I admit to not looking) 

Though -MM- is generally opposed to adding support specifically for mod items, I like this idea and hope it will be considered :)

Link to comment
Share on other sites

On 22.10.2016 at 0:06 AM, FirroSeranel said:

<snip>

As for making it work... I have seen some mods that put an infinite research node at the very end of the tech tree, or at least I seem to recall having seen something like that. So maybe it's possible? I'm not sure.

Do you by any chance happen to remember which mod(s) that might have been? I love playing with some kind of "open-end" tech tree, and as much as I like the idea of R&D here, it's a tad... OP for my tastes :)

Link to comment
Share on other sites

2 hours ago, Phelan said:

Do you by any chance happen to remember which mod(s) that might have been? I love playing with some kind of "open-end" tech tree, and as much as I like the idea of R&D here, it's a tad... OP for my tastes :)

EddieW's recently completed "c'logs" had RoverDude's Alcubierre Warp Drive Mod as the ultimate goal, which cost 100,000 science points to unlock the node. 

 

And regarding R&D being overpowered, all it takes is a bit of creative thinking.  I just started a new 1.2 career with R&D using stock parts in 3.2 scale.  With all delta V requirements around 80 percent higher, the incremental improvements in R&D will be very helpful.  I'm also limiting myself to real world figures in terms of Isp - for example, LFO engines will be limited to an atmo Isp of 350 and a vacuum Isp of 460, and LV-Ns will be limited to a vacuum Isp around 1,000 (which is about all NASA thought they could get from a solid core nuclear thermal rocket).

Link to comment
Share on other sites

3 hours ago, Phelan said:

Do you by any chance happen to remember which mod(s) that might have been? I love playing with some kind of "open-end" tech tree, and as much as I like the idea of R&D here, it's a tad... OP for my tastes :)

 

Hmm... sadly I don't. It was a while ago, maybe in 1.0 IIRC, and I don't think whatever it was got updated.

Or... maybe it's a figment of my imagination? <.< But I swear I remember seeing something like that... My hazy memory -seems- to recall something about it being related to nuclear power in some way, ramping up power output of high-end nuclear power cores so they could eventually compete with antimater and other exotic power sources, but... again, I could just be imagining things. Sorry! D:

Link to comment
Share on other sites

@Phelan: You can tweak the costs and benefits of the KRnD upgrades in its config file, if you feel the current settings are over powered.

 

I've done some testing with the upgrade system and while I was unable to apply upgrades, which were created on the fly, directly to my parts, creating custom tech-tree nodes seems to work just fine. For testing I used a new, custom tech tree node which makes all parts 1t lighter (just place this snippet into a new cfg file in your KSP-installation):

@TechTree
{
	RDNode
	{
		id = massUpgrade
		title = Mass Upgrade
		description = Just for testing.
		cost = 100
		hideEmpty = False
		nodeName = rnd_massUpgrade
		anyToUnlock = True
		pos = -1309,1809,-1
		scale = 0.6
	}
}

@PART[*]
{
	MODULE
	{
		name = PartStatsUpgradeModule
		showUpgradesInModuleInfo = true
		UPGRADES
		{
			UPGRADE 
			{
				name__ = Mass Upgrade
				techRequired__ = massUpgrade
				IsAdditiveUpgrade__ = True	
				PartStats
				{
					mass = -1
				}
			}
		}
	}
}

One could now simply build like 10 of these nodes, each called "Mass Upgrade -10%", but it has some drawbacks:

  • The description of the parts is not updated, even after applying the upgrade with -1 mass to a part which weighs 1.25t, it will still be listed as 1.25t, only with the additional remark "** Upgrades Available **"
  • With this you could obviously create parts with negative mass. So unless you want to start your very own Kerbal Ballooning Program, we would have to generate the upgrades for these nodes programmatically for each part (unless Squad introduces a relative modifier in the future).

While the second point can be solved with a clever mod, the first one seems pretty inconvenient. But maybe some of you guys with incompatible third party mods can do some tests with this to find out whether a system like this would solve your problems?

Link to comment
Share on other sites

 

Would using the arithmetic function of modulemanager:

				PartStats
				{
					mass *= 0.99
				}

not prevent any negative mass problems? This example would reduce mass by 1%, not a plain number.

Thanks,

Dani

 

PS: The quoting and code box function of this forum software is a crime against usability.

2 hours ago, -MM- said:

 For testing I used a new, custom tech tree node which makes all parts 1t lighter (just place this snippet into a new cfg file in your KSP-installation):


@TechTree
{
	RDNode
	{
		id = massUpgrade
		title = Mass Upgrade
		description = Just for testing.
		cost = 100
		hideEmpty = False
		nodeName = rnd_massUpgrade
		anyToUnlock = True
		pos = -1309,1809,-1
		scale = 0.6
	}
}

@PART[*]
{
	MODULE
	{
		name = PartStatsUpgradeModule
		showUpgradesInModuleInfo = true
		UPGRADES
		{
			UPGRADE 
			{
				name__ = Mass Upgrade
				techRequired__ = massUpgrade
				IsAdditiveUpgrade__ = True	
				PartStats
				{
					mass = -1
				}
			}
		}
	}
}

One could now simply build like 10 of these nodes, each called "Mass Upgrade -10%", but it has some drawbacks:

  • The description of the parts is not updated, even after applying the upgrade with -1 mass to a part which weighs 1.25t, it will still be listed as 1.25t, only with the additional remark "** Upgrades Available **"
  • With this you could obviously create parts with negative mass. So unless you want to start your very own Kerbal Ballooning Program, we would have to generate the upgrades for these nodes programmatically for each part (unless Squad introduces a relative modifier in the future).

While the second point can be solved with a clever mod, the first one seems pretty inconvenient. But maybe some of you guys with incompatible third party mods can do some tests with this to find out whether a system like this would solve your problems?

 

Edited by DaniDE
Link to comment
Share on other sites

My 2 cents on the whole compatability thing: If you dont want compatability problems, you need to manually take care of it yourself. Mod Authors cannot foresee the combination of mods a user has. Its not as easy as using some mod manager software, but its also not so complicated you could not do it yourself.

As for compatability, you need to be in control of what modules get applied to which parts. I delete the inclusion patches that come shipped with tweakscale and only apply tweakscale to certain parts like structural stock parts and Infernal Robotics with my own tweakscale MM patch. Sometimes Mods come with tweakscale configs included and you might want to check if you really like to keep those or not.

I got rid of interstellar fuel switch which is way too invasive in its implementation - for some reason, the author decided it would be a good idea to apply it to @PART[*] instead of defining the parts that would receive it. I personally had IFS back then for Fuel Tanks Plus, which recently dropped IFS as a dependency and lets you use Firespitter instead, which does NOT include itself to all parts and is therefore a recommended alternative for all texture switching parts. (Nertea uses B9PartSwitcher for Near Future Tech, which also is not as invasive as IFS and should also not give you trouble controlling it).

What I mean is - decide yourself what parts tweakscale and other Part changing mods apply its module to and check if you really need Interstellar Fuel Switch - If you do, you can basically not *prevent* it from getting applied to all qualified parts, instead you can only try to make a custom mm patch that should *remove* the applied IFS module from a tank/engine that you dont want or need it on by something like this (no guarantees, I bascially wrote that out of my memory, not tested :):

@PART[FuelTank]:BEFORE[KRnD]:AFTER[InterstellarFuelSwitch]:NEEDS[InterstellarFuelSwitch,KRnD]
{
    !MODULE[InterstellarFuelSwitch]{}
}

(What this does is telling Module Manager to remove the module [InterstellarFuelSwitch] from the part [FuelTank] before KRND is run, because it needs to do it beforehand so KRND has not already blacklisted the part, and after IFS so the IFS module applying has already happened. Otherwise IFS would be removed but KRND might not get applied anyway. Only run this Patch when both mods are actually installed.)

 

If you have done the work once, you can place all your custom module manager configs in a separate folder that you can back up for reinstalls, so you dont have to do the same work twice. In the end, you should only have parts that have a part changing module on it, that you decided on beforehand. And if you ever see a part ingame that has two conflicting modules on it, you can patch it with a variant of the above example patch.

Remember to delete the Module Manager cache files in your /gamedata/ folder (ModuleManager.ConfigCache, ModuleManager.ConfigSHA, ModuleManager.Physics, ModuleManager.TechTree) when you made changes, also delete "PartDatabase.cfg" in the Kerbal Space Program folder when you changed your partlist (at least when you delete a part or a mod with parts).

Edited by DaniDE
Link to comment
Share on other sites

On 10/29/2016 at 3:28 PM, Phelan said:

Do you by any chance happen to remember which mod(s) that might have been? I love playing with some kind of "open-end" tech tree, and as much as I like the idea of R&D here, it's a tad... OP for my tastes :)

When I first started playing with R&D I would have disagreed with you about it being over powered(at least in principal).

Then I discovered the converter efficiency upgrade.

With the converter at +50%, you get 1.5 tons of fuel for each ton of ore you process, allowing your high-endurance vessels to have a fuel fraction well over 100% when most of the fuel is stored as ore.  All you really need is a fuel tank that will hold enough fuel for your longest burn, and store the rest as ore, converting it into a larger mass of fuel only as needed.

Any idea what the delta-v is on an ISP 1000 nuclear engine with a fuel ratio of ~130%?   (I really need to install one of those dev versions of KER)

---

Of course with the amount of success I have been having with some of the goals I have set for my space programs, overpowered is probably a good thing...

Edited by Terwin
Link to comment
Share on other sites

Just wanted to say "Thank you!" for this mod!

It sounds simple, but it opens up a completely new way of playing the game, that is not only fun but long-term entertaining. Suddenly gathering science past Kerbin SOI becomes relevant, because you can still upgrade that parts. Also parts that were near useless in stock end-game can now be upgraded to provide interesting build alternatives.

Link to comment
Share on other sites

Thought I'd share what I've been working on for the past few days. Those that use Interstellar Fuel Switch may be particularly interested...

Spoiler

xlZ3bJ2.jpg

 

sySDsW9.jpg

It's not 100% there yet, but progress is definitely being made. I've sent some info over to -MM-, but it will probably need further integration help from FreeThinker to work properly.

Link to comment
Share on other sites

On ‎10‎/‎31‎/‎2016 at 8:35 AM, -MM- said:

I've done some testing with the upgrade system and while I was unable to apply upgrades, which were created on the fly, directly to my parts, creating custom tech-tree nodes seems to work just fine.

Just to get this straight: Does this mean we can add automatic upgrades across the board to tech nodes?  Something like if an engine uses oxidizer, it gains X Isp?

Link to comment
Share on other sites

Can't be 100% sure what the problem is, but there seems to be an issue with the CKAN version.  You can select it in the list, but it doesn't let you apply the change after you do.  Thought you should know as this is an awesome mod that many people would probably love to use.

Link to comment
Share on other sites

18 hours ago, Sweetie bot said:

I have a question,Because of some physical limitations.  When you try to increase the vac isp, It must sacrifice the atm isp, it hard to get both, so do you do it at that way?:wink:

Nope, with this mod you spend science to get a specific % improvement on a specific attribute of a specific part, with costs doubling for every additional improvement on a given part.

(note: weight reduction is limited to 9 upgrades, which reduces the dry weight of a given part to 10% of it's original weight, but I am not aware of any other limits aside from how much science you spend)

For engines, I believe the categories are: dry weight, Max temp, Vac ISP(this also increases vac thrust), Atmos ISP(this also increases atmospheric thrust), Fuel flow(this also increases both vac and atmospheric thrust).

Engines with attached fuel(like solid boosters or the twin boar) can also increase the fuel pressure, like other fuel tanks(increasing total fuel by 5% per level)

note: changes are additive, so 10 levels of fuel pressure give a tank with 150% of stock fuel(1+(0.05*10)), not 163% of stock fuel(1.05^10)

14 hours ago, Turin Malos said:

Just to get this straight: Does this mean we can add automatic upgrades across the board to tech nodes?  Something like if an engine uses oxidizer, it gains X Isp?

By my understanding of the stock upgrade system, you can change the stats of one specific part in a science node, much like making a specific part available in a science node.  While a given node could be made to include the same change to each stock part with given attributes by adding a stat change for each and every part to that node, it would not apply to mod parts that are not also individually added to the node.

If you are asking about the R&D upgrade system, no.  All upgrades apply to a specific part(the 2.5M heat shield or the orange tank for some examples), and only to that part.  To affect other parts you would need to upgrade that attribute on each part you want upgraded.  

Edited by Terwin
Link to comment
Share on other sites

12 hours ago, Leo_G. said:

Can't be 100% sure what the problem is, but there seems to be an issue with the CKAN version.  You can select it in the list, but it doesn't let you apply the change after you do.  Thought you should know as this is an awesome mod that many people would probably love to use.

Scroll up and down your modlist in CKAN.  You might see a red line across another mod - maybe Tweakscale.  This mod conflicts with that and a couple others (possibly procedural parts/wings/whatever), and CKAN won't let you install a mod that may conflict with a different one.

If that's what's happening, you'll have to make a choice as to which mod you'd prefer to use, although I believe there's a blacklist in KRnD that, with a little bit of editing, will allow it to work with those mods.

Link to comment
Share on other sites

I have come across a conflict between this and TAC-LS. When they are installed together, a Kerbal on EVA has no EC capacity. This is bad as TAC-LS uses that to keep one alive. :wink: Log is showing KRnD is looking at the EVA Kerbal for upgrade data:


[KRnD] updatePart(kerbalEVA (Jebediah Kerman)): System.Exception: no original-stats for part 'kerbalEVA'
  at KRnD.KRnD.updatePart (.Part part, KRnD.KRnDUpgrade upgradesToApply) [0x00000] in <filename unknown>:0


I pulled all other mods but these two and cleared the cash and reproduced the problem.

https://www.dropbox.com/s/i5csqqgfss24ugz/output_log.txt?dl=0

EDIT: Good news! This is an easy fix! in the KRnD folder, in the file blacklist.cfg add the line:

BLACKLISTED_MODULE = ModuleTripLogger

EVA is the only time this module is used and this prevents the above problem completely.

Edited by JeffreyCor
Link to comment
Share on other sites

  • 2 weeks later...
@PART[*]:HAS[@RESOURCE[SolidFuel]]
{
	showUpgradesInModuleInfo = true
	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = thrustTransform
		gimbalRange = 0

		UPGRADES
		{
			UPGRADE
			{
				name__ = givEmGimbal
				description__ = SRBs now have thrust vectoring.
				IsAdditiveUpgrade__ = True
				PartStats
				{
				gimbalRangeAdd = 2
				}
			}
		}
	}
 }

//And then

PARTUPGRADE
{
	name = givEmGimbal
	partIcon = liquidEngineT15
	techRequired = experimentalAerodynamics
	entryCost = 5000
	cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this.
	
	title = Gimbal for SRBs
	//basicInfo = Whatever\nblah
	manufacturer = JonzCo
	description = Gimballed SRBs in preparation for your Shuttle launch system.
}

I too have been toying with adding R&D style upgrades through the new upgrade system but I think it is faulty, I'm not convinced that the system is fully implemented yet (boo hiss) so as MM says, you can't get the descriptions to update but I am also unsure as to whether there is a specific list of things that can be upgraded, this for example should add gimbal to all SRBs but for some reason it ain't working...

 

 

Link to comment
Share on other sites

On 5.11.2016 at 8:29 AM, JeffreyCor said:

I have come across a conflict between this and TAC-LS. When they are installed together, a Kerbal on EVA has no EC capacity. This is bad as TAC-LS uses that to keep one alive. :wink: Log is showing KRnD is looking at the EVA Kerbal for upgrade data:


[KRnD] updatePart(kerbalEVA (Jebediah Kerman)): System.Exception: no original-stats for part 'kerbalEVA'
  at KRnD.KRnD.updatePart (.Part part, KRnD.KRnDUpgrade upgradesToApply) [0x00000] in <filename unknown>:0


I pulled all other mods but these two and cleared the cash and reproduced the problem.

https://www.dropbox.com/s/i5csqqgfss24ugz/output_log.txt?dl=0

EDIT: Good news! This is an easy fix! in the KRnD folder, in the file blacklist.cfg add the line:

BLACKLISTED_MODULE = ModuleTripLogger

EVA is the only time this module is used and this prevents the above problem completely.

I am getting the exact same error (no original-stats for part 'xxx' (xxx=seemingly all the installed and qualified parts are being reported with this into the log)  at KRnD.KRnD.updatePart (.Part part, KRnD.KRnDUpgrade upgradesToApply) [0x00000] in <filename unknown>:0) now with the current version of "Kerbal Planetary Base Systems". Only fix I found is to remove Base Systems. I spent some time looking through the files and tried to blacklist things, but nothing worked. I have no idea what @Nils277 changed that could cause this :(

Link to comment
Share on other sites

4 hours ago, DaniDE said:

I am getting the exact same error (no original-stats for part 'xxx' (xxx=seemingly all the installed and qualified parts are being reported with this into the log)  at KRnD.KRnD.updatePart (.Part part, KRnD.KRnDUpgrade upgradesToApply) [0x00000] in <filename unknown>:0) now with the current version of "Kerbal Planetary Base Systems". Only fix I found is to remove Base Systems. I spent some time looking through the files and tried to blacklist things, but nothing worked. I have no idea what @Nils277 changed that could cause this :(

Hmm, i have changed nothing regarding TAC LS or similar. KPBS also does not add modules to other parts than the ones it adds. I haven't checked compatibility with this mod though. You could try to remove the configs for mod support from KPBS and add them one after the other and try out which config causes the bug. The are in the folder "PlanetaryBaseInc/ModSupport/Configs" 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...