mattila42 / betterdatapack Goto Github PK

Try Catch might be one of the best thing in many languages. However in Minecraft if something is wrong then the whole file will be "invisible". No errors, no skips, like you never did anything.

My Try system will work the following way: The content will be put in a different file and called from its original space.
Catching an error will be as simple as creating a new dummy scoreboard and watching if it ever changes. The Try Catch mcfunction would end with a scoreboard specifying a value to said objective, so if it remains the same after loading the file then we can be sure something happened there and will run the commands in the Catch part.

The names of the Try mcfunctions, and the scoreboard shall be configurable in bdconfig.json.

Exmaple code:

/try {
  /tellraw @a "text": "I wonder if this works" # Oh no, a tellraw with no braces?? This surely goes south
} catch {
  /tellraw @a {"text": "No, you dumdum. Tellraws need braces!!"}
}

bdconfigs:

• tryNames: string, specifying the names of the Try mcfunctions followed by a number to make each one unique.
• tryScore: string, specifying the name of the Try score.

If you do something like this:

/execute if entity @e[type=pig] run {
  /kill @e[type=pig]
  /say No more pigs...
}

Then the /say command won't run because the condition is checked for each command and it isn't true anymore.

Solution for the time being:

/execute if entity @e[type=pig] run /function namespace:main/kill_pigs

/mcfunction kill_pigs {
  /kill @e[type=pig]
  /say No more pigs...
}

After I fix this the conversion will do the same as shown above.

This can easily be the most obnoxious idea, but lemme explain:

This would be somewhat like an actual function, the one in real languages that can get parameters. Tho this would look a lot similar to aliases and the parameters would need to be hard coded when called and not some fancy variables. (Since all variables will be global, you don't even need that)

The idea is that you could make your own command with your own parameters.

Example:

# The syntax is: /component <commandname> [parameter(s)/word(s)] { <command(s)> }
# Parameter names must start with a dollar sign
# Any word after the name will be considered a word that needs to be written the same way
# Both of these can contain any special character but not braces (and if starts with a dollar sign then it can only be a parameter)

/component greet $name {
  /say Hello $name! What a nice name you have. I have a friend called $name.
}

/greet Josh # ---> "Hello Josh! What a nice name you have. I have a friend named Josh." is displayed in the chat

/component mycommand word1 word2 word3 {
  /say You ran the mycommand command correctly
}

/mycommand howdoiusethisagain # Won't work
/mycommand asd fgh jkl # Won't work
/mycommand word1 word2 word3 # Will work

# This second example can lead to components being way more useful cramming more functionality inside a single namespace somewhat like this:

/component greet team $name {
  /say And our newest team is here, the $name! Welcome all!
}
 
/greet team Bears # Still the same greet command but if used like this then shows a different message

Lastly, it would be nice to make built-in components. these should either be simply imported before the call like this:

/import greet # Will import all built-in components that creates the greet command

this would make it easy to make your own component with the same name and not worry about the built-in overwriting your code.
OR
Simply make all user-made components overwrite built-in ones. This one is clearly better, but since I thought about the first one and wrote it down I will leave it in.

Since my code for the added features are very basic, none of them can be nested. Though, it is planned to be.

Example:

/mcfunction my_function {
  /mcfunction my_other_function {
    # This won't be declared and will break the whole parent function
  }
}

New boolean setting in bdconfig.json that would hide the VSCode info notification whenever you convert a datapack called hideInfo.

Some sort of option to make certain files "traditional". So basically the extension won't try to convert them.

Example ideas:
##traditional in the first row marks the file as traditional.
traditional.json next to load and tick. Working the exact same way.
bdconfig.json adding a new list property: traditionals: [] and filling it up with paths to the files from the workspace root.
Or just simply finding a way to determine if a file is traditional (maybe not having any command with a slash)

(Currently if you try to convert an already traditional file the output will have all the commands put next to each other in a line)

Many code can be hard to understand when strange definitions are used or long parts of code appear multiple times in the same way.

Aliases would grab any code and save it in a name you wish. For example:

# Single line alias
/alias $creative_player = @p[gamemode=creative, tag=check]

# Multiline alias
/alias $break_specials = {
  /execute as @e[
      type= armor_stand,
      tag= special
    ]
    at @s
    run {
      /setblock ~ ~ ~ air
      /kill @s
    }
}

/execute if entity $creative run $break_specials

I'd like to make it require a $ sign to make it uniform, easier to find and be able to have a different color. All the variable types planned will have this rule too.