本站内容来自互联网，与本站无关，仅供个人学习研究之用,请在二十四小时内删除 FFXIV bots

**admin** · 05-16-2022, 06:06 AM

Introduction

I've decided to write a little bit of what I've learned regarding making stuff for Rebornbuddy. I don't have access to any of Rebornbuddy's internals, so what I'm writing here can be incorrect and is mostly based off of assumptions and my own personal experience. If you're starting to program or don't know C#, I'd highly recommend that you learn it doing something simpler. Coding for Rebornbuddy is mostly about understanding the bot's architecture and if on top of that you also don't know C# then things will get complicated. There are easier things you can do to learn C# out there.

What You Must Learn

Unless you want to extend the Rebornbuddy API, you don't really need to concern yourself with how the bot injects things into the game and reads the game's process memory. What you have to concern yourself with is what the API exposes.

1. How do I read data from the game with the API?
2. How do I act inside the game through the API?
3. How is my code executed by Rebornbuddy?

The third point might not be completely obvious for newcomers, and is where most of the complication lies. There are things that you could do on other environments, like sleeping a thread or making new threads, which are either not correct to do here or you need to do it in a very specific way. This was the hardest part for me to fully grasp, since you have to dig deep to find any documentation.

How It Works

You can interact with Rebornbuddy through three different routes:

1. Making a Combat Routine. Go this route if what you want is to make combat logic which is independent of the bot base used.

2. Making a Plugin. Go this route if what you want to do is a secondary activity to the main one being performed by the bot base. Repairing is a good example of a secondary activity.

3. Making a BotBase. Go this route if what you want to do is the main activity of the bot, and OrderBot cannot do it already through a profile. You gain complete control over what the bot does with this; which also means you must take care of everything you want to do.

All three routes share some stuff in common. You’ll be inheriting from a class or interface in the Rebornbuddy assembly to create either of them. This derived class of yours is your main point of entry to the bot, and provides the interface that the bot will use to interact with whatever you make. These derived classes and all their references must be placed on folders specific to each once inside the Rebornbuddy installation folder.

In all three cases, what you package into your final folder will be the source of your code. This will be compiled by Rebornbuddy upon initialization of the application. You cannot use external pre-compiled libraries with your stuff unless Rebornbuddy already references them internally. You must also be careful about conflicts between classes with the same names; always use a unique namespace for your code.

Any data files, images, or other resources that your code might need must also be included in the final folder that you put on the Rebornbuddy installation directory. All three approaches are based around a single overall design pattern: behavior trees.

Behavior Trees

With few exceptions, almost everything you code will be executed inside a behavior tree. Behavior trees are a design concept used mostly for game artificial intelligence. From FPS to MMOs, many games out there use them for NPC intelligence. Behavior trees are a design pattern, and as such it’s important that you understand them from a conceptual level independent from the particular implementation of them in Rebornbuddy. Here are some good articles that explain them:

1. Gamasutra: Chris Simpson's Blog - Behavior trees for AI: How they work
2. Game AI ? An Introduction to Behaviour Trees | Against the Grain ? Game Development

Behavior trees, like everything else, have their compromises and benefits; and it's important that you learn when to use them and when you’d be better served using something else. Generally, if you need to make a single complex decision, then they can be convenient. They let you make cleaner code and avoid a bunch of nested conditionals that are hard to understand and maintain. If what you want is to make a sequence of steps or simple decisions, then something like a coroutine is better. A coroutine’s greatest benefit is that they are easier to debug. In short, behavior trees are a more powerful version of finite state machines.

The basis of a behavior tree is its nodes. In Rebornbuddy, a node is implemented on the Composite class or any class derived from it. The Composite contains the interface common to all nodes in the tree, required to make them play nice with one another independent of their own logic. In general, there are two kinds of composites: those that control the flow of the tree, and those that actually do something with the game. The tree starts with a top node that has no parent: the root. This root node is ticked approximately 30 times per second when the bot is running. The tick will be propagated to every child node according to the flow established by other composites like priority selectors, decorators and sequences. A leaf composite is one who has no child composites. They represent the end of the tree, and it is inside these that you’ll usually interact with the game.

