search

29988122 / Fate-Grand-Order_Lua

Fate Grand Order auto battle script - no root needed, for Android use only
MIT License
290 stars 95 forks source link

Future of the script #114

Open TryBane opened 5 years ago

TryBane commented 5 years ago

I have been looking over the script and the Ankalua API a bit more in depth now that my schedule isn't as hectic as it was a few months ago. I think I can do an overhaul of the base script to allow for better scalability. I would move the psuedo-functional programming style to a more pure functional programming style rather than what we have now which is a procedural programming style with functional elements.

If this sounds too pretentious I understand as many have been working on this for a while and added some amazingly awesome features. But as the code base grows, the more complex and convoluted it becomes without a more solid foundation. I'm offering to rewrite the base code to be much more flexible and more error proof. Such as closing windows that were unintentionally opened. However, this will require help from many of you as I only have access to testing this with NA servers.

Once I have a working prototype, I can share it here for others to test with the other servers. What does everyone working on the code think?

TryBane commented 5 years ago

For the record, some things I plan to include will be resolution scaling for different devices, better modularity for easier additions, and easier configuration for the user.

potchy commented 5 years ago

Sure, I believe @ryuga93 is working on moving AutoSkill to a separate module.

I'm also trying to improve code clarity in battleLogic.lua, but I didn't push anything yet because I'm not sure if I broke something in the process. lol

I've changed a lot of things though, so I advise you not to go ham on it yet.

TryBane commented 5 years ago

Ah, I see what you mean. I do think that separate scripts will help compartmentalize the workings to make it easier to make adjustments, but I was planning a complete rewrite from scratch. I'll at least get to work to keep the same functionality it has now without adding too many new features like error checking and such. For now, I'll just get it running so that it can do card selection. Maybe Autoskill.

anubi commented 5 years ago

While I've never contributed to the code (mostly because I saw the future of ankulua being bleak with latest android version pretty much killing it?), I think what you're saying makes some amount of sense. The current design of the code is very "waterfall" and won't scale once enough complexity is introduced. I'm eager to see what is created in the future iteration.

The more functional it's made in the future, the easier it is for people to contribute small enhancements without breaking anything.

If it's designed more like an API, I could even see a "wizard" being dreamed up for it. Let people construct routines without needing to write anything themselves. Though, that's a lot of work just to make it more "mainstream" (which has the drawback of drawing more attention to it from DW)

potchy commented 5 years ago

From my experience, the biggest problem of the current code is that there are many "state" variables that don't make much sense at first glance, like decodeSkill_NPCasting or CleartoSpamNP.

Because everything is crammed in regular.lua without much context, you need to jump through the code many times to understand what they mean and what functions use them.

That said, I firmly believe separating concerns in different modules will help with scalability. That's the first step. I'll probably push my changes by the end of this week.

TryBane commented 5 years ago

Yeah, I know what you mean. Modules is along the same lines as what I mentioned with modularity. As we can freely add and remove certain elements of the script without worrying about ruining the running altogether. I'll do some work, and incorporate it into what you've worked on so far after you push the changes you've made.

This script is the only reason I've been farming so well during Christmas, so I thank you guys from the bottom of my heart!

29988122 commented 5 years ago

