Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unmanaged Resource feature discussion #218

Closed
Starwaster opened this issue Jan 31, 2019 · 4 comments
Closed

Unmanaged Resource feature discussion #218

Starwaster opened this issue Jan 31, 2019 · 4 comments

Comments

@Starwaster
Copy link
Contributor

Starwaster commented Jan 31, 2019

Creating this to have a place to discuss and track an upcoming feature: Unmanaged Resources. Put simply, this is the ability to define in a part config resources that will not be touched by Modular Fuel System or Real Fuels.

This primarily has life support mods in mind which might (for example) define Oxygen on a command pod which will also likely have ModuleFuelTanks defined on it. Typically we would define a number of TANK nodes with the life support resources so that they will not be deleted by MFS along with other resources. However, they can still be accidentally deleted by the player and there is no way to exempt those resources.

Now it is possible to do that. We can define as part of the ModuleFuelTanks config any number of UNMANAGED_RESOURCE nodes which will define a quantity of a given resource that will exist on the part separate from any tanks that it might have been configured with or that the player might have added. Details to follow but basically, if we define 5000 units of unmanaged Oxygen on a part, then the amount of Oxygen resource will be 5000 plus any Oxygen the player might have added via MFT. Attached is a build for KSP 1.3.1 (ignore any version errors)

RealFuels_for_1.3.1_unmanaged_resources.zip

@Starwaster
Copy link
Contributor Author

Starwaster commented Jan 31, 2019

// The UNMANAGED_RESOURCE reserves a portion of a resource that will not be touched by MFS/RF.
// Hence, it is 'unmanaged'. The node is placed inside a ModuleFuelTanks node and should be
// accompanied by the resource itself being placed in the PART. In this example, 5100 units of Oxygen
// are reserved for a Mk2Pod. This will prevent the user from accidentally deleting the Oxygen
// and then accidentally launching without it. This Oxygen could be for a life support mod and might
// represent O2 tanks or cabin air. These 5100 units will always be present even if all Oxygen tanks are
// deleted from the part. If additional Oxygen is installed via the tank GUI then that will be a quantity
// in addition to the original 5100. It will also be there regardless of
// what tank type the player might switch to. (i.e. ServiceModule, Default, etc)

@part[Mk2Pod]
{
	RESOURCE
	{
		name = Oxygen
		amount = 5100
		maxAmount = 5100
	}
	MODULE
	{
		name = ModuleFuelTanks
		basemass = -1
		volume = 665
		type = ServiceModule

		UNMANAGED_RESOURCE
		{
			name = Oxygen
			amount = 5100
			maxAmount = 5100
		}
	}
}

@pap1723
Copy link
Contributor

pap1723 commented Jan 31, 2019

Great stuff!

@Starwaster
Copy link
Contributor Author

That build should be mostly bug free - but you know how that goes. If I were totally sure it were bug free then I'd just push the changes live and call it a day.

A couple of issues: If there is a discrepancy between how FuelTank treats an amount of resource and what the UNMANAGED_RESOURCE says there is then FuelTank wins. For instance if I say there is unmanaged CarbonDioxide with amounts of 1000/1000 and the player were to add CarbonDioxide, then the actual amount will be 0/1000 because CarbonDioxide amount always defaults to 0 in the TANK node. And that's really how it should be as far as life support mods go so it's probably a non-issue

The other thing is that the code doesn't currently guard against defining multiple UNMANAGED_RESOURCE of the same named resource, and it should. If the author were to define multiples of a single resource, only one would be used which might result in unintended behavior that wouldn't be reported or logged, so that's something I intend to take care of before this goes live.

@Starwaster
Copy link
Contributor Author

(this was implemented in 6efb387)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants