Hook up a scripting language to Baritone, to allow "normal people" to make baritone do complicated things -- no compiling in new commands.

I think Jython is the best choice, but luaj is also available. I'm totally unbiased.

To be clear, I want to use a scripting language specifically so the script can be hot-reloaded at runtime.

No idea if this is an even vaguely good idea. Maybe it should be a wrapper or something. IronException seems to think it's a not-terrible idea.

• Pick a language (that doesn't suck)
• Design an API (that doesn't suck)
• Implement it (in a way that doesn't suck)
• I have not used any OwO's or UwU's in this issue.

I think something more high-level than the Java API would be a better fit. Having things in a scripting language could be used to hide the onTick calls and to make the thing execute continuously with the time between ticks being spent in methods making Baritone do things. So walking to the next tree and then mining all logs in range could look roughly like this.

pos = findNextTree()
walkTo(pos) // this can take quite some time
if (playerPosition() != pos) {
    log("Could not reach a tree!")
    exit()
}
logpos = findNearby("log")
while (logpos != null) {
    lookAt(logPos) // this one either takes one tick or is instant, not sure what would be better
    while (lookingAt() == logpos) {
        leftclick() // this takes just a single tick, also note that there is no need to release any keys manually
    }
    logpos = findNearby("log)
}
log("Done")

That way there is a real use to it for users who are probably more comfortable thinking about behaviour as a continuous process and not as a dozen function calls per second. We could still expose the entire java api to it for advanced users who don't have a problem stumbling on obfuscated names.
For the implementation I'd suggest using the script engine api built into Java so users can just plug in their language of choice (jython, luaj, javascript, etc.) and on top of that we could use that api to provide ourselves with a script engine for a DSL, but I think a full language implementation is out of scope for Baritone, even if it's super simple. (This entire thing is possibly out of scope, in any variation)
EDIT: I don't see a way for the script engine evaluate() method to return while inside a script function and later resume where it left off, so unless we use a custom interpreter I don't see a way to do the above without running every script in it's own thread which we would then manually sync to the main thread in order to make it run only while the main thread is waiting in the script onTick method.

Scripting is an even worse idea then what we have already because the game is obfuscated requiring Baritone to be re-mapped as compile time therefore at runtime Minecraft classes wont have any friendly names making it almost impossible for anyone who would be using a scripting language in the first place. Processes in a scripting language might cause performance issues depending if they use reflection or not.

What do you expect people to create with a scripting API if these issues exist?

@ZeroMemes Don't tell me this is already a thing.

@SIGSTACKFAULT it’s not, I spent like 5 minutes setting it up on a local environment

What I meant with making it possible to inputs scripts it that also people that dont know much about any programming language have the chance to let baritone do more complicated things then walking somewhere. I do agree that processes are probably better suited but not everyone has the possibilities. Another argument is that writing a script would be faster then coding a process.

the way I imagine it is that you can call the baritone processes (with the same commands as ig) after each other. So what baritone needs to do is look at what is the next thing to do and then lets that process run. If it is just that it would already help a lot of people.

Maybe if we want to go more complicated we could also let run different code when the process fails eg. Or other minecraft specific events...
loops / goto might also come in handy.

What I meant with making it possible to inputs scripts it that also people that dont know much about any programming language have the chance to let baritone do more complicated things then walking somewhere. I do agree that processes are probably better suited but not everyone has the possibilities. Another argument is that writing a script would be faster then coding a process.

You would be coding a process but in a scripting language like js or lua,

lol

NOT GONNA LIE

NOT GONNA LIE

Does not load with the Minecraft launcher but still something 😎

Probably would've if I wasn't doing poz meme to load it.

I think a DSL would be more better suited to this than trying to use Nashorn, or Lua or Python.

I implemented Jython api for my own version of Minecraft Robot . It worked pretty well. Check it out.
Nevertheless, implementing script or DSL may or may not be a painful process for such a huge project due to mapping and confusing.

Pick a language (that doesn't suck)

Should we do a vote or something?

Im not sure why we need a language. I thought this is to make it possible for people that dont know much about programming to also do more complex things with baritone. So having to learn a script language doesnt help with the problem. In my opinion it should be possible to write the commands you would give baritone normaly line by line in the script. Maybe if you have more experience a way could be added that fails are considered and other things like variables. But having to use functions or that kind might scare people off.

should be possible to write the commands you would give baritone normaly line by line in the script

That would require another rewrite of the command system, and plus you would need some other operators as well. It could become like a bash shell, where in any context you can always chain commands and such. But I think the upcoming commands system is all we'll have for a while.

you just need an interpreter

To interpret the code and then do what? Commands only print messages to chat, they don't return even exit codes or anything. They just fire off and then do their own thing.

You can't just slap an interpreter on a completely unrelated system and just assume it'll work.

I think we think about the problem differently. Maybe this issue is also different from what I imagine.
The basic thing would be to pass each line in the script into ExampleBaritoneControl.runCommand (like chat commands are handled). When it fails it also prints that out in chat so you can detect fails in code ofc. The better question would be how to handle fails in the script. Oh and idk how you think about the script but I imagine it as a process of baritone that has a file as a parameter (or rly long string). (like how you give it a schematic to build). Then it can handle the commands without you needing to input them in game after each other

The basic thing would be to pass each line in the script into ExampleBaritoneControl.runCommand (like chat commands are handled)

That's easy. The hard part is getting output from it, because commands don't work that way right now.

Even try this example:

#build <something>
#goal 0 0
#invert
#path

you would have to find a way for the build command to signal when it's complete, which would require a LOT of refactoring, not just in the commands system, but in mineprocess and etc.

ok I get it. Good point.

That interpreter also requires to communicate with the process to know when its done or failed

@IronException The command system needs to be build with that kind of support in mind, and the individual commands need to be redesigned to notify of success or failure. The interpreter can't just communicate with processes either because there's no way to know which one to communicate with. Commands need to cooperate.

okay I thought that wasnt that important but I definitly agree the command system should be changed
I started doing something but then I heared that somebody is already doing it. So I guess we have to wait for that?

Yes, there will need to be major refactoring if you want an interpreter. I will say, however, that the new commands system will be slightly more flexible in this area. that basically means that this will be easier to add to the new command system

I didn't mean "add the ability to write a list of commands in a file and execute them one at a time".

What I meant is, effectively, an API so Python-or-whatever can be used to tell baritone what to do. Loops, if statements, and all.

If you want to implement read-a-file-of-commands, you can do that to get the framework down for this.

effectively, an API so Python-or-whatever can be used to tell baritone what to do. Loops, if statements, and all.

Oooorrrrr you can just use Java like everyone else? This has never been an issue. Baritone has an API already.

Unless you're asking for specifically an interpreted language that can be hot-reloaded at runtime? Or something like that

Specifically an interpreted language than can be hot-reloaded at runtime.

I could probably do that, if you want

@0-x-2-2 i call harassment

edit: LOL I read it, that's nice

You know what nevermind

logan.txt
🦍

If you want to do file-full-of-commands-to-run-in-sequence, make another issue.

That's not really what I meant, but, just nevermind. The offer's off the table, sorry. (not because of you)

Baritone's contributors don't want me here, for being a "furry". I'm glad my commands branch made it into master, but I think that's going to be my last contribution to this project for now. Sorry man... 👋

not a fan of harassment

harasses people

pick one

The Command branch was already been ported to 1.13+. If you would have apologized to leijurv instead of being a child about it and just leaving everything would have been fine. I don't know how leijurv feels but what you did is fucked up and you still won't apologize about it. you are fucking pathetic.

I apologized multiple times, but you all made a big deal about it and wouldn't stop telling me about how stupid it was, so I left the group. Then I post something completely unrelated in here and you come in with your "furry.txt" posting the chat logs for everyone to see.

I don't think I'm the child here.

You've been hostile towards me from the very start anyway, so I think it's better for me to leave.

I apologized multiple times, but you all made a big deal about it and wouldn't stop telling me about how stupid it was, so I left the group.

The chat logs say otherwise about you apologizing instead you just tried to act like you did nothing wrong and that you "warned him" even though from what you said leijurv just thought you were trying to send him something that cannot be sent over discord due to text/file size limits.

"furry.txt"

The furry.txt file was not named by me lol.

You've been hostile towards me from the very start anyway, so I think it's better for me to leave.

I pointed out flaws in your code and reasoning and maybe I was too harsh sorry for that.

@0-x-2-2

WHAT?!
Last Tuesday at 5:17 PM
I'm sorry geez

WHAT?!
Last Tuesday at 5:05 PM
Holy shit
I didn't know
Sorry...

Nah fam have fun

WHAT?!
Last Tuesday at 5:19 PM
Okay
I did warn you though

🦍

Baritone's contributors don't want me here, for being a "furry". i'm not sure why you're transferring a problem with 0x to a problem with me? not sure if you noticed but it's brady and i that can push to baritone.... not 0x

(0x resigned lmao owned)

@leijurv honestly I just blocked everyone on the baritone project, it's maybe not you personally, but you and brady both didn't seem very forgiving in the group chat

This isn't what issues are for anyway, and 0x has just been harassing me for a while about the furry thing and I'm fed up with it, you clearly don't see any problem with it though so.

I blocked you on Discord because I don't want to discuss this anymore. Hope you understand

https://cdn.discordapp.com/attachments/541327608286019615/630228248634064936/Screenshot_20191005-192157.png
wait why did you block me on discord xD

what did i ever do to you? other than being slightly annoyed with you for some email spam (which btw i dont care much about at all)

@LoganDark

Well at least I didn't make a big fuckin deal about it and start harassing you elsewhere, you're the reason I made a contribution to Baritone anyway so you're not that bad, just misguided

WAAAAAAAAAH YOU DIDNT IMMEDIATELY FORGIVE ME
WAAAAAAAAAAAAAAAAAAAAAAH
👶
🍼
😿

Is This Guys Not A Furry? Or Does He Want Us To Call Him A Dog Or Cat Or Wolf Or Lion????

The basic thing would be to pass each line in the script into ExampleBaritoneControl.runCommand (like chat commands are handled)

That's easy. The hard part is getting output from it, because commands don't work that way right now.

Even try this example:

#build <something>
#goal 0 0
#invert
#path

you would have to find a way for the build command to signal when it's complete, which would require a LOT of refactoring, not just in the commands system, but in mineprocess and etc.

Actually the baritone says "building finished" and I can use AdvancedMacros to catch that keyphrase and continue the script.

Yes but the entire purpose of this issue is for the user to have access to the Baritone API in game, also someone else could say building finished in the chat and fuck you up.