Action
The action composite can be considered as a “leaf” of the tree: a node that has no child node. It is in here that most of the code to interact with the game lies. If you want to move the character inside the game, you’ll probably put that code inside an action composite.

RunActionCoroutine
A special composite that wraps an asynchronous method inside it. This is the node that permits you to use coroutines inside the behavior tree. When the async method inside it returns a false boolean result, this composite in turn returns a RunStatus.Failure value to its parent. When it returns true, this gets translated to a RunStatus.Success value. When the async method is stuck on an await keyword, it’ll instead return a RunStatus.Running value. This last value causes the next tick to not start from the top of the tree as usual, but instead tick this composite directly.

Decorator
This composite acts as an IF statement. It has a single child node, and the only way the tick reaches that node is if the conditional statement of the decorator is true. If the conditional is false, the decorator will return a RunStatus.Failure value back to its parent.

Priority Selector
A composite that has many child composites. It will tick each one by one until one of them returns a RunStatus.Success value back; at which point it’ll return that value to its own parent.

Sequence
A composite that has many child composites. It will also tick each child one by one, and continue doing so only if each child returns a RunStatus.Success value back. When a RunStatus.Failure value is returned from any of the children, it’ll return that value to its own parent too.

There are many other less popular composites. You can dig for them inside the TreeSharp namespace. I HIGHLY recommend that you read those articles if you're serious about writing something for Rebornbuddy. If anything, they'll teach you an AI technique that you could use elsewhere. I think that after reading them, most things will be clear.

The way composites are implemented in Rebornbuddy permits you to build them quickly by using lambda expressions inside their constructor. This, however, is what causes them to be hard to debug. I would suggest that you don’t use too many lambda expressions to build Actions, but instead write actual methods that you then pass on their constructor. This way debugging is better since you’ll know which method is causing the problem and can step on them. You can also extend the Composite or Action class to create your own kind of composite with custom logic.

Plugins

To create a plugin, you must create a class that inherits from BotPlugin, which is inside the Rebornbuddy assembly. This interface provides you with methods that Rebornbuddy will call during different times on execution, and a few properties that you have to fill out with your own information. The methods are the entry point to your code. You might be tempted to write your code normally on these methods without using composites or the behavior tree, but this goes against the very design of the bot and is usually a bad idea. Here is what the methods in the interface look like:

As you can see, their names give you a very good hint of when they care called by Rebornbuddy. What you should aim for is creating all your logic inside a composite, and then hooking that composite into the Rebornbuddy tree when your plugin is enabled, while unhooking it when the plugin is disabled. To make hooking things more organized, the main behavior tree inside Rebornbuddy has "categories" that you can hook into. These segments of the tree correspond to a particular activity. You can hook your own behavior composites to any part of the tree, but try and choose the category you consider categorizes what you're trying to do. This is the code I usually use to hook into the tree for a plugin:

The times when you should hook your logic are:

The plugin is enabled and the bot is already running.
The plugin was enabled beforehand and the bot just started running.

The times when you should unhook your logic are:

The bot is running and your plugin gets disabled.
The bot is stopped.

Let me explain what exactly is happening in the hook method.

The first **** is simply loading a settings Yaml file from disk. This file represents an object with all my plugin's settings. Some people prefer to use static variables for their settings, but I prefer the encapsulation that this method provides. The second **** is creating my actual behavior in the form of a composite. The creation of this composite is done on the TeleportLogic class separate from this one. The third **** is what actually hooks my logic into the tree. For this plugin, the composite is being hooked into the very start of the tree. You can think of categories as a PrioritySelector composite, where each category name corresponds to position on the selector, "TreeStart" being the first node. The 0 on the method represents the position within that category.

C# is very similar to Java if you've ever programmed in that. If you haven't programmed at all, then perhaps a couple of "beginner" tutorials out there would help. Always do C# on Visual Studio, best thing out there. You could start with a simple plugin perhaps. I know that learning is mostly about motivation and making something interesting, and what's more interesting than making your character in a game do stuff.

Glad it helped. The behavior tree implementation in RB is probably what keeps most people not understanding fully how to do stuff. It also doesn't help that since you can make composites by passing lambdas on their constructors a lot of the time the formatting makes it very hard to understand what's happening.

**rebornbuddy** · 03-20-2023, 06:47 AM

<Profile>
<Name>Alexander - The Burden of the Father</Name>
<BehaviorDirectory></BehaviorDirectory>
<Order>
<While condition="not HasAtLeast(13587,30)">
<If condition="not DutyManager.InInstance">
<LLJoinDuty DutyId="115"/>
</If>

<If condition="DutyManager.InInstance">


<If Condition="GetInstanceTodo(0) == 0">
<Log Message="Defeat the Manipulator 0/1" />
<Grind GrindRef="FinalBoss" while="not GetInstanceTodo(0) == 1"/>
<If Condition="&openchest; == 1">
<MoveTo XYZ="0.2756959, 10.60451, -6.587952" />
<LLOpenChest/>
</If>
<While condition="DutyManager.InInstance">
<WaitTimer WaitTime="5" />
<LLLeaveDuty/>
</While>
</If>
</If>

</While>
</Order>
<GrindAreas>
<GrindArea name="FinalBoss">
<Hotspots>
<Hotspot Radius="90" XYZ="0, 10.74299, 19.20038" name="Name"/>
</Hotspots>
<TargetMobs>
<TargetMob Id="4347" Weight="1"/> 
<TargetMob Id="4346" Weight="1"/> 
<TargetMob Id="3772" Weight="1"/> 
</TargetMobs>
</GrindArea>
</GrindAreas>
<CodeChunks>
</CodeChunks>
</Profile>

<Profile>：这是整个XML文件的根元素，标志着整个文档的开始。

<Name>Alexander - The Burden of the Father</Name>：定义了该Profile的名称。

<BehaviorDirectory></BehaviorDirectory>：定义了行为文件的目录，留空则使用默认目录。

<Order>：定义了顺序控制块，包含一些控制程序执行顺序的指令。

<While condition="not HasAtLeast(13587,30)">：使用While循环指令，只要条件成立，就一直执行循环内部的代码块。该条件的意思是，如果物品ID为13587的物品数量小于30，则条件成立。

<If condition="not DutyManager.InInstance">：使用If条件语句指令，根据条件是否成立来决定执行哪些指令。该条件的意思是，如果当前不在副本内，则条件成立。

<LLJoinDuty DutyId="115"/>：这是一个自定义指令，用于加入指定ID的任务或副本。这里指定的DutyId为115。

</If>：结束If条件语句的块。

<If condition="DutyManager.InInstance">：使用If条件语句指令，根据条件是否成立来决定执行哪些指令。该条件的意思是，如果当前在副本内，则条件成立。

<If Condition="GetInstanceTodo(0) == 0">：使用If条件语句指令，根据条件是否成立来决定执行哪些指令。GetInstanceTod o函数用于获取当前副本的进度，并且0代表第一个目标，即Defeat the Manipulator 0/1。该条件的意思是，如果该目标的进度为0，则条件成立。

<Log Message="Defeat the Manipulator 0/1" />：这是一个自定义指令，用于在日志中记录一条消息。

<Grind GrindRef="FinalBoss" while="not GetInstanceTodo(0) == 1"/>：使用Grind指令，进行击杀怪物的行为。GrindRef属性指定了所使用的GrindArea 的名称，while属性指定了当GetInstanceTodo(0)返回值为1时停止击杀的条件，即Defe at the Manipulator 1/1。

<If Condition="&openchest; == 1">：使用If条件语句指令，根据条件是否成立来决定执行哪些指令。&openchest;是一个自定义变量，表示是否需要打开宝箱。如果该变量为1，则条件成立。

