Hey,
i want to test and hopefully improve the bigdoors-doors like a garagedoor.
Sadly, i do not understand, how i can compile bigdoors-doors and use it with bigdoors?
Therefore, a readme or little developer instructions would be awesome.
I also want to ask for some javadocs.

My players are a bit annoyed by the fact that when a friend gives them control over one of their doors with /BigDoors AddOwner, it counts as one of their own doors for bigdoors.own.<numberOfDoors>, meaning that they can't actually own the amount of Doors that are advertised and feel it is misleading. (e.g. 4 Doors using bigdoors.own.4 are actually only 2 Doors if you also have permission to use 2 Doors of your Friend)
I thought a bit about it and i also agree with them.

So i wanted to ask you if you could either stop the doors of other players being counted for your own limit or at least add an option to enable that behavior (To not cause problems for servers that like the way it currently is.)

Thank you in advance :)

Hello there!

It seems something happened when a windmill structure was deleted while still spinning.

Now the blocks are stuck mid-animation and you can't get rid of them, even in creative!

How can I get rid of these stuck blocks?

Hey, I have been using BigDoors for quite a while now and me and my players love it, but I just noticed on the Spigot page that it Supports 1.11 o 1.19, which is just super unnecessary, as some of those versions are literally not played anymore...
You can see on Spigot's Bstats or Paper's Bstats that versions like 1.11, 1.13 and 1.14 are literally not played anymore and versions such as 1.12 and 1.15 are barely played anymore...
Note that Support from Mojang, Spigot or Paper for these versions has also been long gone...

So you could optimize/modernize BigDoors code a bit and make it easier to maintain if you remove the support for these ancient MC versions that aren't even played anymore (So make the plugin 1.16.5+ only) (If you still want to support the about 8% of Servers that for some weird reason are still on 1.16...best would probably be 1.18.2+)
This would also probably remove the need for XSeries and thus also quite significantly reduce compile time and jar size...

Edit: or consider doing it like UltraCosmetics does it, support 1.12.2 and 1.16.5+, if your 1.12 playerbase is too big to just remove yet :)

Please tell me what you think about this 😅

I don't know why, there doesn't appear to be any errors in the log, but only the garage door and flag structures are loading from the jars. I really was hoping for the windmill and clock structures since they'd be amazing additions to a server im building, but they don't seem to be loading when the server it restarted :/

