I'd been struggling with the heat inserter energy_source connections for so long, never thought to do it the other way around; using the hidden heat pipe to form the connections, and setting the inserter energy_source to copy from from the hidden heat pipe instead

Hope you don't mind, but I'll be copying that general solution into my own mod, since I do realize the functionality was not exactly working properly in 2.1 (at least I'm pretty sure it was still working on 2.0, unless a Factorio update changed something across both versions)

It's under MIT license, so feel free to do it, no worries ~
And you are welcome ~
And yea I though about that solution, but had hard time to do it, but thanks to the AI fixing my broken stuff, it seem to work very well.
Since I'm very bad at scripting, and I'm not fully confident in AI help, if you see something that could be improved in 'my' script, let me know ~ (aka redundancy, useless line of codes, etc...)

Edit: Oh and as far as I could test myself, they both work in 2.0 and 2.1.

Edit2: Also, using that method prevent from a weird crash: when copy/cutting something, when pressing shift when in blueprints/ghost mod with the heat inserter, it was making the game crash. But using the heat-pipe compound to transfer heat to the inserter instead, do not make the game crash when pressing shift key. What was making the game crash, it's using the heat_connections on the inserter.

Hm, interesting; I hadn't run into that crash myself, but I also wasn't using blueprints very often, was expecting the Things API (which handles the composite entity part of the runtime code for me) to be able to handle that more gracefully in 2.1

But no worries about the license; I don't plan on using the code (since your exact implementation is very different from mine; more hard-coded and less automated during the data stage, and I'm not comfortable borrowing anything from the control stage)

As for improving your own runtime implementation, I did notice that you use %10 to process every 10 ticks, which is fine for a small number of entities, but might cause problems if you were to add too many.

I doubt it will ever be a problem for you (like, how many heat inserters could one base use, compared to all the other calculations that would need to happen outside of your own control code), but I've heard that spreading checks across several ticks to be the idealized solution from most experienced modders. Unfortunately, I don't have a good implementation of this myself (I did something like spreading n number of entity checks across x number of ticks, but not in the most optimal way)

The best advice I got (which I am using to update my control code in the next heat inserters update) was to look at this on_tick code, provided by Thremtopod on the Foundry discord, and how they use next() to keep track of their placement in the storage table. You can try feeding that code to whichever AI assistant you are using, with some context about spreading entity checks across multiple ticks instead of checking them all in one tick

Understood ~
And yea, I tend to hard code thing, because I don't know how to do otherwise, that's why I suck in scripting tho.

I see, I can understand why it is better to change the refresh rate dynamically for better performances, but I just don't know at all how to do this (When I say my level in scripting is bad, it's probably an understatement ^^')

When I find the time and the energy, I'll look at this code, thanks a lot! And I will probably setup a better workflow with the AI since I'm only using simple chat prompting yet, no external databases.

In the end, I try to make the code the shortest and the simplest possible... And I still understand only half of it sooo...
(Sorry, I don't try to complain about my code level, it's just an hard wall that prevent me to go further for now x'p)

For now, I can change the refresh rate to be 60 I guess (every one second)? Because if people use the inserters as it is, with mods that add more purpose to the heat mechanic, it could end to performances problems ^^'

I think your %10 implementation is fine the way it is now; I have no idea how many it will take to cause a noticeable impact on the game, but it would likely be somewhere in the hundreds or thousands of heat inserters, maybe more? Megabase levels of exclusively using heat inserters; very unlikely imo

Changing the rate would only change how often you get a spike of activity, which won't really alleviate the problem, if it ever gets to that level

Ahah, true x'p
And understood, thank you anyway for your guidance ~