Support loading user plugin from .pck

[Airyzz]

In a production environment, writing custom scripts to integrate software with a studio pipeline is often required.

For the most part, all we need to do is load a scene which can then run whatever script the user likes. User plugins can be created in godot and exported as .pck

In an ideal world, we would have a defined API that can be used to interact with material maker, but of course such a thing would be a much larger feature. As it is, I think just being able to load user scripts is sufficient, as we can grab nodes dynamically. even if there is a risk of node layouts changing between updates and breaking user scripts, I think this is a large benefit

[Calinou]

Is there documentation for this feature? Make sure to open a PR for the manual as well 🙂

Also, I'm not sure whether PCK is more suited than a raw folder structure. While PCK doesn't require extracting a ZIP archive to be able to use it, it's harder to modify for local use and slows down iteration as a result.

In Godot 4.1 and later, you have ZIPPacker and ZIPReader classes so add-ons could be shipped as ZIP files (perhaps with renamed file extension, if you don't want users to accidentally extract them).

[RodZill4]

Is there documentation for this feature? Make sure to open a PR for the manual as well 🙂

Documentation should be updated in this PR I guess.

That's an interesting feature, but do you have examples of what kind of plugins you'd want to create? I'm afraid it would not really be usable without a well defined API.

[Airyzz]

Is there documentation for this feature? Make sure to open a PR for the manual as well 🙂

Also, I'm not sure whether PCK is more suited than a raw folder structure. While PCK doesn't require extracting a ZIP archive to be able to use it, it's harder to modify for local use and slows down iteration as a result.

In Godot 4.1 and later, you have ZIPPacker and ZIPReader classes so add-ons could be shipped as ZIP files (perhaps with renamed file extension, if you don't want users to accidentally extract them).

I agree that iteration with pck is slow, but the reason I decided to go this way is that I would like the option to be able to create custom UIs using godot and export them that way, instead of having to create eveything via gdscript. would this be possible with just a folder structure? I am not sure how to load resource pack from a folder instead of pck/zip

[Airyzz]

Is there documentation for this feature? Make sure to open a PR for the manual as well 🙂

Documentation should be updated in this PR I guess.

That's an interesting feature, but do you have examples of what kind of plugins you'd want to create? I'm afraid it would not really be usable without a well defined API.

The main thing I want to create is just to get material maker integrated in to my asset pipeline. So handling things like importing/updating external assets, and facilitating the publishing of materials to other departments

So far it hasnt been too hard to interact with material maker just by grabbing get_node("/root/mm_globals") and interacting from there - but as I'm still early in developing my integration maybe I will face some issues soon

[Airyzz]

As i continue, im realising its actually not particulary difficult to interact with material maker despite not having a defined API. there are some things that are a little hacky, but for the most part its not too bad. For example, part of my pipeline integration require exporting of animation which was relatively easily achieved:

static func export(plugin_node, file_path, recommended_file_name):
    var globals = plugin_node.get_node("/root/mm_globals")
    var project = globals.main_window.get_current_project()

    var material_node = project.get_node("node_Material")
    var port = material_node.generator.get_source(0)
    var generator = port.generator
    var index = port.output_index

    var window = load("res://material_maker/windows/export_animation/export_animation.tscn").instantiate()
    var export_button = window.get_node("VBox/Buttons/Export")

    # disconnect existing button behaviour and replace with our own
    for connection in export_button.pressed.get_connections():
        export_button.pressed.disconnect(connection.callable)

    export_button.pressed.connect(func() : do_export(window, recommended_file_name, file_path))

    mm_globals.main_window.add_dialog(window)
    window.set_source(generator, index)
    window.popup_centered()

static func do_export(window, recommended_file_name, file_path):
    window.do_export([file_path + "/" + recommended_file_name + ".png"])

I dont think defining an API for interacting with everything is strictly necessary, but some areas could be improved to make them easier to interact with. For example I had to separate the animation export in to two different functions to be able to export to a predefined file path - small things like this would go a long way to making this work really well.