[15:06:20 WARN]: [AnimatedArchitecture] Plugin AnimatedArchitecture v0.4 generated an exception while executing task 3386
java.lang.AbstractMethodError: Receiver class nl.pim16aap2.animatedarchitecture.structures.windmill.WindmillAnimationComponent does not define or inherit an implementatio
n of the resolved method 'abstract void executeAnimationStep(nl.pim16aap2.animatedarchitecture.core.animation.IAnimator, java.lang.Iterable, int)' of interface nl.pim16aa
p2.animatedarchitecture.core.animation.IAnimationComponent. at nl.pim16aap2.animatedarchitecture.core.animation.Animator.executeAnimationStep(Animator.java:332) ~[AnimatedArchitecture-Spigot.jar:?] at nl.pim16aap2.animatedarchitecture.core.animation.Animator$1.run(Animator.java:469) ~[AnimatedArchitecture-Spigot.jar:?]
at nl.pim16aap2.animatedarchitecture.spigot.util.implementations.ExecutorSpigot$1.run(ExecutorSpigot.java:170) ~[AnimatedArchitecture-Spigot.jar:?]
at org.bukkit.craftbukkit.v1_19_R3.scheduler.CraftTask.run(CraftTask.java:101) ~[paper-1.19.4.jar:git-Paper-513]
at org.bukkit.craftbukkit.v1_19_R3.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:57) ~[paper-1.19.4.jar:git-Paper-513]
at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[paper-1.19.4.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) ~[?:?]

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update dependency com.alibaba:fastjson to v2.0.47
• Update dependency com.github.TechFortress:GriefPrevention to v16.18.2
• Update dependency com.sk89q.worldedit:worldedit-bukkit to v7.2.20
• Update dependency com.uber.nullaway:nullaway to v0.10.23
• Update dependency it.unimi.dsi:fastutil to v8.5.13
• Update dependency net.kyori:adventure-platform-bukkit to v4.3.2
• Update dependency org.apache.maven.plugins:maven-shade-plugin to v3.5.2
• Update dependency org.eclipse.jdt:org.eclipse.jdt.annotation to v2.2.800
• Update JamesIves/github-pages-deploy-action action to v4.5.0
• Update dependency com.github.Angeschossen:LandsAPI to v6.44.10
• Update dependency net.kyori:adventure-api to v4.16.0
• Update dependency org.apache.maven.plugins:maven-compiler-plugin to v3.12.1
• Update dependency org.apache.maven.plugins:maven-surefire-plugin to v3.2.5
• Update dependency org.jetbrains:annotations to v24.1.0
• Update dependency org.xerial:sqlite-jdbc to v3.45.1.0
• Update dependency.version.dagger to v2.51 (com.google.dagger:dagger-compiler, com.google.dagger:dagger)
• Update dependency.version.plotsquared to v7.3.5 (com.intellectualsites.plotsquared:plotsquared-bukkit, com.intellectualsites.plotsquared:plotsquared-core)
• Update mockito monorepo to v5.11.0 (org.mockito:mockito-junit-jupiter, org.mockito:mockito-core)
• Update actions/setup-java action to v4
• Update actions/upload-artifact action to v4
• Update dependency com.github.TechFortress:GriefPrevention to v17
• Update dependency io.github.git-commit-id:git-commit-id-maven-plugin to v7
• Update dependency org.slf4j:slf4j-api to v2
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency ch.qos.logback:logback-classic to v1.2.13 [SECURITY]
• Update dependency ch.qos.logback:logback-core to v1.2.13 [SECURITY]
• Update dependency com.github.TownyAdvanced:towny to v0.100.1.18
• Update dependency net.bytebuddy:byte-buddy to v1.14.12
• Update dependency org.apache.maven.plugins:maven-checkstyle-plugin to v3.3.1
• Update dependency org.apache.maven.plugins:maven-javadoc-plugin to v3.6.3
• Update dependency org.apache.maven.plugins:maven-jxr-plugin to v3.3.2
• Update junit5 monorepo to v5.10.2 (org.junit.jupiter:junit-jupiter-engine, org.junit.jupiter:junit-jupiter-api)
• Update dependency com.puppycrawl.tools:checkstyle to v10.14.0
• Update dependency org.apache.maven.plugins:maven-pmd-plugin to v3.21.2
• Update dependency org.apache.maven.plugins:maven-project-info-reports-plugin to v3.5.0
• Update dependency.version.errorprone to v2.25.0 (com.google.errorprone:error_prone_core, com.google.errorprone:error_prone_annotations)
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency com.plotsquared:PlotSquared-Bukkit to v6.11.2
• Update dependency com.plotsquared:PlotSquared-Core to v6.11.2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

[11:36:55 WARN]: [BigDoors] Failed to initialize the "GriefDefender" (version "2.2.2") compatibility hook!
[11:36:55 WARN]: [BigDoors] Now resuming normal startup with the "GriefDefender" Compatibility Hook disabled!
[11:36:55 WARN]: [BigDoors] java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at BigDoors (3).jar//nl.pim16aap2.bigDoors.compatibility.ProtectionCompatManager.loadFromPluginName(ProtectionCompatManager.java:285)
at BigDoors (3).jar//nl.pim16aap2.bigDoors.compatibility.ProtectionCompatManager.restart(ProtectionCompatManager.java:62)
at BigDoors (3).jar//nl.pim16aap2.bigDoors.compatibility.ProtectionCompatManager.(ProtectionCompatManager.java:50)
at BigDoors (3).jar//nl.pim16aap2.bigDoors.BigDoors.onEnable(BigDoors.java:216)
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:264)
at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:370)
at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:542)
at org.bukkit.craftbukkit.v1_19_R1.CraftServer.enablePlugin(CraftServer.java:565)
at org.bukkit.craftbukkit.v1_19_R1.CraftServer.enablePlugins(CraftServer.java:479)
at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:638)
at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:424)
at net.minecraft.server.dedicated.DedicatedServer.e(DedicatedServer.java:308)
at net.minecraft.server.MinecraftServer.v(MinecraftServer.java:1128)
at net.minecraft.server.MinecraftServer.lambda$spin$1(MinecraftServer.java:307)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NoClassDefFoundError: com/griefdefender/GriefDefenderPlugin
at BigDoors (3).jar//nl.pim16aap2.bigDoors.compatibility.GriefDefenderProtectionCompat.(GriefDefenderProtectionCompat.java:21)
... 20 more
Caused by: java.lang.ClassNotFoundException: com.griefdefender.GriefDefenderPlugin
at org.bukkit.plugin.java.PluginClassLoader.loadClass0(PluginClassLoader.java:153)
at org.bukkit.plugin.java.PluginClassLoader.loadClass(PluginClassLoader.java:105)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 21 more

Currently, a requirement is for the plugin to be on Java 19+, I'm assuming you're using a library that isn't available on previous versions.

Later versions of mc are made and developed on and for Java 17. Minecraft is most optimized for this version. Requiring the server to be on Java 19 in order to use this plugin causes some issues.

I understand that lowering the minimum Java version is a big ask, but I do think it's definitely warranted. Would also let a lot more people be able to use this plugin since not everyone's willing to attempt to run their server on Java 19+

