Open Resource System (ORS) - Mod Resource API - version 1.4.2

[RoverDude]

Version 1.3.0 Released

Changelog

-Main downloaded updated for 0.24 compatibility
-New Part Extension methods: instead of calling ORSHelper.fixedResourceResource(part,....), you can call part.ImprovedRequestResource(...).  
-Additionally added Part extension methods for GetConnectedResources() which could be handy.

Welcome back!

May want to get with Wave as there were other things/pull requests done in his branch of ORS (which is pretty much the same one I use for my entire mod constellation at this point due to the break with 0.24.2). Would be nice to get everyone back on the same canonical version.

[Fractal_UK]

Welcome back!

May want to get with Wave as there were other things/pull requests done in his branch of ORS (which is pretty much the same one I use for my entire mod constellation at this point due to the break with 0.24.2). Would be nice to get everyone back on the same canonical version.

I had a brief peruse and it looked like the changes were approximately equivalent so there shouldn't be a major barrier to adoption but it would be good to get that confirmed by someone more in the loop than I am.

[RoverDude]

I had a brief peruse and it looked like the changes were approximately equivalent so there shouldn't be a major barrier to adoption but it would be good to get that confirmed by someone more in the loop than I am.

Including all of the SCANSat integration bits? Though the larger is going to be the duplicate key bit that causes older versions of ORS to lag into oblivion. IMO the ideal place to land would be an ORS that is common to KSPI, KSPI-L, and the USI mods (Karbonite, MKS, etc.) and that has more active inclusion of pull requests (as we've seen in the fork we've been using for the past couple of months). Then the only rub comes down to resource definition. Solved most of that during your hiatus with KSPI-L which now is in sync with TAC, US, NFT, MKS, etc. - so the question would be whether the original KSPI plays well in that sandbox. Though that is more of a KSPI issue not an ORS issue.

That being said, the one barrier to adoption will be the default resource definitions, as having these bundled gets really weird with CRP (which bundles all of the shared ORS configs in one package). So if those could move to KSPI vs. ORS that would make things easier.

[thisischrys]

Is it ok to load two versions of ORS dlls at the same time? Interstellar Lite and MKS include older versions.

Or is it better to not include the ORS folder from those? MKS also has OpenResourceSystem_1_2_0.dll in \UmbraSpaceIndustries, should I leave that one?

[RoverDude]

Is it ok to load two versions of ORS dlls at the same time? Interstellar Lite and MKS include older versions.

Or is it better to not include the ORS folder from those? MKS also has OpenResourceSystem_1_2_0.dll in \UmbraSpaceIndustries, should I leave that one?

MKS (or any mod that uses CRP, which includes a few outside of my constellation) are not compatible with KSPI at this time, other than the current version of KSPI-L (which uses CRP, just like MKS does).

[undercoveryankee]

Is it ok to load two versions of ORS dlls at the same time? Interstellar Lite and MKS include older versions.

Or is it better to not include the ORS folder from those? MKS also has OpenResourceSystem_1_2_0.dll in \UmbraSpaceIndustries, should I leave that one?

It's generally safe to have an older version-numbered ORS dll in the folder of a plugin that depends on it, as long as GameData/OpenResourceSystem/Plugins/ contains the most recent version and there are no duplicate resource keys. It worked to have UmbraSpaceIndustries/OpenResourceSystem_1_2_0.dll after WaveFunctionP released an ORS 1_2_1. But like RoverDude said, there are resource conflicts that still need to be resolved between CRP and non-Lite KSPI, so trying to run them together out of the box will lead to sadness.

Fractal's development branch of KSPI seems to be pretty good with keeping all of the resources it uses configurable, so I doubt you would have to change the plugin if you wanted to take a stab at integration yourself. If you want the whole constellation to work out of the box, I'd still recommend sticking with KSPI Lite and CRP.

Edited September 17, 2014 by undercoveryankee

[RoverDude]

It's generally safe to have an older version-numbered ORS dll in the folder of a plugin that depends on it, as long as GameData/OpenResourceSystem/Plugins/ contains the most recent version and there are no duplicate resource keys. It worked to have UmbraSpaceIndustries/OpenResourceSystem_1_2_0.dll after WaveFunctionP released an ORS 1_2_1. But like RoverDude said, there are resource conflicts that still need to be resolved between CRP and non-Lite KSPI, so trying to run them together out of the box will lead to sadness.

