JustArchiNET / ArchiSteamFarm

C# application with primary purpose of farming Steam cards from multiple accounts simultaneously.
Apache License 2.0
11.29k stars 1.05k forks source link

Issuing "!update" should force the update, even if it is disabled in config. #229

Closed guihkx closed 8 years ago

guihkx commented 8 years ago

If the option AutoUpdates is disabled in the config file, when you manually issue the !update command, ASF should ignore that option, because you're deciding to update it by yourself.

I decided to disable the auto-updates because since I use Mono, everytime there's an update I first go to Travis CI and see if it compiles OK using Mono. Thanks

JustArchi commented 8 years ago

I decided to disable the auto-updates because since I use Mono, everytime there's an update I first go to Travis CI and see if it compiles OK using Mono.

Why? Auto-updates are always working with binary, and if you're using self-compiled build then you should have auto-updates completely disabled as you're compiling yourself.

Take a look at cc.sh and run.sh scripts - instead of relying on auto-updates you could simply put those two in a loop, so when ASF exits (e.g. by !exit command) - script would automatically pull latest changes, compile, and run (with run.sh).

I can understand the override with !update, and it's valid suggestion that I +1, but it's most likely not what you want for your own purposes. Self-compiled build should have auto-updates disabled, that's one of the reasons why ASF will refuse to update if you run self-compiled (and recommended) ArchiSteamFarm.exe binary instead of ASF.exe dedicated for consumers.

guihkx commented 8 years ago

I just check it on Travis CI because if it doesn't compile using Mono, I imagine it won't even run the binaries compiled on Windows? If I'm wrong I'm sorry, because what I'm asking would be pointless. >:D

So no, I don't compile it myself.

JustArchi commented 8 years ago

Travis and AppVeyor are there to watch the build process, which means if ASF compiles in given environment, and if it passes tests, but as ASF doesn't have any yet, only compilation process is checked.

So no, it's not equal to being able to run. There can be a binary that doesn't compile with Mono, but runs with Mono properly (e.g. because xbuild in given Mono version is broken), and there can also be build that compiles properly with Mono (xbuild), but doesn't work because Mono of given version is broken (very often case).

Travis and AppVeyor can be used to check if build is passing, which means if ASF is able to compile (and work) in current state. This is true nearly always, as I tend to avoid any build breakings (unless accidentally). But it's not reliable way of telling if such ASF is working properly.

guihkx commented 8 years ago

Oh, interesting! Yeah, a couple of days ago I saw that the Mono build wasn't passing and the Windows one were fine, so I immediately disabled the auto-updates. Anyway, sorry for the misunderstanding and thank you.

JustArchi commented 8 years ago

Don't blindly trust Travis as well, build can fail very often due to things such as networking issues, packages being broken on Debian and many other cases - if build failed then it's wise to check why, because it could be a pure coincidence that e.g. mono repo was down at the time of the build due to networking issues.

So in the end, my suggestion remains same. If you're consumer and you don't want to bother with that stuff, you can't go wrong with auto updates being enabled. Of course, in very rare cases such as pre-releases or bugs slipping to stable releases, it's still possible of getting "broken" ASF, but such "broken" ASF is corrected quite fast (ASAP), and you can always download older binary from GitHub, disable auto-updates and keep using that version - I don't remove any version from GitHub, you can even use version 0.1 if you want to.

And if you're developer or user that wants to compile himself because of one reason or another - you shouldn't be using auto-updates at all (AutoUpdates equal to false and UpdateChanel set to 0), and instead handle updates manually with cc.sh and run.sh scripts, or whatever that suits you.

guihkx commented 8 years ago

I appreciate the advices!

JustArchi commented 8 years ago

Also keep in mind that you don't need to compile in order to use ASF - official releases should work on both Windows and Mono. You can compile if you want to, but you're also good to go with wget ASF.exe and mono ASF.exe.

guihkx commented 8 years ago

Even if I wanted I can't, my VPS server has only 128MB RAM, and right now I don't have any interest in compiling ASF myself. One thing I want to ask you though if you're familiar with systemd. I created an systemd unit file to run ASF whenever the server starts. If I'm running ASF directly from the terminal window and it starts updating, ASF is able to successfully re-open itself. However, if I start ASF using systemd and update it, for some reason that I'm not aware of, ASF can't re-open itself... Is this a mono or systemd issue? Or neither?

JustArchi commented 8 years ago

systemd expects service to be a daemon, and ASF (in default settings) acts as a program, not service.

If you want to run ASF as a service, consider setting AutoRestart to false, as stated in the wiki - this way ASF will only exit itself, instead of proceeding with the restart.

When that happens, systemd should be smart enough to notice that process exited, and if you configured your service properly - systemd should restart new ASF.

Another option is to avoid systemd, and instead use e.g. /etc/rc.local and your own script, for example the one I wrote in wiki link above.

Also, if you're low on RAM, you might be interested in fine-tuning Mono for lower memory needs, e.g. by using --desktop option, which should perform garbage collections more aggresively (for performance cost of course). There are also MONO_GC_PARAMS and other things which you can find in man or on Mono website. ASF code-wise tries to be as low on resources as possible, but garbage collector is controlled by runtime and not ASF itself.

