vBot update check should be removed.

[divinity76]

Priority

Enhancement

Area

• Data
• Source
• Docker
• Other

What is missing?

upstream vBot is unmaintained. The last git commit was in 2022.
And our bundled vBot is maintained (I've recently done a bunch of vBot improvements personally)

Maybe it's even time to switch the name, to clarify that it's no longer upstream vBot, but a diverged fork. rvBot (redemption vBot) ?

nah, kiss, but even so, the update check should be removed.

Code of Conduct

• I agree to follow this project's Code of Conduct

[InnerCircleTFS]

Is this relevant?
Why is an issue being opened for this debate? That’s what Discord is for.

Improvements or bug fixes are nothing compared to the work of Vithalex and Kondra. It's an insult to change their names just because you made 3 PRs where you fix things for version 7.6 and probably break things for versions higher than 7.6.

[divinity76]

@InnerCircleTFS

Why is an issue being opened for this debate?

Cus I don't want to deal with it right now, but I got a network error related to the update check, and I was like "wait, there shouldn't be an update check anyway, it's abandoned upstream"

I expected it more as a to-do list than a debate.

Improvements or bug fixes are nothing compared to the work of Vithalex and Kondra.

True. (Wait, who is Kondra? and what did Kondra contribute to vBot?)

It's an insult to change their names

Okay fine, let's keep it simple and not change the name.

you made 3 PRs where you fix things for version 7.6 and probably break things for versions higher than 7.6.

It's way more than 3, and I liberally use 760 guards when I think it might break something for newer versions:
1/9: Allow disabling "Hunting Rounds Limit" (#880)
2/9: Looting blacklist (#881)
3/9: Support "Mage" vocation (#882)
4/9: Fix typo scrupts → scripts (#1420)
5/9: Fix handling of floor-change tiles in walk logic (#1494)
6/9: Fix (vBot): Item list scrolls to bottom on new entry (#1530)
7/9: Improve (vBot): poscheck supports optional maxRetries argument (#1532)
8/9: Fix (vBot): Expose Directions to bot sandbox (#1533)

[InnerCircleTFS]

True. (Wait, who is Kondra? and what did Kondra contribute to vBot?)

yes cpp side

---

We are the laughing stock of the community...

---

Yes, you're right, epic changes that will change the course of OpenTibia, and it's necessary to change the name from vBot to DivinityBot76

Check, your changes:

-      if text:lower():find("sorcerer") then
+      if text:lower():find("sorcerer") or text:lower():find("mage") then

-    scrupts here
+    scripts here

+ context.Directions = Directions

• I'm pretty sure this breaks some version.

7/9: Improve (vBot): poscheck supports optional maxRetries argument

5/9: Fix handling of floor-change tiles in walk logic

[divinity76]

@InnerCircleTFS

there is no tibia that doesn't require looting from adjacent tiles

Really? I assumed, since both vBot and BlackD Proxy, had this exact issue for 7.6, and I found references online to Cipsoft's tibia allowing distance looting ( https://forum.gunzodus.net/threads/is-there-an-option-to-loot-from-distance.143/ ),
that it was a version-specific issue.
Personally I don't know because I haven't logged into a Cipsoft server for 15+ years.

How about you make a PR to remove the version check for the looting distance fix?

don't they do reviews of the code...

Yeah, we do. That specific PR ( #1525 ) was authored by CoPilot, and reviewed by me and
luanluciano93 (and probably Zbizu ?)

Zbizu in particular tested on a live cipsoft server, and said that being adjacent was a requirement,
but Zbizu was not sure if non-adjacent looting perhaps was a pacc-only feature or something, and nobody else chimed either.

I'm pretty sure this breaks some version.

Anything specific you think it breaks? Afaik it breaks nothing.

[divinity76]

btw, if vBot's looter really has been broken for everybody since 2022, why did nobody bother fixing it, until 2026 when it broke my 7.6 looting experience?

am i the only guy using vBot autolooting?

[kokekanon]

if I understand the issues correctly.

A lot of text from both of you, just to delete this:

https://github.com/mehah/otclient/blob/b967b4408a51a2e1c4f94f1df096f7168652aea7/mods/game_bot/default_configs/vBot_4.8/vBot/main.lua#L12-L21

Furthermore, since it is GitHub, there should never be an error, unless the author deletes the repository or GitHub goes down status.

[divinity76]

if I understand the issues correctly.

Yeah, you do understand it correctly. This thread derailed.

Furthermore, since it is GitHub, there should never be an error, unless the author deletes the repository or GitHub goes down status.

Incorrect. github.com fail surprisingly often. From 2023, quoting ruffle-rs/ruffle#9121 (comment)

Current PR version appears to be failing for me here, as the url 404s
Step 9/19 : RUN wget 'https://github.com/WebAssembly/binaryen/releases/download/version_111/binaryen-version_111-x86_64-linux.tar.gz' --quiet -O- | tar xfvz -
---> Running in 2e73dcc0bf8e

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
EDIT: wait no, url worked in browser after 3rd try. Huh. But still not from docker.
Anyway, I'd still recommend trying with conda.

and further down quote

.. if that url -sometimes- 404's, maybe it's a github.com issue?
It's gotta be the ugliest hack I have ever done, but.. added a bash-script to attempt to download it up to 10 times if the wget download fails for any reason.. can you try again?

and further down quote

anyone else thinks it's strange that we're questioning github.com's reliability?

and in response to that, quote

anyone else thinks it's strange that we're questioning github.com's reliability? anyway

Believe me, it's not strange given the problems we've been having with GH Actions reliability lately...
For example, we were recently affected by actions/runner-images#6913
And a GitHub API reliability issue recently blanked out the releases table of our website for a few hours, see ruffle-rs/ruffle-rs.github.io#102

I too was surprised, in 2023, to learn that github.com is not extremely reliable.

[divinity76]

(tbf, as far as i recall, i have only experienced significant github.com instability in 2023, with ruffle-rs development. But I did just get a one-off network error in the vBot update-check code a few hours ago. That's how I learned the update check even exist.)

[divinity76]

@kokekanon

Furthermore, since it is GitHub, there should never be an error, unless the author deletes the repository or GitHub goes down status.

here is the actual error that happened to me btw:

WARNING: [BOT] [vBot updater]: Unable to check version:
HttpSession timeout after 2 seconds
ERROR: TCP connection failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
ERROR: HttpSession unable to connect https://raw.githubusercontent.com/Vithrax/vBot/main/vBot/version.txt: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[InnerCircleTFS]

The problem is in the http library, not in the vbot code...
http.get is used in several parts

I could have custom module with HTTP and I could have the same error. (Although I don't get that error.)
and I don't solve anything by removing code from my modules with http

[divinity76]

@InnerCircleTFS

The problem is in the http library

incorrect, the problem was a transient network error, somewhere between my computer and github's servers.
the http library is, in all likelihood, innocent.