Feature Request: Allow user-defined Lua functions to be reusable

[invobzvr]

Current behavior:

• Reusable Lua functions can only be obtained from the community.
• User-defined Lua scripts can be used only as a single node (non-reusable) and become uneditable after adding a version field.

Expected behavior / Proposal:

• Allow users to add Lua scripts manually by default, without requiring them to come from the community.
• Permit user-defined Lua functions to be reused as nodes in other functions when either:
  • the first node of the user-defined function is a Lua script, or
  • the function has no data source.
• Remove the restriction that makes a user-defined Lua script uneditable after a version field is added, or provide a clear and safe workflow to update versions without losing editability.

[SamAmco]

Hi. Thanks for this.

I agree this feature is currently a shortfall in the current system. You should be able to re-use custom node scripts.

I would slightly challenge the idea that you actually need a version for your custom nodes though. My intention was that only catalog nodes need a version.

There were a few motivations for versioning nodes.

1. In the future I'd like to allow the nodes to auto-update if I release a patch for one of them
2. I essentially publish all nodes to one catalog file that gets distributed to all users, the clients are responsible for figuring out which ones they're compatible with, they do this by comparing the apps hard coded compatibility version against the major version of the node.

What's the use case for users to add versions to custom nodes? I would think you'd just name them differently. You could put a version in the name if it helps you organise things.

[invobzvr]

Yes, I understand that, I point out that behavior cuz I notice that the UI changes after adding version metadata.

I tried to extract the same logic lua script to some defined options, but I also found the defined enum options cannot be selected, this may be a separate issue?

Then I came up with the reusable script as a better solution to satisfy my needs.

And thanks for developing this app, looking forward to seeing its continued evolution.

[SamAmco]

Would you like to share your node script so I can check the enum issue?

[invobzvr]

Just paste the community script, but the option is empty

[SamAmco]

Ah i see what's happened here. This is a combination of a minor bug and a mis-understanding.

Essentially anywhere you see a name with an underscore prefix, that's a key lookup. At runtime it looks that key up in a table of localisations. However that table is only available when parsing functions from the catalogue, it doesn't work with local lua scripts. That's expected behaviour, the translations table is only really there for de-duplication of common localised strings (to keep the catalogue more compact). I expect most people don't want or need localisation for their custom scripts, but if for some reason you did you can still embed localisations directly in the script e.g. the title does this:

  title = {
    ["en"] = "Periodic Aggregation",
    ["de"] = "Periodische Aggregation",
    ["es"] = "Agregación Periódica",
    ["fr"] = "Agrégation Périodique",
  },

The minor bug is that the UI is refusing to show the enum options after failing to find the localisations. It should at least just show the raw string the same way the labels do. I'll fix this now locally and it will go out in the next release. I'll also add a note to the docs to try and help others as it is admittedly a bit confusing.

TLDR: The fix for you is essentially to remove the underscore prefixes from any display text (e.g. name values) and remove the version from the script.

[invobzvr]

Ok, thx.

By the way, is there any plan for reusable scripts so far?

[SamAmco]

Not particularly. It requires rather significant work for something that probably most people won't use so it's not high on the priority list right now, sorry.