TheJacob

Follow-up: Repository will be down over the next day or two. I'm changing the project name and integrating Maven in the development process. Moreover, I'm working with some collaborators that are focused on pushing a proof of concept script with the first stable release of the framework. The repository layout will be changing as well to reflect this. This project will be open source (no change).

Follow-up: Finished providing Javadocs for everything under the framework package and discovered & fixed a bug with Active Selector's implementation (see issue#2). Started working on action model of the framework.

Follow-up: Prior to the aforementioned upcoming tasks, I'm going to provide Javadocs for everything under the framework package. In doing this, I'll likely clean up a bunch of the code as well (or at least streamline it). The "decision" model is essentially complete, maybe adding one or two more decorators or composites here and there. The focus will shift to the "action" model once I've finished documenting everything (the "sense" model is provided by the OSBot API hehe, ty.) Initial Javadocs pushed to Git for Tree, TreeFactory, and Behavior. The remainder will follow.

Follow-up: Utility functions implemented. Next updates will expand on buckets, useful utility decorators, and streamlining the script to a (sense -> decide -> act) model. I expect these to be the last additions to the framework before major work will be put in to writing conditions/actions for f2p hybrid pking.

Follow-up: New release (v1.2) with updated framework. This should be the last time I majorly re-work the framework, much more flexible now. Can @Mio or @Gunman move this thread to Soft Dev/Projects. Thank you!

Follow-up: So, I definitely think this approach (a behavior tree) will be sufficient to create a F2P ranged/2h pking script. That said, release 1.2 will separate actions from decisions before diving into the meat and potatoes of pking. Namely, the behavior tree will be parsed to update the blackboard with a set of game states (read as goals) that the game logic will accomplish -- decisions executed in onLoop and decisions processed in onGameTick. Also, I will provide more flexibility with regards to conditional aborts and parsing a "RUNNING" tree. In release 1.3+, grouping and prioritizing actions for pking (as subtrees) will be the toughest part. It's my intent to have a working pk-ready release within the next 10 days. If anyone has any thoughts on what a model might look like for pking, definitely reach out and give me a shout. As well, it's my first time writing a project in Java, so if there's any bad practices you folks see in the project, let me know.

I didn't test your method, but immediately I see there's a chance to throw an array out of bounds exception (not providing array.length - 1 on indexing). Here's a more condensed implementation that might help: static final int[] fWorlds = { 1, 8, 16, ... }; static final int[] mWorlds = { 2, 3, 4, ... }; public static void hopRand() { final int[] hWorlds = getWorlds().isMembersWorld() ? mWorlds : fWorlds; if (!getWorlds().hop(300 + hWorlds[random(0, hWorlds.length - 1)])) { hopRand(); } }

Try passing a parameter with -script as well. I couldn't get -script to work without passing a dummy parameter. java -jar OSBot.jar -login <OSBotUser>:<OSBotPass> -bot <OSRSAccount>:<OSRSPass>:0000 -world <WorldNum> -script <YourScriptName>:params

Released a different approach to creating scripts (behavior tree framework). See this thread. If a decision tree approach is used, it will be a hybrid subtree of the behavior tree framework.

Hey folks, I'm working on an AI framework for writing Scripts on OSBot. After having recently played around with a decision tree framework and reflection (see this thread), I wanted to try a different approach to scripting and I definitely think this is a winner. My intent is to provide two things: flexibility and simplicity (in regards to maintainability). I will be using a behavior tree model w/ a utility function to write a F2P pking script, so let me know where you think we can improve this framework! Source Download (0.0.31): Git Repo (temporarily down) Changes 0.0.31 - new repository, structural changes, and maven integration (streamlines collaboration). 0.0.21 - merged new framework, implemented a utility function, and removed json integration & chicken killer test script. 0.0.12 - loading decision tree from JSON file. 0.0.1 - initial release Setup Updating setup in accordance with 0.0.31 (TODO). Remarks Updating remarks in accordance with 0.0.31 (TODO). Snippets (v0.0.31) MyScript.java

