Implement block states for commands and /testforblock command #579

aramperes · 2017-10-22T19:39:41Z

This PR adds the system to parse and compare block state data as strings instead of numerical data values. This feature was added to some commands in 1.11, and allows using color=orange instead of the data value 1 for wool blocks, for example.

Implements a parsing system to read such block state strings and compare them
- Currently only supports Wool block state as proof-of-concept, needs to be expanded to other blocks.
Implements the /testforblock command, which uses this new functionality.
- Sample usage: /testforblock ~ ~-1 ~ minecraft:wool color=light_blue
Fixed an inconsistency with tilde notation (e.g. ~ ~-1 ~), where the relative Y value would be shifted by 0.5 blocks like the X and Z axis. Some tests needed to be fixed to pass with this correction.
Moved the block entity states inside the net.glowstone.block.entity.state package to avoid confusion.

I still need to add some documentation for the block state parsing system.

Related to #499

smartboyathome

There you go, that's my feedback.

smartboyathome · 2017-10-26T14:30:11Z

src/main/java/net/glowstone/block/state/impl/WoolStateDataReader.java

+
+    @Override
+    public boolean matches(BlockStateData state, Wool data) throws InvalidBlockStateException {
+        if (state.containsKey("color")) {


Just checking whether the BlockStateData contains a key actually leads to the wrong results. This won't catch the case where BlockStateData contains an invalid property for this material. In this case, I would recommend copying all the keys into a new ArrayList, and then while looping over the iterator. This way, whenever a key is successfully matched, you can call iterator.remove() to remove that key from the array. The matches() method then can only return true when the keys list is empty, ensuring that this case is caught.

Doesn't getValidStates() solve this?

smartboyathome · 2017-10-26T14:31:18Z

src/main/java/net/glowstone/block/state/BlockStateReader.java

+
+    public abstract T read(Material material, BlockStateData data) throws InvalidBlockStateException;
+
+    public abstract boolean matches(BlockStateData state, T data) throws InvalidBlockStateException;


I feel like sticking this on the reader is a bit disjoint with how I implemented the Entity's tag matching. I'm not opposed to sticking it on the reader, but and if you want to keep it like this you should think about changing how the CompoundTag's matching works. Otherwise, I'd say you should implement the match method on the BlockStateData, similar to how CompoundTag implements its match method.

smartboyathome · 2017-10-26T14:31:23Z

src/main/java/net/glowstone/block/state/BlockStateData.java

+
+import java.util.HashMap;
+
+public class BlockStateData extends HashMap<String, String> {


Extending an implementation of Map<> seems like the wrong way to go here. In my experience, this makes it harder to refactor, especially if another implementation of map is needed, and can dilute the reason for having BlockStateData vs a regular map. It's convenient, yes, but often introduces a design smell. I usually prefer introducing the map as a field and exposing only the relevant delegate methods, making it clear what is going on.

Good points, I will change this.

smartboyathome · 2017-10-26T14:45:46Z

src/main/java/net/glowstone/block/state/StateSerialization.java

+            throw new InvalidBlockStateException(material, state);
+        }
+        BlockStateData data = new BlockStateData();
+        String[] split = state.trim().split(",");


This is a case where I'd say a small Regex could make the expected syntax a bit clearer, and reduce the number of cases you need to check to throw InvalidBlockStateException. Looks like the regex you want is "^\\s*((\\w+)\\s*=\\s*(\\w+))\\s*(,\\s*(\\w+)\\s*=\\s*(\\w+)\\s*)*$". Looks intimidating, yes, but that is just keeping compatibility with the trimmed code above.

To use this regex, you'd be iterating through all the groups (starting at index 1 because the group at index 0 always matches the entire string), but taking only the second and third group out of every three, as the first will represent the entire "key=value" match.

I hadn't thought of using a regex here, I will consider it. My only concern would be readability, but that can be resolved with a comment.

After checking, the regular expression you provided doesn't work all the time. For the string a=b,c=d,e=f:

Full match a=b,c=d,e=f

Group 1 a=b

Group 2 a

Group 3 b

Group 4 ,e=f

Group 5 e

Group 6 f

This would skip the middle section.

smartboyathome · 2017-10-26T14:59:34Z

src/main/java/net/glowstone/command/minecraft/TestForBlockCommand.java

+            return false;
+        }
+        String itemName = args[3];
+        if (!itemName.startsWith("minecraft:")) {


I'm not as familiar with the plugin side of things, but if a plugin introduces a new block, will it still start with "minecraft:"? If not, then this check would seem to fail when trying to test for a "foo-plugin:bar" block.

You can't register new blocks/items with Bukkit. The ids are registered in the ItemIds class and all start with the minecraft namespace. Adding this functionality is outside of the scope of the PR.

smartboyathome · 2017-10-26T15:05:00Z

src/main/java/net/glowstone/command/minecraft/TestForBlockCommand.java

+            return false;
+        }
+        if (args.length > 4) {
+            String state = args[4];


Since we know this same "check the data value or state argument" is used in at least three commands (clone and testforblock, and testforblocks), mind abstracting this check out into a CommandUtils method? May want to return a custom type with two properties, Integer data and BlockStateData stateData, for ease of use in these commands.

smartboyathome · 2017-10-26T15:08:14Z

src/main/java/net/glowstone/command/minecraft/TestForBlockCommand.java

+            }
+        }
+        if (args.length > 5 && block.getBlockEntity() != null) {
+            String dataTag = String.join(" ", new ArrayList<>(Arrays.asList(args)).subList(5, args.length));


Given we do this CompoundTag check in a few commands as well now, we might want to think about also abstracting this out into a CommandUtils method.

Good point, but it's outside of the scope of the PR. I'll consider it once this is merged.

* Fix exception when parsing a state with no value (something=) * Move some common state utils to CommandUtils * Boxed map instead of extending it (BlockStateData)

aramperes · 2017-10-30T18:23:59Z

I need approval to merge this for the release of 2017.10 on Wednesday. I can address the documentation and further design changes later on.

aramperes · 2017-10-31T14:42:30Z

Merged in 18a3b49.

aramperes added 8 commits October 21, 2017 20:18

Ground work for block state serialization (for commands)

b6fce97

Oops

b4ef01b

Throw exception if invalid color type

33b4d95

Simplify getReader method

1930008

Asterisk wildcard for matching states

bb6bf23

Add /testforblock command

ef79641

Things I forgot to commit

9db1767

Add data tag to /testforblock, fix some tests, add valid state check.

39f75c2

aramperes added this to Review in 2017Q4 Oct 22, 2017

smartboyathome requested changes Oct 26, 2017

View reviewed changes

Fix some things based on feedback.

46c7bc5

* Fix exception when parsing a state with no value (something=) * Move some common state utils to CommandUtils * Boxed map instead of extending it (BlockStateData)

aramperes requested a review from mastercoms October 28, 2017 21:31

mastercoms approved these changes Oct 31, 2017

View reviewed changes

aramperes added a commit that referenced this pull request Oct 31, 2017

Block state serialization for commands, /testforblock command (#579)

18a3b49

aramperes closed this Oct 31, 2017

aramperes deleted the states branch October 31, 2017 19:17

aramperes moved this from Review to Completed in 2017Q4 Nov 1, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement block states for commands and /testforblock command #579

Implement block states for commands and /testforblock command #579

aramperes commented Oct 22, 2017 •

edited

smartboyathome left a comment

smartboyathome Oct 26, 2017

aramperes Oct 27, 2017

smartboyathome Oct 26, 2017

smartboyathome Oct 26, 2017

aramperes Oct 26, 2017

smartboyathome Oct 26, 2017

aramperes Oct 26, 2017

aramperes Oct 27, 2017

smartboyathome Oct 26, 2017

aramperes Oct 26, 2017

smartboyathome Oct 26, 2017

aramperes Oct 26, 2017

smartboyathome Oct 26, 2017

aramperes Oct 26, 2017

aramperes commented Oct 30, 2017

aramperes commented Oct 31, 2017


		public abstract T read(Material material, BlockStateData data) throws InvalidBlockStateException;

		public abstract boolean matches(BlockStateData state, T data) throws InvalidBlockStateException;


		import java.util.HashMap;

		public class BlockStateData extends HashMap<String, String> {

Full match	`a=b,c=d,e=f`
Group 1	`a=b`
Group 2	`a`
Group 3	`b`
Group 4	`,e=f`
Group 5	`e`
Group 6	`f`

Implement block states for commands and /testforblock command #579

Implement block states for commands and /testforblock command #579

Conversation

aramperes commented Oct 22, 2017 • edited

smartboyathome left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aramperes commented Oct 30, 2017

aramperes commented Oct 31, 2017

aramperes commented Oct 22, 2017 •

edited