Home > Internet > The Case for /at (and other thoughts on the proposed 1.13 command changes) – An open letter to /u/Dinnerbone and the Mojang team via /r/Minecraft

The Case for /at (and other thoughts on the proposed 1.13 command changes) – An open letter to /u/Dinnerbone and the Mojang team via /r/Minecraft

August 9, 2017

The Case for /at (and other thoughts on the proposed 1.13 command changes) – An open letter to /u/Dinnerbone and the Mojang team

Dear Mojang, particularly /u/Dinnerbone,

For the most part, I'm very happy with the changes you've proposed to the command system. There's a lot going for it, and not a lot to complain about, and I couldn't be more grateful for the amount of work, effort, and thought that are going into it. With that said, I'd like to make a couple points that I think bear saying.

Here is the link to the original post this is in response to: A completely incomplete, super early preview of everything that will definitely break your maps in 1.13

Please keep in mind that while I consider this to be good advice, in the end it is just my opinion. If you disagree, feel free to discuss it civilly in the comments. Yes, I do know that it says in the post that the changes to /execute, the main point of this post, are not final. That is the exact reason that I'm making this post – to get my opinion on the matter out before it becomes final, so that they can make the best decision for the game that is humanly possible.

1. The Changes to /execute

I think most people will agree that changing /execute can really only be a good thing. As it is, it's kind of a mess – it tries to do far too much at once. The original proposed system of /at, /as, and their companions were a great solution to this. They separated the functionality into more incremental pieces, making it simpler and easier to use and understand.

The new proposed system, however, is a step in exactly the wrong direction. Instead of making /execute better (less complicated, more modular, simpler to understand), this new set of proposed changes only complicate things. The new syntax is significantly more complex and unwieldy than even the existing syntax, and some of the decisions don't even seem to make sense at all.

I would propose returning to the earlier-proposed system of /as, /at, etc., skipping the if/unless functionality (I will touch on this in more detail later). This would come with several benefits – it would retain the simplified and easier to read syntax, while still retaining all the proposed new functionality. It would also likely simplify your jobs as well, in the long run; having worked both with creating Minecraft commands through modding and with programming language design in general, it is significantly more painful to work with parameters to a function when working simply with the function itself is an option. Branching within functions becomes a nightmare to keep track of, and separating things into separate functions keeps things easy to understand and use later.

While this seems like overcomplicating things by adding more commands at first glance, it simplifies things in the long run by breaking the command down into smaller parts that each do one thing, rather than one big blob that does everything, following the basic programming principle of KISS (Keep It Simple, Stupid). The new proposed changes, however, only make said blob worse than the mess it already is.

For those that haven't been keeping up with the proposed changes, this is the relevant command list:

  • Now: `/execute <entity> <x> <y> <z> [detect <x y z> <block> <data>] <command>
  • Current proposal:
    • /execute as <entity> <command> (as entity, not at position)
    • /execute at <entity> <command> (at position of entity, not as)
    • /execute at <x y z> <command> (at given coordinates)
    • /execute (if|unless) block <x y z> <block> <command> (execute only if/unless block exists)
    • /execute (if|unless) blocks <begin> <end> <destination> (all|masked) <command> (execute only if/unless block range at destination matches source)
    • /execute (if|unless) entity <entity> <command> (execute only if/unless entity exists, not as/at)
  • My proposal (also the previous official proposal):
    • /as <entity> <command> (as entity, not at position)
    • /at <entity> <command>(at position of entity, not as)
    • /detect <x y z> <block> <command> (execute only if block exists)
    • /offset <x y z> <command> (at coordinates)

While this does not allow for the if/unless functionality, this functionality is largely unnecessary anyway, especially if /testfor, /testforblock, and /testforblocks are not removed, or even better, updated to work more simply with scoreboard values.

2. The Removal of Custom Gamerules

While the removal of custom gamerules is understandable, and I even generally agree with the reasons why, for some things scoreboards just don't work very well. They aren't a very user-friendly way of interfacing with options, for example. The scoreboard system is complicated, and custom gamerules gave a simple, easy to understand, user-friendly way to work around that at the cost of more pain for the people implementing them.

I wouldn't suggest the re-addition of custom gamerules; as stated in the original post, they do cause a lot of issues. I would, however, suggest replacing them with a similar but better-supported solution, in order to still allow for that easy, familiar, user-friendly interface.

For example, you could do something like this:

  • /customgamerule set <name> <value>
  • /customgamerule get <name> [entity] [scoreboard]

In this scenario, the set version of the command would set a value to a given name, where the get version of the command would either print the value to the chat or (if provided) push it into the given scoreboard value. This is, of course, just one possible way to implement it, but it gives some idea of how a similar system could be implemented without overlapping the existing /gamerule functionality and causing conflicts and confusion.

3. The Removal of /testfor, /testforblock, and /testforblocks

I'll keep this section short: this falls under exactly the same mistake as the new version of the proposed /execute command, entirely because these commands have now been wrapped into it. This is a mistake. Once again, this is simply cramming more functionality into a command that already does too much, when there is no issue (that I know of) with leaving it separate (if there is some technical issue that the condensation of these commands solves, please feel free to enlighten me).

Not removing these commands also essentially removes the need for the if/unless branches of the /execute command, especially if these commands are updated to allow for better interaction with scoreboard values.

4. The Removal of /tp in Favor of Aliasing /teleport

This is probably going to be one of the most controversial decisions among non-technical players. In my opinion, it might make sense if you were going with the /at and /as system, in order to avoid duplicating the functionality, but as it is, I simply can't see any reason for this change beyond simply deciding to not spend the time reimplementing another command. /tp has been an integral part of the game for a long time, and while the functionality that /teleport offers is very useful, it would make more sense in my opinion to go the other way if anything, retracting the functionality of /teleport entirely and retaining the existing functionality of /tp.

5. The Good Stuff

It wouldn't do to make such a seemingly negative, critical post without mentioning some of the stuff that is awesome about the proposed changes. So here's some quick thoughts on the things I really like about the new ideas going into the command system:

  • The unification of the block, entity, and item syntax to put NBT directly in the same argument is absolutely brilliant. Just the ability to use NBT in entity selectors is a huge step forward, and keeping the syntax more consistent between commands is an added bonus.
  • The addition of ranges instead of the _min/_max parameters in entity selectors is again a beautiful addition that will make things a million times easier for mapmakers, especially with the addition of a more concise way to represent "this value and only this value".
  • The ability to use the same parameter multiple times per selector is something map makers have been asking for for ages – with this, there will be no more crazy /execute chaining just to check if an entity has this tag and that tag, for example.
  • The final removal of numerical data values for both blocks and items has been a long time coming, and it seems like you're doing it well.
  • Data packs. Enough said.
  • Better error checking and reporting can only ever be a good thing.

All in all, you guys are doing an amazing job with this update so far. I hope you take my advice under consideration, but either way, keep up the good work! I'm sure whatever you decide will be best for the game in the long run ^-^



Submitted August 08, 2017 at 11:28PM by tripl3dogdare
via reddit http://ift.tt/2vi9kX0

Categories: Internet Tags: , ,
%d bloggers like this: