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

[Beale]

Last I checked he's breaking the Karbonite dependency

Okay! I can stick with the blobs for now, but that is good to hear

Many thanks.

About ORSModuleResourceExtraction , I guess it has no default animation component?

[RoverDude]

Okay! I can stick with the blobs for now, but that is good to hear

Many thanks.

About ORSModuleResourceExtraction , I guess it has no default animation component?

Nope, I added in my own via a plugin.

[Beale]

For your other questions:

2. Plugins. I've done both for Karbonite - feel free to nose around the code, it's CC

3. See point 2 above. Solved problem.

For my own curiosity... given that everything I've seen thus far is pretty much the same as Karbonite minus the parts (it's just a single resource skin over ORS with the plugins you asked about above), why not Karbonite?

(to be clear - more mods is awesome - but I am always interested to see what kind of stuff I missed on - it's where I get ideas for improvements).

I'll be sure to have a look at the source!

For your question:

Karbonite is very good, I've been using it since its first release.

But just to my tastes, it's quite big now in terms of parts (Karbonite powered engines, etc) and I really only want a simple scanning/extraction/conversion setup.

I suppose I could just delete some of the extra parts in Karbonite, but I figured it would be a bit of fun to try and make my own.

Hope this answers you

[RoverDude]

I'll be sure to have a look at the source!

For your question:

Karbonite is very good, I've been using it since its first release.

But just to my tastes, it's quite big now in terms of parts (Karbonite powered engines, etc) and I really only want a simple scanning/extraction/conversion setup.

I suppose I could just delete some of the extra parts in Karbonite, but I figured it would be a bit of fun to try and make my own.

Hope this answers you

Thanks! Always good to explore every chance for good feedback. Poke around the source, have fun, and if you have any questions post away as I tend to watch this thread.

[Cyrik]

Okay! I can stick with the blobs for now, but that is good to hear

Many thanks.

About ORSModuleResourceExtraction , I guess it has no default animation component?

just to chime in: the only thing thats dependent on karbonite/mks right now are the initial configs. if you add your resource to the base.cfg file it should automagicly get a button and thus an overlay. i´ll be removing even that dependency once i´m sure most people have ors 1.2 installed, since it exposes a list of ors minable resources and i dont need to specify it in a .cfg file.

tldr: remove mks/karbonite from Base.cfg, add your resource and you are done.

[Beale]

just to chime in: the only thing thats dependent on karbonite/mks right now are the initial configs. if you add your resource to the base.cfg file it should automagicly get a button and thus an overlay. i´ll be removing even that dependency once i´m sure most people have ors 1.2 installed, since it exposes a list of ors minable resources and i dont need to specify it in a .cfg file.

tldr: remove mks/karbonite from Base.cfg, add your resource and you are done.

I'll be sure to try that, thanks!

Thanks! Always good to explore every chance for good feedback. Poke around the source, have fun, and if you have any questions post away as I tend to watch this thread.

I do have one, now

I notice in the Karbonite code a reference to "ORSExtensions", which I can't seem to find.

This means I don't have access to create a list of type "ORSModuleRailsExtraction" (I'm trying to recreate the Karbonite Drill setup).

Edit: I am currently referencing "OpenResourceSystem_1_1_0" and am able to pull in "using OpenResourceSystem;"

Thanks

[RoverDude]

I'll be sure to try that, thanks!

I do have one, now

I notice in the Karbonite code a reference to "ORSExtensions", which I can't seem to find.

This means I don't have access to create a list of type "ORSModuleRailsExtraction" (I'm trying to recreate the Karbonite Drill setup).

Edit: I am currently referencing "OpenResourceSystem_1_1_0" and am able to pull in "using OpenResourceSystem;"

Thanks

It's on my GitHub under UmbraSpaceIndustries.

[Beale]

It's on my GitHub under UmbraSpaceIndustries.

Found it, thanks

I'll give it a proper read through, but TL;DR on the difference between "ORSModuleResourceExtraction" and "ORSModuleRailsExtraction"?

Does the drill require it to function as it does?

[undercoveryankee]

Found it, thanks

