Configuration nl NL - Rudokhvist/ArchiSteamFarm GitHub Wiki
Deze pagina is gewijd aan het configureren van ASF. Het dient als een complete documentatie van de config directory, zodat je ASF naar eigen voorkeur kunt instellen.
- Inleiding
- Webtoepassing ConfigGenerator
- ASF-ui configuration
- Handmatige configuratie
- Globale configuratie
- Bot-configuratie
- Bestandsstructuur
- JSON mapping
- Compatibility mapping
- Configs compatibility
- Auto-reload
De ASF-configuratie is onderverdeeld in twee hoofdonderdelen: globale (proces) configuratie en de configuratie van elke bot. Elke bot heeft zijn eigen bot-configuratiebestand met de naam BotNaam.json (waarbij BotNaam de naam is van de bot). De globale ASF (proces) configuratie is een enkel bestand met de naam ASF.json.
Een bot is één steam account dat deelneemt aan het ASF-proces. In order to work properly, ASF needs at least one defined bot instance. There is no process-enforced limit of bot instances, so you can use as many bots (steam accounts) as you want to.
ASF is using JSON format for storing its config files. It's human-friendly, readable and very universal format in which you can configure the program. Don't worry though, you don't need to know JSON in order to configure ASF. I just mentioned it in case you'd already want to mass-create ASF configs with some sort of bash script.
Configuration can be done in several ways. You can use our Web-based ConfigGenerator, which is a local app independent of ASF. You can use our ASF-ui IPC frontend for configuration done directly in ASF. Lastly, you can always generate config files manually, as they follow fixed JSON structure specified below. We'll explain shortly the available options.
The purpose of our Web-based ConfigGenerator is to provide you with a friendly frontend that is used for generating ASF configuration files. Web-based ConfigGenerator is 100% client-based, which means that the details you're inputting are not being sent anywhere, but processed locally only. This guarantees security and reliability, as it can even work offline if you'd like to download all the files and run index.html in your favourite browser.
Web-based ConfigGenerator is verified to run properly on Chrome and Firefox, but it should work properly in all most popular javascript-enabled browsers.
The usage is quite simple - select whether you want to generate ASF or Bot config by switching to proper tab, ensure that chosen version of config file matches your ASF release, then input all details and hit "download" button. Move this file to ASF config directory, overwriting existing files if needed. Repeat for all eventual further modifications and refer to the rest of this section for explanation of all available options to configure.
Our ASF-ui IPC interface allows you to configure ASF as well, and is superior solution for reconfiguring ASF after generating the initial configs due to the fact that it can edit the configs in-place, as opposed to Web-based ConfigGenerator which generates them statically.
In order to use ASF-ui, you must have our IPC interface enabled itself. IPC is enabled by default starting with ASF V5.1.0.0, therefore you can access it right away, as long as you didn't disable it yourself.
After launching the program, simply navigate to ASF's IPC address. If everything worked properly, you can change ASF configuration from there as well.
In general we strongly recommend using either our ConfigGenerator or ASF-ui, as it's much easier and ensures you won't make a mistake in the JSON structure, but if for some reason you don't want to, then you can also create proper configs manually. Check JSON examples below for a good start in proper structure, you can copy the content into a file and use it as a base for your config. Since you're not using any of our frontends, ensure that your config is valid, as ASF will refuse to load it if it can't be parsed. Even if it's a valid JSON, you also have to ensure that all the properties have the proper type, as required by ASF. For proper JSON structure of all available fields, refer to JSON mapping section and our documentation below.
De globale configuratie staat in het ASF.json bestand en heeft de volgende structuur:
{
"AutoRestart": true,
"Blacklist": [],
"CommandPrefix": "!",
"ConfirmationsLimiterDelay": 10,
"ConnectionTimeout": 90,
"CurrentCulture": null,
"Debug": false,
"FarmingDelay": 15,
"FilterBadBots": true,
"GiftsLimiterDelay": 1,
"Headless": false,
"IdleFarmingPeriod": 8,
"InventoryLimiterDelay": 4,
"IPC": true,
"IPCPassword": null,
"IPCPasswordFormat": 0,
"LicenseID": null,
"LoginLimiterDelay": 10,
"MaxFarmingTime": 10,
"MaxTradeHoldDuration": 15,
"MinFarmingDelayAfterBlock": 60,
"OptimizationMode": 0,
"SteamMessagePrefix": "/me ",
"SteamOwnerID": 0,
"SteamProtocols": 7,
"UpdateChannel": 1,
"UpdatePeriod": 24,
"WebLimiterDelay": 300,
"WebProxy": null,
"WebProxyPassword": null,
"WebProxyUsername": null
}All options are explained below:
bool type with default value of true. This property defines if ASF is allowed to perform a self-restart when needed. There are a few events that will require from ASF a self-restart, such as ASF update (done with UpdatePeriod or update command), as well as ASF.json config edit, restart command and likewise. Typically, restart includes two parts - creating new process, and finishing current one. Most users should be fine with it and keep this property with default value of true, however - if you're running ASF through your own script and/or with dotnet, you may want to have full control over starting the process, and avoid a situation such as having new (restarted) ASF process running somewhere silently in the background, and not in the foreground of the script, that exited together with old ASF process. This is especially important considering the fact that new process will no longer be your direct child, which would make you unable e.g. to use standard console input for it.
If that's the case, this property if specially for you and you can set it to false. However, keep in mind that in such case you are responsible for restarting the process. This is somehow important as ASF will only exit instead of spawning new process (e.g. after update), so if there is no logic added by you, it'll simply stop working until you start it again. ASF always exits with proper error code indicating success (zero) or non-success (non-zero), this way you're able to add proper logic in your script which should avoid auto-restarting ASF in case of failure, or at least make a local copy of log.txt for further analysis. Also keep in mind that restart command will always restart ASF regardless of how this property is set, as this property defines default behaviour, while restart command always restarts the process. Unless you have a reason to disable this feature, you should keep it enabled.