guihkx commented 8 years ago

Thank you very much, I'll be checking it when I get home.

guihkx commented 8 years ago

Okay, so the first thing I noticed is that my config file was lacking the AutoRestart option. After I added it and set it to false, systemd will automatically restart ASF after an update. Yay!

Here's my current ASF.service file, in case somebody searches for one... (tweaks are welcome!)

Description=Archi Steam Farm

[Service]
Type=simple
User=your_user
Environment="MONO_ENV_OPTIONS=--desktop --gc=sgen"
ExecStart=/usr/bin/mono /path/to/ArchiSteamFarm/ASF.exe
Restart=always
RestartSec=15s

[Install]
WantedBy=multi-user.target
Alias=asf.service

As I'm running ASF in a low-memory server, I've set ShutdownOnFarmingFinished=true to all bots (I just leave one account online so I can issue commands!) and ASF can free some memory for other stuff I use in the server.

However, when I need to redeem a CD-KEY to a bot that's offline, I run !start bot, ASF starts it normally, but immediatelly shuts the bot down when it realizes it has nothing to farm, and then I can't redeem the CD-KEY.

IMO, when you !start a bot, it should not go offlinee unless you manually !stop it, overriding the settings in the config file. However, I realized that when I use the !redeem command to an offline bot, when it gets online I assume it tries to redeem it, but I get these errors:

http://pastebin.com/raw/rNFLYLfB

What do you think?

JustArchi commented 8 years ago

You've tried to redeem key on offline instance, so you got an exception - it's obvious.

ShutdownOnFarmingFinished set to true must exit also instances started with !start, otherwise your bots would not automatically shutdown after farming is done.

The only thing which seems logical to me is waiting up to X seconds, and it nothing happens - shutdown.

guihkx commented 8 years ago

I thought it was weird because when I redeemed the CD-KEY to that offline bot, nothing showed up in the console, I only got those messages after I !started the bot. But I guess that's the expected behavior? I don't know, I don't have much knowledge of how ASF works. >:P

JustArchi commented 8 years ago

You can't redeem cd-key to an offline bot, because when bot is offline it's not connected with Steam. That's why exception is thrown.

guihkx commented 8 years ago

Gotcha! I liked the new addition. Thanks!

JustArchi commented 8 years ago

BTW there is no need for --gc=sgen as SGen is default garbage collector since some time already in Mono.

Also I do not recommend Restart=always, you don't want to restart ASF when it crashes or suddenly file disappears, right? Use Restart=on-success instead - ASF uses proper exit code.

guihkx commented 8 years ago

Okay, I'll remove the --gc parameter. Yeah, it might not be good to Restart=always, but in my experience, the mono process got killed so many times because it ran out of memory, so I just set it to restart always because it's annoying.

JustArchi commented 8 years ago

In this case I suggest catching Mono OOM exit code (I don't know which one it is) and using RestartForceExitStatus, which is still better than restarting on every problem.

guihkx commented 8 years ago

I'll definitely check it out. But changing a bit the subject (I know this isn't the right place, but I promise this is the last time hahah).

Do you know what is the requirement to get the unrestricted cards dropping? I noticed in the wiki page you say there's no obvious answer, but maybe the requirement is to at least have one badge manually crafted? From my observations in my accounts, I never issued a refund to any game I bought and in these accounts the drops are restricted. My accounts which don't have the restriction, have at least one badge crafted. Of course it needs more investigation into it, and people who got tons of bots maybe can verify this easily, but it's just a thought. I'm collecting cards to one game and I'll craft it on my restricted account and then I'll see if the restriction is removed right away or after a few days,

JustArchi commented 8 years ago

You're free to test - I don't know. I'm happy to update wiki with any valid theories if you find out something interesting, but I'm not going to become detective Archi trying to find out the reason of restricted card drops. Not to mention that the restriction can change without any reason as well (as stated).

JustArchi commented 8 years ago

Also check https://github.com/JustArchi/ArchiSteamFarm/wiki/Performance#what-is-the-best-way-to-find-out-if-your-account-is-restricted

guihkx commented 8 years ago

Yeah, I've read about this, and none of my bots finishes farming before 2 hours... Anyway, I'll check if my theory is true and I'll give you a heads up. Thank you for your tremendous help,

JustArchi commented 8 years ago

BTW, I spent some time writing https://github.com/JustArchi/ArchiSteamFarm/wiki/Low-memory-setup - you might be interested in order to decrease memory usage of ASF and avoid Mono's OOM. More tricks and improvements are welcome.

guihkx commented 8 years ago

Really useful article, thank you!

My ASF setup is pretty much the same as what you suggested on the ASF section, and they do help a lot. My low budget VPS server have 128MB of RAM, running CentOS 7.2.1511 64-bit and Mono 4.2.3 (by the way, feel free to add it to the "Supported/Tested Operating Systems" section if you want). And honestly, it suits my needs pretty well at the moment. I can have, for example, all of my 10 bots farming one game and ASF will use only 58.9MB of 128MB.

For now I don't intend to try the advanced setup, but maybe in the future when I have more bots or if I run out of memory. I did run out of memory before, but that was because some useless services were enabled. Now that I've disabled them, ASF is running flawlessly. :smile:

Thanks.