When doing /ctf with an empty hand to a group, "Switched Citadel mode to Normal mode from Normal mode" outputs unnecessarily.

While riding on a horse, pressure plates don't activate so I'm unable to go through the security doors around Westminster that were originally built for horses.

Recently this piece of code has been causing a large amount of lag on the main server.

The timings reveal that it struggles to do something with hoppers. I'm not big brained enough to easily pick out what is wrong with the code, I just know it is causing lag. (Timings: https://timings.aikar.co/?id=dcb74ed0a56c497c8939016b9f5fc97c)

I'd imagine its related to hoppers just bugging out or something, due to large cactus farm or something similar.

Instant aciding makes for rather stupid traps, nowhere is safe and there is no way to detect it. Aciding should have a configurable delay and some kind of indication to nearby players so they can react. Ideally this would also use CivClassic/CivModCore#27

Currently citadel decay scales over time, but as soon as a person on the group with perms logs in, the decay immediately vanishes. It should have a scale as the decay reduces over time. Maybe every time a person on the group logs in, it reduces one decay multiplier instead of all decay? Of course this opens the possibility of gaming the system by just spam logging in to remove all the decay over a short period. But that's still a bit of effort and thinking to make it happen, and the casual person probably wouldn't do that. A more big brained solution of tracking the un-decay with how often they log in and the time period between, to ensure they can only remove the decay so fast, would probably be much more developer-intensive.

I look forward to any developer insight on this

The block is just being set to AIR. Check whether its a container and do smart handling of double chests to drop only the right half.

1. Reinforce a block with bedrock (easiest example due to fast mature time)
2. CTR said block with a lower durability material

Outcome will be that the block continues gaining durability past the materials max durability and continue growing in strength until the block is mature. Can be seen here:

Groups: Diet_Cola & playpen1

When attempting to merge playpen1 into Diet_Cola, green text in chat: Group is under going merge. Group merging may have failed.

I guess resolving from the other part doesn't work

I'm not sure if this falls under Citadel or CMC. This issue was discovered when the server crashed and multiple players reported losing reinforcements in areas they had worked on earlier in the day before the crash. Expected behavior is when a chunk is unloaded and saved, any respective Citadel/etc data is saved to the database.

In some instances players had built using /ctf and had finished and logged off several hours before the crash. After the crash the blocks they had placed were still there, but they had no reinforcements. This leads me to believe the chunk was successfully unloaded and saved, but the Citadel reinforcements were not saved to the database and remained in memory.

If my assumption is correct, there must be some situation which causes Citadel reinforcements not to be saved and to sit in memory all day until restart where they are finally saved. Will need to debug citadel data saving to investigate and fix, unless somebody has other thoughts on why this occurred.

https://pastebin.com/hzx8Z1NL

when the player has at least two stacks of stone in their hotbar, is in fortifying mode with stone, and places a stone block from a stack other than the first will place one stone block from that stack and consume two stone from the first stack, i.e. consuming one stone block more than appropriate

placing stone from the first stack in the hotbar works correctly

Not everything on this list should be fixed. However it's worth at least adding to documentation instances where reinforcements differ from expected Citadel behavior (ie. a player who does not have permissions should not be able to permanently change the state of a block)

• CAMPFIRE

  • Can be lit with flint and steel or fire charges. Can be extinguished with water bottles. These actions can also be performed with a dispenser

• FLOWER_POT

  • Can take/place plants.

• DISPENSER + DROPPER

  • Can be powered by redstone and will fire

• CAULDRON

  • Can be filled and emptied

• SPONGE

  • Can pick up water becoming WET_SPONGE

• *_CONCRETE_POWDER

  • Can be turned into concrete using water

• ANVIL + ENCHANTMENT_TABLE + DAYLIGHT_DETECTOR + COMPARATOR + REPEATER + NOTE_BLOCK + LECTERN

  • Have a commit that fixes these, but will wait for #52 to be closed or merged in order to avoid merge conflicts.

Not on this list are commonly specified non_reinforceables that also probably don't act as a player might expect (eg. CAKE)

