• Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Exilebuddy Release Thread (Forsaken Masters)

    Discussion in 'Archives' started by pushedx, Sep 26, 2014.

    Thread Status:
    Not open for further replies.
    1. pushedx

      pushedx Moderator Moderator Buddy Core Dev

      Joined:
      Sep 24, 2013
      Messages:
      4,252
      Likes Received:
      290
      Trophy Points:
      83
      Welcome to the Exilebuddy Release thread for Forsaken Masters!

      Please start with the Support F.A.Q.. All support issues should go in the Support Forum.

      All current guides for Exilebuddy are now in the Exilebuddy Guides section.

      If you're new to Exilebuddy, it is highly recommend you read over the posted guides and stickies multiple times before diving into Exilebuddy. For existing users who have been following the Beta, the guides and stickies contain some additional information that is worth checking over again.

      This release marks a final "stable" version of Exilebuddy for Forsaken Masters. There are no more large rewrites, or huge changes planned. Exilebuddy is now in a maintenance mode, and will be updated accordingly based on game changes.

      Download links can be found in the "Beta vs Release" section of the Exilebuddy Project Guide, so be sure to read that over first.

      Versions

      Release

      #81 (Poe 1.2.4.12)
      • Beta #965.

      #80 (Poe 1.2.4.12)
      • Beta #960 - #964.

      #79 (Poe 1.2.4.10)
      • Beta #959.

      You need to register and have one post to see spoilers!
      Beta

      #965
      • Login functionality fixed. It broke due to the unannounced patch that added the countdown timer.
      • VendorItem.CanAfford is no longer exposed due to not working anymore.
      • ParseVendorCostFromTextCollation (used by PurchasePanel) updated to parse the new format of item tooltips in the client.
      • WithdrawTask updated to support withdrawing: Alch, Chaos, Chance, Alts, Augments, Scour, Transmutation, and Vaal.
      • WithdrawTask will now use BasicGrindBotSettings.MaxWithdrawTabs to limit how many tabs are searched to withdraw from. This is to avoid unnecessary stash traversal when trying to withdraw currency items.
      • BasicGrindBot's ShouldStashItem function now checks for the new currency items that are able to be withdrawn so they are not stashed.
      • Options to withdraw the new currency types have been added to main gui. This allows devs to develop logic for chancing items or rolling strongboxes without the bot's stashing functions from getting in the way.
      • ExampleRoutineSettings.EnableAurasFromItems added. This allows users to disable the new support for using auras from corrupted items introduced not too long ago.

      #964
      • Updates for poe-1.2.4.12.
      • BaseComponent layout updated so IsCorrupted is now correct.
      • StashPanel.CurrentTabItems and GuildStashPanel.CurrentTabItems are now internal to avoid issues with the items they return not containing location data. Please use "CurrentTabInventory" to get the Inventory of the current tab, which then contains a list of Items.
      • GuildStashPanel.CurrentTab, PurchasePanel.CurrentTab, and StashPanel.CurrentTab have been renamed to CurrentTabName to avoid confusion with the types of other API functions.

      #963
      • WithdrawItemsCoroutine now calls the user's shouldContinue function after shouldWithdrawFromTab returns false, and before the next tab is processed. This allows users to limit how many tabs get processed.
      • The ChaosChanceRecipe has been updated to take advantage of the previous change. A new constant, MaxTabs is now used to determine how many tabs are checked. Since there are now settings or GUI for that plugin at this time, users must modify the code to change the tabs checked, and then re-apply those changes after updates.
      • Tools GUI on MainWindow now catches exceptions from tools to prevent the main gui from bricking.
      • Fixed a bug where DnD logic would fail if the passive reset overlay was showing.
      • StashPanel.FastMove now supports fast moving from a remove-only tab.
      • Added support for launching the PoE client (uses -noupdate to prevent client updates). Steam is not currently supported or tested.
      • LoginSettings.ClientPath added to store the client path for the Path of Exile exe to launch with 'autolaunch'.
      • Using the commandline argument 'exe', users can set the client to launch. This argument will set the LoginSettings.ClientPath property. For example, ExilebuddyBETA.exe --exe:"Y:\Path of Exile\PathOfExile.exe"
      • Using the commandline argument 'autolaunch', the bot will launch the PoE client and auto-attach. For example, ExilebuddyBETA.exe --autolaunch
      • The behavior of launching the client is as follows:
        • The bot will start the game process and wait for it to fully load before auto-attaching.
        • If the "Error" message box for too many clients is shown, the bot will kill the client and close.
        • The bot will be able to launch clients from network paths, e.g., "\\SOME-PC\Path of Exile\PathOfExile.exe", as long as you have proper permissions.

      #962
      • StashTask, SellTask, and IdTask now reset their attempt counters to prevent the bot from stopping from intentional multiple runs for stashing, selling, or iding. Before, the bot would only reset the counters upon an area change, since only one process of stashing and selling would be performed.

      #961
      • Added a new logging implementation with log4net that supports multiple loggers. This allows devs to have their own logging instances to make their life easier. The design has also been updated to not require gui initialization unlike before.
      • ScriptManager updated to take an ILog for support with the new logging system as well as a custom AppDomain.
      • ScriptManagerIoproxy -> ScriptManager.IoProxy.
      • ExamplePlugin updated with support for a custom logger that logs to its own GUI.

      #960
      • The GridExplorer type is now public, instead of internal.

      #959
      • OverwordAreaTweaks updated to fix a compile error introduced in the #958.

      You need to register and have one post to see spoilers!
       
      Last edited: Dec 1, 2014
    2. Hawker

      Hawker Well-Known Member Buddy Core Dev

      Joined:
      Jan 15, 2010
      Messages:
      2,509
      Likes Received:
      70
      Trophy Points:
      48
      We have added 30 days to all keys bought since August 20 when Forsaken Masters hit.
       
    3. pushedx

      pushedx Moderator Moderator Buddy Core Dev

      Joined:
      Sep 24, 2013
      Messages:
      4,252
      Likes Received:
      290
      Trophy Points:
      83
      Support for Do Not Disturb has been added in Beta #946 (and will be enabled in Release #75).

      The default setting, AutoDoNotDisturb, under Settings -> BasicGrindBot is disabled by default. Users should enable this setting if they are getting spammed with invites, to prevent any bot issues from the invite dialog taking up large portions of the right side of the screen.

      Under certain scenarios, the popup's accept button will appear over the position where the bot is about to click to perform an action, such as id'ing an item, or moving one to stash. The bot does not poll for these popups because it's very time consuming to check though all GUI dialogs trying to find such a popup. As a result, the best way to avoid this "invite harassment", is to enable the client's DnD setting, which was added specifically for this reason (i.e., people streaming the game would get spammed endlessly before it was added).

      As a reminder, the bot performs actions in this game the same way a human would, so that's why this issue is even an issue. The bot does not use fixed coordinates for anything, and tries to check the current client state before doing anything, but due to the GUI design of this game, certain issues like these are unavoidable. If the bot were to simply deny each invite as they popped up, you'd be spamming a lot of packets to the server (as would the person sending the invites, but they could do that from a throw-away account) If the bot simply ignored them, and did nothing while they were active, then the bot would be blocked from executing by someone who simply invited over and over. As a result, the best way to handle this is to either use DnD, or babysit your bot, taking manual action if you're getting spammed.
       
    Thread Status:
    Not open for further replies.

    Share This Page