Open HoratioGamer opened 3 years ago
5HT2
commented
3 years ago I suggested #792 for baritone goal queuing which would easily be expanded to all kami commands. I'd rather implement #173 as it's a lot less work on all parties and is much more powerful. This issue would essentially be us writing our own scripting language with an API for minecraft.
5HT2
commented
3 years ago I'd suggest client commands but that's fabric, not forge.
BitBuf
commented
3 years ago A plugin API based on Java / Kotlin is planned instead of a scripting language and API. Please see issue #173 for updates.
5HT2
commented
3 years ago I'd still like this to be possible to quickly do stuff like custom advanced macros in game. Say you want to repeatedly go from X to Y and drop an item each time, and don't want to restart your game for that.
It could be extremely rich, and most people don't want to open a whole ass IDE and plugin form to make something that's hardcoded to a specific time they needed it.
Is your feature request related to a problem? Please describe. Only that there is another level of automation that could be added to Minecraft, KAMI could do it and distinguish themselves as the utility everyone will want.
Describe the solution you'd like The ability for KAMI to execute a script language, from a text file
Describe alternatives you've considered Doing repetitive operations using macros to trigger schematics, with user input required every few minutes.
Additional context Description of A Proposed Script Language:
OK, so, simple things. It could be modelled after the Procomm or PCPlus script language. This was an early program to connect to remote servers via a modem that allowed the script to do different things depending on what stream of data it received back from the modem. In this case, the script language would listen for strings put in the chat stream by Baritone, monitor current coordinates, etc. The language could be modelled differently, after Expect (a variant of TCL), or Postscript, or Forth, or anything really, but I give an example modelled after Procomm. I choose Procomm because it was expected to be programmed by any user, it was meant to be simple, easy to read, in addition to being a script language intending to be a human-substitute to carry on a dialog. The first link contains a sample script after the PROC/ENDPROC syntax was introduced. The second link is a PDF manual for the Procomm scripting language. A quick scan shows it had a lot of dos interface commands in it. This script is for minecraft, so it will have minecraft interface commands in it.
https://www.tek-tips.com/viewthread.cfm?qid=1479368 https://www.jumpjet.info/Application-Software/DOS/Networking/PCPlus/Aspect.pdf
All I recommend is that it be a linear, script-like, not an object oriented language. There may well already be modules for this available for JAVA to create and execute a script language. Do what is easy more than exactly duplicate this syntax, this syntax is provided to show the range of capabilities needed.
Variables:
Declaration:
variable x;
Setting:
set x 45;
Use:
$x
Arithmetic
set x_g $x_s + 200;
Special setting command for current coordinates, three variables assigned simultaneously (to avoid race conditions with a moving player):
setcoordinates xc,yc,zc;
The Main Interaction Command:
command "#buildrepeat $x_dir,0,$z_dir"; - type a command as if the user had typed it. command "#goto $x_g,119,$y_g"; command "#build My_schematic.schematic ~ 119 ~"; command "#cancel";
Define what we mean by "stopped" a condition that can be tested for
set stopped #; Coordinates not changing for # seconds is defined as the condition "stopped".
Program Flow Control
waitfor is the interaction flow control, waiting for something to happen.
waitfor result, $coordinates.x < $xg, "failure text typically reported to chat when the previous command fails", "Success text typically reported to chat", stopped
"result" is the variable in which the result is put. Whatever condition the waitfor matches, the number is put in result.
set timeout #; If a waitfor is not satisfied in timeout seconds, then result = 0 and the waitfor ends.
if $result==0
commands
else
commands
endif
if stopped
endif
loop commands endloop
break #; Where # is a digit representing the number of levels of nesting to break out of -- make languages only have break 1; which makes it necessary to have more state variables like "done" set in the block, and then tested right after the block, to decide whether to execute another break 1; A break # is just so much better.
continue; Like in C, TCL etc, start the current loop block from the top.
exit; end the script.
I have written 5 scripting languages, this is a simple one that will automate a wide variety of things.
Possible Extensions
Optional additional expressions (true/false tests):
block $dx,$dy,$dz,minecraft.netherrack - at location relative to current location, is the block of the type queried
Inventory minecraft.netherrack - true or false (item in inventory not hotbar), used in IFs
Hotbar minecraft.netherrack - true or false (item on hot bar), used in IFs
Shulker (name) minecraft.netherrack - does the shulker named (name) contain, true or false, used in IFs
Shulker is the name of a container where things can be found. minecraft.shulker is the minecraft object
Count unoccupied slots
set f $freeinventoryslots
if 2>$freehotbarslots
A different type of coordinate setting command: nearestblock (x,y,z) minecraft.netherrack; - put the coordinates of the nearest block of this type in x,y,z.
move minecraft.diamondpick, Inventory, Hotbar, 1 movestack minecraft.netherrack, Shulker, Hotbar, 2
throw minecraft.netherrack throwstack minecraft.netherrack
craft minecraft.diamondpick, FavouritePick - make an item and give it a name known to KAMI "FavouritePick" that can be used in place of the generic minecraft.diamondpick for the remainder of this script
rename 2,SecondFavourite - name the item in hotbar position 2 to "SecondFavourite"
set d durability SecondFavourite - remaining durability of the object named "SecondFavourite"
debug "filename"; -- dump a stream of debug information into a file, allowing users to debug their own scripts. debug ""; -- stop writing to the debug file.
With this, ordinary people, not JAVA wizards, could program some really cool scripts, selectively laying and breaking blocks using schematics to make anything.
My dreamed "do something useful on a road" script would be easy. It could automatically switch from maintenance, to digging, to paving, depending on what was available to the bot. The bot could go get it own resources and craft things. It could stop using a mending pick before it breaks and store it away in the RecyclingShulker.
Factions could develop scripts that can be shared between members. None of these scripts have to involve the KAMI code base. They do not need to be tracked. Use at your own risk.