I understand your concerns. The API for RB is excellent; there are hardly any bugs, it's clean, and the naming convention used makes most things self-explanatory. The only problem I found was the lack of documentation in regards to RB's internal architecture. Some things might be obvious for people who have had experience programming bots in the past, but for other programmers whose past work has had little to do with injection or behavior trees it can get rough. Programmers usually learn stuff fast, but there has to be a source to learn it. When I started I felt overwhelmed by the amount of questions that I had. Things like:
Was game data cached each tick? Is it correct to send multiple actions to the game on a single tick? Can I sleep the thread, or make an external thread for a task? In what order are the different hooks on the tree called? Where should I hook this if I want it to be called above combat logic? Must a bot base create a navigator? What is the effect of returning a RunStatus.Running? What do I need to consider when I extend a tag or a composite?
You are right that the way I learned was through looking at other people's code and a lot of trial and error. I have two problems with this though:
1. Many people did bad stuff in their code, and since that's where we learn from, we end up repeating the bad stuff. Like you said, stopping the tree is done a lot, from FateAutoLeveler to Atma Hunter. They sleep the thread outside of coroutines, etc. Then someone new comes around and thinks doing that is fine.
2. Good programmers would learn very quickly how to do stuff without needing to see other people’s full work if there were good documentation and a few good examples. Someone who has experience programming doesn't need to be told that fate info is on FateManager and inventory data is on InventoryManager, they just need to know that game data is separated by managers, and a few technical details like: Is the data cached for the entire tick? i.e. if I read a slot on inventory, move the item to another slot, then read it again on the same tick, will it reflect the change or won't until the next tick?" Once someone knows how to send actions and read data from the game, the rest is up to him.
Rebornbuddy was the first time I programmed something as a hobby that ended up being shared with others, everything else had been for work or personal use. It was a new experience, and it felt good to see people's posts about how useful what you've made is and how grateful they are. What I made, I made it because I needed it for myself, and thought sharing it would be easy. But after a while, things started to feel like an actual job with the amount of customer service you end up giving. I'm of the mindset that the only way I'd give customer service to people is if, in fact, they are my customers.
I am done leveling every crafting class to 50, why should I worry about supporting anything other than endgame crafting now? I can self-repair everything, why should I care about supporting something that repairs with menders? You'd prefer a GUI instead of Yaml/Json/Xml files cause they can be complicated to edit? Well they aren't for me. After a while, the drive to add the features that people wanted, or fix problems specific to other people's circumstances starts to dwindle. I'm at a point where I'll just do the stuff I want to do, like the crafting AI, for myself. I'll probably only share it with people who have helped me in some way, also made something for the community, or are one of the three people kind enough to have donated.
It might sound selfish, but if you're not going to seed the torrent and only leech, then don't expect the seeders to go out of their way to help you either.