Hey,
I am sometimes checking out this repo to see how progress is going for V2 and I have noticed that you have just removed the AutoCloseTimer (#259) and that you don't plan to support it in V2...

I wanted to ask if there is any specific reason for that and for you to please reconsider that change, as the AutoCloseTimer is literally one of the most important features of BigDoors.
IMO, it's even a complete necessity for BigDoors, which without it, the plugin would be quite annoying to use, as you would have to manually close every single door after using it (At least on my server, as almost every BigDoor on my server uses an AutoCloseTimer).

So, please consider re-adding the AutoCloseTimer.

Thanks in advance

A friend figured this out for me, and I confirmed using my alt account. Apparently structures will not work unless the owner of the structure is online, resulting in things like doors remaining permanently closed and flags and windmills stopping.

The Problem

For debugging purposes, it is helpful to know the history of problematic shutdowns such as server crashes. A 'problematic shutdown' in this context refers to any situation where the plugin shuts down without completing the shutdown process.

One example of an issue that may arise after a problematic shutdown is orphaned blocks, as further described in issue #593.

The Implementation

For the implementation, I propose to let the DatabaseManager do most of the heavy lifting for the following reasons:

• This is the only class with direct access to the database.
• It is a registered IRestartable, meaning its initialization and shutdown methods will be called when the plugin is initialized/shut down. Specifically, these methods will be called whenever the plugin's onEnable or onDisable methods are called.
• It is a very 'central' class; It has very few dependencies on its own (none of which are restartable) and it is a dependency of many other classes. In fact, it is the third restartable to be registered at the time of writing (preceded by only the config and the LocalizationManager). On the other hand, it is a dependency of 15 other classes, some of which are restartable.
  The RestartableHolder respects the registration order of the restartables for initialization and shutdown. This means that it calls IRestartable#initialize() for all registered restartables in the order of registration and IRestartable#shutDown() in reverse order. This means that any class that depends on the DatabaseManager will be initialized after the DatabaseManager and shut down before it. In other words, the DatabaseManager is one of the last restartables to be shut down.

The idea is to create three new tables in the database:

• A table containing only a value to keep track of the current initialization state.
• A table containing only a value to store the timestamp of the initial creation of the database.
• A table to keep track of the history of problematic shutdowns.

The table storing the initial creation and the current initialization state may be a single 'metadata' table.

Whenever DatabaseManager#shutDown() is called, the DatabaseManager should tell the database to set the initialization state to false after shutting down the thread pool.

Whenever DatabaseManager#initialize() method is called, the DatabaseManager should tell the database to update the initialization to true and return the previous initialization state before creating a new thread pool. If the last state initialization is not false, we can infer that the previous shutdown of the plugin was problematic.

After detecting a problematic shutdown, the DatabaseManager should instruct the database to store the timestamp at the time of detection. While this is not the time of the problematic shutdown itself, it should be close enough, as any time between the actual problematic shutdown and the subsequent startup is 'dead' time during which nothing can happen regardless.

The database will need several new methods:

• A method to get-and-set the initialization state. This should return the previous initialization state to allow for further processing.
• A method to check if any problematic restarts occurred between two timestamps (and a default method for between a given timestamp and 'now'). This should return an enum to denote any of the following states:
  • No problematic restarts
  • At least one problematic restart
  • Before database creation (so we can track issues where a user deleted the database)
• Methods to retrieve database creation date, problematic restart history, and the most recent problematic restart

Special Considerations

• Currently, there is no way to gather debug data asynchronously. This means we cannot get any data/statistics from the database for the debug report. Until that changes, the DatabaseManager should store

  • Whether the very first initialization was preceded by a problematic shutdown
  • Whether any initialization during the current run was preceded by a problematic shutdown

  These values are likely going to be the same in most cases, but the second one could catch any issues with problematic shutdowns from plugin restarts. While these should never occur, it's nice to catch them regardless.
  More debug items may be added if any come up that could provide useful data.

It would be great to set a per-structure animation speed. For Doors it would be open- and close speed, for windmills it would be the rotation speed.
This Enhancement would bring more realistic animations depending on the environment of the animation

Hey, I updated my server to 1.19.1 (from 1.18.2) and BigDoors just doesn't work at all anymore...
When I click on the "Toggle Door" Button in the menu, it just says [BigDoors] Sliding Door DoorID "DoorName" is not available right now! and nothing happens...sometimes it also throws this error:

[BigDoors] Task #31454 for BigDoors vAlpha 0.1.8.39 (b1107) generated an exception java.lang.NoSuchMethodError: 'double nl.pim16aap2.bigDoors.NMS.CustomEntityFallingBlock_V1_19_R1.dg()' at nl.pim16aap2.bigDoors.NMS.CustomEntityFallingBlock_V1_19_R1.<init>(CustomEntityFallingBlock_V1_19_R1.java:42) ~[BigDoors.jar:?] at nl.pim16aap2.bigDoors.NMS.FallingBlockFactory_V1_19_R1.fallingBlockFactory(FallingBlockFactory_V1_19_R1.java:20) ~[BigDoors.jar:?] at nl.pim16aap2.bigDoors.moveBlocks.SlidingMover.createAnimatedBlocks(SlidingMover.java:125) ~[BigDoors.jar:?] at org.bukkit.craftbukkit.v1_19_R1.scheduler.CraftTask.run(CraftTask.java:101) ~[paper-1.19.1.jar:git-Paper-95] at org.bukkit.craftbukkit.v1_19_R1.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:483) ~[paper-1.19.1.jar:git-Paper-95] at net.minecraft.server.MinecraftServer.tickChildren(MinecraftServer.java:1491) ~[paper-1.19.1.jar:git-Paper-95] at net.minecraft.server.dedicated.DedicatedServer.tickChildren(DedicatedServer.java:446) ~[paper-1.19.1.jar:git-Paper-95] at net.minecraft.server.MinecraftServer.tickServer(MinecraftServer.java:1415) ~[paper-1.19.1.jar:git-Paper-95] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1191) ~[paper-1.19.1.jar:git-Paper-95] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:305) ~[paper-1.19.1.jar:git-Paper-95] at java.lang.Thread.run(Thread.java:833) ~[?:?]

There is no error or something on startup, so I don't know why it's not working...

I'm using Paper 1.19.1 #95 if that helps

Please watch out the video to understand. Rails are white-listed, but the rails will drop.

Maybe you can fix this.

Java 17 is the usual version to run minecraft severs at, and almost every plugin is built for it. PaperMC's offical guide recommends Java 17. Many server hosting services don't even support Java versions above 17. As much as I would love to use this amazing-looking plugin, I can't because of it's java 19 requirement.

Hello! Love the windmill feature.

There's a weird "kachunkachunk" sound that's being played rather inconsistently and at a large radius from the thing, though. I'd like to see an ability in the menu to either mute it altogether or move the block it's coming from!

Assuming that's where the sound is coming from, anyway. It only started playing after we set up the windmill!

It seems that not all of the blocks are rotated, even though they are a part of the selection (in my case - trap doors and grind stones). Is this a bug or is it some kind of a limitation regarding non-solid blocks?

I was wondering why this wasnt working until I checked console and it gave me this error in red

[22:55:16 ERROR]: [ModernPluginLoadingStrategy] Could not load plugin 'AnimatedArchitecture-Spigot.jar' in folder 'plugins'
org.bukkit.plugin.InvalidPluginException: java.lang.UnsupportedClassVersionError: nl/pim16aap2/animatedarchitecture/spigot/core/AnimatedArchitecturePlugin has been compiled by a more recent version of the Java Runtime (class file version 63.0), this version of the Java Runtime only recognizes class file versions up to 61.0
at io.papermc.paper.plugin.provider.type.spigot.SpigotPluginProvider.createInstance(SpigotPluginProvider.java:127) ~[paper-1.20.1.jar:git-Paper-111]
at io.papermc.paper.plugin.provider.type.spigot.SpigotPluginProvider.createInstance(SpigotPluginProvider.java:35) ~[paper-1.20.1.jar:git-Paper-111]
at io.papermc.paper.plugin.entrypoint.strategy.modern.ModernPluginLoadingStrategy.loadProviders(ModernPluginLoadingStrategy.java:116) ~[paper-1.20.1.jar:git-Paper-111]
at io.papermc.paper.plugin.storage.SimpleProviderStorage.enter(SimpleProviderStorage.java:39) ~[paper-1.20.1.jar:git-Paper-111]
at io.papermc.paper.plugin.entrypoint.LaunchEntryPointHandler.enter(LaunchEntryPointHandler.java:36) ~[paper-1.20.1.jar:git-Paper-111]
at org.bukkit.craftbukkit.v1_20_R1.CraftServer.loadPlugins(CraftServer.java:508) ~[paper-1.20.1.jar:git-Paper-111]
at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:273) ~[paper-1.20.1.jar:git-Paper-111]
at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1101) ~[paper-1.20.1.jar:git-Paper-111]
at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:318) ~[paper-1.20.1.jar:git-Paper-111]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.lang.UnsupportedClassVersionError: nl/pim16aap2/animatedarchitecture/spigot/core/AnimatedArchitecturePlugin has been compiled by a more recent version of the Java Runtime (class file version 63.0), this version of the Java Runtime only recognizes class file versions up to 61.0
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:1012) ~[?:?]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150) ~[?:?]
at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:229) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:587) ~[?:?]
at org.bukkit.plugin.java.PluginClassLoader.loadClass0(PluginClassLoader.java:155) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?]
at org.bukkit.plugin.java.PluginClassLoader.loadClass(PluginClassLoader.java:150) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Class.java:467) ~[?:?]
at org.bukkit.plugin.java.PluginClassLoader.(PluginClassLoader.java:76) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?]
at io.papermc.paper.plugin.provider.type.spigot.SpigotPluginProvider.createInstance(SpigotPluginProvider.java:123) ~[paper-1.20.1.jar:git-Paper-111]
... 9 more

Hey there,
as shown in the Image i want to request a "Crane-Door".
This door has 2 new abilities:

1. it's like a sliding-door, but the rotation-block / swing-block is not in the corner of the selection (the iron block)
2. it's like a sliding-door, but it rotates a whole level / layer (yellow concrete, gray concrete and the iron block)

Then you can build cranes with more then 1 block width

Would be very awesome!
An API-Method to Rotate Selections (like i select with worldedit) and rotate this through a point / or example given by coordinates would be the base of this crane-door and for me and testing absolute enough.

https://hosted.weblate.org/projects/AnimatedArchitecture/#information
says CC0, but that creates a bunch of problems, since public domain laws are not compatible across jurisdictions, or even available in this manner. It thus becomes very problematic to even tell what the effective licensing is for anything that can be considered "a work", made harder still for every person contributing to it.

For collaborative work, this is a problem created, with no problems solved.

GPLv3-or-later would be much better, and is compatible with the source code license.

It can be changed in https://hosted.weblate.org/settings/AnimatedArchitecture/animatedarchitecture-core/
and so on for each component.

Newest AA-Release.

Hey there,

i created a new garage door. Everything was fine (i love the preview for the door!!).

The door open as expected:

But when 1 close - 1 row of blocks is not moved

No errors in the Console

