Closed Kein closed 8 years ago
I kinda like that idea, was thinking about the same but the fact they could control my bot too made me not do it.
How about using multiple ASF-Instances? If someone shuts down his bot, you´re not affected.
That is not rally rational and/or pragmatic. Especially if you run it on a cheap OpenVZ host. Resources have cost even if ASF east little to none.
Did you even tried to set up two instances? Sounds for me like you didn´t and even a cheap VPS could handle it. Only the connections per IP are restricted to 100-110, like I mentioned in the Wiki-FAQ. Also my oppinion is that it was never the purpose of ASF to farm cards for other people. It´s okay if your friends have enough trust in you, but I wouldn´t say this is common. However, it´s not my decision.
Well, I'm not here to argue with you. And the request is not about different instances or whatever, there was no reason to drag discussion that way. I also think in general it seems like a good idea to have such vriety even though it may seem redundant. But different people [may] have different tasks. I have no idea why are you so against it, however, it is not my place to judge opinions.
It is not a big deal if it won't be implemented.
Hm.
I somehow like that idea but we'd also have to limit all given bot instance commands to owner as well.
And available for tests in https://github.com/JustArchi/ArchiSteamFarm/releases/tag/2.0.1.2
TL;DR before I write documentation:
There are two access levels now: SteamMasterID
and SteamOwnerID
. Every bot listens only to his SteamMasterID
. Global commands such as !exit
, !update
and !restart
are reserved for SteamOwnerID
only. WCF works with SteamOwnerID
access.
It's nice to note that master of bot 2
can use given bot instance
command on bot 1
which relates to bot 2
and get valid response.
I set up a bot for my friend and he is master of his and you said that another bot would listen to given bot instances that he owns but won't respond on my bot 2
and his is bot 3
Actually forgot to disable the old check done at chat msg.
Glad I am not a complete failure then xD
But executing commands should still work. I mean broken part was only using bot2
to execute commands on bot1
while not being master of bot2
.
Yes commands still work, but I have to issue them for him since I'm Master of bot 2
It's already fixed and will be there in next version.
Sounds good =)
First of all - I don't like that you changed entities here. You should have leaved Master main account with maximal privileged and add a limited one as Owner. Because now everyone would need to modify their configs, even though not using ASF for multiple people. And, mr. @kofe88 told me that commands from Owner does not seems to work via group chat - I didn't checked it myself because don't had time yet to test new version, so maybe someone would check if it is so?
Because now everyone would need to modify their configs
No, you can leave it as it is, only global commands will not work. Also it's modifying one config property, if that's too much for somebody, then probably using ASF is too. Besides, nobody is forcing anybody to update, if you decide to update, then you should also prepare for reading changelog and making required changes (if any) to keep using ASF. All versions are available, and updates are not enforced, you can even use ASF V0.1 if you like.
And, mr. @kofe88 told me that commands from Owner does not seems to work via group chat
Yep, confirmed, I have a fix ready already.
No, you can leave it as it is, only global commands will not work.
Only? You're an optimist.
Also it's modifying one config property, if that's too much for somebody, then probably using ASF is too.
Is somebody have like a few dozens of bots - it can be inconvenient. I didn't said it's a disaster, but it was easier to avoid this in ASF, than make troubles for everyone. And I understand that now it's too late, too bad I didn't thought about this earlier.
Is somebody have like a few dozens of bots - it can be inconvenient
No, it can't be inconvenient, because it's global config property, and it's one file.
Ok, maybe I overestimate the inconvenience, sorry.
There are two access levels now: SteamMasterID and SteamOwnerID. Every bot listens only to his SteamMasterID. Global commands such as !exit, !update and !restart are reserved for SteamOwnerID only. WCF works with SteamOwnerID access.
Okay, wanna clarify few things, especially the latest part with WFC. So, in order to give any command to a bot, my steamID64 must be specified in masterID for the spoken bot, regardless if I'm listed SteamOwnerID. And, WFC follows the same rules too (sine you said it works with SteamOwnerID-level)?
It just confusing because since there is no steamID64 to retrive through WFC - it must work with global privileges regardless, but then it breaks logic of your statement "Every bot listens only to his SteamMasterID". Unless you meant the latter part in context of private/group chat.
@Ryzhehvost And this is a good example again, why it would be a good idea to set up a database with your bot-data. Then you can use PHP or whatever prog-lang you like and generate the JSON-Files easily.
It's a bit different.
If you want to execute command considering bot1
, then you need to be either SteamMasterID
of that bot, or SteamOwnerID
of ASF. Commands considering bot1
include commands sent to it directly (current bot instance), and also commands sent to it indirectly (given bot instance), through e.g. bot2
. So user doesn't have to be SteamMasterID
of bot2
in order to use given bot instance commands considering bot1
such as !stop bot1
or !redeem bot1 key
sent to bot2
. This is convenient, as you can have a combo of primary1
, alt1
, and primary2
, where you own primary1
and alt1
and your friend owns only primary2
, this way he can send to alt1
a command such as !stop primary2
and it will work, even if he's not a master of alt1
.
WCF is executing commands always as SteamOwnerID
specified on the server.
It's very easy to understand - master has control only over his bots, but can use other bots as "helpers". Owner has access to everything, and commands executed by WCF are run always by the owner.
It's very easy to understand - master has control only over his bots, but can use other bots as "helpers". Owner has access to everything, and commands executed by WCF are run always by the owner.
Now this makes sense, thanks.
Planning to let other people use my host to idle 24/7 but don't want anyone doing exit/restart by mistake or intended. It would be nice to add a global directive for OwnerID and an option to limit process-critical commands (EXIT/RESTART) to OwnerID only. MasterID still can do whatever he wants with his bot instance.