[0.24.2] Generic Resource Converter v1.22[Updated 8/5/14]

[okbillybunnyface]

[0.24.2] RESOURCECONVERTER v1.22

----------------------------------------

This is a simple plugin to do resource conversion in a part that doesn't have some of the hang-ups that the stock generator module does. It's intended for use by modders.

I made this to help out the guys making Universal Storage, but I thought I'd make a release thread in case someone else has a use for it.

INSTALLATION:

Simply copy the contents ResourceConverter1.22.zip into your KSP directory, and make the necessary additions to the part's part.cfg (detailed below).

MODULE

{

name = ModuleResourceConverter

canOverflow = false //--optional, defaults to false (If set to true, the converter will continue to operate, consuming input resources, even if one of the outputs is full.)

deactivateIfFull = false //--optional, defaults to false (If set to true, the converter automatically deactivates if one of the output resources is full.)

deactivateIfEmpty = false //--optional, defaults to false (If set to true, the converter automatically deactivates if there one of the input resources is missing. If false, it will continue to 'operate' at 0 speed)

INPUT_RESOURCE

{

name = ElectricCharge

rate = 1

}

INPUT_RESOURCE

{

name = LiquidFuel

rate = 1

}

OUTPUT_RESOURCE

{

name = MonoPropellant

rate = 1

}

OUTPUT_RESOURCE

{

name = Oxidizer

rate = 1

}

}

Download: https://bitbucket.org/okbillybunnyface/moduleresourceconverter/downloads/ResourceConverter1.22.zip

Source Code: https://bitbucket.org/okbillybunnyface/moduleresourceconverter/src/

Changelog:

v1.22 8/5/2014

-fixed a small bug with passing negative amounts to the RequestResource method (I forgot to add an absolute value....)

v1.21 8/5/2014

-Changed the new RequestResource() method to be public (oops). This is a very minor change that won't affect anything unless you plan on making plugins that use the method in this .dll.

v1.2 8/5/2014

-Wrote a (much) better version of the stock part.RequestResource() method. Like, there's no comparison.

-Rewrote the entire Convert() method to be more robust and to make use of the new RequestResource() method.

v1.1 8/2/2014

-Added a status field to converters.

-Added canOverflow functionality

-Fixed bug with resource flow modes (hopefully, seemed to work)

Known Issues:

-At large timewarps, the converter may be limited by the total amount of a resource on the vessel rather than (such as with electric charge) the income rate. I'm fairly certain this is due to the order in which resource calculations are performed from one part to the next, and I'm not sure how to fix it. For instance, the converter uses up all the electricity on its turn, but the electric generators don't actually get to replenish it until it's their turn. Solution: Add a bunch of batteries. More info here

License: Feel free to use or edit this however you want to. You can credit me if you like, but it is not necessary.

Edited August 5, 2014 by okbillybunnyface

[Paul Kingtiger]

Hey Billy,

I've narrowed down the problem I'm having with US. Everything works great if I use stock resources, but as soon as I try it with one of our own it doesn't work.

I've tried with Oxygen and Water, turning both into Oxygizer and Monoprop, but as soon as you click on activate it flashings but nothing happens, like it's instantly turning off.

I tried to add the resources definition to the stock file to see if that might be causing it, but it doesn't make any difference. Below is a sample of the resource definition, I've checked it against the stock resources and it looks good.

RESOURCE_DEFINITION
	{
		name = Water
		density = 0.001
		unitCost = 0
		flowMode = ALL_VESSEL
		transfer = PUMP
		isTweakable = true
	}

I've also uploaded the version of US I'm using and a craft file at:

http://1drv.ms/1tKi3f3

[rynak]

I've been looking for a replacement of resgen, so this might fit the bill, once bugs have been ironed out.

One question: I suppose just as with resgen, this will only work for currently loaded crafts, correct? Vessels out of the so-called rendering range, will not be running this plugin?

[Paul Kingtiger]

Finally managed to sit down and spend a good 3 hours of testing.

So the generator only works if at least 1 of the input resources has the flowMode = STACK_PRIORITY_SEARCH

