[1.8-1.11.x] Beamed Power Standalone (and Propulsion), v1.1.0

[fatcargo]

@Aniruddh if this is not too much to ask : there should be a feature to disable beamed power functionality in certain situations.
Examples:

1. Disable power transfer for crafts that are moving at great velocity using warp drive modded parts

2. If there are dedicated transmitter/receiver pairs, and one of them is being instantly transferred via some kind of "jump gates" (like ESLD beacon mod)

To elaborate it would be cheaty and could be explained in game to player as relativistic effects. I know these mods are sci-fi and are not much in same scope of realism as this mod, but please take this into consideration.

[Aniruddh]

9 minutes ago, fatcargo said:

@Aniruddh if this is not too much to ask : there should be a feature to disable beamed power functionality in certain situations.
Examples:

1. Disable power transfer for crafts that are moving at great velocity using warp drive modded parts

2. If there are dedicated transmitter/receiver pairs, and one of them is being instantly transferred via some kind of "jump gates" (like ESLD beacon mod)

To elaborate it would be cheaty and could be explained in game to player as relativistic effects. I know these mods are sci-fi and are not much in same scope of realism as this mod, but please take this into consideration.

For the first point, I like the suggestion. It would take a bit of time, as every warp drive mod has slightly different code. This isn't a priority, only once I get this mod out of alpha will I add that. Should I also add red-shift/blue-shift for vessels not using warp-drive but travelling near speed of light?

For the second point, I have no clue what a "jump gate" is, I've studied a lot about Alcubierre warp-drives and how they could work, but I don't know the physics for that kind of thing. Is it like a wormhole in any way?

[fatcargo]

11 minutes ago, Aniruddh said:

For the first point, I like the suggestion. It would take a bit of time, as every warp drive mod has slightly different code. This isn't a priority, only once I get this mod out of alpha will I add that. Should I also add red-shift/blue-shift for vessels not using warp-drive but travelling near speed of light?

For the second point, I have no clue what a "jump gate" is, I've studied a lot about Alcubierre warp-drives and how they could work, but I don't know the physics for that kind of thing. Is it like a wormhole in any way?

For warp drive mods : they all have speed in common. There is no way around it. So you could simply test for speed and break power transfer if speed exceeds the limit, optionally could add redshift losses prior to breaking this connection.

For jump gates : this is a bit more complicated, but i believe that they will generally cause vessel unload and a scene switch, maybe sudden relocation of active vessel so that can be accounted for as well.

Edited August 6, 2020 by fatcargo

[Aniruddh]

On 8/6/2020 at 3:30 PM, fatcargo said:

For warp drive mods : they all have speed in common. There is no way around it. So you could simply test for speed and break power transfer is speed exceeds the limit, optionally could add redshift losses prior to breaking this connection.

For jump gates : this is a bit more complicated, but i believe that they will generally cause vessel unload and a scene switch, maybe sudden relocation of active vessel so that can be accounted for as well.

Oh, I misunderstood, I though you were asking for it to check when a warp-drive module is engaged, and then turn off the receiver/transmitter when that occurs. Turns out you just want it to check whether the vessel has exceeded speed c. The latter is much easier to implement!

For jump-gates, according to your description, the same method can be used as the one for warp-drives, or it can check for a scene switch. I'll definitely be implementing the warp-drives part, but it may take a while longer to implement as satisfactory version that works for jump-gates.

Notice:

Also, a notice for everyone, v0.2.0 and 0.1.0 both have errors if the receiver goes beyond 2.3 km from the source, the game will throw null-reference exception and the modules will stop working. This means I highly recommend waiting till v0.3.0, where I hopefully can fix this error. I asked how to make KSPField attributes work beyond 2.3 km here:

If anyone has any ideas, post in that thread, in the mean time I'm trying to find solutions myself. Bare in mind, I'm a complete newbie at writing plugins for ksp, but have lots of free time to spend learning this stuff.

EDIT: The thread's topic has been changed, as I gave up on trying to work on making KSPField variables accessible beyond 2.3 km.

Edited August 8, 2020 by Aniruddh

[fatcargo]

1 minute ago, Aniruddh said:

Oh, I misunderstood, I though you were asking for it to check when a warp-drive module is engaged, and then turn off the receiver/transmitter when that occurs. Turns out you just want it to check whether the vessel has exceeded speed c. The latter is much easier to implement!

