The Varied 11

[Fire]

What is the map name? The Varied 11

What are the x y z coordinates /tp -6271.5 61 3889.5,
What world is the fault on. Zero

What fault has occured. Script/Cmd Block, Glitch

Please give details of fault
Puzzle 1 has some issues with the command blocks. The answer checker as well as the buttons on the south and east sides of the room don't work. I'm fairly certain the main command block system outside the room works fine, because the buttons on the west and north sides work well. It's the two command blocks right behind the buttons that I think don't work.

In puzzle 8, the way dropped items float in water now makes the stone shoot off onto the blocks at the start.

 

[Alphaesia]

Issue appears to be related to using @e[x=,y=,z=,distance=..1,type=] for selecting entities, a solution which I have found to be unreliable working with other redstone projects in 1.13. I assume this is a result of a change in the way coordinate arguments are treated in selectors in 1.13 (no longer shifting the coordinates the command is executed at, instead defaulting to the initial executor without an explicit reassignment as in /execute as or /execute positioned).

Solutions are either using the selector @e[x=,y=,z=,dx=0,dy=0,dz=0,type=] or using /execute positioned x y z as @e[type=,distance=..1].

As an example:

execute as @e[x=-6275,y=65,z=3890,type=item_frame,distance=..1] run data merge entity @s {ItemRotation:1b}

could become either

execute positioned -6275 64 3887 as @e[type=item_frame,distance=..1] run data merge entity @s {ItemRotation:0b}

or

execute as @e[x=-6275,y=65,z=3890,dx=0,dy=0,dz=0,type=item_frame] run data merge entity @s {ItemRotation:1b}

As this is powered by command blocks it hasn't been fixed as of yet. However this could potentially be converted to scripts (and significantly simplified).

rotateItemFrame(Int x, Int y, Int z)
@var itemFrame1Rot += 1
@if itemFrame1Rot > 7
->@var itemFrame1Rot = 0
@fi
@bypass execute positioned {{x}} {{y}} {{z}} as @e[type=item_frame,distance=..1] run data merge entity @s {ItemRotation:{{itemFrame1Rot}}b}

It would be easier to hard code the item frame location for each button rather than making it a function though.

Side Note / Mini Glossary:
/execute positioned x y z means execute the command from these coordinates. This is in contrast to /execute at @selector which only accepts a selector for entities.
/data merge entity is the replacement for /entitydata. It is a lot more than /entitydata as it allows you to directly grab the NBT data of entities.
dx dy & dz represent an area or volume. It basically says the area you are looking in goes X blocks along the x axis, Y blocks up and Z blocks along the z axis from the location specified (x=,y=,z=).

 

[Fire]

If the way puzzle works can be improved by doing it with scripts, then I'd be fine with that. The main reasons I had it done in command blocks was because I didn't want to make a single OP program all of that for 7 buttons, and because I didn't think there was a simple "+1" you could do to item frame rotation; I thought it had to be values 0-7. If fixing the system I already have in place is easier, then I'd rather do that, but it really depends on just how much the puzzle would be improved if everything was overhauled and redone with scripts, and how hard doing so would be for rick or whichever OP would be burdened with that task.
Just 1 of the 5 different things that happen per button press is the item frame change (the others being button replace, command block replace, redstone block set, and RB clear), so it would be around 56 command blocks that would need the exact same format change. Whether or not that would be harder than a script overhaul, I have no clue.

Edit: If the above issue is what's wrong with the system, how come half the buttons already work? It sounds to me like all 7 buttons have the same issue in their cycles, which doesn't make sense if some of the buttons work.

 

[Chillers]

If the way puzzle works can be improved by doing it with scripts, then I'd be fine with that. The main reasons I had it done in command blocks was because I didn't want to make a single OP program all of that for 7 buttons, and because I didn't think there was a simple "+1" you could do to item frame rotation; I thought it had to be values 0-7. If fixing the system I already have in place is easier, then I'd rather do that, but it really depends on just how much the puzzle would be improved if everything was overhauled and redone with scripts, and how hard doing so would be for rick or whichever OP would be burdened with that task.
Just 1 of the 5 different things that happen per button press is the item frame change (the others being button replace, command block replace, redstone block set, and RB clear), so it would be around 56 command blocks that would need the exact same format change. Whether or not that would be harder than a script overhaul, I have no clue.

Edit: If the above issue is what's wrong with the system, how come half the buttons already work? It sounds to me like all 7 buttons have the same issue in their cycles, which doesn't make sense if some of the buttons work.

In 1.13 script creation and editing is vastly simplified with the addition of hastebin. It would probably be much quicker for an op to create the script and amend it per button rather than setting up all the command blocks

 

[rickyboy320]

Issue appears to be related to using @e[x=,y=,z=,distance=..1,type=] for selecting entities, a solution which I have found to be unreliable working with other redstone projects in 1.13.

How is it unreliable? A lot of scripts/commandblocks were converted in this format, and from personal testing it seems to work fine...

Only issue I did find is that /data does no longer accept multiple entities, so selectors are pretty much void there, so I guess it's unreliable in that manner (but this can also easily be solved with a limit=1 tag)

 

[Alphaesia]

How is it unreliable? A lot of scripts/commandblocks were converted in this format, and from personal testing it seems to work fine...

Only issue I did find is that /data does no longer accept multiple entities, so selectors are pretty much void there, so I guess it's unreliable in that manner (but this can also easily be solved with a limit=1 tag)

In 1.12, I used a custom random number generator system for multiple projects. It used something along the lines of @e[x=,y=,z=,type=armor_stand,distance=..1,sort=random,limit=1]. However, it consistently failed to find any entities at all (except myself). Even upping the distance did nothing. However when I changed it to @e[x=,y=,z=,dy=1,type=armor_stand,sort=random,limit=1] it worked perfectly. Honestly I was surprised it worked even in part in The Varied 11. I have no idea why it breaks most of the time and works some of the time. However, I gave had no issues with the other format, it seems to work consistently.

 

[rickyboy320]

Item frames have been fixed, still need a solution for puzzle 8 (will need your input on this one fire). Opened the door for puzzle 8 for the time being.

 

[Fire]

Puzzle 8 can easily be fixed by just adding 1 extra layer of pris bricks to any non-water-path part of the floor. Couldn't fix it in the test server because block changes wouldn't have carried over from there.

 

[Fire]

Required a lot more fixing than I expected, but fortunately it works now.

 

[rickyboy320]

Looks good