I'm not sure how flowMode = STACK_PRIORITY_SEARCH works, but it appears that it takes from the top tank in the stack (following fuel flow allowed restrictions). I don't think that'll cause a problem for US or most other mods.

[okbillybunnyface]

Finally managed to sit down and spend a good 3 hours of testing.

So the generator only works if at least 1 of the input resources has the flowMode = STACK_PRIORITY_SEARCH

I'm not sure how flowMode = STACK_PRIORITY_SEARCH works, but it appears that it takes from the top tank in the stack (following fuel flow allowed restrictions). I don't think that'll cause a problem for US or most other mods.

Thanks for debugging that. Did this happen when you were using the stock generator?

Edited August 2, 2014 by okbillybunnyface

[okbillybunnyface]

I've been looking for a replacement of resgen, so this might fit the bill, once bugs have been ironed out.

One question: I suppose just as with resgen, this will only work for currently loaded crafts, correct? Vessels out of the so-called rendering range, will not be running this plugin?

That is correct. I'll see about adding in the ability to convert on unloaded crafts after I get the initial bugs out.

[Parokki]

Finally a method that looks simple enough for me to understand for allowing my Kerbals to breathe the air and drink the water collected by Interstellar parts! Yay!

[okbillybunnyface]

Uploaded a fancy new version. I highly recommend you replace the old one. It's quite a lot better.

[parachutingturtle]

This looks great, i just have one question about the "installation".

