Closed physics-archive closed 2 weeks ago
After recompiling / rebuilding, I have yet to see ahbot errors or spam, and get the following verification that ahbot is disabled (desired behavior for now): Initialize AuctionHouseBot... AHBot is disabled. Unable to open configuration file(../etc/ahbot.conf).
Originally, as shown in the above server-start logs, there's no confirmation that ahbot being loaded or disabled.
Note my mangosd binary has a different hash than the original:
old sha1sum: 6a25aebc54508cd29c67eb366a1bbac940dd4cd4
new sha1sum: e2d235325f56ce1b2cf51642c92a7545d51aba94
Perhaps I misconfigured something during the first run and produced erratic behavior with ahbots. I'll close this in a week if this install remains stable.
If anyone has any insight on why ahbots were behaving like in my original post, I'd be grateful. Thank you!
Reopening issue#3730 for the following reason: closed by mistake!
We have 2 separate AHbots: Legacy/Deprecated AHBot and new AHBot (controlled via aiplayerbot.conf) They are not compatible with each other. If you have compiled the server with the new playerbots enabled then you need to disable the old playerbots. AHBot can be enabled or disabled in the config files.
We have 2 separate AHbots: Legacy/Deprecated AHBot and new AHBot (controlled via aiplayerbot.conf)
They are not compatible with each other. If you have compiled the server with the new playerbots enabled then you need to disable the old playerbots. AHBot can be enabled or disabled in the config files.
Thanks for this reply.
In my problematic build, I disabled both legacy and new bots in ahbot.conf, but one of those seemed to load in spite of this. Could you tell from the console whether the module is legacy or new?
It's possible I compiled the first one without ahbots, but then why would legacy ahbots try to load even when legacy is disabled in ahbot.conf? Bug or maybe I'm missing something.
[My .conf files were definitely recognized correctly in the problematic build, since I had heavily altered the server configs and that always produced expected behavior.
The log you posted tried to load the new AHBot that comes from the aiplayerbot.conf.
Because you didn't have or didn't rename the aiplayerbot.conf file it tried to load default configurations and so it produces these errors
It looks like I had AHBot off in my cmake parameters for that original build, and I'm thinking this leads to the behavior. To clarify -- I did have aiplayerbot.conf properly renamed and disabled completely. Same with ahbot.conf.
My recompiled/rebuilt version is still stable, so I'm thinking this is an issue with the build process. I'll close this since it's a support thread and I'm not longer in-need, but it is worth noting that the following configuration may lead to bugs on Unix:
Core Version
mangos-classic
Support Request Details
I compiled cmangos for Debian 12 with no problems. The server runs on my internal network and communicates with clients. However, after a second launch, the server is spammed with empty ahbot queries, even if the module is fully disabled in ahbot.conf and no ahbots are online. Let me know if there are any known reasons why ahbot functionality would execute despite disabling them.
I'm recompiling and posting an update on whether this is reproduced. Posting a full server boot (with the bug present).
Steps to Reproduce
cmake ../mangos -DCMAKE_INSTALL_PREFIX=~/cmangos/run -DBUILD_EXTRACTORS=ON -DPCH=1 -DDEBUG=0 -DBUILD_PLAYERBOTS=ON -DBUILD_AHBOT=ON
Crash Log
Core SHA1 Commit Hash
6a25aebc54508cd29c67eb366a1bbac940dd4cd4
Database SHA1 Commit Hash
n/a
Server Operating System
Debian 12
Client Version
1.1.12 (Classic)
Client Operating System
Windows. No client-side problems.