I'll give it a proper read through, but TL;DR on the difference between "ORSModuleResourceExtraction" and "ORSModuleRailsExtraction"?

Does the drill require it to function as it does?

ORSModuleRailsExtraction simulates extraction continuing to occur while the vessel is on rails. It's what all USI drills currently use, but if you don't want to depend on the USI dlls, you can use ORSModuleResourceExtraction and just not have the benefit of that feature.

[Beale]

ORSModuleRailsExtraction simulates extraction continuing to occur while the vessel is on rails. It's what all USI drills currently use, but if you don't want to depend on the USI dlls, you can use ORSModuleResourceExtraction and just not have the benefit of that feature.

Thanks!

I based my code a lot on the Karbonite drill code, but without animated drill bits (just a deploy/retract animation).

A few crashes later...

It's working! Mining Raw propellium at a rate of about 0.01 an hour (who cares, it works! )

Edited September 2, 2014 by Beale

[Cyrik]

propellium

now thats a great name, not sure why we have things like fuel:)

[WaveFunctionP]

I've run across a bug with my nuclear fuel reprocessors. Since tranistioning to enriched/depleted uranium, the flow mode was causing my refueling and reprocessing to not function. Refueling was a simple override of the flow mode via partresource.

Since the reprocessing is supposed to work on rails, and I'm entirely lacking in creativity, I added an alternate fixedRequestResource() which allows you to define the flowmode you would like to use. It shouldn't mess with existing functionality...I think thats how it works atleast.

public static double fixedRequestResource(Part part, string resourcename,  ResourceFlowMode resource_flow, double resource_amount)
        {
            List<PartResource> prl = new List<PartResource>();
            List<Part> parts = new List<Part>();
            part.GetConnectedResources(PartResourceLibrary.Instance.GetDefinition(resourcename).id, resource_flow, prl);
            ResourceFlowMode flow = resource_flow;
            prl = prl.Where(p => p.flowState == true).ToList();
            double max_available = 0;
            double spare_capacity = 0;
            foreach (PartResource partresource in prl)
            {
                parts.Add(partresource.part);
                max_available += partresource.amount;
                spare_capacity += partresource.maxAmount - partresource.amount;
            }

            if (flow == ResourceFlowMode.ALL_VESSEL)
            { // use our code
                double resource_left_to_draw = 0;
                double total_resource_change = 0;
                double res_ratio = 0;

                if (resource_amount > 0)
                {
                    resource_left_to_draw = Math.Min(resource_amount, max_available);
                    res_ratio = Math.Min(resource_amount / max_available, 1);
                }
                else
                {
                    resource_left_to_draw = Math.Max(-spare_capacity, resource_amount);
                    res_ratio = Math.Min(-resource_amount / spare_capacity, 1);
                }

                if (double.IsNaN(res_ratio) || double.IsInfinity(res_ratio) || res_ratio == 0)
                {
                    return 0;
                }
                else
                {
                    foreach (PartResource local_part_resource in prl)
                    {
                        if (resource_amount > 0)
                        {
                            local_part_resource.amount = local_part_resource.amount - local_part_resource.amount * res_ratio;
                            total_resource_change += local_part_resource.amount * res_ratio;
                        }
                        else
                        {
                            local_part_resource.amount = local_part_resource.amount + (local_part_resource.maxAmount - local_part_resource.amount) * res_ratio;
                            total_resource_change -= (local_part_resource.maxAmount - local_part_resource.amount) * res_ratio;
                        }
                    }
                }
                return total_resource_change;
            }
            else
            {
                if (resource_amount > 0)
                {
                    return part.RequestResource(resourcename, Math.Min(resource_amount, max_available));
                }
                else
                {
                    return part.RequestResource(resourcename, Math.Max(-spare_capacity, resource_amount));
                }
            }
        }

As always, let me know if I've been smoking crack.

[WaveFunctionP]

On another note, if anyone knows how to get ORS to negotiate the correct version so that we don't have to keep telling our users to delete the other guys ors folder that would be awesome. I haven't the fainted clue how to do this. There always seem to that one guy who hasn't update their ORS.