Wouldn't this be better as a mod on its own, one that could be used as a dependency in other mods? I mean, if multiple mods copy this dll into their Plugin folder, it'll be loaded multiple times pointlessly. (Sorry if this is a dumb question, i don't fully understand how mod dependencies are supposed to work in ksp anyway.)

[okbillybunnyface]

This looks great, i just have one question about the "installation".

Wouldn't this be better as a mod on its own, one that could be used as a dependency in other mods? I mean, if multiple mods copy this dll into their Plugin folder, it'll be loaded multiple times pointlessly. (Sorry if this is a dumb question, i don't fully understand how mod dependencies are supposed to work in ksp anyway.)

Indeed! I hadn't considered that, hah. I'll update the install instructions and make a folder structure to encourage consolidation. Thanks

Edited August 2, 2014 by okbillybunnyface

[Paul Kingtiger]

Hello,

I'm getting a minor issue at high time compression. Essentially, the resources appear to drain from the part, however when dropping back to lower compression the resources reappear (although at a lower value).

It looks like the resources are being used at the correct rate, but the display gets confused at high time compression.

It's a minor thing as it appears to be visual only, and only when maxed out on time. But I'm letting you know in case it's something you want to look at.

Example (with amazing stream of consciousness narration!)

http://youtu.be/zqcyHV4ut24

[okbillybunnyface]

Hello,

I'm getting a minor issue at high time compression. Essentially, the resources appear to drain from the part, however when dropping back to lower compression the resources reappear (although at a lower value).

It looks like the resources are being used at the correct rate, but the display gets confused at high time compression.

It's a minor thing as it appears to be visual only, and only when maxed out on time. But I'm letting you know in case it's something you want to look at.

Example (with amazing stream of consciousness narration!)

http://youtu.be/zqcyHV4ut24

Thanks.

That looks a lot like something I was encountering, but I didn't notice it happening on resources other than electric charge.

I'll try and see what's going on with it today. The converter keeps its own (hidden) stocks of input/output resources, and requests them independently of the conversion. I suspect it's requesting too fast for some reason.

Edited August 4, 2014 by okbillybunnyface

[okbillybunnyface]

Hello,

I'm getting a minor issue at high time compression. Essentially, the resources appear to drain from the part, however when dropping back to lower compression the resources reappear (although at a lower value).

It looks like the resources are being used at the correct rate, but the display gets confused at high time compression.

It's a minor thing as it appears to be visual only, and only when maxed out on time. But I'm letting you know in case it's something you want to look at.

Example (with amazing stream of consciousness narration!)

http://youtu.be/zqcyHV4ut24

Hold the phone--you said you had canOverflow set to false? That should actually stop it from working when it's full. I'll update the readme to specify that. If so, I suspect it's merely not making it to the step where it refunds the input resources for some reason. Them being at a lower final value is probably a rounding error somewhere.

Edited August 4, 2014 by okbillybunnyface

[okbillybunnyface]

Hold the phone--you said you had canOverflow set to false? That should actually stop it from working when it's full. I'll update the readme to specify that. If so, I suspect it's merely not making it to the step where it refunds the input resources for some reason. Them being at a lower final value is probably a rounding error somewhere.

Yeah... I'm definitely noticing bugs with the overflow I thought I had squished. I think I'm just going to bite the bullet and rewrite the part.RequestResource() method. I'm tired of its shenanigans. >_>;

[okbillybunnyface]

Debugging is hard when so much of the code I'm working with is obfuscated. Give us better documentation, Squad!

[Paul Kingtiger]

Hold the phone--you said you had canOverflow set to false? That should actually stop it from working when it's full. I'll update the readme to specify that. If so, I suspect it's merely not making it to the step where it refunds the input resources for some reason. Them being at a lower final value is probably a rounding error somewhere.

I don't have canOverflow set at all!

I have:

deactivateIfFull = false           
deactivateIfEmpty = false

So I'm guessing that without the line it defaults to false, and so stops when it runs out of output storage (Water).

I added in the line and I'm getting a different issue, everyone works great and low time compression, but when you go up high compression and back down outputs are produces but inputs not used up.

This seems to fix itself at 1000x compression.

http://youtu.be/eq7km8w5-nI

[Paul Kingtiger]

Debugging is hard when so much of the code I'm working with is obfuscated. Give us better documentation, Squad!

Considering how modding is a huge part of this game it would really help to have updated docs.

[okbillybunnyface]

Considering how modding is a huge part of this game it would really help to have updated docs.

I'm think making my own RequestResource method will solve most issues. It feels like I've been coding around the stock method to keep it from going bump in the night this entire time.

[okbillybunnyface]

I'm think making my own RequestResource method will solve most issues. It feels like I've been coding around the stock method to keep it from going bump in the night this entire time.

I wasn't entirely sure this would work, but it's transferring resources just fine, and on the first try no less. All I need to do is iron out a divide-by-zero error. I'm kind of proud of myself.

[okbillybunnyface]

I just released version 1.2. I wrote a new, way better version of the part.RequestResource() method, which I also commented the hell out of and tried to make easy for other modders to appropriate.

Additionally, as I no longer had to dance around the stock part.RequestResource() method, I rewrote pretty much all the code that does the actual resource conversion, and I believe it to be fairly robust now.

Please feel free to poke holes in it if you find any. I bug tested it as much as I know how to (without finding anything noteworthy ), but it's hard to fox out everything.

Edited August 5, 2014 by okbillybunnyface

[Paul Kingtiger]

I just released version 1.2

Sweet! I have this evening set aside for KSP stuff so I'll play around after work and let you know how I get on

[okbillybunnyface]

I accidentally set the new RequestResource() method to be private, so I changed it to public and uploaded a new version. This only affects you if you're a plugin author, so otherwise, feel free to ignore this one.

[Paul Kingtiger]

Had a quick play over lunch.

Seeing some strange behaviour at high time compression, although the sticking issue is completely fixed

It's looking like the convertor can't operate higher than x1000 so when you go faster it still uses resources at the same rate.

http://youtu.be/VIBOXhhkrrU

[okbillybunnyface]

Had a quick play over lunch.

Seeing some strange behaviour at high time compression, although the sticking issue is completely fixed

It's looking like the convertor can't operate higher than x1000 so when you go faster it still uses resources at the same rate.

http://youtu.be/VIBOXhhkrrU

Try putting a few big batteries on that and see if it helps.

[okbillybunnyface]

Had a quick play over lunch.

Seeing some strange behaviour at high time compression, although the sticking issue is completely fixed

It's looking like the convertor can't operate higher than x1000 so when you go faster it still uses resources at the same rate.

http://youtu.be/VIBOXhhkrrU

It actually appears to be capping out at around 5000x. Out of curiosity, what rate is that set to produce electric charge & water at? edit: nevermind, I just stuck US into my test build and rebuilt it

Edited August 5, 2014 by okbillybunnyface