Function Loading
Due to how functions load in Minecraft (It loads sorted by file name), older Datapack Manager versions will always run first and override any newer version of Datapack Manager.
On one hand, this is unwanted behavior because you'd want the latest version to run first, but on the other hand, this means that Datapack Manager will always be backwards compatible if the datapack developer supports older versions.
Dirty System
This is just a simple way for code to be run later. Using it is a matter of setting the dirty variable to false, which will execute functions when the scheduled ticker function runs. It is a good way to create a "callback/listener/subscribe" system where you can simply set a variable in your datapack using the global Datapack Manager scoreboard, and test for it in another datapack. Datapack Manager can also use it to schedule installers and datapack startup functions.
"Singleton"
Since there will always only be one instance of Datapack Manager, everything that Datapack Manager runs must be done through the dirtying system. Datapack Manager can never be unique to each datapack.
References
Code like this cannot exist in Datapack Manager
Code sourced from
dimensionaldoors-v3.00.00\data\datapackmanager\functions\preinstaller\run.mcfunction
29.
30. # run datapack updater/installer
31. execute if score VERSION$minecraft.current DatapackManager matches 14..19 run function dimensionaldoors:startup-3.00.00
32.
The Solution
Datapack Manager should use a push method to get data out to the datapacks and utilize the 'dirty system' to run any global detection code.
Example of how a fix might look like
Example code for datapackmanager\functions\preinstaller\run.mcfunction
This code runs after Datapack Manager completes the preinstallation process
29.
30. # push datapacks to start the installation process
31. execute if score VERSION$minecraft.current DatapackManager matches 13..19 run scoreboard players operation FUNCTION$install DatapackManager = BOOL$true DatapackManager
32.
...
53.
54. scoreboard players operation <DN>$dirty <DatapackName> = BOOL$true DatapackManager
55.
Example code for <datapackname>\functions\tickupdates\update.mcfunction
This function might run on a scheduled tick if dirty is true.
1. # listener => start the installation process
2. execute if score FUNCTION$install DatapackManager = BOOL$true DatapackManager run function <path_to_installer>
3. scoreboard players operation FUNCTION$install DatapackManager = BOOL$false DatapackManager
4.
...
14.
15. scoreboard players operation <DN>$dirty <DatapackName> = BOOL$false DatapackManager
16.
Function Loading
Due to how functions load in Minecraft (It loads sorted by file name), older Datapack Manager versions will always run first and override any newer version of Datapack Manager.
On one hand, this is unwanted behavior because you'd want the latest version to run first, but on the other hand, this means that Datapack Manager will always be backwards compatible if the datapack developer supports older versions.
Dirty System
This is just a simple way for code to be run later. Using it is a matter of setting the
dirtyvariable tofalse, which will execute functions when the scheduled ticker function runs. It is a good way to create a "callback/listener/subscribe" system where you can simply set a variable in your datapack using the global Datapack Manager scoreboard, and test for it in another datapack. Datapack Manager can also use it to schedule installers and datapack startup functions."Singleton"
Since there will always only be one instance of Datapack Manager, everything that Datapack Manager runs must be done through the dirtying system. Datapack Manager can never be unique to each datapack.
References
Code like this cannot exist in Datapack Manager
The Solution
Datapack Manager should use a push method to get data out to the datapacks and utilize the 'dirty system' to run any global detection code.
Example of how a fix might look like