• Minecraft version - Which Minecraft version are you playing on?
  1.17.1
• Mod version and malilib version - Which exact mod version are you using?
  litematica-fabric-1.17.1-0.0.0-dev.20211203.010230
  malilib-fabric-1.17.1-0.10.0-dev.26

This specific issue is most easily replicated using comparators, but sometimes occurs with only redstone wire. Pasted schematic blocks do not update unless they themselves, or a redstone wire down-line are replaced. Specific example:

Pasted hopper minecart and comparator read as 0 signal on the two redstone wires coming from the comparator. Placing items in the hopper minecart has no effect on the redstone strength or comparator. Breaking and replacing a piece of redstone wire anywhere ahead of the comparator causes the line and comparator to update and show a signal. The same goes for when removing items from the hopper minecart. Even if all blocks in the design are manually replaced, blocks in the same spots as the originally pasted ones act the same way._

_I encountered this issue occasionally before, but never has it happened even after manually replacing the block once. Usually, that allows it to update appropriately and in real-time.

Is this on a server or in single player? Did you replace the detector rail below the minecart?

Active detector rails when pasted on a server will get stuck, because there is no vanilla command to schedule the block tick they should have, so they will never update. Same for buttons or pressure plates that are triggered/pressed in the schematic. Pasting in single player should restore the scheduled block ticks correctly (if the schematic has them, which is only the case when it was also saved from single player).

At some point when multiplayer saving and pasting will be supported via Servux on the server side, this should get solved for servers that are able to run the Servux mod. But there is no good way to solve this for vanilla or other servers without the mod. Saving the schematic from a vanilla server does not have access to the scheduled block ticks, nor is there any way to restore them when pasting. The only "solution" would be to substitute affected blocks with their non-triggered variant. But for stuff like (assembled) TNT dupers that would then lead to them blowing up after pasted anyway, since they would then update when the minecart activates the detector rail.

Apologies for not clarifying, this is in a single-player world. I have not been attempting to update the detector rail for the primary reason that Litematica (as opposed to worldedit) pastes these in the correct orientation, and manually replacing them will cause the entire line to reset to the wrong orientation.

With testing, it appears that replacing the detector rail does fix the issue; however, it does mean having to manually replace all the rails that become mis-oriented.

Thank you for your quick response, and hard work!

Was the schematic also saved from a single player world? Could you send it to me?

Detector_Rail_debug_HighPotential.zip

The schematic was built and saved in a single player world.

I added a glowstone arrow to indicate a particular slice for testing. I remove the two minecarts that go below the detector rail in this schematic so i could progress on the design despite the problems. I re-added those two minecarts in one slice for you to experiment with. The easiest way to reproduce would be to paste and load items into the hopper minecart to see if the comparator updates.

It is essentially a sorted shulker-storage unit with minecarts instead of hoppers.

Thanks!

So it seems like your schematic does not have any scheduled block ticks stored:

Was it saved from a working build in single player? And not one where the rails were already stuck on?
But also it looks like there is something broken about restoring the ticks when pasting. Even when I save a new schematic of a rail and a minecart, and the schematic file has the scheduled tick stored, the rail is still left stuck on when pasted...

So maybe if you cloned the slice using Litematica, all the rails in that build already have the rail stuck on, without the scheduled tick to check if they should turn off.

With the way I build it's very likely this stemmed from several copy-paste slices. Its very possible the first, original slice (or module of 5) that I created I failed to remove items and thus left something activated. I usually do this so I can leave the filter items in each and then only manually load the sorted items. I can't say exactly which the original was since its been copied and re-pasted over so many variations, but some testing could reveal whether having items in the original hopper minecart has an effect. (if I am understanding you correctly)

When I noticed the issue at first, to test, I manually created 5 slices and loaded items; it worked. manually created one slice; tested, it worked. Then I copy-pasted both the 1 and 5 slices to create two separate modules (5 and 10) slices; neither worked.

I tested this again knowing that the original saved schematic had no items in the hopper minecart, and no signal on the restone. The copied slice does not work as described, but the original does. There appears to be no affect whether there are items in the original hopper minecart. This is not excluding the activator rails which are active due to the redstone torch.

I tested copying the slice without the minecart at all; so the detector rail is not active. The copied slice DOES work. Having the detector rail active when being copied, not the comparator, is causing the update issue.

Thanks for being very attentive on this.

So turns out the per-chunk pasting didn't actually even try to restore any scheduled ticks. Another thing I completely overlooked when I switched from the old "paste the entire thing at once" pasting to the current "paste it in per-chunk pieces and try to not go over 50 ms/tick on the client".

Here is a fixed build: https://masa.dy.fi/mcmods/litematica/litematica-fabric-1.17.1-0.0.0-dev.20211216.034328.jar
I'll upload it to CurseForge in the coming days, after I try to think if there was anything else I needed to fix.

As for fixing your build, I think the easiest way is either to edit the schematic and replace all the powered detector rails with the default non-powered state, or to do it with a /fill command in-world. It looked like all the rails are even in the same orientation, so I was able to do the schematic edit/rebuild in one operation, and it seemed to fix the contraption when then pasting that edited version, as the minecarts will then re-activate them normally.

There is a page in the wiki about schematic editing if you are unfamiliar with it. The quick summary is: switch to Edit Schematic mode, place one unpowered detector rail in the world in the correct orientation, Alt + middle click it to "store" that block state, then hold the schematicRebuildReplaceAll hotkey (you will get a small colored overlay) and right click on one of the powered detector rails in the schematic with an empty main hand (to use the stored state instead of the item in your main hand), and then switch out of the Schematic Edit mode. That will replace all of the powered detector rails in the loaded schematic in memory with the unpowered version, and then you can paste that in the world and it should "fix itself" when the minecarts activate the rails again.

Thank you so much for working with me on this, and thank you for the quick turn-around update! I tested copying a slice with a minecart, and items in it, and the copied slices work perfectly :) Good reason to rebuild the design in a more neat and compact manner! I did not know that about schematic editing, but it will surely be useful.

High-level minecraft design simply would not be as advanced or creative without your intellectual contributions, they will be a staple of the game for years! Thank you! Everyone on our server are heavy users of all of your mods, couldn't live without them!