It only happens with stone because it is both a reinforcement and a placeable block. If you are reinforcing with stone, and you are placing from a stack which is not the first stack in your hotbar - you will place a stone block from your stack, and citadel will remove two blocks from the first stone stack for reinforcement. So instead of using 2 stone, it uses 3 stone.

To replicate - have multiple stacks of stone in your hotbar. Setup /ctf and place stone reinforced stone, while using any stone stack that is not the first stone stack on your hotbar.

Most likely this is some kind of block state change we are cancelling.

The explosive damage is true for all blocks with low blast resistance, such as with gravel and sand which have a blast resistance of 0.6 and 0.5 respectively. Seemingly any block below a blast resistance of 6 will not fully absorb an explosion, thus allowing the blocks behind it to be damaged too, thus when the reinforced blocks are removed from the damage list, the blocks behind them remain and get removed. One possible solution for this would be to, while a block is reinforced, increase that block's blast resistance to that of End Stone (9).

I think ideally we'd be doing entirely custom tracing for explosion damage detection to allow dealing more damage to nearby blocks with TNT. Possibly also allow damaging reinforcements of blocks that cant be broken by TNT. That's just a nice to have though and until then I'd just call the current behavior a feature. Any block that'd get destroyed by the explosion in vanilla will have its reinforcement damaged

In my opinion, the balance of decay would be better if you had to trust somebody with citadel bypass privileges in order for them to prevent decay, mainly because you can trust anybody with /ctr on your groups, but trusting them with the ability to bypass your reinforcements entirely is a much more risky decision. It's certainly not a critical issue, but I just wanted to make sure to log it here so it doesn't get forgotten in the long term,

https://github.com/CivClassic/Citadel/blob/master/src/main/java/vg/civcraft/mc/citadel/ReinforcementLogic.java#L207

need to properly use

https://hub.spigotmc.org/javadocs/spigot/org/bukkit/block/data/type/Chest.html

to determine where/how the other half is instead of just doing a material check.

As the title says, if you have bypass permissions and break the grass/tall-grass plant things, it'll remove the reinforcement from the host grass block.

Apparently their BlockData is not Openable? Investivate what it is instead and adjust redstone listeners accordingly

Decayed citadel blocks are not shown on /cti, making it impossible to know whether something is decayed unless you break the block and see how long it takes to break

Instead of a single global timer I want localized decay.

Keep a bitmap of the map with a resolution of 512x512 blocks to one pixel. Values in the bitmap are timestamps used for decay.

Players will update the timestamp for their own 512x512 region and all adjacent ones (3x3 field of 512x512 sections) whenever they login or cross a 512-border (make sure to exit moveevent listener early).

Use HashMap for in memory storage, assume most groups have no time stamps for most regions. Standard db table for persisting.
Also add a config value to use as fallback for when no timer is known to avoid all reinforcements initially being fully decayed when this is put on the live server.

While this may be an intended feature, is there a way that you could find out what the rail the minecart hopper is reinforced to, and then determine if that rail is the same as the hopper below, then have it dispense if it is the same group.

This would help improve zombie, skeleton, and other various grinder designs greatly.

Due to not cancelling the final break if the reinforcement is destroyed, the block is broken even if the other chest half is still reinforced.

Need to do a new rein lookup at the current location if the current rein gets broken.

Ever since the Citadel updates, /ctr does not toggle off. The current workaround is switching to /ctf then /ctf to toggle it off. Otherwise you need to /cto which turns off everything, including cti. "Normal" functionality is while in /ctr mode, you can type /ctr to turn it off (unless you're holding a reinforcement material). /ctf has seemed to have maintained the normal behavior.

Hoppers do not seem to be able to push or pull from reinforced double chests.
we can see that the double chests cannot be pushed or pulled from when reinforced, regardless of whether they are single or double reinforced. But testing shows that unreinforced doublechests can be pulled from or pushed into.

I'm not sure if this is the only instance of hoppers breaking, but it seems to be the primary issue that was afflicting our designs so far. Removing all double chests fix the design we had that was breaking hoppers so frequently.

Sweet Berry Bushes can strip the reinforcement of dirt, grass, etc when planted and then broken on top of a reinforced block.

A neat QOL feature would be a user configurable option to show CTI holograms for blocks nearby the block clicked.

This would make it easier to work with structures when one wants to change their reinforcement group or type.

There would obviously have to be a limit of the possible radius size.

Apparently occurred when an individual broke two diamond reinforced blocks with a full inv, instead of dropping on the ground like the intended behavior, it broke.

Discord Message Link (If you're in CC official)

Only close, not open

Notably this means damaging bastions will consume stacks of resources.

Hoppers can extract items from, and insert items into reinforced double chests, without the chest being made insecure.

Note that it is specifically double chests that are vulnerable, single chests are unaffected.

Reason: The onInventoryMoveItemEvent in InventoryListener checks if source and destination blocks are instances of Container, but double chests only implement InventoryHolder.

PR with fix to follow.

Below are some timestamps from logs showing when it starts disabling citadel then when it moves on to the next task.

Log from 3/30
[08:01:17] [Server thread/INFO]: [Citadel] Disabling Citadel v4.1.1
[08:09:33] [Server thread/INFO]: [KiraBukkitGateway] Disabling KiraBukkitGateway v1.2.1

Log from 3/29
[08:01:08] [Server thread/INFO]: [Citadel] Disabling Citadel v4.1.1
[08:12:20] [Server thread/INFO]: [KiraBukkitGateway] Disabling KiraBukkitGateway v1.2.1

Log from 3/28
[08:01:20] [Server thread/INFO]: [Citadel] Disabling Citadel v4.1.1
[08:12:54] [Server thread/INFO]: [KiraBukkitGateway] Disabling KiraBukkitGateway v1.2.1

[23:46:16 INFO]: [Citadel] Eveelution07 created reinforcement with Stone for STONE at Location{world=CraftWorld{name=world},x=-4978.0,y=2.0,z=4328.0,pitch=0.0,yaw=0.0}         
[23:46:16 ERROR]: Encountered an unexpected exception                                                                                                                           
java.lang.AssertionError: TRAP                                                                                                                                                  
        at net.minecraft.server.v1_14_R1.ItemStack.checkEmpty(ItemStack.java:109) ~[patched_1.14.4.jar:git-Paper-243]                                                           
        at net.minecraft.server.v1_14_R1.ItemStack.setCount(ItemStack.java:897) ~[patched_1.14.4.jar:git-Paper-243]                                                             
        at net.minecraft.server.v1_14_R1.ItemStack.add(ItemStack.java:901) ~[patched_1.14.4.jar:git-Paper-243]                                                                  
        at net.minecraft.server.v1_14_R1.ItemStack.subtract(ItemStack.java:905) ~[patched_1.14.4.jar:git-Paper-243]                                                             
        at net.minecraft.server.v1_14_R1.ItemBlock.a(ItemBlock.java:64) ~[patched_1.14.4.jar:git-Paper-243]                                                                     
        at net.minecraft.server.v1_14_R1.ItemBlock.a(ItemBlock.java:24) ~[patched_1.14.4.jar:git-Paper-243]                                                                     
        at net.minecraft.server.v1_14_R1.ItemStack.placeItem(ItemStack.java:185) ~[patched_1.14.4.jar:git-Paper-243]                                                            
        at net.minecraft.server.v1_14_R1.PlayerInteractManager.a(PlayerInteractManager.java:502) ~[patched_1.14.4.jar:git-Paper-243]                                            
        at net.minecraft.server.v1_14_R1.PlayerConnection.a(PlayerConnection.java:1361) ~[?:git-Paper-243]                                                                      
        at net.minecraft.server.v1_14_R1.PacketPlayInUseItem.a(PacketPlayInUseItem.java:27) ~[patched_1.14.4.jar:git-Paper-243]                                                 
        at net.minecraft.server.v1_14_R1.PacketPlayInUseItem.a(PacketPlayInUseItem.java:5) ~[patched_1.14.4.jar:git-Paper-243]                                                  
        at net.minecraft.server.v1_14_R1.PlayerConnectionUtils.lambda$ensureMainThread$0(PlayerConnectionUtils.java:23) ~[patched_1.14.4.jar:git-Paper-243]                     
        at net.minecraft.server.v1_14_R1.TickTask.run(SourceFile:18) ~[patched_1.14.4.jar:git-Paper-243]                                                                        
        at net.minecraft.server.v1_14_R1.IAsyncTaskHandler.executeTask(IAsyncTaskHandler.java:136) ~[patched_1.14.4.jar:git-Paper-243]                                          
        at net.minecraft.server.v1_14_R1.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[patched_1.14.4.jar:git-Paper-243]                                              
        at net.minecraft.server.v1_14_R1.IAsyncTaskHandler.executeNext(IAsyncTaskHandler.java:109) ~[patched_1.14.4.jar:git-Paper-243]                                          
        at net.minecraft.server.v1_14_R1.MinecraftServer.aX(MinecraftServer.java:1029) ~[patched_1.14.4.jar:git-Paper-243]                                                      
        at net.minecraft.server.v1_14_R1.MinecraftServer.executeNext(MinecraftServer.java:1022) ~[patched_1.14.4.jar:git-Paper-243]                                             
        at net.minecraft.server.v1_14_R1.IAsyncTaskHandler.awaitTasks(IAsyncTaskHandler.java:119) ~[patched_1.14.4.jar:git-Paper-243]                                           
        at net.minecraft.server.v1_14_R1.MinecraftServer.sleepForTick(MinecraftServer.java:1006) ~[patched_1.14.4.jar:git-Paper-243]                                            
        at net.minecraft.server.v1_14_R1.MinecraftServer.run(MinecraftServer.java:929) ~[patched_1.14.4.jar:git-Paper-243]                                                      
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]                        

I suspect creating a reinforcement with only 1 reinforcement item (which you are placing) kills the server,

There is probably some method on Material that fits. Until a gold block has been found ignore those blocks while raytracing

When enabling Citadel, the Legacy Material Support is initialized. The following materials fail to parse:

• "ENDER_PORTAL_FRAME"
• "SAPLING"
• "LONG_GRASS"
• "PISTON_EXTENSION"
• "PISTON_MOVING_PIECE"
• "RED_ROSE"
• "YELLOW_FLOWER"
• "CROPS"
• "SUGAR_CANE_BLOCK"
• "PORTAL"
• "CAKE_BLOCK"
• "NETHER_WARTS"
• "ENDER_PORTAL"

When enabling Citadel, the plugin fails to instantiate the following reinforcements types:

• Reinforcement type at reinforcements.stone had no id
• Reinforcement type at reinforcements.iron had no id
• Reinforcement type at reinforcements.diamond had no id
• Reinforcement type at reinforcements.bedrock had no id

This was originally noticed with Bastions, and that was fixed by doing something with Bastions (it checks for invalid reinforcements or something and deletes the bastion). However the underlying issue still exists.

If you break a reinforced block, then place a new block there, /cti will show it as having -1 health. This must be some underlying Citadel / CMC issue? I've tested and it persists even after leaving a chunk and coming back to it, so it does not seem related to this CMC issue.

I'm not always able to replicate this, but one example of what I mean is attached below. I CTI'd the other face of the wall and left the server for a bit. When I came back and CTI'd the face of the wall seen in the image, the holograms were offset in the wrong direction. Even after AFKing ~10 min the effect remained.

edit : to replicate:

1. place reinforced wall
2. CTI
3. relog
4. CTI from opposite side
5. result: Holograms show as if hit from original side

Break a block underneath some reinforced gravel and the gravel appears to break, will remain as a ghost block until the chunk is reloaded, and the reinforcement is ticked.

Additionally reinforcements do not seem to absorb explosive damage as they used to, so if a creeper explodes within your house, your floor's reinforcements will be ticked, but the ground underneath your house have a crater.