KspNoobUsernameTaken

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. 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

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

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.

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).

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

Do all the shipbreaker modules need to be on the same vessel to work together?

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. I'll look into it, thanks!

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, 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.

On further review, this could probably be simulated by just having a ridiculously low frequency. Or, if you want to go the dyson swarm route, an insanely large transmitter dish.

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.

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

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.

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.

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

That was my plan, but my early attempts failed horribly. I made a topic about it: This was the answer I got: I'm looking into it, but for now I'll keep it static. 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.

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):

Yep, I figured it out. Late thanks anyway.

I might be able to create a "laser" transmission mode, by which I mean very low falloff at long distances. I think I've got a hang of the transmission mode code. If you added a beamed power transmitter module configured for laser mode to LaserComm parts, it would feel like it's following the gimbal. That, of course, would be contingent upon LaserComm and Beamed Power targetting the same vessel, which I might be able to add.

IIRC, Beamed power standalone doesn't have any line of sight functions implemented, and it has no requirements from the model. Frankly, gimbals and line-of-sight stuff is far beyond my capabilities. My fork of Beamed power has like 20 new lines of code and it took me weeks to make. You'd have to ask an actually competent mod author. That being said, you don't need to worry about compatibility. Beamed Power Standalone could be slapped onto a random strut and it'll probably work.

@JadeOfMaar I finally completed and tested the beamed power code. When/if you get around to making those parts I can provide a modified version of Beamed Power Standalone that can transmit any resource.

Ah, ok, you already thought of that. This sounds good, I'm looking forward to trying it out.

A nice feature might be a button to "use all printers", which will make all part printers print the correct parts for the vessel printer to use. Does the vessel printer check for stored parts continuously, or at the start of a print job? E.g, if a part printer finished a part while a vessel printer was running, could the vessel printer use that part?

Can multiple vessel-printers work together to speed up building super-large ships?

I thought of that previously but discarded it because I'm not familiar with MODEL nodes. Good to know it's possible. So with this, I could create my own transforms for mod parts without editing the mod's files. Very helpful.