Oh ok, I didn't know about that! I think I can change the design such that it doesn't use reflection. The reason I decided to go with that design in the first place was to reduce code clutter while parsing the decision tree (making the assumption that the script does not know about all the conditions & tasks). In order to get rid of reflection, I can make the script aware of all conditions & tasks while still leaving the decision tree to be dynamic to the user. The 'parser' variable in 'onLoop' should be holding a reference to a spot in the tree at all times rather than a copy of the tree. If I'm not mistaken, this line passes a reference by value rather than copying the whole tree. Condition parser = dto; I might be wrong though, where do you see it copying the whole decision tree or JSON parser every loop?

Solution: I don't think I understood the reasons to extend API vs. MethodProvider, and how exchangeContext ties in with Bot. This post explains it quite well:

Thanks @Czar! I'm still figuring out a few more things about the OSBot api, but I'm aiming within the next two weeks to have a script released demonstrating this framework (more complicated than the simple one I included with this release). I'm sure there's still some drawbacks with it's current design, so definitely give it a look and let me know what you think. Open to all feedback. For example, I don't know how well this framework will perform when more than one decision is needed in a tick, or how to handle running concurrent tasks (such as moving and eating -- maybe hooking in to OSBot's Event API).

Hey folks, I think I understand the purpose of org.osbot.rs07.script.API abstract class but I don't know how to tie everything together in a script. I think it has something to do with the behavior of MethodProvider.exchangeContext, specifically: But I'm stuck on understanding what this actually means. For example, here's a Fighter class that extends API (let's say it'll behave similarly to Combat). public class Fighter extends API { public Fighter(Bot bot) { exchangeContext(bot); } @Override public void initializeModule() { log("Initializing fighter module."); } // Some example method. public String getMyName() { return myPlayer().getName(); } } Right now I don't know where initializeModule should be called, or how I hook this class into the existing API framework for that matter. Based on the docs above, I think it has something to do with overriding the exchangeContext method somewhere, but I don't know where: // This method would be in a class that subclass's MethodProvider (a wrapper, maybe?) // But a problem might be, how do I get getBot().getMethods() to return a reference // to this new method wrapper so I can access getFighter(). @Override public MethodProvider exchangeContext(Bot bot) { super.exchangeContext(bot); fighter = new Fighter(bot); fighter.initializeModule(); return this; } public Fighter getFighter() { return fighter; } Does anyone have those answers? In my mind, the desired end state is something like: @Override public int onLoop() { String myName = getBot().getMethods().getFighter().getMyName(); // or maybe just getFighter().getMyname() for short, similar to getCombat(). // ... return 600; }

Hey folks, here's a decision tree framework for writing Scripts on OSBot. My intent is to simplify the process of making iterative decisions and provide flexibility to the user should they wish to change the decision model. I will be using something similar to this in order to build a F2P PKing Script, so let me know your thoughts on where it can be improved! OUTDATED: CLICK HERE (for a behavior tree framework) Source Download: FastUpload - 1.1 (25 11:00 Jan 2023) Changes 1.1 - removed redundant if condition in deserialize method. 1.0 - initial release. Setup Create a "DeepButler" folder in OSBot's Data folder (getDirectoryData). Create a "deepbutler.json" file in the "DeepButler" folder. Use the example decision tree (and later have fun making your own!) Modify your OSBot to allow reflection (add "-allow reflection" to run.bat). Enter W326 and a secondary world to test the framework. Remarks This framework has not been tested on any scripts yet. I intend to use a similar iteration of this framework on a F2P PKing Script. Create new Conditions and Tasks, and change the decision tree as required. The decision tree doesn't necessarily have to be processed in "onLoop". In fact, I think there's great potential by listening for game tick events. Every Task is a Condition. It makes sense to simply return "true" in Tasks that do not branch anywhere (prompt a re-loop), otherwise use them as a condition & a task if there's subsequent decisions to be processed. The "Cond" annotation is something I was trialing in lieu of reflection. Not integrated at the moment. Snippets deepbutler.json DeepButler.java Decision Tree Parser (deserialize method)