Electric charge inside the VAB

[PhilouDS]

trafficstars

version : pre-relase 0.5.5.1

I tried required_resources inside the VAB to try to compute the total EC needed.

1- For antennas, I don't understand what is the Acceptance Threshold. For the Electric Charge resource, rate seems to be twice the value indicated by KSP2 for each antenna. I assumed that is because the transmission interval is 2 for each antenna so I have to divide the rate by 2 to have the Unity per second.

2- Is required_resources available for every part? At the moment, we can't access the required resources for science parts or reaction wheels.

3- Batteries are not "generator" parts (that makes sense) but is it possible to have access to the Electric Charge they contain (as with ResourceContainer)?

[untoldwind]

Obviously the resource management is one of the core components of the game and quiet complex, so I am still trying to figure things out. From what I can tell:

• The actually power consumption of an antenna per second is indeed resource.rate / transmission_interval.

• The .acceptance_threshold seems to be a multiply defining the minimum rate when a component becomes operational (i.e. 0.1 means 10%). I am not sure what exactly this implies for antennas though. Maybe the transmission_interval will increase accordingly?

• .required_resources only exists for parts that consume resources, though a probably missed a few. Parts that generate resource should have a .resource_settings

• Indeed batteries are considered resource containers. I improved the API for the VAB accordingly.

Next pre-release: https://github.com/untoldwind/KontrolSystem2/releases/tag/v0.5.5.2

[PhilouDS]

Thanks! I'm trying this right now :)

[untoldwind]

0.5.5.3 has bindings for reaction wheels, which are also consumers of electrical charge

[PhilouDS]

Nice! For now, I'm trying to understand how transmission works. I can't understand the numbers! I did some tests with 2 different science experiment and I can't figure out why the time transmission and the EC used for transmission is the same for the 2 experiments with the last 5 antennas. Also: if antenna consumes 5.5 Units per second, why do I need 44 Units to transmit for 4 seconds instead of 22?

[untoldwind]

I think the .data_transmission_interval has indeed a different meaning. In the game I found this calculation:

timeRequired = ceil(researchReport.transmission_size / transmitter.data_packet_size) * transmitter.data_transmission_interval
ecRequired = transmitter.ec_per_second * timeRequired

whereas transmitter.ec_per_second just seems to be the required_resource.rate

Not sure if this matches up with your observations

[PhilouDS]

I have to look at researchReport.transmission_size. Unfortunatly, I have access to this only with research reports. I assume I need to look at each science part to know the transmission size and I can hard-code the value in my script.

Is there a "good" way to code that. Imagine I have 2 science A and B with transmission size of x and y. My idea would be:

if (part_name == "a") {
    return x
} else if (part_name == "b") {
    return y
}

But with about 10 science parts, maybe there is a most efficient way to do that?

[PhilouDS]

Nope, sorry, I think the definition.transmission_size from Experiment gives me the same result. So it should be good.

I noticed a mistake in my data value! I used a script from an other game where difficulty is set to 80%!! 😤

[PhilouDS]

The use of Ceil explains a lot! I have to run test with different antennas now to understand which antenna is chosen to transmit.

[untoldwind]

The transmission size should be also part of the experiment definition.

It is somewhat nested though:

const sizes = assembly.parts.filter_map(fn(part) -> part.science_experiment).flat_map(fn(sci) -> sci.experiments).map(fn(exp) -> exp.definition.transmission_size)

Should list all the transmission sizes of all the experiments of the vessel.

As for the transmitter selection: From what I can tell the transmitter with the biggest .data_package_size that is in-range is selected. Unluckily determining the "in-range" is not so easy since relay satellites are considered ... have to do some digging to figure that out.

[PhilouDS]

0.5.5.3 has bindings for reaction wheels, which are also consumers of electrical charge

How do I have access to this bindings? I see nothing in the documentation about reaction wheels.

[untoldwind]

Yes, forgot to update the docs: https://kontrolsystem2.readthedocs.io/en/prerelease/reference/ksp/oab.html#objectassemblypart i.e. the .reaction_wheel.

[untoldwind]

Hopefully the last pre-release: https://github.com/untoldwind/KontrolSystem2/releases/tag/v0.5.5.4 There is now a vessel.connection_status and vessel.science_storage.active_transmitter the latter should be the transmitter that is used for data transmission (if available).

I think it will be possible to make the CommNet data available as well (i.e. list of all nodes with positions), but that is for a later release, there are already a lot of accumulated changes.

[PhilouDS]

And of course, the requirement value from KSP info box is not the same than the rate value from part.reaction_wheel.value.required_resources

[untoldwind]

Another funny calculation I had to dip up: The resource.rate is the electrical charge per applied torque.

vec3(pitch_torque, yaw_torque, roll_torque).magnitude * resource.rate

(in the above case: sqrt(30^2+ 30^2 + 30^2) * 0.05)

I will add a .potential_torque field to the reaction wheel

[PhilouDS]

Well done! And thanks!

[untoldwind]

.potential_torque has been added to 0.5.5.5 (along with all the other things ;) )

https://kontrolsystem2.readthedocs.io/en/latest/reference/ksp/oab.html#id17

[PhilouDS]

The colors are ugly but it's just to differentiate the parts.

With "Show detail box"

I wanted to add a science detail box but I noticed that the data value given in the VAB are the landed value. So I can only calculate the transmission EC requirement for landed experiments. I'm not sure it's relevant.

With Minmus:

[PhilouDS]

Any chance we can access to the display name of a part? Because .part_name is not very user friendly '^^

[PhilouDS]

Small updates (I added the lines encircled in green)

[untoldwind]

I found a field for .part_title and .part_description that seem to correspond to the name as it appears in the UI. Will be included in the next release.

[untoldwind]

Should be part of 0.5.6.0 now.

[PhilouDS]

As for the transmitter selection: From what I can tell the transmitter with the biggest .data_package_size that is in-range is selected. Unluckily determining the "in-range" is not so easy since relay satellites are considered ... have to do some digging to figure that out.

If two antennas have the same data_package_size, the active transmitter seems to be the one with the lowest resource rate. That makes sense but is there a way to confirm that?

[PhilouDS]

What do you think about this final version?

[untoldwind]

Maybe there is some other logic I am not aware of, but as far as I understand the logic in the ScienceStorageComponent the ActiveTransmitter is determined by going to the part list filtering out all transmitters in connection range and then using the first transmitter of that list with the highest DataPackSize - regardless of the transmitInterval or resource rate.

And the UI looks pretty cool. Would it be okay to link your repo as another showcase in the README?

[PhilouDS]

Maybe there is some other logic I am not aware of, but as far as I understand the logic in the ScienceStorageComponent the ActiveTransmitter is determined by going to the part list filtering out all transmitters in connection range and then using the first transmitter of that list with the highest DataPackSize - regardless of the transmitInterval or resource rate.

Okay... For now, if 2 different antennas have the same DataPackSize, I'll keep the one with the highest rate (worse case scenario)

And the UI looks pretty cool. Would it be okay to link your repo as another showcase in the README?

Thanks. Here my github link with my UIs: https://github.com/PhilouDS/KontrolSystem2_VAB_UI -> UI_EC_info -> UI_stage_info -> UI_time_warp

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.