Jump to content

Customizing configs


Recommended Posts

It is actually not hard, but requires a certain insight into the physics of rocketry. Namely: the mass flow rate of propellant through a rocket engine at a given thrust is governed entirely by its specific impulse. This becomes apparent when you consider that specific impulse can be defined like this: "engine runs this long at 1 kN of thrust using 1 metric ton of propellant". This, incidentally, is why the unit for specific impulse is in seconds. It is literally a burn duration.

So you don't need to worry about propellant ratios and the like. The only thing you need to touch is the atmosphereCurve submodule inside ModuleEnginesFX. As an example, the Swivel engine has this in its config file:

atmosphereCurve
{
	key = 0 320
	key = 1 270
	key = 6 0.001
}

Each "key" is a point along a curve, and is defined by two (technically four) values. On the x axis, you have atmosphere density. On the y axis, you have specific impulse. Then there are two optional tangent numbers, which help shape the curve, but are not required here (and hence, there are only two numbers visible above in each line, not four).

The first point is a 0 atmospheres worth of pressure - in other words, vacuum. There you will find the Swivel's 320s vacuum Isp. The second point is at 1 atmospheres worth of pressure - this is sea level. Again, you'll recognize the 270s. Finally, there's another point at 6 atmospheres of pressure, where pretty much zero Isp is left; this is the point at which the engine gets choked into uselessness. It is relevant for places like Eve. Engines which perform better at high pressures are better for use deep inside Eve's atmosphere.

A simple tweak to make the Swivel engine more fuel efficient would be to just replace the 320 with a 420, and the 270 with a 370. That would make the Swivel have 100s Isp more than before across all normal regimes (though it would still get choked at 6 atmospheres of pressure).

However! It is a bad plan to go into the base game files and start making changes. If you don't know what you're doing, you might end up breaking something, and you'll be unable to revert it - and then you have to reinstall the game. Not the best plan. A much better idea is to use Module Manager. This mod lets you write config files that change other config files while the game is running, so you can leave the original intact. If you break something, all you need to do to fix things is to remove the faulty MM patch. I invite you to read up on how to use Module Manager in the first two posts of the mod's forum thread. Note: you should be able to understand how config files work in the first place. When in doubt, take a good hard look at how they are structured (protip: they work like tupperware boxes inside tupperware boxes). If you have specific questions, feel free to ask.

Here's a sample MM patch that will tweak the Isp of an engine of your choice:

@PART[name]
{
	@MODULE[ModuleEnginesFX]
	{
		@atmosphereCurve
		{
			@key,0 = 0 xxx
			@key,1 = 1 xxx
		}
	}
}

To make it work, you need to do four things:

1.) Install Module Manager, if you don't already have it (it comes bundled with nearly every other mod out there, but can also be downloaded stand-alone).
2.) Copy the above into a textfile, save it with a file extension of .cfg, and place it anywhere you like in your GameData folder.
3.) Where is says 'name' in square brackets, you need to put the internal part name of the engine you wish to modify. You find this name inside the engine's config file, near the top, where it says name = something. For example, for the Swivel, the internal part name would be liquidEngine2.
4.) Where is says 'xxx', put in your desired vacuum and atmospheric Isp values.

 

Hope that helped! :)

Edited by Streetwind
Link to comment
Share on other sites

  • 4 weeks later...
3 hours ago, Dreimal00 said:

@Streetwind
  How would you go about changing max thrust with MM 

That's actually even easier, because you don't need to know anything about float curves. The thrust value is just one single number that's changed directly.

In fact, you should be able to solve this problem yourself just by looking at the config file of the engine you want to change. Find where the thrust is specified, then use the same Module Manager syntax I used in the example up above (with the @ in front of each layer of nested subsections denoting "make a change") to write a patch. It's even the same subnode (ModuleEnginesFX), so you can copy&paste most of it.

But since I'm hoping to help you learn something, you'll have to forgive me for not spoiling the answer immediately :wink: Try it yourself, and if it ends up not working, show me how you tried to do it and I'll show you where the mistake is.

Link to comment
Share on other sites

The electric charge rate of what? The production of an engine's alternator? The consumption of an ion engine? The production of solar panels? The consumption of an ISRU unit? :P Believe it or not, all four are actually done differently, so I can't answer you directly.

But it all boils down to the same thing. You look at the source config in order to find where the value is located. Then, you write a MM patch by traversing from the top layer of the nested node structure using @ signs to the layer where you need to make the change. Finally, you call up the required fields, again with an @ sign, and enter the new value.

Targeting of individual MODULE nodes is done by mentioning the 'name' of the node in square brackets, where 'name' is a field inside that node. Each PART node has a 'name = something' field, which is why you can do @PART[something] with Module Manager. And the same counts for subnodes. A MODULE which includes 'name = ModuleEnginesFX' can be accessed as @MODULE[ModuleEnginesFX]. And a RESOURCE which includes 'name = oxidizer' can be accessed as @RESOURCE[oxidizer]. The text inside the square brackers is like a search term, and it looks for the contents of the 'name' field. It will reliably find the node (on the current layer of nesting) that has that name. Module Manager can also distinguish two nodes with the same name, but you don't need it that often.

(The thing with the atmosphereCurve at the beginning of this thread is actually a special case. It's a node that doesn't have a 'name' field. Which is why you access it without square brackets. It works because it is unique - there can only ever be one such field inside a ModuleEnginesFX, and MM knows that.)

 

Sometimes you admittedly need to do some trial and error testing, because changing the value is one thing, but knowing what to change it to may be quite another. For example, the power production of an engine's alternator is set directly; if you want it to produce 10 Ec/s, you write the number 10 into the config inside ModuleAlternator. But the power consumption of for example the ion engine is not set directly. Instead you will find a 'ratio = something' field which seems to have nothing to do with the EC rate that you see ingame. That is because, as you now know after your initial question, the game auto-calculates resource consumption of an engine from specific impulse alone. So what you actually specify is a mixture ratio of two propellants. Specific impulse dictates that the engine consumes a certain number of volume units of xenon per second while it is running, and the mixture ratios of both propellants combined then dictate that a certain number of units of Ec are also consumed at the same time. Thus in order to change the power consumption, you need to change the mixture ratio so that the mixture contains more (or less) Ec per unit of xenon.

Thus, each module works a little differently. You can generally figure it out pretty quickly just by going and changing the numbers a few times, to see how the values inside the game change in response.

A useful tool for testing is Module Manager's ability to reload patches without quitting the game. On the space center screen, hit Alt+F11. You get a small menu where you can press 'reload database'. You can alt+tab out of KSP, make a change in your MM patch, save it, reload the database and observe the effects of your change, all without having to restart KSP.

Edited by Streetwind
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...