[Beale]

Hi!

I've noticed a slight performance hit when using very high density resource maps.

Something like:

When using this, the number of polygons being drawn when viewing hotspots is immense and slows my game down to the single numbers of frames (even on a pretty powerful PC).

Maybe I'm doing something wrong?

I think a good possibility would be to replace the 3D sphere map with a 2D circle, only visible in map view, which should be less of a performance hit and might be more aesthetically pleasing (In my opinion). Not sure how difficult this would be to implement, I believe you can directly draw basic colour geometry without textures with the GUI?

Edit: It's not so clear if this mod is still being actively developed?

Either way I am still loving this, the code especially is fun to extend and play around with, many thanks!

Edited September 7, 2014 by Beale

[WaveFunctionP]

New version:

Open Resource System v1.2.1
- Extended ORHHelper.fixedRequestResource() to include an arguement for ResourceFlowMode.
- added a changleog for ORS!

[RoverDude]

Hi!

I've noticed a slight performance hit when using very high density resource maps.

Something like:

http://puu.sh/bpSh0/f54121dcf6.jpg

When using this, the number of polygons being drawn when viewing hotspots is immense and slows my game down to the single numbers of frames (even on a pretty powerful PC).

Maybe I'm doing something wrong?

I think a good possibility would be to replace the 3D sphere map with a 2D circle, only visible in map view, which should be less of a performance hit and might be more aesthetically pleasing (In my opinion). Not sure how difficult this would be to implement, I believe you can directly draw basic colour geometry without textures with the GUI?

http://puu.sh/bpSOf/8d39a572df.jpg

Edit: It's not so clear if this mod is still being actively developed?

Either way I am still loving this, the code especially is fun to extend and play around with, many thanks!

Yep, still being developed

ORS really isn't happy about lots of objects being tossed out there. The sphere is already a primitive and it's basically having to redraw them all every tick because of line of sight. A consideration may be to go logarithmic if you are not already, it's a bit more tweakable.

[DMagic]

I've submitted another pull request for this. Primarily this is to simplify accessing resource values through reflection, allowing SCANsat to drop the ORS dependency. I suspect Cyrik's map overlay could use these methods too.

Not needing to distribute another ORS dll with SCANsat should alleviate some of the version problems that ORS has.

[RoverDude]

I've submitted another pull request for this. Primarily this is to simplify accessing resource values through reflection, allowing SCANsat to drop the ORS dependency. I suspect Cyrik's map overlay could use these methods too.

Not needing to distribute another ORS dll with SCANsat should alleviate some of the version problems that ORS has.

Excellent - is there a facility for having some ORS resources NOT on scansat? Karborundum is the new one that should not be located by any means other than on the ground.

[DMagic]

Excellent - is there a facility for having some ORS resources NOT on scansat? Karborundum is the new one that should not be located by any means other than on the ground.

I think it might show up in the list of resources in the settings menu, but you'll never be able to actually scan for it without explicit support, which isn't included, so nothing will show up on the map.

But yes, there is probably a better way of handling this; a few additions to the planetary resource configs might be a good idea. I'm thinking empty and full color fields for overlays (SCANsat or the ORSOverlay) and maybe a field to specify that it not be shown.

[DMagic]

I submitted another pull request with some optional fields for resource colors and a hidden flag.