@anubi @TryBane @pokeguys @TheIanator Thank you guys for trying to help us! Very much appreciated. As a side note - all the messy code were written by 2016 me.. : (

How'd you evaluate other android UI interactive/scripting framework?

I mean, maintaining the compatibility of an Android scripting framework required TREMENDOUS amount of work, and Ankulua did that pretty well. Not to mention that the author of Ankulua personally helped me & this project a lot.

However, I always think that, maybe, just maybe, Ankulua prevent more people from using our script. ($50 lifetime IRRC, I was using contributor's lincense xD) There were already >10 people online and in reallife telling me this.

https://github.com/29988122/Fate-Grand-Order_Lua/issues/75#issuecomment-431590889 As pokeguy mentioned in this thread, he's considering running heavy-duty task on localhost, and make it communicate with our Android emulator/LAN android device. This could be one of our future paradigm. (FYI: I have no idea what I'm talking about, as I'm just a mere CS infosec MS student - heck, I did not code for more than 1000 line my entire acadamic life.)

If done well, we could even implement some card-selection logic based on machine learning(some would say it's overkill, but I guess that'd make this game more n00b/非洲人 friendly.)

Let me summarize our discussion a little bit:

  1. Basic refactoring is definitely needed. @ryuga93 and @potchy are doing it now.

  2. How should we improve our screen recognition "strategy"? Should we offload this task to outside Android. other libraries? Botting but unable to read memory is destinied to be slow, unless we try some more powerful way to gather screen data. Somebody suggessted automation testing framework(just like this pokemon go map implementation https://github.com/mizu-github/PGSS) Look at this monster...It was using Xcode ui debugging to catch data, now changed to tesseract.

  3. How should we improve our card selection strategy? As mentioned, ML/supervised learning could be implemented, eliminated the need of writing combat strategy manually.

  4. Proper logging feature for us to debug in the future. See if this lib suitable for us. http://neopallium.github.io/lualogging/manual.html

  5. Please list out more issue critical to software development. I know nothing.

These are mid-long term goals, apparently. So, in no hurry.

Anyway, thank you guys, my fellow hardcore TM fans!

potchy commented 5 years ago

Oh, we definitely need to think of naming conventions, seriously. In Lua, I'm never sure of when to use camel or pascal casing, for example.

If done well, we could even implement some card-selection logic based on machine learning(some would say it's overkill, but I guess that'd make this game more n00b/非洲人 friendly.)

I have no idea how to do that

TryBane commented 5 years ago

I almost always use camel case. But we should just pick one and stick to it. It doesn't matter ultimately which we choose, so long as it is consistent.

Also @29988122 I know you aren't experienced with programming, as I've seen you mention it many times in other threads criticizing your own coding. But it is fine! We aren't here to judge you, we are here to help!

And I don't know how to implement machine learning, nor do I feel it is entirely necessary. Personally, I was just going to keep the current suggested option of the user providing a priority and then we just find them and use them. We can also implement an ability to prioritize cards with stars too.

As for screen recognition "strategy", I was going to rely more heavily on image identification over wait times. But I was going to remove the hardcoded numbers you originally implemented and find the zones to search based on the device used.

I was also going to implement a hierarchy for naming conventions regarding the actual content of the names in question. Such as BattleScreen_IsUp, BattleScreen_EnemyServant, BattleScreen_EnemyDanger, BattleScreen_CardSelection, etc.

@potchy Also, it seems that you implemented some sort of transparency with the MLB option for CEs, can you get that to work using the "Battle Speed" button in the Card Selection screen? That is the best option I think for determining when the card selection screen is up. Either that, or we just check to see if ANY of the 3 card types are up on the screen.

29988122 commented 5 years ago

Trybane

Agree on the style thing. Also thanks for the kind words! By the way do you use tab or space to indent? XD

potchy

I've personally read a little bit, took a class(HMM, Hidden Markov Model, a simple one). http://www.r2d3.us/visual-intro-to-machine-learning-part-1/ https://towardsdatascience.com/building-a-deep-neural-network-to-play-fifa-18-dce54d45e675 An NES example: https://www.youtube.com/watch?v=xOCurBYI_gY&feature=youtu.be

So yeah, it's a mid-long term goal, just feel the need to list that out clearly (even only for reference), cause reading @pokeguys 's article reminded me that. https://github.com/29988122/Fate-Grand-Order_Lua/issues/75

TryBane commented 5 years ago

@29988122 Tab, ALWAYS tab. I was getting screwy when I saw it was mixed in the script and was like scratching myself. OCD can be a bit of a pain, but tab became ingrained from lower level programming for me.

29988122 commented 5 years ago

So, waiting for potchy's commit, then trybane can do his work based on it? ryuga's dealing with autoskill now btw. (If I recall correctly.)

TryBane

https://github.com/29988122/Fate-Grand-Order_Lua/issues/113#issuecomment-443944663 This, and the following discussion in this thread is what @TryBane proposed to change. I'd be more than willing to grant you contributor status, but I... guess? it's better to draft a PR than commit by oneself in order to prevent the hassle of solving conflicts.

After the refactoring, people can work on different low-coupling parts of code.

TryBane

https://www.youtube.com/watch?v=SsoOG6ZeyUI In case you haven't seen this masterpiece yet. And yeah, alway tab +1. No matter it will be converted to 2 spaces or 4 spaces, pressing tab always gives me the feeling of orgasm. LUL.

TryBane commented 5 years ago

There were a couple other things I was considering with the script too. If we rely more heavily on image recognition to determine the state of the battle, we can remove a lot of the wait times. This will act as a double edged sword though, since there ARE still slight delays in some areas. An example of such is what I outlined in #113 where I mentioned that there is a bit of a delay between when the "battle.png" comes back into view and when you can select a skill. But this is a VERY small and barely noticeable delay. However, it might only be barely noticeable for me because I'm on a fairly newer phone (Samsung S7). So in the case where it is on an older phone it might need a bit of a longer delay. So I was going to implement a variable DelayDefault and set it's value to 1. Then multiple that value by whatever the typical delay is (example given already has a delay of .4 seconds) so in that case it would be DelayDefault * .4. Anyone who needs a longer delay in general can increase the value to something like 1.5 or 2 to increase, or in cases of using an Emulator where it might be hella faster can lower it to .75 or .5

The other thing was creating functions that would do the image recognition for us, so we don't need to type the whole thing over and over. For instance, I used this line copy and pasted over and over in my speedup variant:

BattleRegion:exists(GeneralImagePath .. "battle.png"

And we can instead just have a function that takes a string "battle.png" for example, and a region BattleRegion, and returns a bool for us on whether it exists or not. This can be placed within an if check to allow us to do something in those cases.

29988122 commented 5 years ago

TryBane That sounds very promising!

I edited a few bits in my reply in this thread https://github.com/29988122/Fate-Grand-Order_Lua/issues/114#issuecomment-443961070 , I guess that's what we should work on for now.

In the meantime, I'll handle all the Chinese, English and Japanese part in cfg files, and the Documentation (readme.md), after the majority of behavior changes finished.

TryBane commented 5 years ago

That would be incredibly helpful man. I'll read the adjustments you made to that comment

Also yeah, I don't need contributor status. I can post my finalized scripts in a zip file for review and you guys can worry about conflicts :D

ryuga93 commented 5 years ago

Tbh I had never expected that the day to standardize stuff would come XD. Recalling the early days when I discovered this repo till today is just wow.

So yea onto the main stuff: 1) I agree with @potchy. Naming conventions are needed. I have some ideas of it:

2) I'm working on Autoskill refactoring. This must come first before any future enhancement. 3) Overhauling as mentioned by @TryBane. Detecting changes on the screen is definitely better for run time flexibility, such as sudden slow internet speed etc. Loading screen is harder to recognize, but we can find a constant image along with several unique getColor location to make it work. 4) Improvements on autoskill and card chaining. I have been thinking to improve these modules. Been neglecting to strengthen my servant lineup and the events are getting harder :( https://towardsdatascience.com/project-pendragon-an-ai-bot-for-fate-grand-order-23f51b6e3268 This guy developed a neural network for card chaining, but only works on PC. I have been brainstorming some ideas to emulate this:

- Using [Torch-Android library](https://github.com/soumith/torch-android) and process everything on mobile. Likely to be slower for most of the phone nowadays. 

- Using the concept proposed by pokeguys. The only problem is hosting the trained model locally, which is unsuitable for "actual mobile" users. We can replace localhost with a server, but the server must be able to handle requests and running the back-end AI program efficiently. 

- A more down to earth idea is to compare the cards and group them to make brave chain, then add in the weak/resist weightage along with the crit star value. A voting system will consider all this and make a final decision to make a brave chain, type chain or no chain at all, an expansion of the current card type voting system. The down side is that it will not know who are the servants, unlike the method using AI.

- As for autoskill, I hope that one day I will not have to use Skill_command at all! But for now, I'm going to find a feasible way to make the skill execution less rigid, meaning: healing will automatically be done when HP below certain threshold, activate defensive skills when enemy is going to release NP, buff allies/debuff enemy when allies going to release NP etc, as well as cooldown checking. User will still need to input Skill_command but no details for every turn are needed.
TryBane commented 5 years ago

I have an idea regarding card chaining. There are a few key factors to keep in mind regarding it.

  1. NP Available?
  2. Running double same servant, needs to check if support for comparisons
  3. Type brave chains?
  4. Is a chain required?

NP available for any brave chain should be possible using the comparison you mentioned but seeing if there is any match on one of the above 3 cards. If it is, then it moves on to see if there are other braves available. Up to 2 braves are available in any 1 hand with NPs included. If all NPs are available, there is ALWAYS a brave available (assuming no stuns).

If one of the servants is a duplicate to another on screen, we should double check the support tag on the cards to ensure we are activating a brave.

Next is prioritizing Type chains like Buster Brave chain, or Arts Brave chain, etc.

And finally, is this a situation where a brave chain is wanted? This is probably not going to be checked during the card selection screen. However, it might be a good idea to consider checking the cards before even opening the card menu.

We might be able to figure out the hand using the hand on the bottom right, and their order, to keep from making the calculations while in the selection screen. If we can get multi-threading working we can do these calculations while skills are being activated. But that's a different conversation altogether.

I will work with the naming conventions you described above as well, as they seem fairly thorough in detail. Only issue I have is the idea that there will be ANY variables being made and used in regular.lua cause if I have my way, there won't be ;)

Anyways, sounds like some good stuff to me! We should allow the user to define separate types of script behavior such as farming, where they essentially charge NP to cast NPs wave after wave, vs Challenge Quest/Story Quests where it actually does the harsh calculations for efficient turn by turn attacking.

We might be able to let the script look at the party confirmation screen and recognize the 6 servants chosen and use it to determine skills/NPs, etc. That requires a lot more work on us to write behaviours for each Servants' skill usage and NP firing though. Might not be conceivable until much later. Or if we implement Machine Learning.

EDIT-- Also would like to have a series of locations set in a single Lua file that is imported into regular.lua or FGO_##_REGULAR.lua that will be referenced for click locations and region searches. We can use a few generalized locations too, just in case. Though I'd prefer more personalized ones for the majority of the clicks/checks for when they change UI or menu functionality/behavior. We can then just modify the single affected instance without screwing up many of them.

anubi commented 5 years ago

If different technologies are still being evaluated, I wanted to just point out that in my experience it's challenging to do android automation.

I have some experience with automating Fire Emblem Heroes. I wrote a small solution using monkeyrunner, python, adb (android debugger from the android sdk). It was pretty easy to setup and get some image recognition going. The problem I found though, was that Fire Emblem Heroes actually is leveraging google's anti-cheat service, which periodically seems to download itself onto your device and check for some kind of ADB-based manipulation, because a couple times it flagged me for 'being naughty'. Though I never did get banned for doing any of this. As such, I'm slightly wary of using some kind of "...he's considering running heavy-duty task on localhost, and make it communicate with our Android emulator/LAN android device. This could be one of our future paradigm...." paradigm shift. I mean, there might be good solid technologies with such an approach, but it sounds relatively similar to what I was doing.

I haven't explored this, but I'm curious if the android accessibility features can be leveraged from a native android app to give permission over FGO in order to automate it. I haven't explored that avenue or if it's better than anything else.

In general, I would advise any such future designs involve 'image-based' recognition, if only so unit tests can be created to 'prove' the code works. Maybe that's overdesigning things though, I mean, I think the current state of this project is pretty great. I just think it's hard to make enhancements without having access to multiple devices and having a lot of confidence that nothing will be broken. If things were more functional and relied on something concrete and device-independent like image-analysis... But then again, in my experience image-analysis can be tricky and add a lot of project complexity.

PokeGuys commented 5 years ago

@anubi What I am proposing is to communicate directly through the Ankulua app, not ADB. There is no extra ADB-based manipulation during the communication between API and device. All the requests are sent from the app itself using HTTP(S). It just some normal traffic and it cannot be captured by FGO or other apps unless you are using some MITM proxy.

btw, Can you provide more details about the google's anti-cheat service?

29988122 commented 5 years ago

pokeguys

Some irrelevant anti-cheat write-up about FGO can be found here: https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20

臺灣之光topjohnwu XD

Anyway besides google's safetynet, there are numerous ways of implementing root detection, at least for JP mobile gacha games. They tend to use informal (in regards to security) ways to prevent cheater.

As far as I know, Magiskhide could handle most of them.

PokeGuys commented 5 years ago

@29988122 I have seen that before. I just root my phone a few days ago but still can't open FGO even using Magisk. It turns out it is LineageOS's build.prop problem....

SafetyNet is not really an anti-cheat service. It just verifying are you using a valid phone by checking fingerprint, rom build type, secure flag, root detection, etc. And nothing really related ADB, monkey.

So, I am wondering which Google Service is providing anti-cheat function. AFAIK most of the anti-cheat function is written in the app itself, not provided by google service.

anubi commented 5 years ago

"Anti-cheat" is probably a bad term, it's really 'anti-virus' or 'anti-tamper'. Not much is known publicly

It's definitely https://developer.android.com/training/safetynet/ that Fire Emblem Heroes is using. I think it's https://developer.android.com/training/safetynet/attestation

FGO uses certain exploits in android to its own security checks, not sure what it does aside from that. I'm skeptical they're using this service, but I wouldn't know.

potchy commented 5 years ago

@29988122 I mean, maintaining the compatibility of an Android scripting framework required TREMENDOUS amount of work, and Ankulua did that pretty well. Not to mention that the author of Ankulua personally helped me & this project a lot.

However, I always think that, maybe, just maybe, Ankulua prevent more people from using our script. ($50 lifetime IRRC, I was using contributor's lincense xD) There were already >10 people online and in reallife telling me this.

I'm pretty satisfied with AnkuLua, to be honest. The only drawbacks I see are: no transparency support, issue #40 and price, but I don't really feel like there's a need to change to something else. The author is doing some good progress with Android accessibility, so I think that sometime down the line we won't need ADB anymore.

@TryBane As for screen recognition "strategy", I was going to rely more heavily on image identification over wait times. But I was going to remove the hardcoded numbers you originally implemented and find the zones to search based on the device used.

I think wait() is fine for simple scenarios, like for confirmation dialogs that show up after you click "Update" or something. In fact, image recognition might be even slower depending on the case, not to mention it probably drains more battery, but I'm not sure about that. It would be nice to move waiting times to the configuration file, I guess.

Also, it seems that you implemented some sort of transparency with the MLB option for CEs, can you get that to work using the "Battle Speed" button in the Card Selection screen? That is the best option I think for determining when the card selection screen is up. Either that, or we just check to see if ANY of the 3 card types are up on the screen.

AnkuLua doesn't support transparency, so the best we can do is limit the pattern image as much as possible and use similar() to increase tolerance with unnecessary pixels. Read this for a better explanation.

@ryuga93

  • PascalCase for all functions. Eg: CheckCardType()

For consistency, I think we should stick with AnkuLua's camelCase. That's why functions are already like this in support.lua.

  • camelCase for variables in regular.lua. Eg: turnCounter

In order to not mistake these as functions, due to the point above, we should treat them like local module variables, in _camelCase.

  • module_moduleName for imports. Eg: local module_support = require "support"

DEAR GOD NO just _support is totally fine

@pokeguys I have seen that before. I just root my phone a few days ago but still can't open FGO even using Magisk. It turns out it is LineageOS's build.prop problem....

This might be related.

ryuga93 commented 5 years ago

@potchy Right. So:

Btw, I prefer to have temp_name for temporary variables living in functions. It's more intuitive on first glance. What do you think?

potchy commented 5 years ago

Okay, after making some changes to the code, I feel like using _UPPER_CASE for local module constants visually annoys me for some reason. Can we use UPPER_CASE for all constants? They're just constants, anyway.

Btw, I prefer to have temp_name for temporary variables living in functions. It's more intuitive on first glance. What do you think?

I think it might be useful in some scenarios, but most of the time that's obvious if you declare them as local. 😵

TryBane commented 5 years ago

As I mentioned before, I am fine with whatever so long as we stick to it. With that being said, please let us all use tabs, not spaces. Also, I don't see a huge need to differentiate between the constants.

As an aside, I don't feel we will be using the local module variables outside of the module, and they should probably hold all the variables that they themselves need. And due to that, they probably don't need distinguishing factors like the underscore beforehand.

This helps to keep modularity, keeping the variables localized to their modules and keeping global variables out of the picture. So someone might grab the module itself and write their own form of the regular.lua script without needing any tinkering. They can grab the module and it just works, given that they include any additional files needed such as support images etc.

potchy commented 5 years ago

they should probably hold all the variables that they themselves need

Uh, actually, I'm going to open another thread about this particular issue, after I'm done here. I'll need the underscores for now.

@ryuga93 I'm combining my changes and yours. Please don't commit anything else to autoskill.lua before I finish. 😭

TryBane commented 5 years ago

I can understand if you need them for the moment. But this is part of what I plan to be working on with the overhaul. Keeping things compartmentalized.

There are two functions I see being used outside of the modules themselves. Init where we pass in the compare and script size so that everything is uniform. Might pass in other information as well.

The other instance is a Perform function, such as PerformAutoSkill where we pass in the string or whatever variable we use to store the skills being used. Keeping it this way will also allow us to later implement the machine learning or whatever method for figuring a better strategy for combat beside user input. Cause then a separate function figures out the strategy and then passes the skills it figures are best to the autoskill Perform function.

ryuga93 commented 5 years ago

@potchy sure lolz.

@TryBane I think after @potchy commit his changes we will freeze the repo for you to work on the overhaul stuffs, unless there is an urgent bug.

TheIanator commented 5 years ago

I haven't read this whole thread in depth but I thought I'd mention some thoughts I had earlier about making the script work better. I'm an extremely novice programmer so my idea's could be completely off base.

I don't really know the details of machine learning, but in basic isn't it trying everything and then iterating on what works to find ideal solutions? Since grand order is a game of simple math and numbers my thought was that instead of just going for weak cards or brave chains it would be possible to find the optimal chain that would deal the most damage out of all available chains.

A few month ago I wrote a couple of very messy programs, the first you provide a short list of servants and it returns the cards on screens, what servant it is, whether it's buster/arts/quick and whether its a support or not.

The second takes the composition of your team, the enemy team, and the available cards and tests every chain, starting on each enemy, it assumes the worst random damage multiplier and returns the chain the would deal the most damage.

The identifying servants and cards portion was fairly slow, but could probably be improved. I haven't done any work on it in several months, but since people are talking about ways to improve the script I thought I mention and share my work if anyone felt like it was a good approach and wanted to take a look at and/or improve on what I wrote.

Warning, horribly messy, extremely barebones code: AdvancedCardLogic.zip

Some things I think would need to added to this to be a viable solution:

Since it always assumes the lowest possible damage it could think an enemy is alive when it isn't. Might it be possible to get new HP values from a screenshot each turn instead of just remembering HP values from last turns calculation (not that it does that either yet.)?

A database of servant skills interwoven with autoskill, so if you use Charisma the next three turns of calculations takes the +damage into account.

Incorporate NP's from autoskill, calculate where in the chain to put it to maximize damage.

Also the asset rip I found only had card images through Merlin, so a newer datarip would be needed or uses would have to manually add images for servants they intend to use. Technically a team could only have images for five of the servants and when it doesn't recognize a servant assume it's the sixth.

Less important:

Since the various wikis list enemies in nodes there could be a database you can copy/paste from instead of manually listing expected enemies and their HPs/Classes/Attributes.

TryBane commented 5 years ago

You have some nice ideas, the issues are implementing them. For the idea of having a database of the servants and their affected values, that will require us to hardcode a LOT of information. Including setting various variables. We've gotta incorporate support for JP as well, which will only increase the amount of information we need to include.

Some servants' NPs work really weird, such as the new Lancers' for instance, which will create making functions really annoying or difficult to implement. I don't know if we can truly make an autoskill setup so that it can make its own decisions without user configuration and such. I think the setup currently is pretty fine though, except maybe including some cooldown support and synergistic casting of skills. For instance, if Mana Burst was cast this turn, also cast NP. Or if NP is not ready, don't cast Mana Burst. Or NP is ready, but Mana Burst is on cooldown, so wait for Mana Burst to come up before casting NP. That kind of support works, but the program won't know it's mana burst. The user will configure the skill selection to be used to match the casting time.

As for card selection for strongest damage, the issue is that sometimes you don't WANT the most damage. Sometimes you want an Arts chain to get NP charge, sometimes you want an alternating Buster chain between 2 servants so that you can wipe the screen in 1 turn without using NPs. These kinds of combo behaviors should be able to be configurable in the future, probably separately from Autoskill. Just in terms of Card selection. Since Autoskill handles NP and skill usage, which are key for synergy from what I mentioned above, they should be paired. But Card selection can be determined by the cards brought up and the NP selected rather than needing to be synergistic with Autoskill. You might consder NP charging to be a good idea if it's possible during wave 2 of your farming, just to try and get the NP you need for wave 3.

Anyways, long enough of a post on that.

@ryuga93 Yeah, that would be nice. I can work really hard on it come Sunday since it's my day off. If potchy can get it all committed by Thursday, I'll have some time to work on it on that day before work as well. Btw, you're moving Autoskill to a module. Are you making any adjustments to it as well? In terms of functionality I mean. Such as cooldown support and the like? Just want to know if the overhaul I plan should cut the autoskill portion, or if I should do an overhaul of it all, and then when you get your hands on it you can just change the autoskill to be incorporated with the module.

ryuga93 commented 5 years ago

Nope, go ahead to do the full overhaul. I'll start after you're done.