The Problem

Ideally, animated blocks (display entities) should never be orphaned (I define orphaned in this context as no longer being tracked by this plugin.) The real blocks should be converted to animated blocks for the animation and back to real blocks when the animation ends. Any interruptions to the animation or the server should result in the animation being terminated, so there should be no way for animated blocks to 'escape' this cycle.

However, there are certain situations we cannot handle gracefully, such as a server crash. Situations like that, or bugs like #461 can result in blocks being orphaned regardless of our methods to avoid it.

The Goal

To handle orphaned blocks gracefully, I intend to add a recovery system. This is not intended as a replacement for any systems that try to avoid this issue in the first place. Whenever a block needs to be recovered using this system, it will be logged and treated as a potential bug.

The Implementation

The BlockDisplay entity is a PersistentDataHolder. This means we can store whatever data we want in a PersistentDataContainer inside the entity itself.

The plan is to store the original location of each animated block in a PersistentDataContainer.

Whenever a chunk is loaded, the plugin would then check to see if there are any BlockDisplay entities in that chunk. For every BlockDisplay entity we find that has a PersistentDataContainer with data in our namespace, we can use these data to restore the block to its original position. Because we no longer update the blockdata of the animated block itself, we can use the blockdata (which contains the block type/rotation/etc) provided by BlockDisplay#getBlock().

Special Considerations

• The plugin will try to toggle structures on chunk load based on their redstone state. Because perpetually moving structures are more likely to lead to orphaned blocks than structures with temporary animations, it is very likely that the structures that are impacted by orphaned blocks will try to toggle on chunk load. As such, we need to make sure that any recovery systems run before any redstone checks.
• It may be nice to implement a way to track server crashes so we can see if orphaned blocks are the result of a bug in this plugin or a side-effect of a server crash. However, it will be tricky to say this for certain, as the server might restart normally after a server crash without loading any of the chunks with orphaned blocks. This issue could be solved by storing the date of the last time we tracked the entity alongside its original coordinates. We could then use this to reference a map of known dates of server crashes to see if a server crash could have been the root cause of the issue.
• In issue #461, the blocks were orphaned after the structure was deleted but the animation was not. To allow us to track such issues in the future, it would be nice to store the UID of the structure in the data container alongside the original coordinates. Not only would this allow us to track issues regarding structure deletion, but it would help improve our logging of orphaned blocks as well.

Hello again!

I'd like to request more than 60 seconds to complete all the steps related to creating a new structure. Since it has to be done in survival (it doesn't work in creative, maybe that's a separate bug), if it's a large structure there's not enough time to get from points A to B to C. Alternatively, maybe get rid of the time limit altogether and just rely on manually cancelling on failure?

My friend and I have built this really cool windmill. But we couldn't figure out how to get the beam/log in the center of it, the thing the blades are on, to also spin.

I tried using a clock, another windmill... Rotating door. Is there a way to do this? If not, I'd like to request this feature!

Spigot 1.19.3-3616
BigDoors 0.1.8.40

On server start-up

