Is there anyway we can get a download link to the first update you did this morning? Everything was running fine then in terms of plugin support. I'm not sure how longs its going to take people to update these plugins and i myself am not knowledgable enough to do it myself. I'd gladly pay a dev to update them but a donation alone from me isnt going to spark up any motivation.
From what I've seen in some logs people were touching functions like reloadassemblies, and i looked at there context they were using it and it was just wrong. There really wasn't a clear indication it shouldn't have been used, but if anyone had taken the time to use reflection to look at the functions they'd realize that it didn't do what they wanted (or in some cases it didnt do anything at all) To be honest the function should have never been exposed , but a lot of the *manager code was when the bot just came out and I was in a hurry to get something working and didn't really take the time to make sure functions were properly internalized. I'll try to do better in the future but there's no use crying over spilled milk now. That's literally one of the only acceptable places for it. Calling it from a plugin to change botbases is also the only other place that i'd support it, but doing this is tricky because people assume code after a treeroot.stop will run, but thats not the always the case, you'll need to do treeroot.stop and then listen for the botstopped event to make the change and then restart it.
No. Previous versions are not supported. Especially when there was an offset change like there was today.
Underestimated the scale of how many plugins were using the wrong inheritance. Rolling that change back for now but there is still going to be a ton of broken plugins because the authors failed to ever implement the iequality requirement and left it to contain an exception being thrown (which is why botplugin should be used instead as it handles that requirement amongst others for you.).
Seriously?? In what world are you supposed to code to an API's abstract classes instead of the interface? Usually that's what an interface is for...
What? Perhaps you should give this a read: https://msdn.microsoft.com/en-us/library/scsyfw1d(v=vs.71).aspx BotPlugin inherits the IBotPlugin interface and implements the code for the iequality operations along with a few other helpers. Aka doing exactly what should be done. It was my mistake to expose the ibotplugin interface to be public instead of internal, but the main example QuestDevTools has been using BotPlugin since its release.
Maybe you should go back and read that thread again too: Let me just point out something for ya... That's directly from your link. Are you trying to say that 2 different plugins are closely related? Agil is closely related to GourmetGuy? RePear is closely related FateTeleporter? Plugins really should be Interfaces. Is the Equality method really the only reason you're trying to put it into an abstract class? If so, that's a pretty sore excuse for a reason.
I couldn't use the latest rebornbuddy after the latest update, some error windows saying "not support" popped up after entering the key session
Abstract classes may also provide members that have already been implemented. Therefore, you can ensure a certain amount of identical functionality with an abstract class, but cannot with an interface. If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members. Ie equality, and insuring that initialization only takes place once, etc. But really it doesn't matter. The interface shouldn't have been made public end of discussion.
I still think it's crap that the only "common, implemented functionality" is the IEquatable. To me, that says you should really just move that functionality elsewhere, but what do I know...Mastahg the god of code has spoken so now we all get to just deal with it. In effort to just "deal" with it: Will you also be removing any other interfaces? There's the entire ff14bot.Interfaces Namespace...should we not be using anything out of there either? Documentation Page on RB Interfaces Can you provide us with a list of interfaces/abstract classes that we should/should not be using?
Me too, the bot starts the first time, crash after a couple of minute and then he won't starts again, i need to close the process manually or reboot the pc.
Version 275 Code: Tweak threadshutdown logic slightly Fatebot will now longer die if stop gets called twice. RoutineManager.PickRoutineFired event has been added. -This is called at the top of pickroutine so adding an event handler here will make it very easy for plugins to set the PreferedRoutine string. Mainwindow bot selector now changes if selected botbase is changed via a plugin.
Version 276 Code: Startup speed should be faster now Buddyauth logout call during program close has been shifted. Bug fixes: Don't prompt for combat routine selection twice during startup Part of the ongoing internal code cleanup questdevtools and rebornconsole now no longer use thread.Abort() and instead invoke the form close handler. Rebornconsoles hotkey system has been also hooked up so you can execute the current codechunk without having to activate the window manually.
Form buttons don't appear to be working properly now (Combat Settings is grayed out, Settings for RebornConsole is grayed out, etc.).
Since my accounts were hit by the ban hammer I'm starting to play this game, just to point out that since I'm new to this area of honorbuddy, the thread is a little confusing. Its called Thread: [Release] RebornBuddy Version 1.0.267 but when I downloaded it from Buddy Updates it had a different version number. You should update this thread to version 1.0.278.0 so in case others wont get confused as well.
The thread title is updated when there is a release with new functionality. For minor releases like single bug fixes the thread is not updated because it would be unnecessary.
Version 279 Code: Some logging output has been added to a few orderbot tags. Api: New function that will make quest profile developers lives easier: IsTodoChecked(int questId, int step, int objectiveIndex) /// <summary>Checks if the quest step has progressed past the provided step or that the objective at the given index has been completed. </summary> /// <param name="questId">global quest id</param> /// <param name="step"></param> /// <param name="objectiveIndex">Starts at 0</param> /// <returns>true if objective is completed.</returns> This lowers the entry to making quest profiles easier as now directly accessing the quest variables should not be needed for most cases. QuestLogManager.Quests() is now deprecated, use QuestLogManager.ActiveQuests instead. Next Version(s): Treeroot.Stop(bool,string) will be removed next version, and replaced with two functions, one for stopping the bot from within the botthread and one for gently stopping and waiting from another thread. The "gentle" function will be the 'proper' way to stop the bot, switch botbases and then restart the bot. I'll provide sample code for properly doing this once the next version is released. Also, next version use of Quest's RawId will no longer be supported as this will hinder the implementation of support for leves. I haven't seen any profiles use anything other then the globalId so I don't think this will be an issue. GaiaNavigator.CanFullyNavigateTo will probably be changed to be an async function so that the game client will not lockup during its use.
