I moved the proposal so I could use Markdown (something I actually know how to use), and so I could easily update the proposal without going through the editor (which sometimes doesn't load for me). I also moved it here because when I am able to do so, I will upload patch files showing a suggested implementation.
When patch files are released, the additional code is released under the MIT License. The documentation there is also provided under the MIT License.
Liking the customization you've got there. Especially the conditional effect, great for Smite-like effect. Hopefully with clearer item description though, like "+1 Damage to Undead"
Sorry for waiting a while to respond.
Also sorry about the bad formatting. I wrote this in a general text document because there was a lot to put, and my computer is prone to random crashes
For the description, I can certainly add a description field, and I think that would be a good idea as well. The main question is when you would want the description to show up, as when I make a formal proposal, that would be the kind of thing to include.
This seems like something extremely heavy to work with. I like the idea, but it seems to just invite server operators to destroy vanilla balancing because users whine too much about wanting mending and infinity on their bow.
It just feels like opening Pandora's Box
It would actually not be possible (with my syntax directly) to put both mending and infinity on a bow, even by overriding the vanilla definitions (I don't think that would work however), as both mending and infinity, under my system, would require internal support. However it should be noted that server operators (at least ones running Forge/Spigot servers), can already do that though, in my experience, server-side custom enchantments suck to actually implement.
This would just give operators an easy, and consistent way to do something that they could do already. It would also make it possible to add custom enchantments to Vanilla 'Modpacks', or Modpacks built solely using vanilla features, with an effectively vanilla backend.
In standard programming, bitwise operators are something that a lot of programmers use and can take for granted. In Command Programming, this is much harder to implement. The idea is that the bitwise operators, & (bitwise and), | (bitwise or), ^ (bitwise exclusive or), << (bitwise shift left), and >> (bitwise logical shift right) would work well with the scoreboard players operation command, as well as the unary ~ (bitwise not/inversion) operator. The addition of unary ~ is a "would be nice", as it would require adding a new (unary) syntax for scoreboard players operation, and bitwise not is equivalent to bitwise xor with -1 (since java is 2s compliment, and these bitwise operations would be implemented directly in java, right?).
Example Usage
scoreboard players set Reg register_acc 15
scoreboard players set Reg register_accb 10
scoreboard players operation Reg register_acc ^= register_accb
Puts 5 in Reg#register_acc (Fancy notation I use for the score of register_acc for Reg)
The unary syntax could be
scoreboard players operator ~ Reg register_acc
Which from the previous case, would put -6 in Reg#register_acc, because 2s compliment
If unary sytanx will be added, the unary - (negation) operation would also be nice. (again its trivial to do on its own).
The main problem is that all of that is client side. Most people using x-ray exploits don't use bugs in the game, but use custom clients, and those clients don't have to abide by what the vanilla one does.
Another problem with this is, the reason that this is handled on the client side is to reduce the load of the server side, and to smooth up the client.
While the execute store template is nice, it needs some additional support, namely for the Complex NBT Datatypes, (String, List, Byte Array, Compound, Int Array). While obviously this would not work for storage to scores, it should be available for entity and block storage.
Assume that A is a selector, Player Name, or Entity Unique ID to one entity, and that B is the same, but for a different entity; A and B both have a NBT Compound tag called "Data", and B has a Sub compound tag called "Data.Object". "Data.Object" is either a compound in A, or does not exist.
It should be possible to copy One to the other, for example
/execute store entity A Data.Object compound run data get entity B Data.Object
The contents of Data.Object in B will be copied to A.
Another thing is Variables, and storage in functions. Functions should not just be comments and commands, but have variables for storage. At the very least, constants should be available.
A Third thing would be direct operations on variables, Score's, and/or NBT Data.
I have listed a few operators here, some that are important, others that "would be nice". They are listed in the order of importance:
++, -- (both prefix and post fix) (increment and decrement operators)
Finally, some IO Support would be nice: IE the ability to read information about files relative to the world/server path into a Compound, and the ability to open IO Handles for those files.
Example syntax would be:
/file info <path> -> {PathName:<string>,Exists:<byte>,CanRead:<byte>,CanWrite:<byte>,IsDirectory:<byte>,IsFile:<byte>,SubFiles:<list of compound>,<other info about the file>}
Obtains the information about the given file,
Then
/file open <info compound> <read|write|append> -> {<Some sort of IO handle, such as a buffer or stream. Not meant to be directly used, but passed arround as arguments>} -> Would fail if the file does not exist, is a directory, or you don't have the correct access for the mode. Naturally, this IO System would be sandboxed.
/file read <handle> <target> <datatag, must be a ByteArray> [offset] [length] -> What more do you want from me, its basically InputStream.read(byte[],int,int)
/file write <handle> <target> <datatag> [offset] [length] -> Thats OutputStream.write(byte[],int,int).
If offset is not provided, then the offset is 0. If length is not provided, then the length is the length of the array.
The system above should be easy to implement, and could also be expanded (Random Access Files?)
0
I have fixed up the proposal and changed some syntax.
I've also moved the proposal here: https://github.com/chorman0773/Minecraft-Proposals/blob/master/Custom Enchantments/
I moved the proposal so I could use Markdown (something I actually know how to use), and so I could easily update the proposal without going through the editor (which sometimes doesn't load for me). I also moved it here because when I am able to do so, I will upload patch files showing a suggested implementation.
When patch files are released, the additional code is released under the MIT License. The documentation there is also provided under the MIT License.
0
Liking the customization you've got there. Especially the conditional effect, great for Smite-like effect. Hopefully with clearer item description though, like "+1 Damage to Undead"
Sorry for waiting a while to respond.
Also sorry about the bad formatting. I wrote this in a general text document because there was a lot to put, and my computer is prone to random crashes
For the description, I can certainly add a description field, and I think that would be a good idea as well. The main question is when you would want the description to show up, as when I make a formal proposal, that would be the kind of thing to include.
0
It would actually not be possible (with my syntax directly) to put both mending and infinity on a bow, even by overriding the vanilla definitions (I don't think that would work however), as both mending and infinity, under my system, would require internal support. However it should be noted that server operators (at least ones running Forge/Spigot servers), can already do that though, in my experience, server-side custom enchantments suck to actually implement.
This would just give operators an easy, and consistent way to do something that they could do already. It would also make it possible to add custom enchantments to Vanilla 'Modpacks', or Modpacks built solely using vanilla features, with an effectively vanilla backend.
0
Proposal for Custom Enchantments in Datapacks
Changed the Proposal to Markdown and some of the syntax and moved it here: https://github.com/chorman0773/Minecraft-Proposals/blob/master/Custom Enchantments/
0
In standard programming, bitwise operators are something that a lot of programmers use and can take for granted. In Command Programming, this is much harder to implement. The idea is that the bitwise operators, & (bitwise and), | (bitwise or), ^ (bitwise exclusive or), << (bitwise shift left), and >> (bitwise logical shift right) would work well with the scoreboard players operation command, as well as the unary ~ (bitwise not/inversion) operator. The addition of unary ~ is a "would be nice", as it would require adding a new (unary) syntax for scoreboard players operation, and bitwise not is equivalent to bitwise xor with -1 (since java is 2s compliment, and these bitwise operations would be implemented directly in java, right?).
Example Usage
0
The main problem is that all of that is client side. Most people using x-ray exploits don't use bugs in the game, but use custom clients, and those clients don't have to abide by what the vanilla one does.
0
Another problem with this is, the reason that this is handled on the client side is to reduce the load of the server side, and to smooth up the client.
0
Also comparisons for constants would be a good thing, and comparison tests.
1
Commands and Functions need some work.
While the execute store template is nice, it needs some additional support, namely for the Complex NBT Datatypes, (String, List, Byte Array, Compound, Int Array). While obviously this would not work for storage to scores, it should be available for entity and block storage.
Another thing is Variables, and storage in functions. Functions should not just be comments and commands, but have variables for storage. At the very least, constants should be available.
A Third thing would be direct operations on variables, Score's, and/or NBT Data.
I have listed a few operators here, some that are important, others that "would be nice". They are listed in the order of importance:
+, -, *, /, %, -(unary) (basic mathematical operations)
==, <=, <, >, >=, != (comparison operations)
&, |, ^, ~(unary), <<, >>, >>> (bitwise operators)
[](subscript operator) (Good idea to support variables for input)
[]= (subscript assignment operator) (AKA, set the value at the index)
+=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=, >>>= (compound operators)
++, -- (both prefix and post fix) (increment and decrement operators)
Finally, some IO Support would be nice: IE the ability to read information about files relative to the world/server path into a Compound, and the ability to open IO Handles for those files.
The system above should be easy to implement, and could also be expanded (Random Access Files?)