Ehy mastahg (Or somebody who understand of this stuff) is possible to let bot avoid to attack normal mobs after a fate pls? it makes me lose a lot of experience...รน+ Ty in advance...
Version 264 Code: Bug fixes: Current target is now cleared when we set the poi to a gameobject. This prevents some issues where we have a target that isn't what we are looking for anymore. Taken fate will now be handled properly
Enemy of my enemy now starts automatically when its up, then it will spawn enmity of my enemy. One problem I have found, however, is that if you fail enmity of my enemy and it continues waiting it will not loop back to initiate enemy of my enemy again. Is there anything that can be done to make this happen? If there aren't enough ppl here to do it there is high risk of failing so a loop to start pre req fate would be nice if it won't break anything
Version 267 Code: RoutineManager,BotManager and PluginManager have all been rewritten. -Using the Reload*OnFileChange settings in GlobalSettings.json should actually work now -You can now start rebornbuddy with the command line option of -customclass=ccname -You can now specify which combat routine to use when switching classes by setting RoutineManager.PreferedRoutine to name of the routine you wish to use(this is also set by setting the startup option) -Plugins list in the main window will now update when plugins are disabled via code Orderbot,PvpBot,Gathering Bot,Grinding Bot,Fishing bot,Fatebot will now close any opened trade windows and blacklist the other player. -This can be disabled via the settings menu. Combat Assist: Root composite is now cleared on botstop. QuestDevTools: Updated to run in another thread, this is the 'proper' thing to do when displaying a window that remains open unlike a simple settings window. Bug fixes: ChatManager.SendChat now properly handles sending chat messages that are not standard latin. LoadFile dialog has been changed to use the wpf reference version, this should fix issues where uses with .net 4.5.2 installed couldn't load profiles. UseItemTag will now properly shortcircuit if the target has disappeared. Should be no longer possible to accidentally click the start/stop button more then once in a short period of time. Stopping the bot via the stop button in the ui is now much more gentle. -Now certain cleanup actions are run on the bot thread. -This logic is likely to be extended to TreeRoot.Stop, and the function signature will change in upcoming versions. -- Any developers using this should [s]stop being bad[/s] start thinking of alternatives.
When i click ok on the RB key box upon starting the bot, the bot just never pops up, but it shows a session as active. Getting this on multiple computers
[16:20:43.047 N] Logging in... [16:20:43.185 N] T: 5247356462857978932 H: 3515552168 [16:20:43.624 D] Microsoft Windows NT 6.2.9200.0 [16:20:47.223 D] Current Locale Eng [16:20:47.224 N] Currently a level 50 Botanist [16:20:47.229 D] Reloading AssemblyLoader<ff14bot.AClasses.BotBase> - Initializing Got two working, going to try turning the one that isnt working off and on again and see if it works~! Will post update It didnt fix it, all the logs end at the one line it shows there, [16:20:47.229 D] Reloading AssemblyLoader<ff14bot.AClasses.BotBase> - Initializing So whatever is the issue, it just isnt going past that point upon loading up. I'm just gonna leave it sit for about 20 minutes and see if it ever does anything
Version 271 Code: Since It looks like a lot of plugins broke, better off doing some other changes I was holding off on. IBotPlugin wasn't really meant to be used, but rather the abstract class BotPlugin. IBotPlugin has now been removed. Plugins must now inherit from ff14bot.AClasses.BotPlugin
Was there ever any discussion or guidance that IBotPlugin was deprecated? It's not exactly easy to develop with no actual documentation other than the class structures, and then to just remove the interface that most of the plugins depend on is a good way to quickly alienate your dwindling developer community. It's good to keep in mind that most of the people adding code or writing plugins are not part of the RB team, but hobbyists contributing some of their spare time to the community. They're not being compensated for their work other than a pat on the back and the occasional meager donation.
The only documentation that I have time to provide is the open source samples included in the releases. I consider QuestDevTools to be the example that people should base their work off. Switching from IBotPlugin to BotPlugin will require almost no work at all. If your having a hard time, stop using notepad, go and install the free version of visual studio, and follow the guide in the dev section. Intellisense will reveal the functions that are interesting to you. 99% of everything is named in a manner that you should be able to figure out what the function does.
I understand the API has to get cleaned. What I'd appreciate is a warning beforehand when doing breaking changes. What's next? I'd really like to know if there's going to be some major overhauls to the API come Heavensward that we have to prepare for, and what they are. Next thing you know, you no longer gather stuff by using the GatheringItem.GatherItem() method and it's now on the window itself or whatever and our future projects break.
I've been working on these changes since before the last release, I didn't think the changes today to the *managers would have broken anything. But it looks like there's a bunch of stuff out there touching functions they should have been no where near. So while stuff was already broken I decided to go in and cleanup stuff. As long as its not a change to abstract classes you really shouldn't have to worry. As for heavensward I am considering making plugins have a new func that is async so you can just write coroutine code inside of your plugin without having to use hooks. I don't think this will break anything tho. If you want a heads up here it is again: Treeroot.Stop() stop using it now, its functionality is going to be changing soon.
I think most people would prefer that their code isn't broken before refactoring from an interface to an abstract class regardless of the effort involved and that's not considering the plugins that aren't being actively maintained. When I type : BotPl I would know that one of the two are deprecated, I'd most likely choose the non-deprecated one by reading intellisense. It's not too much to ask that in the future you add [Obsolete("IBotPlugin is deprecated use BotPlugin instead")], commenting and being transparent would make it a lot easier to refactor code in the future without the blowback that usually comes with it. Again I have to ask, how are people supposed to know that they should be no where near those functions other than the code breaking?
Just a question though, if TreeRoot.Stop() is going to be unusable, what would be the correct way to stop the bot? I mean, when there's a legit reason to stop it from a bot base.
