[daxsc]

Summary

Adds api calls to control DTPF behaviour.

isConvergenceEnabled function():bool -- Returns whether this block has convergence enabled.
setConvergenceEnabled function(enabled:bool) -- Sets whether this block has convergence enabled.
getConvergenceCatalystType function():number -- Returns the catalyst tier this block uses when convergence is enabled.
setConvergenceCatalystType function(tier:number) -- Sets catalyst tier used when convergence is enabled.

I wasn't sure which clamp function to use for setConvergenceCatalystType so let me know if there is a different one I'm supposed to use.

Checklist

• I have tested this PR in DevEnv
• I have tested this PR in Fullpack
• This PR is in compliance with the GTNH AI Policy
• This PR requires another PR in order to merge

[Ruling-0]

It would be good if you could share some details on the following:

1. Why should these functions exist -- what capability gap are you trying to solve, or how does this allow for better player expression (and doesn't somehow trivialize existing functionality)?
2. Why don't these functions need a matching redstone-friendly implementation on the DTPF, or how will you implement that if this is approved?

Just to answer common developer questions that arise when people propose improved OC functionality.

[daxsc]

1. Why should these functions exist -- what capability gap are you trying to solve, or how does this allow for better player expression (and doesn't somehow trivialize existing functionality)?

I use this in my playthrough to enable convergence on my ondemand DTPFs when they are making something I requested and disable it when it switches back to passive recipe. That's the only impactful use-case I can imagine for these functions. It might allow people to take advantage of convergence without needing to be able to afford running them in convergence mode 24/7, but I don't think it has that much of an impact on the game.

2. Why don't these functions need a matching redstone-friendly implementation on the DTPF, or how will you implement that if this is approved?

I don't know if they need a matching redstone-frinedly implementation (I'd say not but I'm a redstone hater). To implement this through redstone I'd make custom hatches (or maybe covers but hatches will work better, probably) for DTPF to read/send redstone signals. So 4 hatches total, 2 to read/write convergence status and 2 to read/write catalyst config.

[Ruling-0]

1. Why should these functions exist -- what capability gap are you trying to solve, or how does this allow for better player expression (and doesn't somehow trivialize existing functionality)?

I use this in my playthrough to enable convergence on my ondemand DTPFs when they are making something I requested and disable it when it switches back to passive recipe. That's the only impactful use-case I can imagine for these functions. It might allow people to take advantage of convergence without needing to be able to afford running them in convergence mode 24/7, but I don't think it has that much of an impact on the game.

2. Why don't these functions need a matching redstone-friendly implementation on the DTPF, or how will you implement that if this is approved?

I don't know if they need a matching redstone-frinedly implementation (I'd say not but I'm a redstone hater). To implement this through redstone I'd make custom hatches (or maybe covers but hatches will work better, probably) for DTPF to read/send redstone signals. So 4 hatches total, 2 to read/write convergence status and 2 to read/write catalyst config.

From some quick discussion, I think for now this PR should get frozen (as we're close to 2.9 release). There are currently some 2.10 plans that involve adding a redstone hatch already to DTPF. That hatch would be an ideal candidate to gain this functionality, and when that's done, I think this can be added.