Before submitting a job, the add-on now checks the version of the Manager.
If this is not the same version of the add-on, a warning is shown and a
"Force Submit" button appears. This makes it both explicit that something
is iffy and still allows for pushing forward.
This is important when upgrading Flamenco, because I'm sure many people
will forget to actually redownload and reinstall the add-on.
Split the `comms.ping_manager()` function into two: one that returns the
version & config of the Manager, and the other that reports on it.
This will make it possible to do the former without the latter in certain
other situations where we want to refresh the manager info in the
background.
Add a new `abspath(path)` function to the add-on, for use in job type
settings. With this, the "simple blender render" job can support relative
paths for the "render output root" setting, and still have an absolute
final "render output path".
Always use absolute paths in the `last_n_dir_parts()` function. This fixes
an issue with the "simple Blender render" job type, when a
blendfile-relative path was used for the render output root.
The etag prevents job submissions with old settings, when the job
compiler script has been edited. The etag is the SHA1 hash of the
`JOB_TYPE` dictionary (as defined by the JavaScript file). The hash is
computed in a way that's independent of the exact formatting in the
JavaScript file. Also the actual JS code itself is irrelevant, just the
`JOB_TYPE` dictionary is used.
Whenever the URL to Flamenco Manager is updated, check it and report.
This required moving the 'ping manager' code into a separate function, as
calling an operator from an RNA update callback is not a good idea.
For each job setting, if it's visible and has an `eval` property, it is now
evaluated immediately when switching job types. This means that properties
like the frame range get filled in automatically.
If there is already a value, this process is skipped, in order to not
overwrite the user's choice.
This resolves a common issue where the render job was rejected because
the frame range was kept empty.
Refactor the `FLAMENCO_OT_submit_job.poll()` function to actually use the
`job_types.active_job_type()` function instead of reimplementing similar
logic.
No functional changes.
Flamenco now no longer uses the Git tags + hash for the application
version, but an explicit `VERSION` variable in the `Makefile`.
After changing the `VERSION` variable in the `Makefile`, run
`make update-version`.
Not every part of Flamenco looks at this variable, though. Most
importantly: the Blender add-on needs special handling, because that
doesn't just take a version string but a tuple of integers. Running
`make update-version` updates the add-on's `bl_info` dict with the new
version. If the version has any `-blabla` suffix (like `3.0-beta0`) it
will also set the `warning` field to explain that it's not a stable
release.
Two-way variable implementation in the job submission end-point. Where
Flamenco v2 did the variable replacement in the add-on, this has now
been moved to the Manager itself. The only thing the add-on needs to
pass is its platform, so that the right values can be recognised.
This also implements two-way replacement when tasks are handed out, such
that the `{jobs}` value gets replaced to a value suitable for the
Worker's platform as well.
When the to-be-submitted blend file is already stored in the shared
storage, and Shaman is disabled, the add-on now skips BAT-packing it.
Instead, the file is copied to `filename.flamenco.blend` and the path is
submitted as-is.
Adjust the loading of BAT from a wheel file in such a way that all
submodules are loaded in one go. This ensures that they're still
isolated from the rest of Blender (so other add-ons won't find our BAT),
but not from each other (so that there is only one copy of each
submodule).
In practice, this solves an issue where calling
`blender_asset_tracer.blendfile.set_strict_pointer_mode(False)` had no
effect. This was caused by each loaded submodule having a different copy
of `blendfile`.
Also loaded modules are logged more explicitly (at INFO level) to aid in
debugging later on.
Due to issues with library overrides and unsynced pointers, it's quite
common for the Blender Animation Studio to get "address unknown" errors
from BAT. To avoid these, Strict Pointer Mode is disabled.
Manager always creates an implicit variable `{jobs}`. This used to be
Shaman-dependent, but now it's always there (has been for a while). This
is now reflected in an add-on comment, and in an extra unit test.