<MoveTo XYZ="0.2756959, 10.60451, -6.587952" />：这是一个自定义指令，用于移动到指定的坐标。

<LLOpenChest/>：这是一个自定义指令，用于打开宝箱。

</If>：结束If条件语句的块。

<While condition="DutyManager.InInstance">：使用While循环指令，只要条件成立

<Grind GrindRef="FinalBoss" while="not GetInstanceTodo(0) == 1"/>：当未完成任务目标“打败操纵者（Defeat the Manipulator）”时，就进入“FinalBoss”区域杀怪，该区域包含一个半径为90的热点（ Hotspot），并且要击杀3种怪物：左前腿（ID为4347）、右前腿（ID为4346）和操纵者（I D为3772）。GrindRef参数告诉脚本使用哪个GrindArea，这里是“FinalBoss” 。
<If Condition="&openchest; == 1">：如果打败了操纵者并且获得了宝箱，就执行下面的代码。&openchest;是一个特殊的变量，如果它的值为1，则表示已经打开了宝箱。
<MoveTo XYZ="0.2756959, 10.60451, -6.587952" />：移动到指定坐标，这里是宝箱的位置。
<LLOpenChest/>：打开宝箱。
<While condition="DutyManager.InInstance">：如果正在进行实例副本，就一直执行下面的代码块。
<WaitTimer WaitTime="5" />：等待5秒钟。
<LLLeaveDuty/>：离开实例副本。

最后的 </Profile> 表示 Profile 的结束。这个 Profile 的目的是通过杀死 FinalBoss 区域中的怪物来完成 Alexander - The Burden of the Father 副本任务，并打开获得的宝箱。

**moon** · 04-29-2023, 02:27 AM

谢谢你的分享，再根据以上案例我学到了很多新的知识，
但是现在有一个问题我不能解决，
“如何在特定的一个副本聚集区域内所有怪物再进行战斗，而不是遇到怪物立刻原地杀死怪物以后再继续前进。” 如果我需要对一个现有的脚本进行这样的调整，请问我需要如何调整代码。在尝试了多次调整代码但依旧未能成功，希望获得帮助。

**dalong988314** · 1周前

这个指令怎么用，想查看NPC的 ID，创建一下XML文档复制进去没有用，序列读不了
Name: Detailed Target Information (Target Something!)
--------------------------------------------------
ClearLog();
GameObject s = GameObjectManager.GetObjectByNPCId(Core.Target.Npc Id);
Log("Can Attack - " + s.CanAttack.ToString());
Log("Combat Reach - " + s.CombatReach.ToString());
Log("Current Health Percent - " + s.CurrentHealthPercent.ToString());
Log("English Name - " + s.EnglishName.ToString());
Log("Fate ID - " + s.FateId.ToString());
Log("Heading - " + s.Heading.ToString());
Log("Id Location - " + s.IdLocation.ToString());
Log("Is Behind - " + s.IsBehind.ToString());
Log("Is Fate Gone - " + s.IsFateGone.ToString());
Log("Is Flanking - " + s.IsFlanking.ToString());
Log("Is Me - " + s.IsMe.ToString());
Log("Is Targetable - " + s.IsTargetable.ToString());
Log("Is Valid - " + s.IsValid.ToString());
Log("Is Visble - " + s.IsVisible.ToString());
Log("Location - " + s.Location.ToString());
Log("LUA String - " + s.LuaString.ToString());
Log("Max Health - " + s.MaxHealth.ToString());
Log("Name - " + s.Name.ToString());
Log("NPC ID - " + s.NpcId.ToString());
Log("Object Id - " + s.ObjectId.ToString());
Log("Type - " + s.Type.ToString());

本站内容来自互联网，与本站无关，仅供个人学习研究之用,请在二十四小时内删除 FFXIV bots

有用的代码，用于制作脚本等

有用的代码，用于制作脚本等

评论

评论

评论

评论