Resources default to not-hidden, so nothing needs to be changed unless you have a special case like Karborundum that you don't want to show up on overlays. This doesn't specifically affect anything in ORS (though it could be used to adjust ORS scanners' behavior), it's just being used by SCANsat as a flag to ignore certain resources.

There are also options for low and high color values, so that resource creators can specify what colors they want for their resources on overlays; there are default values for these too (hello hot pink ).

They need to be entered as 0-1 float RGB values.

lowColor = 1, 0.8, 0.2
highColor = 1, 0.4, 0

Those are yellow and orange colors that I've been using to test Karbonite. They can have different values for each planet (the same goes for the hidden flag, as with any other ORS resource parameter).

To get these values from the more common 0-255 range just divide each value by 255.

The highColor value is 255, 102, 0 in standard format; divide each by 255 and you get 1, 0.4, 0. It's probably best not to include a fourth, alpha channel value.

Whenever you do update ORS I would ask that you name it OpenResourceSystem_1_3_0.dll, following the naming convention that's been used in the past, and make sure the assembly version is 1.3.0.0. I'll probably be updating SCANsat soon, and I have it set to check for this specific version of ORS ( it doesn't really matter if this isn't updated before SCANsat, ORS overlays won't work, but everything else will be fine).

My other suggestion here is that this should probably have a new thread. And that ORS should have its own repo, not be part of Interstellar.

[WaveFunctionP]

I submitted another pull request with some optional fields for resource colors and a hidden flag.

Resources default to not-hidden, so nothing needs to be changed unless you have a special case like Karborundum that you don't want to show up on overlays. This doesn't specifically affect anything in ORS (though it could be used to adjust ORS scanners' behavior), it's just being used by SCANsat as a flag to ignore certain resources.

There are also options for low and high color values, so that resource creators can specify what colors they want for their resources on overlays; there are default values for these too (hello hot pink ).

They need to be entered as 0-1 float RGB values.

lowColor = 1, 0.8, 0.2
highColor = 1, 0.4, 0

Those are yellow and orange colors that I've been using to test Karbonite. They can have different values for each planet (the same goes for the hidden flag, as with any other ORS resource parameter).

To get these values from the more common 0-255 range just divide each value by 255.

The highColor value is 255, 102, 0 in standard format; divide each by 255 and you get 1, 0.4, 0. It's probably best not to include a fourth, alpha channel value.

Whenever you do update ORS I would ask that you name it OpenResourceSystem_1_3_0.dll, following the naming convention that's been used in the past, and make sure the assembly version is 1.3.0.0. I'll probably be updating SCANsat soon, and I have it set to check for this specific version of ORS ( it doesn't really matter if this isn't updated before SCANsat, ORS overlays won't work, but everything else will be fine).

My other suggestion here is that this should probably have a new thread. And that ORS should have its own repo, not be part of Interstellar.

Why does it need two color definitions?

The naming convention hasn't ever been broken as far as I am aware. I am curious as to where you've run into someone using something different. I did release a 1.1 to fix for .24.1 and forgot to bump the version, but other than that I have been updating the name and version.

To be clear, if these questions have obvious answers, just assume that I am an idiot, because, well, I am.

Edited September 11, 2014 by WaveFunctionP

[DMagic]

Why does it need two color definitions?

For low and high concentrations. What those concentrations are is arbitrary, but having two colors allows you to lerp between the two of them creating a better looking overlay so you can see at a glance where the higher concentrations are.

[RoverDude]

Why does it need two color definitions?

The naming convention hasn't ever been broken as far as I am aware. I am curious as to where you've run into someone using something different. I did release a 1.1 to fix for .24.1 and forgot to bump the version, but other than that I have been updating the name and version.

To be clear, if these questions have obvious answers, just assume that I am an idiot, because, well, I am.

FYI. To fix the version breaking thing, it looks like as long as you reference your DLL by version (not the default OpenResourceSystem.dll) and include your version in your own plugin folder, the versioning issue is fixed. this is what we had to do to get MKS working again with an older ORS

[DMagic]

I was referring to naming the next version 1.3 instead of 1.2.2 or something like that. I just realized that it doesn't really matter though. When using reflection to get a method it's only the namespace that matters, and that is always OpenResourceSystem, regardless of what the actual file is called.

FYI. To fix the version breaking thing, it looks like as long as you reference your DLL by version (not the default OpenResourceSystem.dll) and include your version in your own plugin folder, the versioning issue is fixed. this is what we had to do to get MKS working again with an older ORS

I think this has always been the idea; point any hard-links at the numbered versions, and only update the non-numbered version, because it should be the first one to load. So if your plugin folder comes before ORS (obviously not a problem for something like SCANsat or USI, but if someone put it the community resource pack folder it would be loaded first) it might be problematic to include a different copy of the plugin in that folder.

[Fractal_UK]

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.