Regulator block reuse / library

[dracorpg]

There (that I know of) is no proper way to propagate/share property changes (i.e. fixing an erroneous value or refining the efficiency curve) from a regulator block to other similar ones on the same schematic.
One must either manually edit characteristics for each regulator block, which is both tedious and error-prone (especially for efficiency curves) or reassign their loads to new copies of the modified regulator block (taking care to re-edit their names etc... also tedious and error-prone!). Furthermore, there is no way to share all this across schematic file boundaries (other than using a previous file as base for a new one).

The ideal solution would probably be a library of regulators, likely stored in the schematic file but supporting export/import of individual (or all?) regulators for sharing across schematics. I'm aware this would represent a sizeable feature compared to the current scope of PTree.

Maybe a good first MVP could be just supporting the export/import of an individual regulator block's properties to its own JSON file? Or maybe even just import/export efficiency (& dropout?) curves as CSV?

[smariel]

This is, again, a good idea.
An internal library may be very hard to build and to maintain. But an export/import function for all curves may be a good compromise to let users build their own libraries. A proprietary JSON file would be much easier than a a spreadsheet but less flexible. I'll think about it.

By the way, in your project, you can copy/paste a regulator. Did you noticed that you can right click each elements on the tree ? There are a lot of simple functions but no documentation yet.

[dracorpg]

By the way, in your project, you can copy/paste a regulator. Did you noticed that you can right click each elements on the tree ? There are a lot of simple functions but no documentation yet.

Yes, this is what I mentioned as the only way to "update" several instances of the same regulator. By the way, I think the documentation isn't that lacking as the UI remains quite simple : most features are intuitively discoverable by the typical user.

Half off-topic, on the subject of the JSON file structure: I had a quick look into a .ptree file (to see if some quick&dirty text replacement could help achieve my use case) and it turns out that PTree doesn't dump a JSON representation of its complete object hierarchy, but rather nests JSON string representations at each hierarchical level (resulting in massive amounts of quote escaping).

The beginning of a .ptree file looks like this: {"tree":"{\"item_list\":[\"{\\\"id\\\":0,\\\"type\\\":\\\"root\\\"....
Surely this was not an intentional design - shall I create an issue for us to discuss that properly?

[smariel]

That's because JS JSON methods work with strings. You can open an issue, it would be an interesting optimization but not a priority.