Fractal's development branch of KSPI seems to be pretty good with keeping all of the resources it uses configurable, so I doubt you would have to change the plugin if you wanted to take a stab at integration yourself. If you want the whole constellation to work out of the box, I'd still recommend sticking with KSPI Lite and CRP.

The weird bit is we have two forks - an ORS 0.2.1 that is actually further ahead (things like duplicate key detction, better SCANSat integration, etc.) than the 0.1.3 branch. And yep, couple that with some flat-out incompatibilities in resource structure (MKS and KSPI-L use CRP, Fractal's KSPI uses it's own thing), we're in an odd spot until I see how things shake out. And for the record, I really can't do another breakage of MKS - the pain was enough the last time.

[Fractal_UK]

Here is what I recommend:

In future Oceanic and Atmospheric resource definitions should be wrapped into another ConfigNode describing the pack of their origin, as follows:

ATMOSPHERIC_RESOURCE_PACK_DEFINITION
{
    name = ExamplePack
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveCarbonDioxide
	guiName = Carbon Dioxide
	celestialBodyName = Eve
	abundance = 0.6217
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveNitrogen
	guiName = Nitrogen
	celestialBodyName = Eve
        abundance = 0.3654
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveArgon
	guiName = Argon
	celestialBodyName = Eve
	abundance = 0.0103
    }

    .....

}

The same should be repeated with OCEANIC_RESOURCE_PACK_DEFINITION. Now, the user should have only one of these packs so I will set it up such that ORS will load from only one pack.

A new directory should probably be created called ORSResourcePack to contain the oceanic and atmospheric definitions, this should be the standard mechanism for distributing packs and should make it easier for the user to make sure they only have one installed at a time.

How does that sound?

[RoverDude]

Here is what I recommend:

In future Oceanic and Atmospheric resource definitions should be wrapped into another ConfigNode describing the pack of their origin, as follows:

ATMOSPHERIC_RESOURCE_PACK_DEFINITION
{
    name = ExamplePack
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveCarbonDioxide
	guiName = Carbon Dioxide
	celestialBodyName = Eve
	abundance = 0.6217
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveNitrogen
	guiName = Nitrogen
	celestialBodyName = Eve
        abundance = 0.3654
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveArgon
	guiName = Argon
	celestialBodyName = Eve
	abundance = 0.0103
    }

    .....

}

The same should be repeated with OCEANIC_RESOURCE_PACK_DEFINITION. Now, the user should have only one of these packs so I will set it up such that ORS will load from only one pack.

A new directory should probably be created called ORSResourcePack to contain the oceanic and atmospheric definitions, this should be the standard mechanism for distributing packs and should make it easier for the user to make sure they only have one installed at a time.

How does that sound?

Sure, as long as it only loads one then that takes care of that particular issue. What about planetary resources though? The dup key issue is the current showstopper. Will that follow a similar pattern where only one planetary resource file is loaded?

The only issue I see with having a specified folder is that it's confusing to users if they have two mods that have ORS definitions (thus making it a bit less open). Why not just handle it via dropping any duplicate keys that hit? So if a user installs both CRP and KSPI, they get the net of both packs, but in the event that both packs define water, only one gets loaded?

(EDIT)

ORS as a whole is going to have to be robust enough to handle multiple mods using it simultaneously and by folks who do not care to be in the same playground and who will absolutely duplicate and stomp over keys. Thus duplicate checking and multiple mod support from a config standpoint is pretty critical.

Edited September 17, 2014 by RoverDude

[undercoveryankee]

Here is what I recommend:

In future Oceanic and Atmospheric resource definitions should be wrapped into another ConfigNode describing the pack of their origin, as follows:

ATMOSPHERIC_RESOURCE_PACK_DEFINITION
{
    name = ExamplePack
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveCarbonDioxide
	guiName = Carbon Dioxide
	celestialBodyName = Eve
	abundance = 0.6217
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveNitrogen
	guiName = Nitrogen
	celestialBodyName = Eve
        abundance = 0.3654
    }
    ATMOSPHERIC_RESOURCE_DEFINITION
    {
	name = EveArgon
	guiName = Argon
	celestialBodyName = Eve
	abundance = 0.0103
    }

    .....

}

The same should be repeated with OCEANIC_RESOURCE_PACK_DEFINITION. Now, the user should have only one of these packs so I will set it up such that ORS will load from only one pack.

A new directory should probably be created called ORSResourcePack to contain the oceanic and atmospheric definitions, this should be the standard mechanism for distributing packs and should make it easier for the user to make sure they only have one installed at a time.

How does that sound?

I like it. I would probably name the top-level nodes something like ATMOSPHERIC_RESOURCE_PROFILE and OCEANIC_RESOURCE_PROFILE if it were up to me, but the concept is solid.

Using ModuleManager to inject a resource into an existing pack or change a resource from information-only to extractable is possible, and a patch that specifically looks for and tries to modify a known pack will be easier to write without breaking anything than a patch for "any definitions that happen to be loaded."

If we adopt this, it will be nice if pack authors try to keep up a wiki page with the names of published packs and try to avoid using the same name for different packs.

[RoverDude]

I like it. I would probably name the top-level nodes something like ATMOSPHERIC_RESOURCE_PROFILE and OCEANIC_RESOURCE_PROFILE if it were up to me, but the concept is solid.

Using ModuleManager to inject a resource into an existing pack or change a resource from information-only to extractable is possible, and a patch that specifically looks for and tries to modify a known pack will be easier to write without breaking anything than a patch for "any definitions that happen to be loaded."

If we adopt this, it will be nice if pack authors try to keep up a wiki page with the names of published packs and try to avoid using the same name for different packs.

I'd anticipate and expect that mod authors are going to break things randomly, duplicate keys, and not play nice Cover that case and anything else is gravy.

[madlemur]

I'd anticipate and expect that mod authors are going to break things randomly, duplicate keys, and not play nice Cover that case and anything else is gravy.

Aye. No matter how easy you make it to play together and have nice things, there will always be someone who, through inattention, ignorance, inexperience, or infernally malicious sociopathy, will not play nice, and will break not just other peoples things, but all the things...

[RoverDude]

Aye. No matter how easy you make it to play together and have nice things, there will always be someone who, through inattention, ignorance, inexperience, or infernally malicious sociopathy, will not play nice, and will break not just other peoples things, but all the things...

One way to correct this in the case of ORS would be to have the unique key be a combination of ORS key and package, and not really care where the configs are. So I can continue to keep my ORS version in the USI folder, and my configs in the CRP folder without stomping on KSPI or vice versa.

[Fractal_UK]

One way to correct this in the case of ORS would be to have the unique key be a combination of ORS key and package, and not really care where the configs are. So I can continue to keep my ORS version in the USI folder, and my configs in the CRP folder without stomping on KSPI or vice versa.

I don't think it ultimately makes sense for their to be multiple sets of configs, it really breaks immersion if you're looking at a set of concentrations in one part which is telling you one thing and another part tells you another. It also becomes confusing because you have to start using different instruments to measure the resources associated with different mods.

Hence seperate the resource definitions cfgs from ORS into a seperate ORSResourcePack directory. The user then decides which pack they want to use, for now I'll probably just load the first if for some reason there are two but in future I might a drop-down list in the space centre so that users can switch between their resource config options there.

[RoverDude]

I don't think it ultimately makes sense for their to be multiple sets of configs, it really breaks immersion if you're looking at a set of concentrations in one part which is telling you one thing and another part tells you another. It also becomes confusing because you have to start using different instruments to measure the resources associated with different mods.

Hence seperate the resource definitions cfgs from ORS into a seperate ORSResourcePack directory. The user then decides which pack they want to use, for now I'll probably just load the first if for some reason there are two but in future I might a drop-down list in the space centre so that users can switch between their resource config options there.

Kinda defeats the purpose of an Open Resource System if it's not really open

Say for example someone wants to play with KSPI and MKS at the same time... they won't be able to unless we're in lockstep. Then if someone else wants to include a mod that added spice harvesting to Duna... well, it gets weird.

[Fractal_UK]

Kinda defeats the purpose of an Open Resource System if it's not really open

Say for example someone wants to play with KSPI and MKS at the same time... they won't be able to unless we're in lockstep. Then if someone else wants to include a mod that added spice harvesting to Duna... well, it gets weird.

As far as I can tell, the entire purpose of the CRP is to make sure that a bunch of mods are using the same resource defintions, the whole point of this change is to support things like that. All I will be doing is enforcing that you have to commit to one pack or another for atmospheric and oceanic resource definitions. In other words, if Kerbin has 20% Oxygen in it's atmosphere in one ORS-based mod, it must have 20% Oxygen in all ORS-based mods. If one mod tells you 20% and another tells you 10%, it's just not helpful to the player and it doesn't provide a good experience.

