deityslayer
New Member
- Joined
- May 18, 2014
- Messages
- 23
- Reaction score
- 0
Does this bot support maps yet?
Map support
- Thread starter deityslayer
- Start date
No. I'm sorry to be negative, but numerous people claimed to be working on it and they eventually all became quiet about it. The bot API is supposed to be able to do this easily, and I hope an example will eventually be published. I'm not asking for everything to be worked out, but an example, which would serve as a start, does not exist. There is no reason for me personally to believe map support again unless I see it. Again, I'm sorry for sounding negative about this.
Two part answer, first to the OP: BasicGrindBot does not contain the functionality to do maps. It's an overworld grinding bot only. There are no plans to add grinding maps to BasicGrindBot for the time being. The API fully supports maps and provides all the functionality required to run them. However, since it's not provided in BasicGrindBot, it is up to users to do it if they want it. Please see the Exilebuddy Project Guide for more information on the way EB is setup.
Now to what cyberbot said.
If people want to work on their own bots and not give them out, it's certainly in their right to do so. Our model is not to profit off of forcing people to dev stuff for our products and then share it. The Buddy store was added to further help incentivize people to contribute and get something in return. While EB doesn't have store support yet (as it is brand new, and being tested mostly with HB since it's the largest bot) I can certainly understand if people spend their time on this stuff and want to keep it private.
I don't know the actual status of the people trying to make a map bot, but no one that is actually trying has come to me with code that they needed help on or had issues with the current API that they needed something to be done differently. Anyone that needs help, gets it, as long as they have made an attempt and have something to show for it. If you just ask me to help write a map bot, then there's nothing I can do for you, because you're basically asking me to write a map bot for you.
The "we don't have guides or examples" argument is no longer valid. I personally made it a point of emphasis since I took over and did the beta rewrite. In fact, I was just talking about this yesterday in this reply. Trying to give users more dev resources by keeping things out of the bot itself is the main reason why BasicGrindBot is setup as oddly as it is right now.
If you need help understanding what is provided right now and how that is applicable to this topic, I can certainly clear that up for you in this reply. However, what you don't understand, is that what you're asking for is for everything to be worked out for you, because the only thing you actually need, is the specific logic that uses the API. There's no "map" example to provide that doesn't involve being a working map bot. All I can do, is tell you what you should already know or be doing to develop things with the API and programming in general.
A map bot can be thought of as 3 distinct parts:
1. Starting in town, withdrawing a map and traveling to the map room.
2. Inside the map room, activating a map and taking the portal.
3. Grinding the map itself.
Part 1
ExampleBot contains example code for what needs to be done for withdrawing and stashing. You have to add your own withdraw task that makes use of Coroutines.WithdrawItemsCoroutine (as noted). Existing tasks are provided you can use to get an idea of the task design. ExampleResurrectTask, for example, shows a really simple task that uses an API function that would be perfect to start with. For stashing, you can use the provided bot task, and implement your own logic in the user functions to not stash your maps or other things like currency if needed.
For traveling to the map room, look inside the Coroutines namespace for a provided function to help out. You want to take a waypoint to the map room, so you should be able to find something and get working. With the task based design, you'll be adding a TravelToMapRoom task that executes after your other town tasks are done. See the Task section in the BasicGrindBot Guide to follow the task flow of it for a better idea of order of operations.
Part 2
Now, you're in the map room at the waypoint. You need to interact with the Map Device to bring up the GUI for it. The Coroutines namespace provides a coroutine you can use to interact with an object. ExampleBot provides a few tasks that perform interaction, so check out ExampleLootItemsTask and ExampleOpenChestTask.
Once you have interacted with the map device, it's GUI pops up. Refer to the "Using Loki to interact with the client" section in the An Overview of Loki: Exilebuddy's API for Path of Exile to get an idea of which namespace contains the functions needed to interact with that GUI.
Likewise, you'll want to also find a section to interact with the main inventory as well. The process for starting a map is the same as you would do in game: pickup the map to the cursor, place the item into a map slot, activate the map device. The new Fast Move mechanic just added is not supported in the API because you can't control which slot the item will go in. It might be added later, but for now, it's not needed.
Once you have activated the device, you need to find the portal objects and take them. Check the Coroutines namespace for a coroutine you can use to take the closest portal. As with before, you want to make a task that executes when you're in the map room to take the portal. If you don't want to use the coroutine, you can implement one yourself by simply interacting with the found portal, after moving to it. This is the same as chest/loot stuff.
Part 3
Now, you're in the map. ExampleBot contains a lot of the code for showing how to do looting, opening chests, doors, combat, and exploring. The explore system simply runs though the area, and then exploration complete kicks in. As with the current BasicGrindBot implementation, you must add extra logic to take boss rooms or handle killing every single mob, because the CR by default doesn't, as explained in the guides. Look at the CorruptedAreaTweaks plugin for a simple way to do it.
Once the map is completed, you can implement the logic to go back to town and start all over. The Coroutines namespace contains a coroutine you can use to create and take a portal to town. Alternatively, you can just logout, or travel back to the starting portal for the area if you store it's position. Taking the existing portal is the same as you did for taking a portal to the map, you just need to move back there to close to it.
ExampleLootItemsTask does not contain logic to do a town run when the inventory is full, but that is part of the process for learning how to work with things. You'll want to go to town, and set a flag that you need to return from the portal rather than start a new map room trip. Using the same process as explained, you should be able to find functions that do what you need already. All you have to do is tie the logic together.
You don't have to do all those parts in order either. When it comes to development, you want to find simple ways to get the basics of what you want working, then look into expanding it into one concrete implementation. Start with a map in your inventory in the map room, and start with Part 2 to get a map created and taken. The ExampleBot implementation will take care of everything else in the map area, and just stop at the end. or when the inventory is full. As long as you don't die, that should be more than enough for you to work with. There's nothing to really customize or change, aside from rewriting all the bot functionality that is being provided to users (all the stuff in Coroutines, for example, or the existing Tasks exposed).
Once you do this stuff yourself, and start learning how to use the API, things will make more sense and you'll be able to actually rewrite provided functionality to work in ways better for you, rather than what's there.
That's basically the extents of bot programming using Exilebuddy. We give you a lot of the pieces you need, you just have to use them to do what you want. If those pieces aren't enough, or aren't useful because you don't have source to modify them, then you can start from the API we provide and build up something different or open instead.
Now to what cyberbot said.
If people want to work on their own bots and not give them out, it's certainly in their right to do so. Our model is not to profit off of forcing people to dev stuff for our products and then share it. The Buddy store was added to further help incentivize people to contribute and get something in return. While EB doesn't have store support yet (as it is brand new, and being tested mostly with HB since it's the largest bot) I can certainly understand if people spend their time on this stuff and want to keep it private.
I don't know the actual status of the people trying to make a map bot, but no one that is actually trying has come to me with code that they needed help on or had issues with the current API that they needed something to be done differently. Anyone that needs help, gets it, as long as they have made an attempt and have something to show for it. If you just ask me to help write a map bot, then there's nothing I can do for you, because you're basically asking me to write a map bot for you.
The "we don't have guides or examples" argument is no longer valid. I personally made it a point of emphasis since I took over and did the beta rewrite. In fact, I was just talking about this yesterday in this reply. Trying to give users more dev resources by keeping things out of the bot itself is the main reason why BasicGrindBot is setup as oddly as it is right now.
If you need help understanding what is provided right now and how that is applicable to this topic, I can certainly clear that up for you in this reply. However, what you don't understand, is that what you're asking for is for everything to be worked out for you, because the only thing you actually need, is the specific logic that uses the API. There's no "map" example to provide that doesn't involve being a working map bot. All I can do, is tell you what you should already know or be doing to develop things with the API and programming in general.
A map bot can be thought of as 3 distinct parts:
1. Starting in town, withdrawing a map and traveling to the map room.
2. Inside the map room, activating a map and taking the portal.
3. Grinding the map itself.
Part 1
ExampleBot contains example code for what needs to be done for withdrawing and stashing. You have to add your own withdraw task that makes use of Coroutines.WithdrawItemsCoroutine (as noted). Existing tasks are provided you can use to get an idea of the task design. ExampleResurrectTask, for example, shows a really simple task that uses an API function that would be perfect to start with. For stashing, you can use the provided bot task, and implement your own logic in the user functions to not stash your maps or other things like currency if needed.
For traveling to the map room, look inside the Coroutines namespace for a provided function to help out. You want to take a waypoint to the map room, so you should be able to find something and get working. With the task based design, you'll be adding a TravelToMapRoom task that executes after your other town tasks are done. See the Task section in the BasicGrindBot Guide to follow the task flow of it for a better idea of order of operations.
Part 2
Now, you're in the map room at the waypoint. You need to interact with the Map Device to bring up the GUI for it. The Coroutines namespace provides a coroutine you can use to interact with an object. ExampleBot provides a few tasks that perform interaction, so check out ExampleLootItemsTask and ExampleOpenChestTask.
Once you have interacted with the map device, it's GUI pops up. Refer to the "Using Loki to interact with the client" section in the An Overview of Loki: Exilebuddy's API for Path of Exile to get an idea of which namespace contains the functions needed to interact with that GUI.
Likewise, you'll want to also find a section to interact with the main inventory as well. The process for starting a map is the same as you would do in game: pickup the map to the cursor, place the item into a map slot, activate the map device. The new Fast Move mechanic just added is not supported in the API because you can't control which slot the item will go in. It might be added later, but for now, it's not needed.
Once you have activated the device, you need to find the portal objects and take them. Check the Coroutines namespace for a coroutine you can use to take the closest portal. As with before, you want to make a task that executes when you're in the map room to take the portal. If you don't want to use the coroutine, you can implement one yourself by simply interacting with the found portal, after moving to it. This is the same as chest/loot stuff.
Part 3
Now, you're in the map. ExampleBot contains a lot of the code for showing how to do looting, opening chests, doors, combat, and exploring. The explore system simply runs though the area, and then exploration complete kicks in. As with the current BasicGrindBot implementation, you must add extra logic to take boss rooms or handle killing every single mob, because the CR by default doesn't, as explained in the guides. Look at the CorruptedAreaTweaks plugin for a simple way to do it.
Once the map is completed, you can implement the logic to go back to town and start all over. The Coroutines namespace contains a coroutine you can use to create and take a portal to town. Alternatively, you can just logout, or travel back to the starting portal for the area if you store it's position. Taking the existing portal is the same as you did for taking a portal to the map, you just need to move back there to close to it.
ExampleLootItemsTask does not contain logic to do a town run when the inventory is full, but that is part of the process for learning how to work with things. You'll want to go to town, and set a flag that you need to return from the portal rather than start a new map room trip. Using the same process as explained, you should be able to find functions that do what you need already. All you have to do is tie the logic together.
You don't have to do all those parts in order either. When it comes to development, you want to find simple ways to get the basics of what you want working, then look into expanding it into one concrete implementation. Start with a map in your inventory in the map room, and start with Part 2 to get a map created and taken. The ExampleBot implementation will take care of everything else in the map area, and just stop at the end. or when the inventory is full. As long as you don't die, that should be more than enough for you to work with. There's nothing to really customize or change, aside from rewriting all the bot functionality that is being provided to users (all the stuff in Coroutines, for example, or the existing Tasks exposed).
Once you do this stuff yourself, and start learning how to use the API, things will make more sense and you'll be able to actually rewrite provided functionality to work in ways better for you, rather than what's there.
That's basically the extents of bot programming using Exilebuddy. We give you a lot of the pieces you need, you just have to use them to do what you want. If those pieces aren't enough, or aren't useful because you don't have source to modify them, then you can start from the API we provide and build up something different or open instead.
darkbluefirefly
Community Developer
- Joined
- Nov 8, 2013
- Messages
- 1,927
- Reaction score
- 18
Thanks Pushedx.
I'll start working on it after I fix an issue with QuestPlugin that restarts at the town instead of instance.
I'll start working on it after I fix an issue with QuestPlugin that restarts at the town instead of instance.
pushedx, before I get into my more critical statements, I first thank you for your hard work.
I hope you get two things right.
1) It was you on multiple occasions who said you would provide a simple map example "soon". See one such occasion at https://www.thebuddyforum.com/exilebuddy-forum/exilebuddy-profiles/173808-request-plugin-maps.html
If you think providing a map bot example is not a good idea, then state as such like you have in this thread. Making empty promises is never a good idea.
2) As I said in my post in this thread, we do not need anything to be worked out and an example map bot would be a great start. Then you made the claim that writing a map bot example, an idea which was introduced by you, is the same as writing a complete map bot that works on every map. I sincerely doubt such a claim. A general map bot will probably have to deal with specific situations on each specific map type (transitions, boss name(s) and location(s)). Writing a map bot example that works for the "Crypt Map" may not work well for the "Palace Map". If an example is provided, then we users can tweak the example for specific maps.
The logic for a map bot is not difficult or it is not hard to follow your steps listed, but the difficulty is that the documentation for the API is lacking. If I am wrong on this, I will appreciate you point me to the right place for a more complete documentation at one location. The trouble for me has been finding the names of the right functions to do what I need. When so many pieces come from so many places in the provided example plugins and bots, it is not easy to learn the API, at least for me.
I hope you get two things right.
1) It was you on multiple occasions who said you would provide a simple map example "soon". See one such occasion at https://www.thebuddyforum.com/exilebuddy-forum/exilebuddy-profiles/173808-request-plugin-maps.html
If you think providing a map bot example is not a good idea, then state as such like you have in this thread. Making empty promises is never a good idea.
2) As I said in my post in this thread, we do not need anything to be worked out and an example map bot would be a great start. Then you made the claim that writing a map bot example, an idea which was introduced by you, is the same as writing a complete map bot that works on every map. I sincerely doubt such a claim. A general map bot will probably have to deal with specific situations on each specific map type (transitions, boss name(s) and location(s)). Writing a map bot example that works for the "Crypt Map" may not work well for the "Palace Map". If an example is provided, then we users can tweak the example for specific maps.
The logic for a map bot is not difficult or it is not hard to follow your steps listed, but the difficulty is that the documentation for the API is lacking. If I am wrong on this, I will appreciate you point me to the right place for a more complete documentation at one location. The trouble for me has been finding the names of the right functions to do what I need. When so many pieces come from so many places in the provided example plugins and bots, it is not easy to learn the API, at least for me.
Last edited:
darkbluefirefly
Community Developer
- Joined
- Nov 8, 2013
- Messages
- 1,927
- Reaction score
- 18
Hey dude, thanks for the critique.
Um, I have to find it, but Someone stated that Map support was on the "features" page when they bought the bot. I proved them wrong.
Map support is not even officially supported, Pushedx's work is basically done already, yet he keeps adding more support and API features, which I'm very grateful for.
Mapping is not as simple as grinding, his Simple example, I think. Meant that it would put a map into device and enter. That's it.
Once you are in portal though, things get dicy, like how many times you can travel to town, what if you die, etc.
It becomes more complicated as more things need to get done in order to support mapping.
If he did put out a simple example, no doubt people would ask for more of that "simple" example, knowing him, he will take time to do "more" then he needs to do.
I do not think you realize the scope of the problem, and there are many, many other things to work on, like Party support, hideout support, etc.
I do not know if you are aware, but Pushedx is also on Heartbuddy as well, so he's managing 2 projects.
As Far as API is concerned, I can vouch that there is ample information on how to get a working maping solution. It just takes time.
I, started about a month ago with zero knowledge on C# and EB, read Pushedx's guides, and got here today, with a working QuestPlugin. I believe there's roughly 6000 lines of code. It's not really complicated if you are willing to learn.
The API, is actually very well documented. What are you using to access it? Like its very indepth.
Isn't that how things are learned? You piece information together and use your brain to digest and use it? I for one enjoy taking bits and pieces form here and there, then making it work.
That being said and done, there's probably a reason why so many people said they are maping but nothing is being posted.
1 - It's private
2 - There are challenges, and people want to post a stable version, not one where it does a suicide map.
Hope that clears things up from my perspective.
I see the issue now. There's a misunderstanding behind what I've said and what I did compared to what you think I'm saying, and what you think I'll doing.
I'll try to clarify that now.
First, anything said on forums is subject to change. While we try our best to keep to what is said, things change. All I can do is explain the current status of things when they are brought up if what was said in the past is no longer applicable.
Here's a prime example, at that point in time, I was under the impression I'd be able to do all these things for the bot we provide as mentioned here: What lies in the future of Exilebuddy ?. However, after the numerous rewrites and the month long update for 1.2, things are now this way for the project: Exilebuddy Project Guide. All I can do is say sorry, things didn't work out the way I wanted them to.
Now for the map bot example issue. You thought I was saying I'd provide a working map bot you can just tweak for various areas, but it's complete and you don't have to do anything to actually get it running. That is not what I intended to imply when saying I'd get a map bot example provided soon. Consider my last reply fulfillment of the example, because that's all you need to have something that works with minimal amount of work. That's also as much as I can do for devs in regards to the issue. There's nothing more I can provide code wise. There's a very specific business guideline I have to adhere to when it comes to this stuff, which is the reason why our bot logic isn't open source and freely modifiable to users.
As for the API issue, there's no way for me to know what issues you are having if you don't communicate them to me. Unless I've missed a thread or a PM, I can't recall any time you've brought up API issues that I didn't address. If you're not sure about something, you only need to ask, and I'll get you pointed in the right direction.
How to Setup a Project for Exilebuddy goes over how to setup a project of Exilebuddy and covers how to access our API docs, though Visual Studio. If you're not doing this, then that's why you're having problems working with the API. EB doesn't have online docs to go through, but that might be a future possibility, but that's irrelevant to the issue at hand as very few people have ever said "online docs are a must, opposed to the seamless development experience possible in VS".
That's the biggest reason why the How to Debug Your Bot/Plugin/Routine Code In Visual Studio guide was just created a few days ago. The seamless development experience in Visual Studio is unmatched by anything else. Being able to finally do this will greatly help in development efforts.
Likewise, the guide, How to Use Code-Behind/XAML for your WPF Guis was recently added to address the impracticalities of GUI development with the current system. If it were possible to have had that in from the start, it would have been done. However, this stuff is not simple and takes a lot of time and testing to figure out the best way to work. I acknowledges that in my linked reply to WIMM.
An Overview of Loki: Exilebuddy's API for Path of Exile gives you a starting point for the API. It's two sections: interacting with the client and reading data from it. As I mentioned in my previous reply, you just find what is applicable and go from there. If you're not using VS, then the task is almost impossible since there's no way to know what's what unless you go though the provided XML docs file that VS loads.
Other than that, there's not much else that can be done differently with our setup. The API is brand new and was written over the course of a month (Aug-Sept), and then the current bot implementation was developed over a month (Sept-Oct). Everything you see now has been achived over the course of literally 2 months.
If you're trying to dev with our setup/API and are having issues, you need to communicate those issues to us, as otherwise we have no idea. Until people actually start trying things and finding shortcomings with the setup, there's no reason for us to think things need to change or the API is unclear, since we're the ones that wrote it. We have a natural bias in thinking things are clear because the way we think, isn't the way everyone else thinks. As always, if you need something feel free to ask, and we'll do our best to help, or explain why we can't help.
A complete working bot with source that users can just tweak a few things here and there is not something we can provide. We have a model to empower users with the tools to do it themselves, but it's up to them to put it together.
I'll try to clarify that now.
First, anything said on forums is subject to change. While we try our best to keep to what is said, things change. All I can do is explain the current status of things when they are brought up if what was said in the past is no longer applicable.
Here's a prime example, at that point in time, I was under the impression I'd be able to do all these things for the bot we provide as mentioned here: What lies in the future of Exilebuddy ?. However, after the numerous rewrites and the month long update for 1.2, things are now this way for the project: Exilebuddy Project Guide. All I can do is say sorry, things didn't work out the way I wanted them to.
Now for the map bot example issue. You thought I was saying I'd provide a working map bot you can just tweak for various areas, but it's complete and you don't have to do anything to actually get it running. That is not what I intended to imply when saying I'd get a map bot example provided soon. Consider my last reply fulfillment of the example, because that's all you need to have something that works with minimal amount of work. That's also as much as I can do for devs in regards to the issue. There's nothing more I can provide code wise. There's a very specific business guideline I have to adhere to when it comes to this stuff, which is the reason why our bot logic isn't open source and freely modifiable to users.
As for the API issue, there's no way for me to know what issues you are having if you don't communicate them to me. Unless I've missed a thread or a PM, I can't recall any time you've brought up API issues that I didn't address. If you're not sure about something, you only need to ask, and I'll get you pointed in the right direction.
How to Setup a Project for Exilebuddy goes over how to setup a project of Exilebuddy and covers how to access our API docs, though Visual Studio. If you're not doing this, then that's why you're having problems working with the API. EB doesn't have online docs to go through, but that might be a future possibility, but that's irrelevant to the issue at hand as very few people have ever said "online docs are a must, opposed to the seamless development experience possible in VS".
That's the biggest reason why the How to Debug Your Bot/Plugin/Routine Code In Visual Studio guide was just created a few days ago. The seamless development experience in Visual Studio is unmatched by anything else. Being able to finally do this will greatly help in development efforts.
Likewise, the guide, How to Use Code-Behind/XAML for your WPF Guis was recently added to address the impracticalities of GUI development with the current system. If it were possible to have had that in from the start, it would have been done. However, this stuff is not simple and takes a lot of time and testing to figure out the best way to work. I acknowledges that in my linked reply to WIMM.
An Overview of Loki: Exilebuddy's API for Path of Exile gives you a starting point for the API. It's two sections: interacting with the client and reading data from it. As I mentioned in my previous reply, you just find what is applicable and go from there. If you're not using VS, then the task is almost impossible since there's no way to know what's what unless you go though the provided XML docs file that VS loads.
Other than that, there's not much else that can be done differently with our setup. The API is brand new and was written over the course of a month (Aug-Sept), and then the current bot implementation was developed over a month (Sept-Oct). Everything you see now has been achived over the course of literally 2 months.
If you're trying to dev with our setup/API and are having issues, you need to communicate those issues to us, as otherwise we have no idea. Until people actually start trying things and finding shortcomings with the setup, there's no reason for us to think things need to change or the API is unclear, since we're the ones that wrote it. We have a natural bias in thinking things are clear because the way we think, isn't the way everyone else thinks. As always, if you need something feel free to ask, and we'll do our best to help, or explain why we can't help.
A complete working bot with source that users can just tweak a few things here and there is not something we can provide. We have a model to empower users with the tools to do it themselves, but it's up to them to put it together.
pushedx
The main problem is that standard Explorer sucks on maps. It usually explores 60-70% of the whole area. I have written exploration based on monster pos before standard kicks in, but it has it's own draw backs you know. If you decrease standard exploration grid cell size, will that increase the "depth" of exploration? Now the size is 23, if I understood decompiled code right.
The main problem is that standard Explorer sucks on maps. It usually explores 60-70% of the whole area. I have written exploration based on monster pos before standard kicks in, but it has it's own draw backs you know. If you decrease standard exploration grid cell size, will that increase the "depth" of exploration? Now the size is 23, if I understood decompiled code right.
I didn't use VS to access the documentation. I didn't see the debugging page until now. Thanks for that.
One of selling points of using a script language is for its lightweight. Using something as heavyweight as VS is a bit slow.
Another question about debugging: If I have modified a plugin or a bot, do I have to close EB and restart it to load the modified code? Is there a faster way to have EB reload the modified code?
You have to broaden your perspective when it comes to the problem.
Consider the following scenario: you were able to insta-kill any mob that was in the client spawn range. The question would be, using the current explorer, would you full clear the standard map without any boss areas? The answer is yes, barring latency issues where you could possibly miss mobs on the edge of spawn range. You don't have to actually visit every single cell on the map for the client to know about it, and the new explorer works the same way, but better, than the last in this regards.
Now, what is different is exploration is no longer tied to monsters, chests, items, or anything else, whereas before it was. In the old system, exploration was self-propelled by the position of those objects, which in turn created this massive system that required a ton of overhead per tick update because it had to re-calculate where the bot should go based on the current changes in exploration nodes. That created all sorts of design issues when it comes to the explorer needing to know not to update exploration nodes if the user wasn't going to be interacting with an object that otherwise would cause the bot to get stuck at the same spot and never progress (which was a well known issue). Needless to say, the old system was fundamentally flawed, and there's no way to fix it. I told Apoc even, at the time after spending months on different methods, the only way to solve all the issues was to drop the entire system and switch to something similar to what is being used now.
The new system works by greatly simplifying the problem: what if we just cover the entire map, and let other logic do their own thing in each area as needed? The only thing exploration has to keep track of then, is if it's been in a particular part of the map, which is easy enough with some simple map using the tile size the game uses (23). Now, exploration just handles literal exploration. Should exploration care where mobs are, where chests are, where items are and if the bot should be doing anything with them? No! And that's the flaw the old system had, which created unsolvable issues.
Now, you have the means to cover the entire map and process whatever you want, however you want, whenever you want, without it getting in the way like before. The new system works perfectly for any area, because it simply covers the entire map (aside from areas with islands, since exploration doesn't transition them). The only thing you could do differently, would be to use some better exploration heuristics per known area to make it explore faster to cut down on crossing the same area each time, but that's not really worth it in a game like this with random area generation.
The real issue you're pointing out, is simply the design of ExampleRoutine. As mentioned in the guides, ExampleRoutine only hands combat "around it", due to the way the game works. If you want to full clear an area, you need to either change the way the CR works to do so, or use a system like the CorruptedAreaTweaks plugin shows with storing the position of every mob, and then traveling to that position to see if there's anything left to kill. If you remember the first CR I released for this new 1.2 version, a lot of people said the backtracking that was resulting from killing all the mobs was unacceptable, so it was removed. Now, people say it doesn't "kill enough", but there's no real middle ground. You either kill as much as you can around you as you progress (which is what the current version does) or you kill everything by traveling to the exact location they are(which has the drawbacks as you mentioned).
There's no other real alternative, because the terrain is randomly generated and the game objects are dynamic. You can't pre-plan a perfect route to take, and then be able to handle combat/looting/other interactions in a way that doesn't involve back tracking or spending more time in the instance (unlike mmos with static terrain). That's why it's up to users to change things if they want it to work a certain way, there's no way we can accommodate everyone.
To answer your question, you can setup a new explorer that works however you want. You just implement it via the IExplorer interface. Then, you can set: AreaStateCache.DisableDefaultExplorer = true in Start before it's used for anything else. You then need to assign AreaStateCache.Current.Explorer your own explorer instance each time it is null for each new area. This is because all our code uses AreaStateCache as a commonly used systems class for the bot. If you write your own bot, you'd not want to rely on AreaStateCache, and make one yourself so you have full control over everything. You can't change the grid size for ours though, because it's specific to the way the game is setup. There's no need to change the way ours is setup though. The issue isn't exploration now, because exploration doesn't handle combat anymore, and neither does the bot itself.
Hopefully that makes more sense. I've explained this each time as it comes up as best as possible, but I don't have links handy to all the previous replies. Basically, if you want more combat coverage, you just have to add in a system to add those points, and travel to them so the CR kicks in. You don't have to do it for all mobs. You can do it for mob packs instead. The new design is setup so your in control now, and have the freedom to tweak it how you need to, as opposed to us forcing you to use our one way.
EB doesn't have a profile system, so that's why C#/VS is required. In most of the other bots, you don't actually code new stuff in (unless you're trying to setup something entirely new), but rather develop content though XML profiles, taking advantage of what's already exposed. However, the other games are mostly MMOs, or games that have enough static data to make the profile design work fine. Apoc started EB, and based on his experiences with WoW, D3, and most of the other bots, decided profiles would not be viable for EB, so we never had a system in place for them. See this thread. As I mentioned in another recent reply, I would like to find a way to make this possible so users can develop content rather than code, but it's an on going process that will take some time.
Quite a few versions ago, pre 1.2, I updated the Python support we have via IronPython. You can develop new things via Python if you want, but you're looking at building up a whole new base set of functionality compatible with Python that doesn't translate 1:1 with C#. In a recent update, I exposed more of the Python bindings we have so users actually have more control over being able to use Python to handle dynamic execution a lot easier. The reasoning behind that was so I can look into fixing issues with the complexities of CR design using dynamic Python code execution, which is what the other bots do for profiles. That allows you to change code as it's running, without the issues of trying to do it via C#/.Net, in which it's a lot more complicated. ExamplePlugin contains that code you can look at right now. Just enable it and check out its Settings tab.
If you make changes to your code, you do have to restart the bot to reload it. This is because we dynamically load, compile, and execute user code, which is only possible that way. Support for unloading existing code and reloading it is not enabled due to the way .Net works. It's possible, but it's really hit and miss, and can cause issues so it's not worth having that enabled anymore. This is just typical for development using compiled languages. Each time I work on the bot itself, I have to recompile and re-run. You just get used to the model, because that's just how it works.
The Exilebuddy Developer's Guide to Writing Bots goes over a practical example of writing a bot that you can reload it's code on demand. Trying to develop a bot that you can change and reload any part seems like a nice thing, but in the end, it gets in your way unless you have a really good design otherwise. The CodeDOM model is great for testing little things, and translate 1:1 with the code you write for the bot. That's why the Dev tab was added, see The "Dev" Tab: Runtime Development Using CodeDOM if you haven't already. It's very useful and helps speed up a lot of testing.
I don't really want to get into the whole scripted vs compiled debate though. Both have their pros and cons, but for what we're doing, having a base setup in C# is what's best for us. The new Beta is setup so users can do things their own way though, they just have to handle the C# to their language of choice bindings. If you want to use Lua, you certainly could with a bit of extra work. IronPython has a strong .Net compatibility by design, so that's why it's used instead.
Nice!
pushedx
I know I can implement my own Explorer, but standard is just fine. It's only flaw is big grid cells. Good example is The Docks, where bot usually skips the end of piers, but thats the place where desired rare packs are.
You told 23 is a standard tile size, but anyway, exploration grid is imaginary, will something bad happen if you reduce cell size? Will it lead to high-quality exploration because bot will be forced to visit more smaller cells or I am wrong? If you don't have time to experiment with that, you can give public API to Explorer.
Another question is how the logic behind marking the cell as visited works? Bot should visit any position in the cell (so the borders and corners are fine) or it should visit the center?
Giving monster caching logic to combat routine is not the case because it leads to a very long combat task, bot will skip a lot of items. You need to tweak loot item task then, or even merge it with combat.
And all that things are just not needed. Its a step back. Current exploration logic is good. I really like it. The only problem is too big cells.
I know I can implement my own Explorer, but standard is just fine. It's only flaw is big grid cells. Good example is The Docks, where bot usually skips the end of piers, but thats the place where desired rare packs are.
You told 23 is a standard tile size, but anyway, exploration grid is imaginary, will something bad happen if you reduce cell size? Will it lead to high-quality exploration because bot will be forced to visit more smaller cells or I am wrong? If you don't have time to experiment with that, you can give public API to Explorer.
Another question is how the logic behind marking the cell as visited works? Bot should visit any position in the cell (so the borders and corners are fine) or it should visit the center?
Giving monster caching logic to combat routine is not the case because it leads to a very long combat task, bot will skip a lot of items. You need to tweak loot item task then, or even merge it with combat.
And all that things are just not needed. Its a step back. Current exploration logic is good. I really like it. The only problem is too big cells.
Last edited:
You're still missing the point I was making, but if you want to try and solve the problem though exploration, you certainly can, but it's not the appropriate way to do it.
In terms of using a number smaller than 23, the negative effect will be significantly more memory used for exploration, specifically in the larger areas, and the exploration process backtracking over known nodes to achieve more coverage since the tiles are now smaller, and the exploration vision is too.
Consider a map that is 111 C x 81 R, which was just a random instance of The Riverways. The actual map size is 111*23, 81*23, or 2553 x 1863. Let's say you use a cell size of 12 instead. You now have 213 x 156 nodes to process. Exploration slows down considerably, and any pre-processing tasks now take place in a much larger problem space due to the extra nodes.
You can't modify our GridExplorer to change the grid size or the exploration vision range though. You'll need to make your own grid explorer with virtual nodes, and implement your vision range the way you want if you want a system that is designed around using exploration as the means to trigger game interactions. Our GridExplorer is setup to avoid doing that, because I've found it's not the best way to handle the problem as I previously explained.
You're free to try to solve it that way though if you think it's better, but you'll have to do it though your explorer code.
darkbluefirefly
Community Developer
- Joined
- Nov 8, 2013
- Messages
- 1,927
- Reaction score
- 18
I've been reading, and still do not get it. Why would you want to use or remake explorer, its pretty efficient now. Even if you wanted it to be more efficient than it already is, you would get marginal gains. One minute less per map? Over a 24 hour period gives you how many hours would you have to spend to get something working, more optimized, vs how much you would gain for that X amount time saved per map?
Imho, it's not worth it. And reading through pushedx's logic for making a workable map plugin, that's exactly what I planed in my head before tackling this problem.
I like a KISS approach, get something working, then modify it for optimization.
Let me get at this problem and see what has to be overcome.
naut
Community Developer
- Joined
- Feb 9, 2012
- Messages
- 277
- Reaction score
- 21
Honestly I agree with darkblue... from the sounds of things you are basically saying you want to recode the entire exploration portion of the bot so you can avoid missing a few trash mobs per map.....why?
You need to realise that actually taking the time to kill 100% of the mobs in any zone rather then just completing exploration and creating a new one is going to result in your bot actually being less efficient in terms of items per hour, which is the only thing that matters when you are botting.
So basically you will waste hours if not days of your life coding new exploration logic, only to be incredibly dissapointed with your results.
As for you.. either learn to write a map plugin yourself or keep your complains to yourself and patiently wait like everyone else.
Demanding is only going to result in the plugin not being publically released when it is finished.
You need to realise that actually taking the time to kill 100% of the mobs in any zone rather then just completing exploration and creating a new one is going to result in your bot actually being less efficient in terms of items per hour, which is the only thing that matters when you are botting.
So basically you will waste hours if not days of your life coding new exploration logic, only to be incredibly dissapointed with your results.
As for you.. either learn to write a map plugin yourself or keep your complains to yourself and patiently wait like everyone else.
Demanding is only going to result in the plugin not being publically released when it is finished.
Last edited: