Detergent13 / tft-bot

Automate Teamfight Tactics (TFT) for token/mission farming. Updated for Set 11!
GNU Affero General Public License v3.0
81 stars 45 forks source link

Enhancement: time-based surrendering instead of round-based (no image-search needed) #74

Open Kiruscha opened 2 years ago

Kiruscha commented 2 years ago

Hello,

for any coders working on this project:

For convenience implement a time-based surrendering system instead of round based. That means starting a timer after the script recognizes the game having started. This would also have the positive effect of reducing load, as it does not have to scan for the rounds image.

CaS1ow commented 2 years ago

The current game's token system give us tokens based on time The higher your ingame rank, the more tokens you get, so the macro need round check because check the round and get items and give item to champion etc..

anyway The most important thing is If I am in 6th, 7th, and 8th places, the time-based surrender system may be good, but if I am in 1, 2nd, 3rd, and 4th places, I am in a situation where I surrender even though I have the opportunity to obtain 4 tokens per minute.

Detergent13 commented 2 years ago

As @CaS1ow said, I don't see much of a point in switching to time-based surrender at the moment. Aside from processing load (which I'm not too worried about- maybe others are?), surrendering at a time vs. at a stage is effectively the same. Maybe some hybrid decision-making between time and stage could be beneficial, but again I think you'd often be accomplishing the same thing either way. (Time is roughly tied to stage anyway)

If any change were to be made to surrender decision-making, I think based on place/ranking would be the best bet. But not sure how well image recognition would lend itself.

Kiruscha commented 2 years ago

Hey, sorry to make a discussion out of this, but you are forgetting multiple factors:

  1. Stages are (more or less) hit at the same time every single game. (Only differentiates by seconds if someone goes overtime).
  2. The script doesnt give items to champs, what do you mean?
  3. As previously mentioned, it doesnt matter having input be stage 3-2 or timer 10 minutes. It happens at the same time. But what matters here, is that 1. the script doesnt have to scan for the round, 2. the implementation is easier, no need to recapture screenshots if the software breaks, 3. you can chose between every single gametime, no need to select between handpicked selection of captures (eg if only 2-5 and 2-6 screenshots exist, you can only take those, which is very user-unfriendly).

Your suggestion is also something I thought about. Should be able to be done since players that lost are greyed out if I remember correctly.

CaS1ow commented 2 years ago

i already made item give functions personally i will give it to @Detergent13 later

The best way for the program to run normally is to capture images. If the game breaks down and you connect again, macro have to detect the image of the round and proceed again But if it works time base, as you say, macros may not work depending on whether the game is reconnected(crash) or if there is a new update of the game. i think using "timebase macro" is lower version of "image detect macro"

you said "Only differentiates by seconds if someone goes overtime" how about if round over 3~5 going overtime or finish early ?, it can happen, If that happens, time will be pushed back, so all subsequent macro will be ruined.

I respect your opinion, but from the developer's point of view, time-based macros don't look so good because we need more update for macro and Image detect is more update-friendly.

It's not easy to develop macro developers have to think about each situation-specific variable, and time-based macros create more variables.

Detergent13 commented 2 years ago

Seconding what @CaS1ow said. There's a very real risk of the macro 'derailing' by the timing gradually becoming more and more off. And regardless, you'd still need to be scanning for many images to keep you on track for loading into the game, surrendering, re-queueing, etc.

Again, maybe adding a little bit of time-based decision-making could be helpful or a bit more flexible, but definitely not on a wide scale, and I don't think it'd make a huge difference.

As it stands, I don't see enough of a benefit of time-based decision-making to actually implement it, but perhaps I'm missing something.

Kyrluckechuck commented 2 years ago

As a counter to time-based decision making, would it be possible to update the "logic" to handle just playing until eliminated as opposed to surrendering? I was able to piecemeal it together to skip the surrendering, but half the time it ends up AFK'ing until eliminated instead of "pseudo playing" like normal.

Frequently the main reason for farming/using this is for the time-based XP & tokens, and less time spent between matches is both beneficial, and increases odds of randomly getting into top 4, which doubles the amount of XP received.

Detergent13 commented 2 years ago

As a counter to time-based decision making, would it be possible to update the "logic" to handle just playing until eliminated as opposed to surrendering? I was able to piecemeal it together to skip the surrendering, but half the time it ends up AFK'ing until eliminated instead of "pseudo playing" like normal.

Frequently the main reason for farming/using this is for the time-based XP & tokens, and less time spent between matches is both beneficial, and increases odds of randomly getting into top 4, which doubles the amount of XP received.

The easy fix to this is to just set the surrender stage to an extremely late stage.

There used to be a no-surrender branch, but I deprecated it due to it being a pain to maintain. If you need some inspiration, you could take a look at the git history too!

Kyrluckechuck commented 1 year ago

@Detergent13

There used to be a no-surrender branch, but I deprecated it due to it being a pain to maintain. If you need some inspiration, you could take a look at the git history too!

Unfortunately that branch does not seem to exist at all in git's history for this repo, I suppose it was deleted upstream? If you still have a stale copy of it locally would you mind re-pushing it?