You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UUIDs should always be the same for the add-on. So if the project is for example pulled and built by someone else, it is important that they have the same UUIDs as the BP may make use of a custom manifest which has the RP's UUID as a dependency (or an external add-on not directly related to the project).
It would make sense to introduce a allay.lock file that stores this information. It could look like this:
# This file is @generated and managed by Allay# Do not edit this file manually!
[uuid.bp]
header = "<uuid>"modules = { data = "<uuid>", script = "<uuid>" }
[uuid.rp]
header = "<uuid>"modules = { resource = "<uuid>" }
[uuid.sp]
header = "<uuid>"modules = { skin_pack = "<uuid>" }
[uuid.wt]
header = "<uuid>"modules = { world_template = "<uuid>" }
On top of that, all UUIDs should be generated on demand. The allay uuid subcommand can gray out UUIDs that are (probably) not used.
The text was updated successfully, but these errors were encountered:
UUIDs should always be the same for the add-on. So if the project is for example pulled and built by someone else, it is important that they have the same UUIDs as the BP may make use of a custom manifest which has the RP's UUID as a dependency (or an external add-on not directly related to the project).
It would make sense to introduce a
allay.lock
file that stores this information. It could look like this:On top of that, all UUIDs should be generated on demand. The
allay uuid
subcommand can gray out UUIDs that are (probably) not used.The text was updated successfully, but these errors were encountered: