Hi gang! I know, i know: the snapshot isn't even out yet and I'm already starting a thread. There's already a thread which discusses the new textures in 1.13 but my problem is that I always turn to this forum for general Minecraft stuff. So I figured, why not start a general thread as well... Now, to add something useful here... In 1.13 some commands are going to get changed, in specific the /execute command. This is going to be a big issue because /execute is very often used with custom maps. For example.... A small contraption I cooked up this evening; how to "auto craft" (basically you throw down a stick and one coal and then b00m!, you'll get a torch): Code: testfor @e[type=Item] {Item:{id:"minecraft:stick"}} scoreboard players tag @e[type=Item,tag=!stick] add stick {Item:{id:"minecraft:stick"}} execute @e[type=Item,tag=stick] ~ ~ ~ testfor @e[type=Item,r=1] {Item:{id:"minecraft:coal"}} execute @e[type=Item,tag=stick] ~ ~ ~ summon Item ~ ~ ~ {Item:{id:torch,Count:1},Tags:["torch"]} execute @e[type=Item,tag=stick] ~ ~ ~ kill @e[type=Item,r=5,tag=!torch] In the new version /execute will be split into: /as /at /offset /detect Now, my first reaction was like many others: that's going to break some stuff , and initially I somewhat disliked this whole idea. To a certain degree I still do because I think that backwards compatibility should be an important thing. In other words: ensuring that things continue to work in future versions of your software. Of course it's a bit too early to start complaining, because for all we know /execute can also be left in the game while those new commands got added besides it. Yeah, well, even so I can now also come up with solid arguments why this change is going to be a good thing. For starters: when done right then these new commands have the potential to reduce quite a bit of lag (depending on how much /execute command are being used). Lets take a look at one of the above execute commands: /execute @e[type=Item,tag=stick] ~ ~ ~ summon Item ~ ~ ~ {Item:{id:torch,Count:1},Tags:["torch"]} There's a lot of stuff happening here. First the system detects an Item entity which has a tag 'stick'. Then it'll check for the location of that entity (the ~ ~ ~ behind the @e) after which it will execute a command (/summon). Because summon uses ~ ~ ~ as position the location of the entity will be looked up once again for the summon command before the actual item (torch) get's summoned. In the new version this will probably get changed into something like this: /at @e[type=Item,tag=stick] summon Item ~ ~ ~ {Item:{id:torch,Count:1},Tags:["torch"]} It's simple really: /at the location of the entity (type Item and has tag stick) a command needs to be executed. So the location of the entity is looked up and passed to the summon command. Which then uses that same location (/summon Item ~ ~ ~) to summon the actual item. What to think of this: /execute @e[type=Item,tag=stick] ~ ~ ~ testfor @e[type=Item,r=1] {Item:{id:"minecraft:coal"}} Here I actually don't care at all about the location of my entity, all I care for is to know about a possible piece of coal being nearby. Even so the location is still being looked up. Twice. Not in 1.13: /as @e[type=Item,tag=stick] testfor @e[type=Item,r=1] {Item:{id:"minecraft:coal"}} /as will basically find an Item entity with a tag stick. Nothing more. It will then execute the testfor command as that same entity which will then in its turn check the direct surroundings. Internally it'll need to know where the entity is, but it won't be information which always gets explicitly looked up. Note: At this point in time the above is pure speculation, obviously. We don't even have a snapshot yet. Even so... I think chances are high that I'm pretty close on the mark Sure... if you only have 4 or 8 of these commands in your map then I doubt you'll notice much difference (but who knows..). But if you use a whole command block program (like the stuff from TheRedstoneEngineer and such) which uses dozens of command blocks then I think we will notice a speed improvement. At least I hope so
Yay! To be honest, I like to observe who these threads get started by. First (when I joined) they were made by x_I_LIKE_A_PIG_x, then by me, then by SkyDragonv8, and now by you. All quite respectable people of the EMC community, in my opinion.
YES!!! I've been waiting for this thread!!! WARNING!!! I love code and although it isn't code, it's somewhat close to that field, so Essay INCOMING!!! Note: What I'm saying here could be true today at the time of writing, but be completely different tomorrow. So don't be surprised if some of the examples I use don't actually work in 1.13(Although I feel confident they will work anyways. ). Execute Split I won't touch on this too much as ShelLuser already said a lot about it. However I will point out that my favorite command out of the four is /detect. Currently without /detect, we would either have to test for a block, and then use a conditional chain command block to do something else. Or we'd have to use an execute command. For Example: Code: testforblock 0 0 0 cobblestone say Cobble! execute @e[tag=Placeholder] ~ ~ ~ detect 0 0 0 cobblestone 0 say Cobble! There is a problem with both methods. With the testforblock command, you need an extra conditional chain command block. With the execute command, you need to have an extra entity in the world. Neither is an ideal solution to me anyways, but with /detect it can all be in one command without an entity. Code: detect 0 0 0 cobblestone say Cobble! Blocks So Mojang has apparently removed block data values and separated them into their own blocks/blockstates. As a result, commands needed to be changed too. So now instead of doing the following: Code: setblock ~ ~ ~ command_block facing=up replace {"Command":"say hi"} or setblock ~ ~ ~ command_block 1 replace {"Command":"say hi"} We must do this instead: Code: setblock ~ ~ ~ command_block[facing=up]{"Command":"say hi"} replace Now while it won't be fun to update some things, a lot more is now possible because of this. For Example: Lets say we have a cube of command blocks from 1 1 1 to 5 5 5. A random amount contain the command "say Dirt!" whereas the rest contain the command "say Stone!". Now I want to change out the command blocks that have the command "say Stone!" and replace it with "say CobbleStone!". I also want the "say Dirt!" command blocks to remain intact. While you would think that should be possible, it currently isn't. However when 1.13 comes around, the following should work: Code: fill 1 1 1 5 5 5 command_block{"Command":"say Cobblestone!"} replace command_block{"Command":"say Stone!"} My apologies if the above example is confusing by the way, It was rather difficult to explain. Now personally, I like the change for that added functionality alone, it makes a lot more possible. Color Coding So Mojang added in a command UI above the chat bar that updates live as your typing. So if I type in a command and make an error, it will tell me exactly what's wrong and where to look in red. They also added in color coding. I think this change in particular is a great one! It makes things easier to see without breaking anything. My Concerns Like ShelLuser, I'm also concerned about backwards compatibility, Especially when it comes to this update as so many things will break. My hope is that since it is a technical update, maybe it will be a while before Mojang makes such drastic changes again? Now although I'm fairly confident this will be the case, I also hope to see a huge performance improvement in the game in general since it's literally a technical update. 63 Block Limit One thing I really want fixed is the 63 block limit. For those of you who don't know what that is, if more than 63 blocks are placed at exactly the same time and in the exact same chunk, you're going to get some lag. Now while that might not sound that bad as the block updates also have to be inside the same chunk, think of FireFloor. In FireFloor, the fire spreading, the leaves decaying, the sand falling, and even the lighting updates all contribute to the 63 block limit. Now although not all of FireFloors lag is coming from the 63 block limit, some of the lag probably is. The only other sources of lag I can think of are the fire animations, and the amount of falling sand entities/players there are. Feel free to correct me if I'm somehow wrong Staff on any of what I just said regarding FireFloor... Now I don't think there can be a full fix to this as there are limits to everything technically speaking, but I would still be happy if it was raised to a higher number like 128, 256, or even better 512. I don't think this will happen, but I would be extremely happy if it did. Here's a video explaining the 63 block limit a bit more. Please note that the video is a bit outdated and while not all of it is true anymore, I think a lot of it is still relevant today. Better interface for Command Blocks Although not as high on my list of things I'd like to see, I would love to see an improvement here. Things easily get out of control when messing with JSON, so it would be nice to spread it out across multiple lines. It would make things a lot easier to see and read. I could easily keep going and mention some smaller details, but I'm going to stop here. This post is long enough already... TL;DR I gave my opinion on a bunch of upcoming 1.13 features, and I'm excited for what I have seen so far... ~SUPERI0N