Planetary resource definitions are a completely different kettle of fish, so if someone wants to create a mod with spice resource maps for Duna and the ability for harvesting them, they can regardless of choice of pack.

[DMagic]

Planetary resource definitions are a completely different kettle of fish, so if someone wants to create a mod with spice resource maps for Duna and the ability for harvesting them, they can regardless of choice of pack.

Regardless of what happens with the other types of resources it's planetary resources that are the most common cause of critical errors in ORS.

The first thing that should be done, and already has been done (WaveFunctionP's development branch already contains a number of fixes to ORS and should probably be the starting point for any further development), is to fix the loading mechanism for planetary resources to prevent the game becoming unplayable when someone uses multiple copies of the same resource (and someone will always do this, regardless of how careful you are about distribution). The CRP already nicely handles the issue of multiple mods distributing the same resources in different packages, so I don't see any reason not to continue using that going forward.

[RoverDude]

Regardless of what happens with the other types of resources it's planetary resources that are the most common cause of critical errors in ORS.

The first thing that should be done, and already has been done (WaveFunctionP's development branch already contains a number of fixes to ORS and should probably be the starting point for any further development), is to fix the loading mechanism for planetary resources to prevent the game becoming unplayable when someone uses multiple copies of the same resource (and someone will always do this, regardless of how careful you are about distribution). The CRP already nicely handles the issue of multiple mods distributing the same resources in different packages, so I don't see any reason not to continue using that going forward.

Yep, crustal resources are our current bone of contention and I agree that it would be best if the work done on guard clauses, etc. was integrated if it has not already been done.

[Fractal_UK]

Yep, crustal resources are our current bone of contention and I agree that it would be best if the work done on guard clauses, etc. was integrated if it has not already been done.

Already done in my working copy.

[RoverDude]

Already done in my working copy.

How soon are we looking at getting an update? I'm currently testing all of my work in anticipation of the 0.25 release, and have to make some hard decisions on how I handle resources before it hits.

Thanks

Edited September 19, 2014 by RoverDude

[Fractal_UK]

Version 1.4.0 Released

Here is your update!

changelog:

-Duplicate key detection for planetary resources
-Exposed IDictionary of current planetary resource info
-Atmospheric/Oceanic resources organised into map packs as described in #209
-Default atmospheric/oceanic resources removed from ORS
-Internal code more concise

[RoverDude]

Version 1.4.0 Released

Here is your update!

changelog:

-Duplicate key detection for planetary resources
-Exposed IDictionary of current planetary resource info
-Atmospheric/Oceanic resources organised into map packs as described in #209
-Default atmospheric/oceanic resources removed from ORS
-Internal code more concise

Thanks! Will start testing this

[Fractal_UK]

Thanks! Will start testing this

Great, let me know if that seems to be working as you need.

[DMagic]

Any specific reason why this, this, and this weren't implemented? The first two fix fairly critical bugs that can make the game unplayable in some cases, the third just makes things vastly simpler for accessing through reflection.

Also, is there anywhere where the source is available online? All I see is older versions on GitHub and Bitbucket; I'd rather not have to resort to ILSpy to get to the source. Edit: nevermind, I just noticed how recently it was updated here.

[Fractal_UK]

Any specific reason why this, this, and this weren't implemented? The first two fix fairly critical bugs that can make the game unplayable in some cases, the third just makes things vastly simpler for accessing through reflection.

Also, is there anywhere where the source is available online? All I see is older versions on GitHub and Bitbucket; I'd rather not have to resort to ILSpy to get to the source. Edit: nevermind, I just noticed how recently it was updated here.

I've incorporated the first two changes but I don't like the last one because it means there is two copies of almost the same code in ORSPlanetaryResourceMapData and that is really bad for maintenance.

As an alternative, I've added getPixelAbundanceValue(int pix_x, int pix_y) and getLatLongAbundanceValue(double lat, double lng) to ORSPlanetaryResourceInfo and the getResourceAvailability methods in ORSPlanetaryResourceMapData now just call these methods for the appropriate ORSPlanetaryResourceInfo object rather than handling doing the actual calculations.

You can get access to the ORSPlanetaryResourceInfo's pixel abundances by using the ORSPlanetaryResourceMapData.PlanetaryResourceMapData property which returns an IDictionary<string, ORSPlanetaryResourceInfo>.

This has actually made the code quite a bit neater.