Is there a reason why after 0.8 seconds and under you are not classed as fighting anymore? Should you not get the message "Your target is currently battling." insteada the fight starting while the other one is still happening? Or am i missing some information on how the fights occur internally.
questions
<Rapture>
2019-10-24 05:38:34
[5 years, 30 days ago] |
|
Administrator 2019-11-04 01:36:28
[5 years, 19 days ago] |
I'm having trouble wrapping my head around this. Can you (or someone else that understands) clarify for me the sequences of events that happened, what you then expected to happen as a result, but what you actually instead observed? |
<Rapture>
2019-11-04 02:59:11
[5 years, 19 days ago] |
I think i worded that rather poorly, so i shall try again. If the fights are short enough, say 1~3 seconds and you have 2 bots ready to fight the same target, when the fight on the first bot gets to around 0.8 seconds remaining and you click fight on the 2nd bot, it'll start the fight on the second bot while the fight is still in progress on the first bot. Try doing the same when the timer is on 1 second and above on the first bot and you'll get the target is battling message on the second bot. Doing this basically allows you to dump wins or whatever on the target bot twice as fast compared to doing the fights one bot at a time. This is what i was curious about since shouldn't you still in a fight until its over and you get the option to click fight again? So i wanted to know whether this was normal behaviour or not. Hopefully this is a bit more clearer and sorry if it is still confusing. |
<Apex>
2019-11-04 03:07:43
[5 years, 19 days ago] |
Weird. This was supposedly already fixed: http://bots4.net/forum/10/7390 |
<Rapture>
2019-11-04 05:28:23
[5 years, 19 days ago] |
If the fight is 30nseconds long you can click fight again within 2-4 seconds remaining also |
<Apex>
2019-11-04 18:59:49
[5 years, 18 days ago] |
What browser are you using? I'm unsure nowadays, but firefox used to lag behind with the timers making it slower than real time. In that I mean a fight that's actually 10s long could take 11 or 12s to finish resolving on your screen (but internally it already finished, so you could fight again from another window). This is the only scenario outside of the <1s remaining thing that was fixed that I can think of. |
2019-11-04 19:32:09
[5 years, 18 days ago] |
There is a delay between dealing the final hit/being dealt the final hit and the fight again link appearing, of about 0.5s or so. Also there is latency to consider. By dumping with 2 bots on the same target you can bypass these delays, if your timing is good. Interestingly in bots2 there were times when there was no delay between the final hit and the fight again link appearing, but there was a longer delay between clicking fight again and the new fight starting. |
2019-11-04 21:56:44
[5 years, 18 days ago] |
Just confirmed that the <1 second "feature" still works on chrome, firefox and edge (lmao). |
2019-11-04 22:46:20
[5 years, 18 days ago] |
The fights are still taking 1s at least. You can't dump wins before that fight is over. The fastest I have been able to dump over an extended period of time is about 1 fight every 1.5s using the two bot technique. If someone can demonstrate >1 fight every second, then they might have grounds that there is something unintended working. Until then, I would say that everything is working as intended. |
2019-11-04 22:48:09
[5 years, 18 days ago] |
Oh yeah I should have mentioned it was on 3-4 second fights my bad |
2019-11-07 13:22:33
[5 years, 16 days ago] |
Hmm I remember using this technique (i.e. using 2 dumpers at same time to score on my main) when I wanted to gain energy fast (namely racing for the 10th spot in the end of the month :P). |
Administrator 2019-11-13 01:04:14
[5 years, 10 days ago] |
Interesting, thanks for clarifying the problem. I understand the (possible) issue now. I'm inclined to agree with the theory that what's actually happening is that the battle is taking longer to play out in your browser window than what the game/server is expecting, i.e. nothing game-breaking is happening. So for example, the game/server is expecting your battle to last 30 seconds, but your browser is actually taking 35 seconds to render it (or 31 seconds, or whatever). As for why this could be happening, there's quite a bit of complexity in the rendering code to deal with (a) browsers now (as of many years ago) setting a minimum background update time for inactive tabs of 1 second (meaning the battle needs to "catch up" if you switch tabs mid-battle) and (b) buffs making it so that time between attempts in a battle is variable. It's possible there's a bug with this logic, but so far I'm not seeing evidence of anything game-breaking, so I'm hesitant to dig into it. All that said, if someone can definitively demonstrate something unintended happening here and they can pinpoint technical details of the problem (most likely by working through what's happening in battle.js, probably in/around showBattle()), then I will reward you with 3 stars via the game's bug disclosure reward program. |