Universal Resource Transfer (Beamed Power Standalone for any resource)

[KspNoobUsernameTaken]

This is hereby designated as the dev thread. Release and main mod thread here:

 

 

Hey everyone. This is a fork of @Aniruddh's Beamed Power Standalone mod. The only new feature is that you can decide what resource is transmitted. The original author appears to have disappeared, and the mod was under an unlicense license, so I think it's fine to adopt it.

Configuration:

In GameData/UniversalResourceTransfer/Settings.cfg, you'll find the mods settings and instructions for changing them.

Managed resource is the resource the mod transmits.

GuiUnitName is the thing that shows up in the UI. EC/s etc.

This is just the resource transfer aspect of the mod, not the propulsion stuff. 

 

 

Limitations:

• The system can only manage one INPUT resource at a time. Multiple outputs are fully supported.
  • Multiple received resources can be handled in parallel as of V1.0.0
  • Multiple input resources in progress.
• Currently, GUI names are unchanged from the original mod. So it will still read "EC/s" etc. This will be changed in the first full release. 
  • Fixed
• Error handling: what to do if GuiUnitName or Managed resource isn't found.
  • Fixed, to be released.
  • Released

Future intentions:

• Adding a laser transmission mode for long distance transmission
  • Part of large rework in V2
• Allowing multiple resources to be transferred at the same time (theoretical, I've got an idea for how to do it but might not be able to implement it)
  • Multiple received resources complete and included in V1.0.0
  • Multiple output resource in progress; see dev branch MultipleInputResources.
• Creating a receiver part
  • Completed
• Dynamic gui units
  • Completed

Download:

https://github.com/ProgrammerFailure/Universal-Resource-Transfer/releases

Acknowledgements:

@Aniruddh for the original mod.

@HebaruSan for all his help with answering my questions.

@JadeOfMaar for the new receiver parts.

 

People who might be interested:

@theJesuit

@JadeOfMaar

 

Help needed:

• Suggestions for what to change the GUI names to. For example, "Transfer Rate" instead of "EC/s"
  • Completed
• Bug testing. I couldn't find any errors in my tests, but if anyone has experience looking for bugs, help would be greatly appreciated.

 

 

Dev notes (mainly for myself):

 

Edited August 20 by KspNoobUsernameTaken
new icon

[JadeOfMaar]

34 minutes ago, KspNoobUsernameTaken said:

Suggestions for what to change the GUI names to. For example, "Transfer Rate" instead of "EC/s"

Perhaps do like ModuleEngine does and get the abbreviation key value of the resource and append "/s" after it. An engine that eats LiquidFuel will show "LF/s." If it eats ThermalPower it will show "ThP/s" and so on.

Congrats on the WIP release.

47 minutes ago, KspNoobUsernameTaken said:

Creating a receiver part

Hold my beer.

[KspNoobUsernameTaken]

2 minutes ago, JadeOfMaar said:

Perhaps do like ModuleEngine does and get the abbreviation key value of the resource and append "/s" after it. An engine that eats LiquidFuel will show "LF/s." If it eats ThermalPower it will show "ThP/s" and so on.

That was my plan, but my early attempts failed horribly. I made a topic about it:

This was the answer I got:

Quote

You're not going to be able to pass a value from a config file into an [Attribute()], that just can't work based on how C# works. Attributes are a compile-time feature.

You could conceivably load the config file and then acquire a reference to the KSPField object and modify it at runtime, via  the Fields["ReceivedPower"] property on a given part module.

I'm looking into it, but for now I'll keep it static. 

 

6 minutes ago, JadeOfMaar said:

Hold my beer.

Assuming this means you'll make a model - thank you! Seriously, my modelling skills are subpar.  

I think I'll add dynamic GUI units to the future intentions list.

[JadeOfMaar]

9 hours ago, KspNoobUsernameTaken said:

Assuming this means you'll make a model - thank you! Seriously, my modelling skills are subpar.  

Yep. My quick and easy plan for this part is a roll-out panel with two texture themes: Rectenna Red or White (for ElectricCharge) and Heatsink Black (for ThermalPower).

Edited August 5 by JadeOfMaar

[KspNoobUsernameTaken]

Does anyone know how you fetch the short name of a resource in code? Assuming you have the resource name and hash?

 

No longer necessary as of v0.1.1

Edited August 6 by KspNoobUsernameTaken

[KspNoobUsernameTaken]

I'm pretty sure I can make it display Thermal power or ElectricCharge etc based on the managed resource, but I don't know how to fetch the display/short names.

[fatcargo]

Will this work only with resource tanks within craft loading range, or will it be able to transfer resources to/from unloaded parts as well ?
If considering unloaded parts/crafts, this will need to be addressed because if there are custom plugins capable of processing/generating resources in background, those plugins may assume that nobody is touching resources onboard unloaded parts/crafts.

Do note that this may very well be one of the endgame mechanics for ultimate logistics / resource management.
Sigh ...TLDR - original plugin thread does point to handling resources for unloaded parts/vessels XD.

Edited August 5 by fatcargo

[KspNoobUsernameTaken]

12 hours ago, fatcargo said:

Will this work only with resource tanks within craft loading range, or will it be able to transfer resources to/from unloaded parts as well ?
If considering unloaded parts/crafts, this will need to be addressed because if there are custom plugins capable of processing/generating resources in background, those plugins may assume that nobody is touching resources onboard unloaded parts/crafts.

Do note that this may very well be one of the endgame mechanics for ultimate logistics / resource management.
Sigh ...TLDR - original plugin thread does point to handling resources for unloaded parts/vessels XD.

Unloaded vessels are supported, based on the standard catch up mechanism of KSP

 

There's also an actual background processing feature, but I have not tried it yet.

Edited August 6 by KspNoobUsernameTaken
delete the extra quote

[KspNoobUsernameTaken]

23 hours ago, JadeOfMaar said:

Perhaps do like ModuleEngine does and get the abbreviation key value of the resource and append "/s" after it. An engine that eats LiquidFuel will show "LF/s." If it eats ThermalPower it will show "ThP/s" and so on.

Alright, I've successfully made the resource names dynamic. There is a new line in settings.cfg, GUIUnitName, which controls this. Screenshot below:

 

https://imgur.com/a/Jaof36Y

[KspNoobUsernameTaken]

This is enough for full release; currently, the main goal of the mod has been achieved. It does everything Beamed Power Standalone does, but I'll do some further testing, and possibly include @JadeOfMaar's receiver part, if its made soon. 

[KspNoobUsernameTaken]

@JadeOfMaar,

If you plan to integrate with sterling systems, would you prefer patches for this mod to be in sterling systems or this mod?

 

I've been wondering what to do if people actually start using this and we end up with 1 mod wanting EC transmission and the other ThP transmission etc. With the current system, they would both have to replace the Settings.cfg file.

[JadeOfMaar]

@KspNoobUsernameTaken I'm close to finishing the sample part for this mod. It's a roll out kind. 0.625m bottom node, 48 m² surface area. Rectenna Red produces ElectricCharge. Heatsink Black produces ThermalPower. Both respond to the same input -- a microwave beam.

It might be the wisest choice to invent a resource that represents the beamed energy then let the receiver have a resource converter to fit its role and surface area. This way, at least, B9 Part Switch gets to shine as usual, job's done and everyone's happy. The resource could simply be named BeamPower and its abbreviation be kW or MW (preferrably MW). This should resolve both the issues of overlapping settings files and integration with Sterling Systems.

[KspNoobUsernameTaken]

1 hour ago, JadeOfMaar said:

It might be the wisest choice to invent a resource that represents the beamed energy then let the receiver have a resource converter to fit its role and surface area.

This would mess with beamed power's power beamed slider. It would force you to receive at least x amount of power. Unless there's a way for ModuleResourceConverter can scale to resource flow?

Same applies for creating the BeamedPower resource. 

 

But, I could define a received resource and ManagedResource conversion ratio in the receiver config. Then, ManagedResource controls what resource is beamed, but each receiver can independently get a different resource. This deals with Sterling integration, partially fulfills multiple resource transfers, and retains all of Beamed Power's current features.

 

 

Note, this system still keeps one ManagedResource, rather than making it dynamic, so that we don't need to specify conversion ratios for multiple ManagedResource's in the receiver cfg, which would make it much more difficult to parse in the code.

[JadeOfMaar]

30 minutes ago, KspNoobUsernameTaken said:

This would mess with beamed power's power beamed slider. It would force you to receive at least x amount of power. Unless there's a way for ModuleResourceConverter can scale to resource flow?

I did feel the hit to my toe, metaphorically, and feel that problem -- needing to throttle the converter. There is a module for that in this module pack:

I'm not sure I get all of that but I'm happy that you came up with something better which you can do.

 

[KspNoobUsernameTaken]

2 minutes ago, JadeOfMaar said:

I'm not sure I get all of that but I'm happy that you came up with something better which you can do.

The gist of it is, I can make each receiver output a different resource while retaining beamed power's other functionality, and I can control the conversion rate from ManagedResource to the receiver's own resource individually for each receiver. And I think this can be done in a manner that B9 can change the receiver's output ratio.

 

5 minutes ago, JadeOfMaar said:

There is a module for that in this module pack:

I'll look into it, thanks!

[Watermel00n]

1 hour ago, JadeOfMaar said:

I did feel the hit to my toe, metaphorically, and feel that problem -- needing to throttle the converter. There is a module for that in this module pack:

I'm not sure I get all of that but I'm happy that you came up with something better which you can do.

 

Oh yeah, i forgot to make the slider start at 100% instead of 0%... guess I need to update

[JadeOfMaar]

@KspNoobUsernameTaken Part is finished (excluding any patches for anything, even this mod) and is using the solar panel module as a placeholder.

Due to the nature of the solar panel module the part shatters like this by default. I thought I'd show this before (hopefully) turning it off. Note: hidden variant meshes show up.

[KspNoobUsernameTaken]

7 minutes ago, JadeOfMaar said:

@KspNoobUsernameTaken Part is finished (excluding any patches for anything, even this mod) and is using the solar panel module as a placeholder.

Due to the nature of the solar panel module the part shatters like this by default. I thought I'd show this before (hopefully) turning it off. Note: hidden variant meshes show up.

Perfect! What's the surface area? Do I have permission to include it in this mod?

[KspNoobUsernameTaken]

Here are some pictures from a test build for multiple resources:

https://imgur.com/a/ObMFrAl

The transmitter is transmitting ThermalPower, and the receiver is outputting ElectricCharge. Works perfectly. 

The issue with this implementation is that you could put in ThermalPower and get out LiquidFuel. You just have to trust people won't use this as a resource transmmuter. 

I'm also considering changing the frequency implementation. As it is, there is a Short and a Long frequency, and only interaction between parts with the same frequency is permitted. I'd like to change that to a numerical entry, and efficiency gradually falls off the bigger the gap between transmitted frequency and receiver design frequency. It would make implementing super high-energy transmitters much more reasonable (wouldn't need code changes, only cfg).  

[KspNoobUsernameTaken]

If I'm not mistaken, I've found a way to have variable transmitted and received resources running at the same time; I just don't know how to force a receiver to accept only one transmitted resource.

[KspNoobUsernameTaken]

I've somehow made more progress in the last three days than the 2 months I've worked on this.

[JadeOfMaar]

14 hours ago, KspNoobUsernameTaken said:

Perfect! What's the surface area? Do I have permission to include it in this mod?

8 x 6m. Yeah you have permission. I made for this to do as you need to do.

7 hours ago, KspNoobUsernameTaken said:

I've somehow made more progress in the last three days than the 2 months I've worked on this.

Exponential progression curve is real.

11 hours ago, KspNoobUsernameTaken said:

I'm also considering changing the frequency implementation. As it is, there is a Short and a Long frequency, and only interaction between parts with the same frequency is permitted. I'd like to change that to a numerical entry, and efficiency gradually falls off the bigger the gap between transmitted frequency and receiver design frequency. It would make implementing super high-energy transmitters much more reasonable (wouldn't need code changes, only cfg).  

I like this. I'm sure the more nerdy among us would like that. When I make parts for laser comm they would serve quite well for mid IR through hard UV.

Wouldn't there need to be some kind of correlated falloff scaling? That is: How good the particular frequency is over distance?

I've mentioned you in a post on GitHub. Hopefully it's in your inbox there and waiting. I'm done making the part.

[KspNoobUsernameTaken]

2 hours ago, JadeOfMaar said:

Wouldn't there need to be some kind of correlated falloff scaling? That is: How good the particular frequency is over distance?

Yep. I'm thinking about what equation would be best for this. I believe higher frequencies have lower falloff, but I need to do some research.

 

2 hours ago, JadeOfMaar said:

I've mentioned you in a post on GitHub. Hopefully it's in your inbox there and waiting. I'm done making the part.

Couldn't see it on GitHub.. I'll check your GitHub profile for it.

Found it: it's this right? 

https://github.com/JadeOfMaar/sandbox/releases/tag/bpwr-1.0

[KspNoobUsernameTaken]

An interesting observation: @Aniruddh's original code actually almost fully supports any wavelength. Everything in the code actually uses numerical wavelengths. The only thing it's missing is efficiency falloff based on how different transmitted wavelength is from the design frequency.

I think he decided on the current approach so as to never deal with two different frequency parts interacting.

 

I dunno, just found this interesting so I put it here.

 

3 hours ago, JadeOfMaar said:

Exponential progression curve is real.

I concur. Also, I just started learning C# for this project, so that probably plays a part in it.

[JadeOfMaar]

16 minutes ago, KspNoobUsernameTaken said:

Found it: it's this right? 

Yep