For jump-gates, according to your description, the same method can be used as the one for warp-drives, or it can check for a scene switch. I'll definitely be implementing the warp-drives part, but it may take a while longer to implement as satisfactory version that works for jump-gates.

The speed detection could be a problem : crafts using warp drive mods to simulate speed above c may not actually move crafts at speed c For example alcubierre drive mod just make it easier to transfer craft in space, does not need c to do it. What can be done is to detect speed that is above limit and then take action. This limit can be written into mod config so it can be tweaked to something realistic/working.
 

This also raises another interesting question : if there is a speed limit between transmitter and receiver, there may be situations where transfer breaks just because crafts with this mod parts orbit planets with large speed difference So do account for this too. Especially since there are mods that add alternative solar systems that can have planets with quite large speed differences. And please don't consider anything beyond this, at least at this stage, or mod development will get really complicated.

[fatcargo]

@Aniruddh one more idea about warp drive detection : you could list all parts in transmitter/receiver vessel for any warp drive part modules, check their fields and then let beam power mod decide.

 

Now, this can easily blow up into a large list and make this mod unusable, but there may be a way to do it, at least gradually.

You could add a list in config file describing quadruplet of module name, ksp field, value and action to be taken.

Small fake example config :
 

MODULE

{

  name = WirelessSource //same for WirelessReceiverDirectional

  CONDITION

  {

    name = WarpDrive

    field = DriveState

    value=Engaged

    action = Disable

  }

  CONDITION

  { ...}

}

Each "CONDITION" node tells the plugin when and how to work.

You can see how to access KSPField in other mods like Action Groups Extended, Kerbal Operating System and Mod Actions (this last one may be most relevant).

Note that this node list can be used for anyhing else as well, not just warp drive mods.

 

Edited August 7, 2020 by fatcargo

[Shoujo Q]

The poll here makes me wish that it was done by approval voting - I would vote for both Simple and Some Realism (my current vote) in that case.

Seconding the request for this to also allow you to push ships around directly with lasers. How about using a heat-shield like item (with the Ablator resource) as a source of thrust via laser ablation?

[Aniruddh]

13 hours ago, Shoujo Q said:

The poll here makes me wish that it was done by approval voting - I would vote for both Simple and Some Realism (my current vote) in that case.

I can edit the poll to make it let you choose multiple choices, if that's what you want.

13 hours ago, Shoujo Q said:

Seconding the request for this to also allow you to push ships around directly with lasers. How about using a heat-shield like item (with the Ablator resource) as a source of thrust via laser ablation?

Yes, I will implement this at some point, but currently there are some serious bugs I need to fix and more important features to add into the plugin which take priority. It's technically a pre-release atm.

