Cory
- cory
- cory
- Europe/Stockholm
- Yes
- No
MC-2316
MCL-10523Recreate Steps:
Destroy a 1x1 block area and place water.
Next to it, place a grass block.
Then behind facing you, place any block where the grass is. (For Instance, Stone or Glowstone.)
On top of the stone, Place two pistons on top of each other facing you.
Behind the pistons, place stone (or any block) up to the level of first stone and first piston. (2 x 2 block of stone)
Place a repeater on top where the top of the second piston is located.
Place redstone dust on the second stone connecting the repeater.
Place a lever and don't activate it yet.
Place 3 tall sugarcane on the grass block.
Activate the redstone.
You'll should now noticed the 'Top Piston' has an extended piston and shouldn't be doing that and only does this with Sugarcane I've noticed.
I don't know of this is a 'Bug' or something in redstone has changed to cause this, but I figure I'd submit this anyway and see if you can confirm this or not.
If this is a bug, this it works on Single Player and Multiplayer tested on 1.3.2, 1.4.2 and 1.4.3.
I've created a Single Player World in 1.4.3 demonstrating, If I were to make a massive farm and "How it works".
Mirror 1: https://dl.dropbox.com/u/61261837/Testing.zip
Mirror 2: http://www.mediafire.com/?i2i6zo29ibb5qu7Video: http://www.youtube.com/watch?v=gsnuPuHafaw
Again, if this is not a bug I apologize and I'll just use a "Sticky Piston Method" just figure this was going to bug me until I submitted this and know for sure.
Regards,
Cory_
ScoreboardLimitation Bug
Scoreboard Maximum Bug
Confirmed: Tested on "world above" and a "clean world".
In older clients, I'm also getting this,
http://www.imgwiz.com/OqL
After recreatiing the server I've recieved the same error, Instead of making another issue figure this was related.
Confirmed this works in 1.6.1 as well. I was taking a look at the tutorial page and found the "Security Scan" for TNT and this makes it where you cannot get anything out of your inventory.
Depending on the clock if slow enough, You can obtain the item.
Yes it's been confirmed fixed.
Please wait for 1.6.2 - Not much you we do at this point.
Confirmed for 13w41a.
You cannot also take screenshots in the GUI area before joining "Single Player" or a "Server" anywhere outside before actually joining a game.
Anything over 16 characters would say:
Character count > Maximum count
Originally in 1.10.x and lower it would say:
65 > 16
128 > 16
Here it's showing:
65 > 64
64 > 16
Clearly, something may have changed.
Hello,
I can clearly say this is NOT invalid and it's an issue. Even if you create and run the Minecraft Snapshot through the console. It still creates a `backups` folder outside its directory. This should not be doing this.
This is not invalid and actually does this on Windows as well.
Nothing is modified and completely a vanilla JAR.
Kind Regards,
Cory
Additional things that may have fixed and removed:
I can confirm I'm having a similar issue on Multiplayer and appears as it doesn't save the Prefix and Suffix at all.
Confirmed on the following Launcher 'Released'
Attached a GIF. Still an issue and would like to disable my logs.
Unable to run scripts under an `xfs` filesystem if the `ftype` is set to 0. This issue continues to be a problem and identical to the issue we were having a year ago.
I’ve entirely isolated this issue to a VPS using the service called `Vulr` and replicated the problem by doing the following. This is worth noting as when installing `AlmaLinux` as the (“Host Machine”) with an xfs filesystem it was `ext4` in this environment.
Additional things to note. We do know this isn’t meant to be run on AlmaLinux, and we run our bedrock servers in docker running Ubuntu. However, since the (“Host Machine”) is an xfs filesystem with ftype=0. This will cause (“scripts”) to fail. We isolated it to make sure it wasn’t a docker-related issue, and it’s not.
If you use `Vultr` they do have a scripts area where you can easily copy/paste to build this server from scratch and don’t have to manually do it. The main command is creating partitions with the `mkfs.xfs` parameters.
Once the server has booted or completed the tasks.
If everything looks set up properly. We’re going to build a server mostly from scratch. This will create the essential files/worlds required.
The next step is the scripts. You can find your own scripts or use the one provided. This includes behavior and resource packs and a modified `level.dat` to enable experimental builds. Might want to do this manually to ensure the files get extracted properly.
Next, we will proceed by copying these same files into the new directories/partitions we created earlier.
Modify the ports to avoid conflicts or just run one at a time.
Let us confirm the issue. Go into each directory and start the server respectively.
You will see that `ext4` and `ftype1` works perfectly fine, and for `ftype0` the scripts don’t load at all. Keep in mind these are identical servers we just copied and the 2 main differences are the filesystem and server port.
This is where it becomes interesting…
This will load the scripts fine. However, if we switch to:
cd /ftype0/ screen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4Do you notice we’re using the same `screen` command as above? The difference in this case, we ran the command from `/ftype0` and the result is that it failed. However, we run it from `cd /home/new/` directly. It doesn’t fail. Not likely a path issue per Se. This is still a `ftype=0` issue and needs to be resolved.