Jump to content

Universal Resource Transfer (Beamed Power Standalone for any resource)

KspNoobUsernameTaken
 Share

Recommended Posts

KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted

@JadeOfMaar,

I'm not very familiar with B9PS. I've made this config which I think is correct, could you review it?

Spoiler

PART
{
    name = bpwr_rx_panel01 // beamedpower_receiver_panel 01
    module = Part
    author = JadeOfMaar
    rescaleFactor = 1
    node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0
    TechRequired = largeElectrics
    entryCost = 15600
    cost = 13000
    category = Electrical
    subcategory = 0
    title = BP-SPRP-048 Power Receiver
    manufacturer = TBA
    description = A space power receiver panel which rolls out and can receiver power in a handful of ways.
    attachRules = 1,1,0,0,1
    mass = 1.46
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 1
    crashTolerance = 15
    maxTemp = 2400
    bulkheadProfiles = srf
    thermalMassModifier = 2.0
    emissiveConstant = 0.7
    heatConductivity = 0.04
    tags = charge deploy e/c thermal thp elect energ extend fold generat panel power retract sun track unfold volt watt microwave solar
    
    CoLOffset = -0.62, 0, 0
    CoMOffset = -0.62, 0, 0
    CoPOffset = -0.62, 0, 0
    
    refArea = 48 // sq m
    
    NODE
    {
        name = bottom
        transform = bottom
        size = 0
        method = FIXED_JOINT
    }
    MODEL
    {
        model = BeamedPowerTest/rxPanel01
    }
    MODULE
    {
        name = ModuleDeployableSolarPanel
        secondaryTransformName = sunCatcher
        pivotName = rotorYaw
        isBreakable = false
        resourceName = ThermalPower
        chargeRate = 0.3
        impactResistance = 5
        impactResistanceRetracted = 15
        animationName = unroll
        extendActionName = Extend <<1>>
        retractActionName = Retract <<1>>
        extendpanelsActionName = Toggle <<1>>
    }
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = 600
    }
    MODULE
    {
        name = WirelessReceiver
        recvType = Directional    // either Spherical or Directional
        recvDiameter = 2.5        // in metres, pick an appropriate value
        recvEfficiency = 0.9    // a value between 0.0 and 1.0
        maxSkinTemp = 1200    // these temps determine when the module will shutdown, optional (will default to 1200)
        maxCoreTemp = 900    // optional (will default to 900)
        OutputResource = ThermalPower
        OutputResourceGUIName = ThP/s
        ConversionRate = 1
    }
    MODULE
    {
        name = ModuleB9PartSwitch
        moduleID = Service
        switcherDescription = Service
        switcherDescriptionPlural = Services
        affectDragCubes = false
        affectFARVoxels = false
        switchInFlight = false
        SUBTYPE
        {
            name = Thermal
            title = Thermal
            primaryColor = FadedRed
            secondaryColor = ResourceColorElectricChargeSecondary
            descriptionSummary = Employs a conductive inner mesh which soaks up incoming microwaves or insolation and exchanges the resulting heat with its coolant flow. <br><br><b>Max Temp</b>: 2400 K <br><b>Solar Thermal</b>: 0.3 ThP/s
            transform = B01
            transform = B02
            transform = B03
            transform = B04
            transform = B05
            transform = B06
            transform = B07
            transform = B08
            maxTemp = 2400
            MODULE
            {
                IDENTIFIER
                {
                    name = ModuleDeployableSolarPanel
                }
                DATA
                {
                    resourceName = ThermalPower
                    chargeRate = 0.3
                }
            }
            MODULE
            {
                IDENTIFIER
                {
                    name = WirelessReceiver
                }
                DATA
                {
                    OutputResource = ThermalPower
                    OutputResourceGUIName = ThP/s
                    ConversionRate = 1
                    maxSkinTemp = 2400
                    maxCoreTemp = 2000
                }
            }
        }
        SUBTYPE
        {
            name = Electric
            title = Electric
            primaryColor = ResourceColorElectricChargePrimary
            secondaryColor = ResourceColorElectricChargeSecondary
            descriptionSummary = Employs a resonant circuit mesh to convert incoming microwaves into electrical potential. Delicate circuitry has quite a habit of melting easily. <br><br><b>Max Temp</b>: 1200 K <br><b>Solar Thermal</b>: N/A
            transform = A01
            transform = A02
            transform = A03
            transform = A04
            transform = A05
            transform = A06
            transform = A07
            transform = A08
            maxTemp = 1200
            MODULE
            {
                IDENTIFIER
                {
                    name = ModuleDeployableSolarPanel
                }
                DATA
                {
                    chargeRate = 0
                }
            }
            MODULE
            {
                IDENTIFIER
                {
                    name = WirelessReceiver
                }
                DATA
                {
                    OutputResource = ElectricCharge
                    OutputResourceGUIName = EC/s
                    ConversionRate = 20
                }
            }
        }
    }
}

 