For the first point, either you are talking about photon sails or beamed power thermal rockets, both of which are in KSPIE and work well, the latter of which I will add to this mod as well. The propulsion concept that uses ablation for thrust is a good idea I'm thinking of implementing, although it won't be particularly good gameplay wise (you'd need a lot of power beamed and converted to heat to make this worthwhile, may even be impractical, will do some further research into this).

Edited August 7, 2020 by Aniruddh

[fatcargo]

1 hour ago, Aniruddh said:

For the first point, either you are talking about photon sails or beamed power thermal rockets, both of which are in KSPIE and work well, the latter of which I will add to the mod as well in the plugin. The propulsion concept that uses ablation for thrust is a good idea I'm thinking of implementing, although it won't be particularly good gameplay wise (you'd need a lot of power beamed and converted to heat to make this worthwhile, may even be impractical, will do some further research into this).

Irradiated ablative receiver propulsor (you are free to use the name  ) is like a normal receiver that also expends ablator resource. The thrust for it can be somewhere between chemical rockets and ion engines (very wide range, i can't pinpoint it) but in game it should provide uniquely difficult use case -  a orbital probe could carry only this part with mass of ablator resource and remotely receive energy (no need for heavy power generator) required to vaporize it, but since energy received can drop off drastically with distance, it may need a dedicated beam transmitter with a lot of power output.

[Aniruddh]

v0.3.5 is out and fixes the issue with receivers not working when the transmitter was beyond 2.3 km. This release was 4 days in the making! I pretty much gave up on making KSPFields work beyond the load distance, and instead went for the brute force approach of using config nodes and saving them to a custom file on disk. This means there is a new file in the mod folder under PluginData called save.cfg, if you delete this, the mod won't work! This method means multiple save files are currently not supported, as I don't know how to get the save file's name and id, and how to get the active vessel's save file. Anyways, hope you enjoy this release, it's no longer marked as pre-release on GitHub anymore!

[theJesuit]

What happens if you start a new save?  Do you loose all the other settings and craft setups of the first save?

[Aniruddh]

6 hours ago, theJesuit said:

What happens if you start a new save?  Do you loose all the other settings and craft setups of the first save?

I added a bit of code that removes vessels in the file that no longer exist in the save. Since, craft in other saves don't exist in this one, their config node in the file will indeed be deleted. Your actual crafts won't be deleted, you will just have to switch to your transmitter spacecraft and back, and the configs will be reloaded.

Edited August 9, 2020 by Aniruddh

[linuxgurugamer]

2 hours ago, Aniruddh said:

I added a bit of code that removes vessels in the file that no longer exist in the save. Since, craft in other saves don't exist in this one, their config node in the file will indeed be deleted. Your actual crafts won't be deleted, you will just have to switch to your transmitter spacecraft and back, and the configs will be reloaded.

That doesn’t sound good.  Why not just load in the profiles for the vessels in the save.  Better yet, you could save the vessels either to the Persistent.sfs file or to a file in the save directory

On 8/3/2020 at 4:58 PM, Aniruddh said:

This version does not support multiple save files, I have yet to figure out how to retrieve names of savefiles and organise the config nodes in that way. I'd still recommend reloading all spacecraft that have these part modules, (switching to them and back).

Here you go:

KSPUtil.ApplicationRootPath + "saves/" + HighLogic.SaveFolder + "/"

 

[fatcargo]

I agree with @linuxgurugamer, this plugin can be a PartModule that saves the list of all  connected transmitters or receivers (with respect to its receive/transmit type). One transmitter can have list of multiple receivers and a one receiver can only have one transmitter (unless some kind of list for fallback transmitters is added to compensate for loss of power due to lost line of sight, power failure  or other disabling conditions). All save/load happens on OnLoad and OnSave which write into Persistent.sfs file that holds all save game config data.

[Aniruddh]

27 minutes ago, fatcargo said:

All save/load happens on OnLoad and OnSave which write into Persistent.sfs file that holds all save game config data

I know that, but I don't want to have to save/load data when a game save/load happens, I'd rather do it independently of that, so that save/loads are more frequent.

42 minutes ago, linuxgurugamer said:

Here you go:

KSPUtil.ApplicationRootPath + "saves/" + HighLogic.SaveFolder + "/"

Thank you! I will implement this right away. It is indeed not good to not support multiple save files. HighLogic.SaveFolder returns the name of the save right? I'd rather stick to saving the config nodes to a separate file in my mod's folder, so when the user deletes the mod folder, the data about the transmitters is also removed, and there is no residual data in the persistent.sfs.

Edited August 9, 2020 by Aniruddh

[linuxgurugamer]

2 minutes ago, Aniruddh said:

I know that, but I don't want to have to save/load data when a game save/load happens, I'd rather do it independently of that, so that save/loads are more frequent.

Thank you! I will implement this right away. It is indeed not good to not support multiple save files. HighLogic.SaveFolder returns the name of the save right? I'd rather stick to saving the config nodes to a separate file in my mod's folder, so when the user deletes the mod folder, the data about the transmitters is also removed, and there is no residual data in the persistent.sfs.

World be best to store in the save directory so that the save can be fully backed up by copying the folder

5 minutes ago, Aniruddh said:

know that, but I don't want to have to save/load data when a game save/load happens, I'd rather do it independently of that, so that save/loads are more frequent

You run the risk of your save files being out of sync with the persistent.sfs file by doing it that way

[fatcargo]

To add to above : also, if there is something wrong with code, all data will be in one place. It will be hard to match saved game state against custom data in separate file. Be aware of this. I had run into similar problem of saving state of my part and i analyzed the save and found the bug.

[Aniruddh]

1 minute ago, fatcargo said:

To add to above : also, if there is something wrong with code, all data will be in one place. It will be hard to match saved game state against custom data in separate file. Be aware of this. I had run into similar problem of saving state of my part and i analyzed the save and found the bug.

For both receiver modules, I figured out how to load transmitter data directly from save file, so, by definition, multiple save file support will come in the next release. Currently working on resolving a few nullref errors, but should be done by tomorrow.

[Aniruddh]

EDIT: Problem with if statement solved.

Also for those who were asking for beamed power propulsion, I've figured out ModuleEngines, so the next release will also have an optional photon sail and thermal rocket part module. I initially though I wouldn't do this, but I'm bored in partial lockdown, so might as well, it'll be a fun addition to this project.

Edited August 11, 2020 by Aniruddh
problem solved

[fatcargo]

On 8/11/2020 at 12:30 AM, Aniruddh said:

EDIT: Problem with if statement solved.

Also for those who were asking for beamed power propulsion, I've figured out ModuleEngines, so the next release will also have an optional photon sail and thermal rocket part module. I initially though I wouldn't do this, but I'm bored in partial lockdown, so might as well, it'll be a fun addition to this project.

Uh-oh ! I completely forgot about "beam propulsion" - it is direction-dependant ! You could imagine it as trying to raise orbit using only ion engine. You need to fire the engine at the single point in orbit to get what is needed. This one will be tricky. Imagine using sail-like propulsion to drive TOWARD source of beam, that is contradiction.

[Aniruddh]

5 hours ago, fatcargo said:

Uh-oh ! I completely forgot about "beam propulsion" - it is direction-dependant ! You could imagine it as trying to raise orbit using only ion engine. You need to fire the engine at the single point in orbit to get what is needed. This one will be tricky. Imagine using sail-like propulsion to drive TOWARD source of beam, that is contradiction.

Thanks for pointing this out, I didn't realise it at first. I have found a partial solution to it- it only works if the photon-sail is pointing in the same direction as the root-part of the vessel it's on. I'll experiment with this to see if this can be improved.

But, anyways, a framework for the photon-sail part module has been added to v0.4.1. Don't use it in game, but feel free to look at the source code and OP, and see how it will function, once fully released.

[Aniruddh]

On 8/12/2020 at 11:57 PM, Aniruddh said:

I'll experiment with this to see if this can be improved.

Looks like I did find a full solution, it's fairly complicated however, it's probably the first time I've experimented with quaternions. I'll have to see how this goes, but this is quite promising!

Edited August 16, 2020 by Aniruddh

[Aniruddh]

Ok so here is a new release, (0.4.5), it adds heat mechanics to the part modules currently in the mod. The heat is added both to the part's skin and core, bare this in mind. I don't know if the numbers I've used are suited to game balance, if you think at any point some part is producing too much/too little heat, let me know and I'll tune it. A few other features have also been added. More details given on the OP. 

Just in case anyone doesn't know, to type in exact values into the part right click menu instead of using the slider, click the '#' buttons at the top-right of the right-click menu.

EDIT: 0.5.0 is also out, a small version upgrade that adds CommNet based planetary occlusion.

Edited August 23, 2020 by Aniruddh

[Aniruddh]

I think at this stage this mod is very close to a 1.0. I finished work on the thermal engine and ablative engine part modules, and have released them in v0.8.0.  Instructions for applying this part module are given on the OP, as well as in the README file in download.

Ok, so here is the development process for these propulsion concepts: 

The main problem I initially ran into is that the stock ModuleEnginesFX doesn't allow it's maxThrust to be scaled based on the power received (I'm guessing it's a constant). So I found a clever (not really)  workaround to this problem, now the code dynamically adjusts the thrust limiter of the engine based on the power received. This makes it look like more power received means more thrust from engine, although it' just the thrust limiter being adjusted. Then the code locks the thrust limiter. This means to reduce thrust yourself, you either use the throttle, or the received power limiter in the right-click menu. All of this applies both to the thermal engine and the ablative engine.

Here is a screenshot from testing (notice the right-click menu):

Obviously this isn't my part model, this is actually the antimatter-induced microfusion engine from the old FFT. I applied the thermal engine part module to it, and it works great. The model is fit for purpose as well.   

Anyways, I still have Photon-Sail left to do, after which I will say this mod is feature-complete. Support for warp-drives are also coming as well as Localization, hopefully in 0.9.0.

[Cyne]

looking awesome, I'm sure this will become something great!