[08:21:04] [Server thread/INFO]: [BigDoors] Enabling BigDoors vAlpha 0.1.8.40
[08:21:04] [Server thread/INFO]: [BigDoors] Power Block Types:
[08:21:04] [Server thread/INFO]: [BigDoors]  - GOLD_BLOCK
[08:21:04] [Server thread/INFO]: [BigDoors] Blacklisted materials:
[08:21:04] [Server thread/INFO]: [BigDoors]  - BEDROCK
[08:21:04] [Server thread/INFO]: [BigDoors]  - END_PORTAL
[08:21:04] [Server thread/INFO]: [BigDoors]  - END_PORTAL_FRAME
[08:21:04] [Server thread/INFO]: [BigDoors]  - NETHER_PORTAL
[08:21:04] [Server thread/INFO]: [BigDoors] Whitelisted materials:
[08:21:04] [Server thread/INFO]: [BigDoors]  - REDSTONE_BLOCK
[08:21:04] [Server thread/INFO]: [BigDoors] DestroyListed materials:
[08:21:04] [Server thread/INFO]: [BigDoors]  - LAVA
[08:21:04] [Server thread/INFO]: [BigDoors]  - WATER
[08:21:04] [Server thread/INFO]: [BigDoors]  - SNOW
[08:21:04] [Server thread/INFO]: [BigDoors]  - FERN
[08:21:04] [Server thread/INFO]: [BigDoors]  - GRASS
[08:21:04] [Server thread/INFO]: [BigDoors]  - TALL_GRASS
[08:21:04] [Server thread/INFO]: [BigDoors]  - SEAGRASS
[08:21:04] [Server thread/INFO]: [BigDoors]  - TALL_SEAGRASS
[08:21:04] [Server thread/WARN]: [BigDoors] ╔═══════════════════════════════════════════════════════╗
[08:21:04] [Server thread/ERROR]: [BigDoors] java.lang.Exception: Failed to generate NMS code! Please contact pim16aap2!
        at nl.pim16aap2.bigDoors.codegeneration.FallbackGeneratorManager.generateFallingBlockFactory(FallbackGeneratorManager.java:75)
        at nl.pim16aap2.bigDoors.codegeneration.FallbackGeneratorManager.getFallingBlockFactory(FallbackGeneratorManager.java:40)
        at nl.pim16aap2.bigDoors.BigDoors.compatibleMCVer(BigDoors.java:816)
        at nl.pim16aap2.bigDoors.BigDoors.onEnable(BigDoors.java:187)
        at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:264)
        at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:342)
        at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:480)
        at org.bukkit.craftbukkit.v1_19_R2.CraftServer.enablePlugin(CraftServer.java:539)
        at org.bukkit.craftbukkit.v1_19_R2.CraftServer.enablePlugins(CraftServer.java:453)
        at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:587)
        at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:412)
        at net.minecraft.server.dedicated.DedicatedServer.e(DedicatedServer.java:250)
        at net.minecraft.server.MinecraftServer.w(MinecraftServer.java:973)
        at net.minecraft.server.MinecraftServer.lambda$0(MinecraftServer.java:301)
        at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.ExceptionInInitializerError
        at nl.pim16aap2.bigDoors.codegeneration.FallbackGeneratorManager.getMappingsVersion(FallbackGeneratorManager.java:83)
        at nl.pim16aap2.bigDoors.codegeneration.FallbackGeneratorManager.generateFallingBlockFactory(FallbackGeneratorManager.java:55)
        ... 14 more
Caused by: java.lang.NullPointerException: Expected 1 method, but got 0 for input: [public static net.minecraft.world.level.block.state.IBlockData net.minecraft.nbt.GameProfileSerializer#[*](net.minecraft.nbt.NBTTagCompound)]. excluding superclasses, excluding interfaces
Found methods: []
        at nl.pim16aap2.bigDoors.reflection.ReflectionBackend.findMethod(ReflectionBackend.java:298)
        at nl.pim16aap2.bigDoors.reflection.MethodFinder$TypedMethodFinder.get(MethodFinder.java:218)
        at nl.pim16aap2.bigDoors.codegeneration.ReflectionRepository.<clinit>(ReflectionRepository.java:268)
        ... 16 more