Link to comment
Share on other sites
JadeOfMaar

JadeOfMaar

Posted
Posted

@KspNoobUsernameTaken That looks perfect. But why does the first (default) subtype's values for the receiver module not match the baseline outside of the B9 module or rather, why do the receiver module's values not align with the first subtype? That's making for conflicting baseline settings. (Ultimately, B9's values apply and the info in the part info panels would be false.) Consequently, the 2nd subtype should contain keys and values for different core and max temps (since this is not the default and it's where the part's heat tolerance is lowered).

Related: I find it odd that the shutdown temperatures are set to where the part would be destroyed and that the max core temepratures are set to a high fraction of that (for electric producers / this panel's electric variant). My understanding (from DMs with a very big nerd :D ) tells me:

  • For thermals, set max core temp to somewhere between 1000 ~ 1400K (assuming molten metal is flowing through it like in high temperature radiators. The part is, in practice, a radiator in reverse). I guess shutoff temperature can remain at the part's max skin temperature.
  • For electrics (probably applies to all prior parts in this mod), max core temp should be mroe modest. Somewhere 400 ~ 500K because electrics are gonna get hot. (Related: System Heat puts stock ISRU parts at 500K.) But the shutoff temperature should also be more modest like 900K where delicate bits would start to melt and fail before total destruction of the part.

What happens when a part is between its max core temp and shutoff temp? Does converter efficiency go down along some sort of curve?

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted
6 minutes ago, JadeOfMaar said:

But why does the first (default) subtype's values for the receiver module not match the baseline outside of the B9 module or rather, why do the receiver module's values not align with the first subtype? That's making for conflicting baseline settings. (Ultimately, B9's values apply and the info in the part info panels would be false.) Consequently, the 2nd subtype should contain keys and values for different core and max temps (since this is not the default and it's where the part's heat tolerance is lowered).

I was going to change the default values and use the ones in subtype 1 in about 10 minutes. The default I used is copied directly from a different part, it hasn't been adjusted. 

8 minutes ago, JadeOfMaar said:

Related: I find it odd that the shutdown temperatures are set to where the part would be destroyed and that the max core temepratures are set to a high fraction of that (for electric producers / this panel's electric variant). My understanding (from DMs with a very big nerd :D ) tells me:

  • For thermals, set max core temp to somewhere between 1000 ~ 1400K (assuming molten metal is flowing through it like in high temperature radiators. The part is, in practice, a radiator in reverse). I guess shutoff temperature can remain at the part's max skin temperature.
  • For electrics (probably applies to all prior parts in this mod), max core temp should be mroe modest. Somewhere 400 ~ 500K because electrics are gonna get hot. (Related: System Heat puts stock ISRU parts at 500K.) But the shutoff temperature should also be more modest like 900K where delicate bits would start to melt and fail before total destruction of the part.

What happens when a part is between its max core temp and shutoff temp? Does converter efficiency go down along some sort of curve?

I honestly have no idea of this. The heat code is completely incomprehensible to me. I might look into the heat stuff later, for now I don't want mess with it.

I'll implement the config changes you suggested before full release. 

Oh also, the heat values were copied from the heat values in your provided solar panel config.

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted

This is much more frustrating than expected; Universal Resource Transfer doesn't seem to play well with B9: even when I use the Thermal subtype, it is acting as a EC receiver.

I'm guessing it's an issue with however B9 saves it's changes to persistent.sfs.

If it doesn't actually edit the module in the save file, instead just saving a current subtype field and doing stuff at runtime, it won't be compatible with Universal Resource Transfer.

Sadly, I can't really diagnose the issue because B9's code is unintelligible to me. It's a whole different level of complexity. I'm just gonna ask the B9 devs about this.

Link to comment
Share on other sites
JadeOfMaar

JadeOfMaar

Posted
Posted

@KspNoobUsernameTaken There's very little I can say about this, only that B9PS works by changing the "recipe" within a module and then reinitializing that module. For a module to be affected by B9PS it would need to use certain calls. Example: You use OnUpdate but should use OnFixedUpdate. (idk the proper names. Don't assume that's correct.) If you use the modding Discord link in my signature I can introduce you to folks who have experience to share.

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted
7 hours ago, JadeOfMaar said:

@KspNoobUsernameTaken There's very little I can say about this, only that B9PS works by changing the "recipe" within a module and then reinitializing that module. For a module to be affected by B9PS it would need to use certain calls. Example: You use OnUpdate but should use OnFixedUpdate. (idk the proper names. Don't assume that's correct.) If you use the modding Discord link in my signature I can introduce you to folks who have experience to share.

I've joined the discord, but I have an idea for testing the error so I'll try that before asking about.

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted

That was not the issue... 

Section from a vessel with the beamed power part:

Spoiler

MODULE
                {
                    name = WirelessReceiver
                    isEnabled = True
                    Listening = True
                    PowerLimiter = 100
                    ReceivedPower = 113.400002
                    counter = 0
                    OutputResource = ThermalPower
                    OutputResourceGUIName = ThP/s
                    ConversionRate = 1
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                        ToggleBPReceiver
                        {
                            actionGroup = None
                        }
                        ActivateBPReceiver
                        {
                            actionGroup = None
                        }
                        DeactivateBPReceiver
                        {
                            actionGroup = None
                        }
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }

This shows that the data is being saved, it just isn't working how I'd expect from the code side. ModuleB9PartSwitch is interfering somehow.

Link to comment
Share on other sites
JadeOfMaar

JadeOfMaar

Posted
Posted
17 minutes ago, KspNoobUsernameTaken said:

@JadeOfMaar, what part of the config you sent controls the model changing between EC and ThP modes?

That would be the set of transform keys in each subtype. The named transforms are shown when that subtype is selected and hidden when not selected.

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted
28 minutes ago, JadeOfMaar said:

That would be the set of transform keys in each subtype. The named transforms are shown when that subtype is selected and hidden when not selected.

Oh. I was wondering what those did. I'm going to split the part into a EC receiver and a ThP receiver for now, until I can fix the B9 issues.

Link to comment
Share on other sites
JadeOfMaar

JadeOfMaar

Posted
Posted
8 minutes ago, KspNoobUsernameTaken said:

Oh. I was wondering what those did. I'm going to split the part into a EC receiver and a ThP receiver for now, until I can fix the B9 issues.

Ah. Well let me know if/when you decide that B9PS is indeed interfering and I'll send split models that won't still need B9PS to hide what needs to be hidden.

Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted (edited)

I think wavelength is related to lines 151-168 in UsefulModules.cs. The string wavelengths are converted to a multiplier.

 

Other important bit is 255-267 in BeamedPowerSource.cs

 

Most important section: 284-292 in BeamedReceiver.cs 

 

This directly converts the string into a a wavelength

Edited by KspNoobUsernameTaken
Link to comment
Share on other sites
KspNoobUsernameTaken

KspNoobUsernameTaken

Posted
  • Author
Posted (edited)

@JadeOfMaar, I'm getting this NRE related to a sterling radiator: 

[KSPCF/DragCubeGeneration] Call to 'Assembly-CSharp:ModuleDeployableRadiator.AssumeDragCubePosition()' failed on part 'strl-rad-lfr-sta01' for drag cube 'RETRACTED'
System.NullReferenceException: Object reference not set to an instance of an object
  at ModuleDeployablePart.AssumeDragCubePosition (System.String name) [0x00088] in <4b449f2841f84227adfaad3149c8fdba>:0 
  at KSPCommunityFixes.Performance.DragCubeGeneration+<RenderDragCubesOnCopy>d__21.MoveNext () [0x005a4] in C:\Users\Got\source\repos\KSPModdingLibs\KSPCommunityFixes\KSPCommunityFixes\Performance\DragCubeGeneration.cs:413

Is this normal?

 

In other news:

My recent testing shows I broke something since finishing the dynamic gui stuff. Gotta figure out what change caused this... I need to backtrack on a week's work.

Edited by KspNoobUsernameTaken
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...