本頁面專門用於說明ASF的設定。 這是一份關於​config​資料夾的完整文件，使您能夠依照您的需求調整ASF。

• 簡介
• 設定檔生成器網頁工具
• ASF-ui 設定
• 手動設定
• 全域設定檔
• Bot 設定檔
• 檔案結構
• JSON 映射
• 相容性映射
• 設定檔相容性
• 自動重新載入

ASF的設定分為兩個主要部分⸺全域（程序）設定與每個Bot的設定。 每個Bot都有自己一個名為​BotName.json​的Bot設定檔（​BotName​為Bot的名稱），而全域ASF（程序）設定是一個名為​ASF.json​的檔案。

每個Bot都是一個在ASF程序中執行的獨立Steam帳號。 為了能夠正常運作，ASF需要定義​至少一個​Bot實例。 程序不會強制限制Bot實例的數量，所以您可以依據您的需求使用任意數量的Bot（Steam帳號）。

ASF使用​JSON​格式來儲存自身的設定檔。 這是個人性化、可讀性高且非常通用的格式，您可以在裡面設定程式。 不過不用擔心，您不需要為了設定ASF去專門了解JSON。 我提到它只是考慮到您可能會想要使用一些Bash腳本批次建立大量的ASF設定檔。

您可以經由幾種方式來完成設定。 您可以使用我們的​設定檔生成器網頁工具​，這是一個獨立於ASF的本機應用程式。 您也可以使用我們的IPC前端​ASF-ui​來直接設定ASF。 最後，您也隨時能夠依照下文指定的固定JSON結構，手動生成設定檔。 我們將簡明地解釋這些可用方式。

我們的​設定檔生成器網頁工具​的目標是提供您一個用於生成ASF設定檔的友善前端。 設定檔生成器也是基於用戶端的網頁工具，也就是說，您輸入的任何資訊都不會被上傳，而只會在本機中進行處理。 這保證了安全性與可靠性，因為如果您願意下載所有相關檔案，然後在您偏好的瀏覽器中打開​index.html​，它甚至可以​離線​執行。

設定檔生成器網頁工具在Chrome與Firefox上經過驗證能夠正常執行，且它應該也能在所有支援JavaScript的主流瀏覽器中正常執行。

它的用法非常簡單：切換到適當的分頁來選擇要生成​ASF​設定檔還是​Bot​設定檔，確保所選設定檔的版本與您的ASF版本相符，然後輸入所有詳細資訊，並點擊「下載」按鈕。 最後將這個檔案移動到ASF的​config​資料夾中，如果需要的話，覆蓋掉已經存在的檔案。 若要繼續設定，則重複以上操作，並參考本章節的其他部分來了解所有可設定的選項。

我們的​ASF-ui​ IPC介面也允許您設定ASF，且這是在生成初始設定檔後修改設定的最佳方式，因為與設定檔生成器網頁工具總是生成新的檔案不同，這可以在原地直接編輯設定檔。

為了使用ASF-ui，您必須先啟用​IPC​介面自身。 從ASF V5.1.0.0版本開始，​IPC​預設為啟用，因此只要您沒有把它停用，就可以直接存取它。

在啟動程式後，直接前往ASF的​IPC位址​。 若一切運作正常，您可以在這裡修改ASF設定。

在一般情形下，我們強烈建議使用我們的設定檔生成器或ASF-ui，因為這樣更簡單，且能確保您不會不小心造成JSON結構錯誤。但如果您出於某些原因不想使用它們，那麼您也可以自行建立正確的設定檔。 參考以下的JSON範例，有個好的開始來了解正確的結構。您可以將內容複製到檔案中，並把它當作設定檔的基礎內容。 由於您沒有使用任何我們的前端，請確保您的設定檔​是有效的​，因為如果無法剖析，ASF會拒絕載入。 即使它屬於有效的JSON，您也必須確保所有屬性都有正確的型別，就像ASF所要求的。 關於所有可使用欄位正確的JSON結構，請參閱​JSON映射​及我們下方的文件。

全域設定位於​ASF.json​檔案中，具有下列結構：

{
    "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
}

所有選項的解釋如下：

bool​型別，預設值為​true​。 本屬性定義了是否允許ASF在需要時自行重新啟動。 有些事件會要求ASF自行重新啟動，例如ASF更新（經由​UpdatePeriod​或​update​指令來達成），編輯​ASF.json​設定檔、​restart​指令或類似事件。 通常重新啟動包含兩個部分⸺建立新的程序及結束當前程序。 大多數使用者對此應該沒有問題，且應維持本屬性為預設值​true​，但是⸺若您正在透過自己的腳本並／或經由​dotnet​執行ASF，您可能會想完全控制程序並避免某些情形，例如有新（重新啟動）的ASF程序在背景沉靜執行，而不是在腳本前景與舊的ASF程序一起退出。 考慮到新的程序將不再是您原有程序的直接子程序，這一點特別重要，因為這可能會使您無法為其使用標準控制台輸入。

如果有這樣的情形，那麼本屬性就是為您所準備的，您可以把它設定成​false​。 但是，請注意，在這種情形下​您​需要負責自行重新啟動程序。 這在某種程度上很重要，因為ASF將只會退出，而不會生成新程序（例如在更新後）。因此，若您沒有加入任何邏輯，它將會停止運作直到您再次啟動它。 ASF總是會以正確的錯誤碼退出，指示出成功（零）或不成功（非零）。這樣您就能在腳本中加入正確的邏輯，以避免在故障時自動重新啟動，或至少製作一份本機副本​log.txt​來提供進一步分析。 也請注意，不論如何設定本屬性，​restart​指令總是會重新啟動ASF，因為此屬性只用於定義預設行為，而​restart​指令總能重新啟動程序。 除非您有停用此功能的理由，否則您應維持啟用它。

ImmutableHashSet<uint>​型別，預設值為空。 顧名思義，本全域設定屬性定義了ASF自動掛卡程序要完全忽略的AppID（遊戲）。 但不幸的是，Steam喜歡將夏季／冬季特賣徽章標記成「可掉落的交換卡片」，這誤導了ASF程序，相信這是一個能掛卡的有效遊戲。 若沒有任何形式的黑名單，ASF最終會「掛」在掛卡一個實際上並非遊戲的遊戲上，並無限等待不存在的卡片掉落。 ASF黑名單的目的是將這些徽章標記成無法掛卡，因此我們可以在掛卡時直接忽略它們，而不是落入Bug陷阱。

ASF包含兩個預設的黑名單：​SalesBlacklist​硬編碼於ASF的程式碼中，且無法編輯；一般的​Blacklist​則是在本處定義。 SalesBlacklist​與ASF版本一同更新，且通常會包含在發布時已知的所有「不良」AppID，因此如果您使用最新版的ASF，就不需要自行管理這裡定義的​Blacklist​。 本屬性的主要目的是允許您將ASF發布時未知的新AppID加入黑名單，它們不應被掛卡。 硬編碼的​SalesBlacklist​都會在第一時間更新，因此如果您使用最新版的ASF，就不需要自行更新您的​Blacklist​；但如果沒有​Blacklist​，您就被迫強制更新ASF以在Valve釋出新的特賣徽章時能「正常執行」⸺我並不想強制您使用最新版的ASF程式碼，因此假如您因為某些原因，或無法在新的ASF中更新硬編碼的​SalesBlacklist​，但您又想要讓舊的ASF維持運作，本屬性允許您自行「修復」ASF。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

若您正尋找基於Bot的黑名單，請查看​fb​、​fbadd​及​fbrm​指令​。

string​型別，預設值為​!​。 本屬性指定用於ASF​指令​區分大小寫​的前綴。 也就是說，這是您要在每個ASF指令前加上這個，ASF才會聽從您的指令。 您也可以將此值設定成​null​或留空，來讓ASF不使用前綴，在這種情形下，您可以直接輸入帶有一般識別碼的指令。 但是，這樣做會降低ASF的效能，因為ASF經過最佳化，如果訊息不是以​CommandPrefix​開頭，就不會進一步剖析它⸺若您決定不使用前綴，ASF將會被迫讀取並回應所有訊息，即使它們並不是ASF指令。 因此，若您不喜歡預設值​!​，仍建議繼續使用​CommandPrefix​，如​/​。 為了保持一致，​CommandPrefix​會影響整個ASF程序。 除非您有理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​10​。 ASF會確保在兩次連續的雙重驗證確認提取請求間至少間隔​ConfirmationsLimiterDelay​秒，以避免觸發速率限制⸺這被使用在​ASF雙重驗證​上，例如​2faok​指令，以及在一些與交易相關的操作上面。 預設值是依據我們的測試結果所訂定，如果您不想遇到問題，請勿減少此值。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​90​。 本屬性定義了ASF執行各種網路操作的逾時時間，以秒為單位。 特別是，​ConnectionTimeout​定義了HTTP及IPC請求的逾時秒數，​ConnectionTimeout / 10​定義了心跳機制的最大失敗次數，而​ConnectionTimeout / 30​定義了我們允許初始Steam網路連線請求的分鐘數。 對於大多數人來說，預設值​90​應該是適合的，但是如果您的網路連線或PC速度較慢，您可能會希望增加此值（像是​120​）。 請注意，即使是更大的值也無法神奇地修復緩慢或甚至是無法存取的Steam伺服器，所以我們不應該無限等待不會發生的事情，而是稍後再試。 將此值設定過高會導致在抓取網路問題時出現過多延遲，並降低整體效能。 將此值設定過低會降低整體的穩定性及效能，因為ASF會在尚在剖析時中止有效的請求。 因此，在一般情形下，將此值設定成比預設還要低並沒有任何優點，因為Steam伺服器常常會變得異常緩慢，且可能會需要更多時間來剖析ASF請求。 預設值是相信我們的網路連線穩定，及懷疑Steam網路能在逾時前處理我們的請求之間的平衡。 若您想盡快發現問題，並使ASF更快重新連線／做出回應，預設值就足夠（或稍微低於，像是​60​，使ASF不用等那麼久）。 與之相反，若您發現ASF遇到了網路問題，例如請求失敗、遺失心跳包或與Steam連線中斷，如果您確定這​並非​由您的網路所引起的，而是Steam自身，則增加此值就具意義，因為增加逾時時間可以讓ASF有更多「耐心」，來不會決定要立刻重新連線。

可能需要增加此屬性的一個範例情形是讓ASF處理極大量的交易提案，Steam可能需要2分鐘以上才能完全接受並處理這些提案。 透過增加預設的逾時時間，ASF會更有耐心並等待更長時間，然後才會決定不完成交易並放棄初始請求。

另一種情形可能是設備或網路連線非常緩慢，需要更多的時間來處理正在傳輸的資料。 這是個非常罕見的情形，因為CPU／網路頻寬基本上不會是個瓶頸，但仍是個值得一提的可能性。

簡而言之，在大多數情形下預設值是適合的，但如果需要，您可能會想要增加它。 不過遠高於預設值也沒有任何意義，因為更多的逾時時間也無法神奇地修復無法存取的Steam伺服器。 除非您有理由編輯此屬性，否則您應維持它為預設值。

string​型別，預設值為​null​。 預設情形下，ASF會嘗試使用您的作業系統語言，且如果可以，會優先使用該語言的翻譯字串。 這要感謝我們的社群，他們致力於將ASF​在地化​成各類主流語言。 若出於某種原因，您不想使用您的作業系統原生語言，您可以使用此設定屬性來選擇任意一種您想使用的有效語言。 如需所有可以使用的語言，請造訪​MSDN​來查詢​語言編碼​。 值得一提的是，ASF接受包含特定國家或地區的編碼，例如​"en-GB"​，也接受通用編碼，例如​"en"​。 指定當前語系還可能會影響與地區相關的行為，例如貨幣／日期格式等。 請注意，若您選擇非本機原生語言，您可能會需要額外的字型／語言套件才能正確顯示特定語言的字元。 通常在您偏好以英文而非您的母語使用ASF時，會需要使用這個設定屬性。

bool​型別，預設值為​false​。 本屬性定義了程序是否以除錯模式執行。 在除錯模式中，ASF會在​config​旁建立一個特殊的​debug​資料夾，用於追蹤ASF與Steam伺服器間的所有通訊。 除錯資訊有助於發現與網路及一般ASF工作流程相關的棘手問題。 除此之外，某些程式常式會更加詳細，例如​WebBrowser​會說明某些請求失敗的確切原因⸺這些條目會被寫入至一般的ASF紀錄日誌中。 除非開發人員要求，否則您不應在除錯模式下執行ASF​。 以除錯模式執行ASF會​降低效能​、​減少穩定性​，且會​生成過量除錯訊息​，因此​只應​在需要時短暫使用，用於除錯特定問題、重現錯誤或獲得關於失敗請求的更多資訊，但​不應​用於日常的程式執行階段。 您將會看到​非常大量的​新錯誤、問題及異常狀況⸺若您決定自行分析這些資訊，請確保您對ASF、Steam及其特點有著充分的了解，因為並不是所有資訊皆與問題相關。

警告：​啟用本模式會在紀錄日誌中記錄​可能敏感​的資訊，例如您登入至Steam的帳號及密碼（因網路日誌所記錄）。 這些資料會同時寫入至​debug​資料夾及標準的​log.txt​（現在是故意詳細記錄本資訊）中。 您不應在任何公開位置張貼ASF生成的除錯內容，且ASF開發人員總是會提醒您應經由電子郵件或其他安全位置傳送它。 我們不會儲存或利用這些敏感資訊，它們只是做為除錯常式的一部份而寫入，因為它們或許會與您遇到的問題有關。 我們希望您不以任何方式修改ASF紀錄日誌，但如果您擔心，您還是依然能適當編輯這些敏感資訊。

您可以使用取代的方式替換掉敏感資訊，例如使用星號。 但您需要避免完全刪除包含敏感資訊的資訊行，因為它們可能與問題有關，應予以保留。

byte​型別，預設值為​15​。 ASF會在正常運作時每隔​FarmingDelay​分鐘檢查一次當前掛卡的遊戲是否已掉落所有卡片。 將此屬性設定過低可能會傳送過多的Steam請求，而設定過高可能會使ASF在掛卡完成後仍「掛著」指定遊戲，直到最多滿​FarmingDelay​分鐘。 預設值應該對於大多數使用者來說是適合的，但如果您有很多個Bot在執行，則可以考慮增加至例如​30​分鐘，以限制傳送的Steam請求。 值得一提的是，ASF使用基於事件的機制，並在每個Steam物品掉落時檢查遊戲的徽章頁面，所以在一般情形下，​我們甚至能不必每隔固定時間去檢查​，但由於我們並不完全信任Steam網路⸺如果我們無法在​FarmingDelay​分鐘內未能檢查卡片是否掉落，我們仍會去檢查遊戲的徽章頁面。 假設Steam網路運作正常，降低此值​不會以任何方式提高掛卡效率​，而且​還會顯著增加網路負擔​⸺建議維持預設值​15​分鐘，並只在需要時才增加它。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

bool​型別，預設值為​true​。 本屬性定義了ASF是否會自動拒絕已知被標示成惡劣行為者的交易提案。 為此，ASF會依據需要與我們的伺服器通訊，以提取Steam ID黑名單清單。 列出的那些Bot，是我們歸類為對ASF有害的人所操作的，例如那些違反我們的​行為準則​、使用我們提供的功能及資源例如​PublicListing​來濫用或利用他人，或是從事直接犯罪行為例如對伺服器發動DDoS攻擊的人。 因為ASF對於使用者之間的整體公平、誠信及合作方面有堅定的立場，以使得整體社群蓬勃發展，因此預設情形下此屬性為啟用，ASF會篩選掉歸類為對我們提供的服務有害的Bot。 除非您有​充分的​理由編輯此屬性，例如不同意我們的聲明，並故意允許這些Bot進行操作（包含利用您的帳號），否則您應維持它為預設值。

byte​型別，預設值為​1​。 在兩個連續的贈禮／序號／授權處理（兌換）請求間，ASF會確保至少間隔​GiftsLimiterDelay​秒，以避免觸發速率限制。 除此之外，這也用於遊戲清單請求的全域限制器，例如由​owns​指令​所發出的請求。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

bool​型別，預設值為​false​。 本屬性定義了程序是否以無頭模式執行。 在無頭模式中，ASF會假定它在伺服器或其他非互動式環境下執行，因此它不會嘗試在控制台輸入中讀取任何資訊。 這包含了隨選詳細資料（帳號憑證，例如雙重驗證代碼、Steam Guard代碼、密碼，或ASF操作所需的其他任何變數），及其他所有控制台輸入（例如互動式指令控制台）。 也就是說，​Headless​模式等同於將ASF控制台變成唯讀。 本設定主要給在伺服器上執行ASF的使用者使用，在需要使用者輸入（例如雙重驗證代碼）時，ASF將會直接停止使用該帳號以中止輸入操作。 除非您在伺服器上執行ASF，且您先前已確認ASF能夠在非無頭模式中執行，否則您應維持停用它。 在無頭模式下，任何使用者互動行為皆會被拒絕，如果您的帳號在啟動過程中需要​任何​控制台輸入，則帳號不會啟動。 這對伺服器來說非常有用，因為ASF可以在要求提供憑證時嘗試中止帳號登入，而不是（無限）等待使用者提供這些憑證。 啟用此模式也會允許您能夠使用​input​指令​，來作為標準控制台輸入的替代方式。 若您不確定如何設定本屬性，請保留預設值​false​。

若您在伺服器上執行ASF，您可能會需要將本選項與​--process-required​命令列引數​一起配合使用。

byte​型別，預設值為​8​。 當ASF沒有東西掛卡時，它會每隔​IdleFarmingPeriod​小時檢查帳號內是否擁有新遊戲可供掛卡。 在我們獲得新遊戲時，並不需要此功能，因為ASF足夠智慧，可以在這種情形中自動檢查徽章頁面。 IdleFarmingPeriod​主要是針對我們在帳號中已有的遊戲新加入了交換卡片功能的情形。 在這種情形下不會產生事件，因此如果我們要知道這件事，ASF就必須定期檢查徽章頁面。 將值設定為​0​時會停用本功能。 也請注意：​ShutdownOnFarmingFinished​。

byte​型別，預設值為​4​。 ASF會確保在兩次連續的物品庫請求間至少間隔​InventoryLimiterDelay​秒，以避免觸發速率限制⸺這被使用在提取Steam物品庫時，特別是在您自己的指令中，例如​loot​或​transfer​。 預設值​4​是依據連續提取超過100個Bot實例的物品庫所設定的，應該能滿足大部分（可能不是全部）的使用者需求。 但是，如果您的Bot數量很少，您可能會想要減少它，或甚至把它更改成​0​，使ASF忽略延時並加快獲得Steam物品庫。 但請注意，設定過低的值​將會​導致Steam暫時封鎖您的IP，並完全阻止您提取您的物品庫。 若您執行了很多需要大量物品庫請求的Bot，您可能還會需要增加此值，但在這種情形下，您可能更應該去限制這些請求的數量。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

bool​型別，預設值為​true​。 本屬性定義了ASF的​IPC​伺服器是否與主程序一同啟動。 IPC允許行程間通訊，包含透過啟動本機HTTP伺服器使用​ASF-ui​。 若您不打算使用任何ASF的第三方IPC整合工具，包含我們的ASF-ui的話，您就可以安全地停用這個選項。 否則，最好保持啟用狀態（預設狀態）。

string​型別，預設值為​null​。 本屬性定義了每個經由IPC執行的API呼叫的強制性密碼，作為一項額外的安全措施。 當設定成非空值時，所有的IPC請求都會需要額外的​password​屬性，為此處指定的密碼。 預設值​null​將會跳過要求密碼，並使ASF接受所有請求。 除此之外，啟用此選項也會啟用內建的IPC反暴力破解機制，一個​IPAddress​在非常短的時間內傳送過多未授權的請求時，將會被暫時封鎖。 除非您有理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​0​。 本屬性定義了​IPCPassword​屬性的格式，使用​EHashingMethod​作為基本類型。 若需了解更多，請參閱​安全性​章節，因為您需要確保​IPCPassword​屬性確實包含匹配IPCPasswordFormat​的密碼。 也就是說，在您更改​IPCPasswordFormat​的時候，您的​IPCPassword​就必須​已經​是您所選的格式了，而不是在更改完成後才是。 除非您知道您在做什麼，否則請保留預設值​0​。

Guid?​型別，預設值為​null​。 本屬性允許我們的​贊助者​使用付費的選擇性功能來增強ASF的運作能力。 在目前，這允許您使用​ItemsMatcher​外掛程式中的​MatchActively​功能。

While we recommend you to utilize GitHub since it offers monthly and one-time tiers, as well as allows full automation and gives you immediate access, we also support all other currently-available donation options. See this post for instructions on how to donate using other methods in order to get a manual license valid for given period.

Regardless of the method used, if you're ASF sponsor, you can obtain your license here. 您會需要以GitHub登入來確認您的身分，我們只會請求您的公開唯讀資訊，也就是您的使用者名稱。 LicenseID​由32個十六進制字元組成，例如​f6a0529813f74d119982eb4fe43a9a24​。

請確保您沒有與其他人共用您的​LicenseID​。 因為它是給個人使用的，如果洩漏出去就有可能被撤銷。 如果不幸您意外洩漏了授權碼，您可以在相同地方生成一個新的。

除非您想要啟用ASF的額外功能，否則您沒有必要在此提供授權碼。

byte​型別，預設值為​10​。 在兩個連續的連線嘗試間，ASF會確保至少間隔​LoginLimiterDelay​秒，以避免觸發速率限制。 預設值​10​是依據超過100個Bot實例的連線所設定的，應該能滿足大部分（可能不是全部）的使用者需求。 但是，如果您的Bot數量很少，您可能會想要增加／減少它，或甚至把更改成​0​，使ASF忽略延時並加快連線至Steam。 但請注意，在有很多Bot的情形下​將會​導致Steam暫時封鎖您的IP，觸發​InvalidPassword/RateLimitExceeded​錯誤，並​完全​阻止您登入⸺不只是在ASF，也包含您的Steam用戶端那邊。 同理，如果您執行大量Bot，特別是在同一IP位址內一起使用其他Steam用戶端／工具，您可能還會需要增加此值，以將登入請求分散至更長的時間段。

另外說明一下，此值還會用於所有ASF計畫任務的附載平衡緩衝，例如在​SendTradePeriod​中的交易。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​10​。 如您所知，Steam並不總是能正常運作，有時候會發生奇怪的狀況，例如雖然我們正在遊玩，但沒有到紀錄我們的遊玩時數上。 ASF允許一個遊戲在單一遊戲模式下最多掛卡​MaxFarmingTime​小時，並在此之後認為該遊戲已完成掛卡。 這是為了在發生怪異情形時不會使掛卡程序卡住所必需的，也可能Steam因為某種原因釋出了一個新的徽章，而使ASF卡住掛卡進度（參見：​Blacklist​）。 預設值​10​小時應該足以使一個遊戲掉落全部的交換卡片。 將此屬性設定過低可能會使ASF跳過有效的遊戲（是的，有些遊戲甚至需要長達9小時卡片才能全部掉完），設定過高則可能會導致掛卡程序卡住過久。 請注意，本屬性只會影響單次掛卡期間的單一遊戲（在完成整個佇列後，ASF將會重新計時），此外，此屬性並非依據遊玩時數，而是ASF內部的掛卡時數，因此ASF也會在重新啟動後重新計時。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​15​。 本屬性定義了我們願意接受的交易託管最大天數⸺ASF會拒絕保留超過​MaxTradeHoldDuration​天的交易，如​交易​章節所述。 此選項只會作用於在​TradingPreferences​中啟用了​SteamTradeMatcher​的Bot，而不會影響來自​Master​／​SteamOwnerID​的交易，也不影響贈禮。 對每個人來說，交易託管是非常惱人的，沒有人想被它打擾。 ASF應在自由的原則下幫助每個人使用，不論是否有交易託管⸺這就是為什麼本選項的預設值為​15​。 但是，如果您想要拒絕所有具交易託管的交易，您可以在此處設定成​0​。 請注意以下說明：有時間限制的交換卡片不受此選項影響，且ASF會自動拒絕具有交易託管的交易，如​交易​章節所述，所以沒有必要只因為這個原因而拒絕所有人。 除非您有理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​60​。 本屬性定義了以秒為單位的最小時間，如果ASF先前因為​LoggedInElsewhere​而失去連線，則在等待這段時間後才會再次恢復掛卡：如果您決定以執行遊戲來強制使當前掛卡的ASF斷線，就會產生這種情形。 這種延遲存在的原因主要是為了方便並節省負擔，例如它使您能夠重新啟動遊戲，不必因為那一兩秒鐘的空檔，去跟ASF爭奪帳號的使用權。 由於重新獲得連線階段會使​LoggedInElsewhere​失去連線，ASF就必須執行整個重新連線的流程，這會使設備及Steam網路增加額外的壓力，因此能夠的話，避免掉所有不必要的斷線。 預設情形下，本屬性設定成​60​秒，這應該足以讓您輕鬆重新啟動遊戲了。 但是，在某些情境中您可能會希望增加此值，例如您的網路經常失去連線，且ASF會太快接管，這會導致您被迫自行重新連線。 此屬性的最大允許值為​255​，這應該足以應付所有常見情境。 除了上述情形外，您也可以減少甚至設定成​0​來完全取消本延遲，但因上述原因，我們通常不建議這樣做。 除非您有理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​0​。 本屬性定義了ASF在執行期間偏好的最佳化模式。 目前，ASF支援兩種模式：​0​為​MaxPerformance​；​1​為​MinMemoryUsage​。 預設情形下，ASF會盡可能地平行（並行）執行越多的工作，以跨CPU核心、多個CPU執行緒、多個網路插座及多個執行緒集區工作來增強效能。 舉例來說，ASF會在檢查需要掛卡的時查詢您的第一頁徽章頁面，在請求完成後，ASF會從中讀取您實際的徽章頁數，然後同時向所有剩餘頁面傳送請求。 這​基本上​就是您所想要的，因為在大多數情形下負擔是最小的，即使在單個CPU核心和非常有限功率的老舊硬體上，也能看到ASF異步程式碼的好處。 但是，由於許多工作是平行處理的，因此ASF需要在執行期間負責維護它們，例如維持網路插座開啟、執行緒處於活動狀態及工作有被處理，這可能會導致記憶體使用量不時增加。若您的可用記憶體嚴重受限，您可能會想要切換本屬性為​1​（​MinMemoryUsage​）來強制ASF處理盡可能少的工作，並盡量以同步方式執行可平行處理的異步程式碼。 只有在您已詳閱​低記憶體設定​後，且決定想要犧牲大量效能以獲得節省極少量的記憶體負擔時，才應考慮開啟此屬性。 通常本選項比您能夠使用的其他方式達成的成效還來得​差得多​，例如經由限制您的ASF使用，或調整執行環境的垃圾收集器，如​低記憶體設定​所述。 因此，如果您無法經由其他（更好的）方式獲得滿意的結果，則應將​MinMemoryUsage​作為重新編譯執行環境前的​最後手段​。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

string​型別，預設值為​"/me "​。 本屬性定義了加入至ASF送出的所有Steam訊息最開頭的前綴。 預設情形下，ASF使用​"/me "​為前綴，使Steam聊天以不同顏色顯示Bot訊息，以便更容易區分它們。 另一個值得提及的前綴是​"/pre "​，它有相似的結果，但有著不同的格式。 您也可以將本屬性設定成空值或​null​來完全停用前綴，並以傳統的方式輸出所有ASF訊息。 值得一提的是，本屬性只會影響Steam訊息⸺以其他通道（例如IPC）回傳的回應不會受到影響。 除非您想要自訂標準的ASF行為，否則最好保留預設值。

ulong​型別，預設值為​0​。 本屬性定義了ASF程序擁有者的64位元Steam ID，與指定Bot實例的​Master​權限非常相似（但作用於全域）。 基本上您會想要將本屬性設定成您自己的Steam主帳號的ID。 Master​權限包含對該Bot實例的完全控制，但是全域指令例如​exit​、​restart​或​update​則只能由​SteamOwnerID​使用。 這很方便，因為您可能想要為您的朋友執行Bot，但同時不允許他們控制ASF程序，例如使用​exit​指令退出程序。 預設值​0​代表ASF程序沒有擁有者，這代表沒有人能使用全域ASF指令。 請注意此屬性只適用於Steam聊天，即使沒有設定本屬性，​IPC​與互動式控制台仍會允許您執行​Owner​指令。

byte flags​型別，預設值為​7​。 本屬性定義了ASF在連線Steam伺服器時使用的Steam網際網路協定，其定義如下：

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項，且該選項本身無效。

預設情形下，ASF會使用所有可以使用的Steam協定，作為應對當機期間及其他相似的Steam問題的措施。 通常若您想限制ASF使用一個或兩個指定的協定，而不是所有可用的協定時，您會想要修改此屬性。 例如若您在防火牆中啟用只啟用了TCP的流量，且您不希望ASF嘗試透過UDP連線，就可能會需要這樣的措施。 但是，除非您在除錯特定問題，否則您基本上會希望確保ASF能夠自由使用當前支援的所有協定，而不是只有一兩個。 除非您有​充分的​理由編輯此屬性，否則您應維持它為預設值。

byte​型別，預設值為​1​。 本屬性定義了ASF使用的更新通道，用於自動更新（如果​UpdatePeriod​大於​0​時），或更新通知（​UpdatePeriod​為​0​時）。 目前ASF支援三個更新通道：​0​為​None​；​1​為​Stable​；而​2​為​Experimental​。 Stable​通道是預設的發布通道，這適合大多數的使用者。 Experimental​除了​Stable​版本以外，也包含了專門提供進階使用者及其他開發人員測試新功能、確認錯誤修復或提供相關增強計畫回饋的​預覽版本​。 實驗性版本通常包含了尚未修補的錯誤、未完成或重寫的功能​。 若您任為您並非進階使用者，請保留預設值​1​（穩定的）更新通道。 Experimental​通道是專門提供給知道如何回報錯誤、處理問題並給予回饋的使用者所使用⸺我們不會提供任何技術支援。 若您想了解更多，請參閱​發布週期​。 若您想完全停用所有版本檢查，您也可以將​UpdateChannel​設定成​0​（​None​）。 將​UpdateChannel​設定成​0​會完全停用與更新相關的功能，包含​update​指令。 強烈反對​您使用​None​通道，因為這會使您自己面臨各種問題（在下文​UpdatePeriod​的說明中有提到）。

除非您知道您在做什麼，否則我們​強烈​建議維持它為預設值。

ushort​型別，預設值為​300​。 本屬性定義了ASF每隔多久會檢查一次自動更新。 更新是非常重要的，不僅能獲得新功能及重要安全補丁，也能修復錯誤、獲得效能增加及提高穩定性等。 當設定的值大於​0​時，ASF會在有新版本可供使用的時候自動下載、取代並重新啟動自身（如果​AutoRestart​允許）。 為了達到上述功能，ASF會每​UpdatePeriod​小時檢查一次我們的GitHub儲存庫上是否有新版本可供使用。 值為​0​會停用自動更新，但您仍能夠手動執行​update​指令。 您可能還會對​UpdatePeriod​需要設定的正確的​UpdateChannel​感興趣。

ASF的更新過程涉及到更新整個ASF所使用的資料夾結構，但不會動到位於​config​資料夾中您自己的設定檔或資料庫⸺這代表在ASF資料夾中的所有無關檔案都會在更新過程中遺失。 預設值​24​能在不必要的檢查與維持ASF足夠新之間取得不錯的平衡。

除非您有​充分的​理由停用此屬性，否則您應維持使用合理的​UpdatePeriod​來啟用自動更新，​這是為了你好​。 這不只是因為我們只支援最新的穩定版ASF，也因為​我們只對最新版本提供安全保證​。 若您使用過時的ASF版本，您就是故意讓您自己暴露於各種問題下，從小型錯誤、損壞的功能，到​Steam帳號永久停權​，所以我們​強烈建議​，為了你好，請始終確保您的ASF版本是最新的。 自動更新使我們能夠對任何問題快速反應，在造成後果之前能停用或修補有問題的程式碼⸺若您選擇停用，您會失去我們所有的安全保證，並需承擔執行可能的有害程式碼的風險後果，不只是對Steam網路，也包含您自己的Steam帳號。

ushort​型別，預設值為​300​。 本屬性定義了向同一個Steam Web服務傳送兩個連續請求間的最小延遲，以毫秒為單位。 這種延遲是必需的，因為Steam內部使用的​AkamaiGhost​服務包含了依據指定時間段內傳送請求總數的速率限制。 在正常情形下很難處發Akamai的限制，但如果我們在極短的時間內持續傳送過多的請求，導致異常繁重的工作負載及大量的持續佇列請求，就有可能觸發它。

預設值是依據假設ASF是存取Steam Web服務的唯一工具所設定的，特別是​steamcommunity.com​、​api.steampowered.com​及​store.steampowered.com​。 若您使用了其他工具向同一Web服務傳送請求，那麼您應確保您的工具也包含類似​WebLimiterDelay​的功能，並將兩者都設為預設值的兩倍，也就是​600​。 這能保證在任何情形下，您都不會在每個​300​毫秒中傳送超過1個請求。

在一般情形下，將​WebLimiterDelay​減少至預設值以下是​強烈反對這麼做的​，因為它可能會導致各種IP相關的封鎖，有可能會是永久的。 預設值足以在伺服器上執行單一ASF實例，或在普通情境下與原版的Steam用戶端一起使用ASF。 對於大多數用法來說這應該是正確的值，且您應該只能增加它（永遠不要減少），除非⸺除了ASF之外，您還使用了另一個可能會向ASF所使用的Web服務傳送大量請求的工具。 簡而言之，由單一IP傳送至單個Steam網域的請求總量每​300​毫秒不應大於1個請求。

除非您有理由編輯此屬性，否則您應維持它為預設值。

string​型別，預設值為​null​。 本屬性定義了網頁代理位址，用於ASF的​HttpClient​傳送的所有HTTP及HTTPS請求，特別是例如​github.com​、​steamcommunity.com​及​store.steampowered.com​服務。 在一般情形下，代理ASF請求並沒有好處，但它對於繞過各式各樣的防火牆來說特別有用，特別是中國的長城防火牆。

本屬性定義為URI本文：

URI字串由協定名稱（支援：http/https/socks4/socks4a/socks5）、主機名稱及選擇性的連接埠所組成。 一個完整URI字串的範例是​"http://contoso.com:8080"​。

若您的代理需要使用者身分驗證，您還需要設定​WebProxyUsername​與／或​WebProxyPassword​。 若不需要，則僅設定本屬性即可。

目前ASF只對​HTTP​及​HTTPS​請求使用網際網路代理，​不包含​在ASF內部Steam用戶端完成的內部Steam網路通訊。 目前並無支援該功能的計畫，其主要原因是缺少了​SK2​功能。 若您需要／希望支援此功能，我建議可以先從此處了解。

除非您有理由編輯此屬性，否則您應維持它為預設值。

string​型別，預設值為​null​。 本屬性定義了要提供代理功能的目標​WebProxy​設備支援的Basic、Digest、NTLM或Kerberos身分驗證所使用的密碼欄位。 若您的代理不需要使用者憑證，您就不需要再此處輸入任何內容。 本選項只有在使用了​WebProxy​的情形下才有用處，否則它沒有任何效果。

除非您有理由編輯此屬性，否則您應維持它為預設值。

string​型別，預設值為​null​。 本屬性定義了要提供代理功能的目標​WebProxy​設備支援的Basic、Digest、NTLM或Kerberos身分驗證所使用的使用者名稱欄位。 若您的代理不需要使用者憑證，您就不需要再此處輸入任何內容。 本選項只有在使用了​WebProxy​的情形下才有用處，否則它沒有任何效果。

除非您有理由編輯此屬性，否則您應維持它為預設值。

如您所已知的，每個Bot都有自己的設定檔，使用基於下列範例的JSON結構： 首先您需要決定您的Bot的名稱（例如​1.json​、​main.json​、​primary.json​或​AnythingElse.json​），然後再開始設定。

注意：​Bot無法被命名為​ASF​（因為該關鍵字保留為全域設定），ASF也會忽略所有以點為開頭的設定檔。

Bot設定檔具有以下結構：

{
    "AcceptGifts": false,
    "AutoSteamSaleEvent": false,
    "BotBehaviour": 0,
    "CompleteTypesToSend": [],
    "CustomGamePlayedWhileFarming": null,
    "CustomGamePlayedWhileIdle": null,
    "Enabled": false,
    "FarmingOrders": [],
    "FarmPriorityQueueOnly": false,
    "GamesPlayedWhileIdle": [],
    "HoursUntilCardDrops": 3,
    "LootableTypes": [1, 3, 5],
    "MatchableTypes": [5],
    "OnlineFlags": 0,
    "OnlineStatus": 1,
    "PasswordFormat": 0,
    "Paused": false,
    "RedeemingPreferences": 0,
    "RemoteCommunication": 3,
    "SendOnFarmingFinished": false,
    "SendTradePeriod": 0,
    "ShutdownOnFarmingFinished": false,
    "SkipRefundableGames": false,
    "SteamLogin": null,
    "SteamMasterClanID": 0,
    "SteamParentalCode": null,
    "SteamPassword": null,
    "SteamTradeToken": null,
    "SteamUserPermissions": {},
    "TradeCheckPeriod": 60,
    "TradingPreferences": 0,
    "TransferableTypes": [1, 3, 5],
    "UseLoginKeys": true,
    "UserInterfaceMode": 0
}

所有選項的解釋如下：

bool​型別，預設值為​false​。 啟用時，ASF會自動接受並兌換所有發送給Bot的Steam禮物（包含錢包禮物卡）。 這也包含了不在​SteamUserPermissions​中定義的使用者所發送的禮物。 請注意，發送到電子郵件的禮物不會直接轉發給用戶端，所以ASF無法在沒有您幫助的情形下接受這些禮物。

本選項建議只在小號上使用，因為您很有可能不希望在主要帳號上自動兌換所有發送過來的禮物。 若您不確定您是否想要啟用本功能，請保留預設值​false​。

bool​型別，預設值為​false​。 眾所周知，在Steam夏季／冬季特賣活動期間，Steam透過每日瀏覽探索佇列或其他活動特定事件來提供您額外的交換卡片。 啟用本選項時，ASF會每隔​8​小時自動檢查Steam探索佇列（從程式啟動一小時內開始），並在需要時完成它。 若您想自己執行該行為，則不建議使用本選項，因為在一般情形下本選項只對Bot帳號有意義。 此外，若您想要收到這些交換卡片，您需要確保您的帳號等級至少​8​等，這是Steam本身的限制。 若您不確定您是否想要啟用本功能，請保留預設值​false​。

請注意，由於Valve經常產生問題或改動，​我們無法保證本功能是否能運作正常​，因此本選項是很有可能​完全無效​的。 我們不接受​任何​相關的錯誤報告，也不支援關於本選項的請求。 這是在沒有任何保證的情形下所提供的，您需要自行承擔風險。

byte flags型別​，預設值為​0​。 本屬性定義了在各種事件中ASF的自動化行為，定義項如下：

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項。

在一般情形下，若您想要ASF有一定的自動化行為，像使用Bot帳號，而不是ASF主要帳號的那樣，就需要更改本屬性。 因此，本屬性主要用於小號，但您仍可在主要帳號上使用所選選項。

一般（​None​）模式的ASF行為只是將使用者所想要的自動化（例如自動掛卡或​SteamTradeMatcher​交易，如果在​TradingPreferences​中有設定）。 這是對帳號控制最少的模式，並對大多數使用者來說都不錯，因為您可以完全控制您的帳號，且能自行決定是否允許某些超出範圍的交互行為。

無效的好友邀請是指由不具​FamilySharing​或更高權限（定義於​SteamUserPermissions​）的使用者所發出的好友邀請。 如您所預期的那樣，一般模式下的ASF會忽略這些邀請，給予您自由選擇是否接受邀請的空間。 RejectInvalidFriendInvites​會使這些邀請被自動拒絕，實際上這會阻止其他人將您加入至他們的好友清單中（因為ASF會拒絕所有這類請求，除非他們在​SteamUserPermissions​中有被定義）。 除非您想要徹底拒絕所有好友邀請，否則您不應啟用本選項。

無效的交易提案是指不被ASF內建模組接受的交易。 關於本問題的更多資訊，可以在​交易​章節中找到，其中明確定義了ASF願意自動接受哪些類型的交易。 有效的交易還會被其他設定所定義，特別是​TradingPreferences​。 RejectInvalidTrades​會使所有無效的交易提案被拒絕，而不是被忽略。 除非您想要直接拒絕所有ASF未自動接受的交易提案，否則您不應啟用本選項。

無效的群組邀請是指來自​SteamMasterClanID​群組以外的邀請。 如您所預期的那樣，一般模式下的ASF會忽略這些邀請，使您可以自行決定是否要加入特定的群組。 RejectInvalidGroupInvites​會使這些群組邀請被拒絕，使您無法加入​SteamMasterClanID​以外的其他任何群組。 除非您想要徹底拒絕所有群組邀請，否則您不應啟用本選項。

若您開始對收到新物品的通知感到厭煩時，​DismissInventoryNotifications​會是一個相當有用的功能。 ASF無法去除通知本身，因為它是您Steam用戶端內建的功能，但它能在收到通知後自動清除通知，這樣就不會留有「新物品在您的物品庫」的通知了。 若您希望自行評估所收到的物品（特別是ASF掛到的卡片），那麼很明顯您不應該啟用本選項。 但如果您快要開始被煩到抓狂了，切記這裡有個選項可以使用。

MarkReceivedMessagesAsRead​會自動將ASF執行的帳號所收到的​所有​訊息標示成已讀，包含私人及群組聊天。 這通常只應由小號所使用，以清除例如在執行ASF指令期間來自您的「新訊息」通知。 我們不建議在主要帳號上使用本選項，除非您希望能隔絕所有種類的訊息通知，​包含​在您離線時的通知，ASF仍會清除它們。

MarkBotMessagesAsRead​以類似的方式運作，但只會將Bot的訊息標示成已讀。 但請注意，在使用本選項時，若您的Bot與其他人都在群組聊天中，已知Steam在將聊天訊息標示成已讀時，​也​會將​該訊息前的​訊息標示成已讀，所以如果您不想要錯過在這期間的其他訊息，就應該避免使用本功能。 很顯然，當您在同一個ASF實例上執行多個主要帳號（例如其他使用者的帳號）時也是有風險的，因為您可能會錯過正常的無關ASF的訊息。

若您不確定如何設定本選項，最好保留預設值。

ImmutableHashSet<byte>​型別，預設值為空。 在ASF完成收集一套此處設定的物品類型時，它可以透過Steam交易傳送所有收集完成的物品套組自動傳送給具有​Master​權限的使用者，如果您想將指定的Bot帳號用於例如TM匹配等需求，同時將收集完成的套組移動至另一個帳號上，這將會非常方便。 本選項與​loot​指令作用相同，因此請注意，首先它需要您有帳號的交易合法權限，且使用者具有​Master​權限，而您可能也要有有效的​SteamTradeToken​。

目前，在本設定中支援下列物品類型：

請注意，不論上述如何設定，ASF都只會處理Steam分類（​appID​為753）中的社群物品（​contextID​為6），因此依據定義所有遊戲物品、禮物等物品都會被排除在交易提案之外。

由於使用本選項會造成額外負擔，我們建議您只在有機會收集完成物品的Bot帳號上使用⸺舉例來說，若您平常已在使用​SendOnFarmingFinished​、​SendTradePeriod​或​loot​指令，就沒有必要使用本選項。

若您不確定如何設定本選項，最好保留預設值。

string​型別，預設值為​null​。 在ASF掛卡時，可以顯示「非Steam遊戲中：​CustomGamePlayedWhileFarming​」而非正在掛卡的遊戲名稱。 若您想讓您的朋友知道您正在掛卡，卻又不想使用​Offline​的​OnlineStatus​時，這就非常有用。 請注意，ASF無法保證Steam網路的實際顯示順序，因此這只能為一個建議值，可能會正確顯示，也可能不會。 特別是，如果ASF需要使用很長一段時間來完成已滿的​32​個遊戲欄位，自訂名稱就無法顯示在​Complex​的掛卡演算法中。 預設值​null​會停用本功能。

ASF提供了數種您能在本文中使用的特殊變數。 {0}​會被取代成ASF正在掛卡的遊戲的​AppID​；而​{1}​會被取代成ASF正在掛卡的遊戲的​GameName​。

string​型別，預設值為​null​。 與​CustomGamePlayedWhileFarming​類似，但是是用於ASF閒置的時候（因為帳號已掛卡完成）。 請注意，ASF無法保證Steam網路的實際顯示順序，因此這只能為一個建議值，可能會正確顯示，也可能不會。 若您與本選項同時使用​GamesPlayedWhileIdle​，那麼請注意，​GamesPlayedWhileIdle​的優先級更高，因此您不可以宣告超過​31​個遊戲，否則​CustomGamePlayedWhileIdle​會無法占用遊戲欄位來顯示自訂名稱。 預設值​null​會停用本功能。

bool​型別，預設值為​false​。 本屬性定義了是否啟用Bot。 啟用Bot實例（​true​）會自動在ASF執行後開啟，而停用Bot實例（​false​）就需要您手動開啟。 預設情形下，每個Bot都是停用的，因此您可能希望將需要自動啟動的Bot切換本屬性至​true​。

ImmutableList<byte>​型別，預設值為空。 本屬性定義了指定Bot帳號的​首選​掛卡順序。 目前有以下可供使用的掛卡順序：

由於本屬性為一個陣列，因此它允許您以多個設定值來設定您的掛卡順序。 舉例來說，您可以依序設定數值​15​、​11​及​7​，來先以掉落可交易卡片的遊戲排序，然後再以最高徽章等級排序，最後才以字母順序排序。 正如您所猜測的，實際上順序非常重要，因為反向的排序（​7​、​11​及​15​）會造成截然不同的結果（首先由字母順序排序，但由於遊戲名稱是唯一的，其他兩個排序實際上是無作用的）。 大多數的人可能只會使用其中一個順序，但如果您想要，您也可以透過額外的參數來進一步排序。

另請注意，在上述所有描述中都有字詞「嘗試」⸺ASF實際的排序受​交換卡片掛卡演算法​的嚴重影響，且排序只能影響ASF認為效能相同的結果。 舉例來說，在​Simple​演算法中，選擇​FarmingOrders​能影響全部的當前掛卡階段（因為每個遊戲都具有相同的效能值），但在​Complex​演算法中，實際的掛卡順序會先受遊玩時數所影響，然後才依所選的​FarmingOrders​排序。 這將產生不同的結果，因為具有遊玩時數的遊戲會優先於其他的，因此ASF會優先選擇已滿足​HoursUntilCardDrops​要求的遊戲，然後才會依您選擇的​FarmingOrders​進一步排序那些遊戲。 同樣，一旦ASF完成高優先遊戲的掛卡，它將會先依遊玩時數對佇列進行排列（因為這能減少將任何遊戲掛至​HoursUntilCardDrops​所需的時間）。 因此，本設定屬性只是給ASF參考的一個​建議​，只要它不會對效能產生負面影響（若有負面影響，ASF則總是會在掛卡時優先考慮效能，其次才是​FarmingOrders​）。

另外，您還可透過​fq​指令​來存取掛卡優先佇列。 若使用優先佇列，則實際的掛卡順序首先由效能排序，然後是掛卡佇列，最後才是您的​FarmingOrders​。

bool​型別，預設值為​false​。 本屬性定義了ASF是否只自動掛卡您使用​fq​指令​加入至優先掛卡佇列中的應用程式。 在啟用本選項時，ASF將會跳過所有不在清單中的​appIDs​，使您能夠挑選您想要ASF自動掛卡的遊戲。 請注意，若您沒有在佇列中加入任何遊戲，ASF會表現得像您帳號中沒有任何遊戲可以掛卡一樣。 若您不確定您是否想要啟用本功能，請保留預設值​false​。

ImmutableHashSet<uint>​型別，預設值為空。 若ASF沒有遊戲可供掛卡，它可以遊玩您所指定的Steam遊戲（​appIDs​）。 以這種方式遊玩遊戲會增加您的「遊玩時數」，除此之外，別無他用。 若要使此功能正常運作，您的Steam帳號​必須​擁有您指定的所有​AppIDs​的有效許可，包含免費遊戲。 本功能可以與​CustomGamePlayedWhileIdle​同時啟用，能在遊玩您所指定的遊戲的同時在Steam網路中顯示自訂狀態。但在這種情形下，如同​CustomGamePlayedWhileFarming​一樣，我們無法保證實際的顯示順序。 請注意，Steam只允許ASF最多同時遊玩​32​個​appIDs​，因此您也只能在本屬性中設定最多這個數量的遊戲。

byte​型別，預設值為​3​。 本屬性定義了帳號是否受到掉卡限制，若有，則定義初始小時數。 掉卡受限制代表該帳號在遊戲的遊玩時數在到達​HoursUntilCardDrops​小時後才會開始掉卡。 但ASF沒有自動偵測它的魔法，所以只能靠您手動設定。 本屬性會影響您所使用的​掛卡演算法​。 正確設定本屬性會最大化您的效益，並將掛卡所需的時間減至最少。 記住，您應該選擇何值並沒有確切的答案，因為這完全取決於您的帳號。 似乎從未要求退款的老帳號​掉卡不受限制​，而曾經要求退款的新帳號則會​受限制​。 但是，這只是理論，不應將它視為規則。 本屬性的預設值是依據「兩害相權取其輕」及大多數使用情形所設定的。

ImmutableHashSet<byte>​型別，預設值為​1, 3, 5​的Steam物品類型。 本屬性定義了ASF在獲得物品時的行為⸺這可以是手動使用​指令​，也可以透過一個或多個設定屬性來自動獲得。 請注意，不論上述如何設定，ASF都只會處理Steam分類（​appID​為753）中的社群物品（​contextID​為6），因此依據定義所有遊戲物品、禮物等物品都會被排除在交易提案之外。

請注意，不論上述如何設定，ASF都只會處理Steam分類（​appID​為753）中的社群物品（​contextID​為6），因此依據定義所有遊戲物品、禮物等物品都會被排除在交易提案之外。

ASF的預設設定是依據最常見的Bot用法，即只獲得擴充包及交換卡片（包含閃亮卡片）。 本處定義的屬性使您能夠依自己所需自訂該行為。 請注意，上述所有未定義的類型都會顯示成​Unknown​類型，特別是在Valve發布一些新的Steam物品時，ASF也會將它們標示成​Unknown​，直到它們（在未來的版本中）被加入於本表格中。 這也是在一般情形下不建議在​LootableTypes​中選擇​Unknown​類型的原因，除非您知道自己正在做什麼，且您也了解萬一Steam網路再次損毀時，會將您的所有物品標示成​Unknown​，並在交易提案中發送出您物品庫中的所有物品。 我強烈建議即使您希望獲得所有（其他的）物品，也不要在​LootableTypes​中選擇​Unknown​類型。

ImmutableHashSet<byte>​型別，預設值為​5​的Steam物品類型。 本屬性定義了在您啟用​TradingPreferences​中的​SteamTradeMatcher​選項時，允許用於匹配的Steam物品類型。 類型定義如下：

當然，您通常在本屬性只應選擇​2​、​3​、​4​及​5​，因為STM只支援這些類型。 ASF擁有能夠判斷物品稀有度的正確邏輯，因此匹配表情符號或背景也會是安全的，因為ASF只會將來自同一個遊戲、相同類型及稀有度的物品視為相等的。

請注意，​ASF並非交易機器人​，且​不會考慮物品的市場價格​。 若您不認為在同一組中稀有度相同的物品是等價的，那麼這個選項並不適合您使用。 如果您決定更改本設定，請先理解並同意此聲明，並再次評估風險。

除非您知道您在做什麼，否則請保留預設值​5​。

ushort flags​型別，預設值為​0​。 本屬性可以當作​OnlineStatus​的補充功能，指定向Steam網路發布額外的在線狀態。 需要​OnlineStatus​不為​Offline​，定義如下：

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項。

本屬性依據的基本​EPersonaStateFlag​型別包含了更多可供使用的旗標，但據我們所知，直到目前它們還仍無任何效果，因此為了可見性將它們刪除了。

若您不確定如何設定本屬性，請保留預設值​0​。

byte​型別，預設值為​1​。 本屬性指定了Bot在登入Steam網路後，要顯示的Steam社群狀態。 目前您可以選擇下列狀態之一：

Offline​狀態對於主要帳號來說非常有用。 如您所知，遊戲掛卡時會顯示您的Steam狀態為「正在遊玩：XXX」，這可能會誤導您的朋友，讓他們以為您真的正在玩遊戲，但實際上您只是在掛卡而已。 使用​Offline​的狀態能夠解決此問題：在您使用ASF掛卡時，您的帳號不會再被顯示成「遊戲中」。 能這樣做是因為ASF不必登入至Steam社群就能正常運作，所以即使實際上我們正在玩這些遊戲，且連線至Steam網路中，但仍能不顯示我們的在線狀態。 請注意，使用離線狀態遊玩的遊戲仍會增加您的遊玩時數，並在您個人檔案中顯示成「最近遊玩過的」遊戲。

除此之外，若您希望在ASF執行時能夠接收到通知及未讀訊息，且不用打開Steam用戶端，那麼本功能就很重要。 這是因為ASF把自身當作一個Steam用戶端，不論ASF是否願意，Steam都會向它廣播所有的訊息及事件。 若您同時執行ASF及您自己的Steam用戶端，這就不會是個問題，因為全部的用戶端都會收到完全相同的事件廣播。 但是，如果只有ASF在執行，Steam網路就會將部分事件及訊息標示成「已送達」，但您原版的Steam用戶端將會因為不在線上而接收不到這些訊息。 離線的狀態能夠解決此問題，因為在這種情形下，ASF不再會接收任何社群事件，因此所有未讀訊息與其餘事件都會在您回來後仍維持著未讀狀態。

特別注意，在​Offline​模式下執行的ASF將​不能​以一般的Steam聊天方式接收指令，因為此時聊天系統與整個社群都是離線狀態。 解決此問題的方式是使用​Invisible​模式，它以相似的方式運作（但不會暴露您的狀態），且能夠保有接收及回應訊息的能力（因此如上所述，仍能清除通知及未讀訊息）。 Invisible​主要適用於您不想暴露狀態，但仍需要傳送指令的小號上。

但是，​Invisible​模式具有一個問題：它並不是很適合用在主要帳號上。 這是因為​任何​的Steam連線階段都會將在線狀態​公開​，即使ASF並無此意。 This is caused by the current limitation/bug of the Steam network that isn't possible to be fixed on ASF side, so if you want to use Invisible mode you will also need to ensure that all other sessions to the same account use Invisible mode as well. This will be the case on alt accounts where ASF is hopefully the only active session, but on primary accounts you'll almost always prefer to show as Online to your friends, hiding only ASF activity, and in this case Invisible mode will be entirely useless for you (we recommend to use Offline mode instead). Hopefully this limitation/bug will be eventually solved in the future by Valve, but I wouldn't expect that to happen anytime soon...

If you're unsure how to set up this property, it's recommended to use a value of 0 (Offline) for primary accounts, and default 1 (Online) otherwise.

byte​型別，預設值為​0​（​PlainText​）。 This property defines the format of SteamPassword property, and currently supports values specified in the security section. You should follow the instructions specified there, as you'll need to ensure that SteamPassword property indeed includes password in matching PasswordFormat. In other words, when you change PasswordFormat then your SteamPassword should be already in that format, not just aiming to be. 除非您知道您在做什麼，否則請保留預設值​0​。

bool​型別，預設值為​false​。 This property defines initial state of CardsFarmer module. With default value of false, bot will automatically start farming when it's started, either because of Enabled or start command. Switching this property to true should be done only if you want to manually resume automatic farming process, for example because you want to use play all the time and never use automatic CardsFarmer module - this works exactly the same as pause command. 若您不確定您是否想要啟用本功能，請保留預設值​false​。

byte flags​型別，預設值為​0​。 This property defines ASF behaviour when redeeming cd-keys, and is defined as below:

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項。

Forwarding will cause bot to forward a key that is not possible to redeem, to another connected and logged on bot that is missing that particular game (if possible to check). The most common situation is forwarding AlreadyPurchased game to another bot that is missing that particular game, but this option also covers other scenarios, such as DoesNotOwnRequiredApp, RateLimited or RestrictedCountry.

Distributing will cause bot to distribute all received keys among itself and other bots. This means that every bot will get a single key from the batch. Typically this is used only when you're redeeming many keys for the same game, and you want to evenly distribute them among your bots, as opposed to redeeming keys for various different games. This feature makes no sense if you're redeeming only one key in a single redeem action (as there are no extra keys to be distributed).

KeepMissingGames will cause bot to skip Forwarding when we can't be sure if key being redeemed is in fact owned by our bot, or not. This basically means that Forwarding will apply only to AlreadyPurchased keys, instead of covering also other cases such as DoesNotOwnRequiredApp, RateLimited or RestrictedCountry. Typically you want to use this option on primary account, to ensure that keys being redeemed on it won't be forwarded further if your bot for example becomes temporarily RateLimited. As you can guess from the description, this field has absolutely no effect if Forwarding is not enabled.

AssumeWalletKeyOnBadActivationCode will cause BadActivationCode keys to be treated as CannotRedeemCodeFromClient, and therefore result in ASF trying to redeem them as wallet keys. This is needed because Steam might announce wallet keys as BadActivationCode (and not CannotRedeemCodeFromClient as it used to), resulting in ASF never attempting to redeem them. However, we recommend against using this preference, as it'll result in ASF trying to redeem every invalid key as a wallet code, resulting in excessive amount of (potentially invalid) requests sent to the Steam service, with all the potential consequences. Instead, we recommend to use ForceAssumeWalletKey redeem^ mode while knowingly redeeming wallet keys, which will enable the needed workaround only when it's required, on as-needed basis.

Enabling both Forwarding and Distributing will add distributing feature on top of forwarding one, which makes ASF trying to redeem one key on all bots firstly (forwarding) before moving to the next one (distributing). Typically you want to use this option only when you want Forwarding, but with altered behaviour of switching the bot on key being used, instead of always going in-order with every key (which would be Forwarding alone). This behaviour can be beneficial if you know that majority or even all of your keys are tied to the same game, because in this situation Forwarding alone would try to redeem everything on one bot firstly (which makes sense if your keys are for unique games), and Forwarding + Distributing will switch the bot on the next key, "distributing" the task of redeeming new key onto another bot than the initial one (which makes sense if keys are for the same game, skipping one pointless attempt per key).

The actual bots order for all of the redeeming scenarios is alphabetical, excluding bots that are unavailable (not connected, stopped or likewise). Please keep in mind that there is per-IP and per-account hourly limit of redeeming tries, and every redeem try that didn't end with OK contributes to failed tries. ASF will do its best to minimize number of AlreadyPurchased failures, e.g. by trying to avoid forwarding a key to another bot that already owns that particular game, but it's not always guaranteed to work due to how Steam is handling licenses. Using redeeming flags such as Forwarding or Distributing will always increase your likelyhood to hit RateLimited.

Also keep in mind that you can't forward or distribute keys to bots that you do not have access to. This should be obvious, but ensure that you're at least Operator of all the bots you want to include in your redeeming process, for example with status ASF command.

byte flags​型別，預設值為​3​。 This property defines per-bot ASF behaviour when it comes to communication with remote, third-party services, and is defined as below:

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項。

This option doesn't include every third-party communication offered by ASF, only those that are not implied by other settings. For example, if you've enabled ASF's auto-updates, ASF will communicate with both GitHub (for downloads) and our server (for checksum verification), as per your configuration. Likewise, enabling MatchActively in TradingPreferences implies communication with our server to fetch listed bots, which is required for that functionality.

Further explanation on this subject is available in remote communication section. 除非您有理由編輯此屬性，否則您應維持它為預設值。

bool​型別，預設值為​false​。 When ASF is done with farming given account, it can automatically send steam trade containing everything farmed up to this point to user with Master permission, which is very convenient if you don't want to bother with trades yourself. 本選項與​loot​指令作用相同，因此請注意，首先它需要您有帳號的交易合法權限，且使用者具有​Master​權限，而您可能也要有有效的​SteamTradeToken​。 In addition to initiating loot after finishing farming, ASF will also initiate loot on each new items notification (when not farming), and after completing each trade that results in new items (always) when this option is active. This is especially useful for "forwarding" items received from other people to our account.

Typically you'll want to use ASF 2FA together with this feature, although it's not a requirement if you intend to confirm manually in timely fashion. 若您不確定如何設定本屬性，請保留預設值​false​。

byte​型別，預設值為​0​。 This property works very similar to SendOnFarmingFinished property, with one difference - instead of sending trade when farming is done, we can also send it every SendTradePeriod hours, regardless of how much we have to farm left. This is useful if you want to loot your alt accounts on usual basis instead of waiting for it to finish farming. Default value of 0 disables this feature, if you want your bot to send you trade e.g. every day, you should put 24 here.

Typically you'll want to use ASF 2FA together with this feature, although it's not a requirement if you intend to confirm manually in timely fashion. 若您不確定如何設定本屬性，請保留預設值​0​。

bool​型別，預設值為​false​。 ASF is "occupying" an account for the whole time of process being active. When given account is done with farming, ASF periodically checks it (every IdleFarmingPeriod hours), if perhaps some new games with steam cards were added in the meantime, so it can resume farming of that account without a need to restart the process. This is useful for majority of people, as ASF can automatically resume farming when needed. However, you may actually want to stop the process when given account is fully farmed, you can achieve that by setting this property to true. When enabled, ASF will proceed with logging off when account is fully farmed, which means that it won't be periodically checked or occupied anymore. You should decide yourself if you prefer ASF to work on given bot instance for the whole time, or if perhaps ASF should stop it when farming process is done. When all accounts are stopped and process is not running in --process-required mode, ASF will shutdown as well, putting your machine at rest and allowing you to schedule other actions, such as sleep or shutdown at the same moment of last card dropping.

若您不確定如何設定本屬性，請保留預設值​false​。

bool​型別，預設值為​false​。 This property defines if ASF is permitted to farm games that are still refundable. A refundable game is a game that you bought in last 2 weeks through Steam Store and didn't play for longer than 2 hours yet, as stated on Steam refunds page. By default when this option is set to false, ASF ignores Steam refunds policy entirely and farms everything, as most people would expect. However, you can change this option to true if you want to ensure that ASF won't farm any of your refundable games too soon, allowing you to evaluate those games yourself and refund if needed without worrying about ASF affecting playtime negatively. Please note that if you enable this option then games you purchased from Steam Store won't be farmed by ASF for up to 14 days since redeem date, which will show as nothing to farm if your account doesn't own anything else. 若您不確定您是否想要啟用本功能，請保留預設值​false​。

string​型別，預設值為​null​。 This property defines your steam login - the one you use for logging in to steam. In addition to defining steam login here, you may also keep default value of null if you want to enter your steam login on each ASF startup instead of putting it in the config. This may be useful for you if you don't want to save sensitive data in config file.

ulong​型別，預設值為​0​。 This property defines the steamID of the steam group that bot should automatically join, including its group chat. You can check steamID of your group by navigating to its page, then adding /memberslistxml?xml=1 to the end of the link, so the link will look like this. Then you can get steamID of your group from the result, it's in <groupID64> tag. In above example it would be 103582791440160998. In addition to trying to join given group at startup, the bot will also automatically accept group invites to this group, which makes it possible for you to invite your bot manually if your group has private membership. If you don't have any group dedicated for your bots, you should keep this property with default value of 0.

string​型別，預設值為​null​。 This property defines your steam parental PIN. ASF requires an access to resources protected by steam parental, therefore if you use that feature, you should provide ASF with parental unlock PIN, so it can operate normally. Default value of null means that there is no steam parental PIN required to unlock this account, and this is probably what you want if you don't use steam parental functionality.

In limited circumstances, ASF is also able to generate a valid Steam parental code itself, although that requires excessive amount of OS resources and additional time to complete, not to mention that it's not guaranteed to succeed, therefore we recommend to not rely on that feature and instead put valid SteamParentalCode in the config for ASF to use. If ASF determines that PIN is required, and it'll be unable to generate one on its own, it'll ask you for input.

string​型別，預設值為​null​。 This property defines your steam password - the one you use for logging in to steam. In addition to defining steam password here, you may also keep default value of null if you want to enter your steam password on each ASF startup instead of putting it in the config. This may be useful for you if you don't want to save sensitive data in config file.

string​型別，預設值為​null​。 When you have your bot on your friend list, then bot can send a trade to you right away without worrying about trade token, therefore you can leave this property at default value of null. If you however decide to NOT have your bot on your friend list, then you will need to generate and fill a trade token as the user that this bot is expecting to send trades to. In other words, this property should be filled with trade token of the account that is defined with Master permission in SteamUserPermissions of this bot instance.

In order to find your token, as logged in user with Master permission, navigate here and take a look at your trade URL. The token we're looking for is made out of 8 characters after &token= part in your trade URL. You should copy and put those 8 characters here, as SteamTradeToken. Do not include whole trading URL, neither &token= part, only the token itself (8 characters).

ImmutableDictionary<ulong, byte>​型別，預設值為空。 This property is a dictionary property which maps given Steam user identified by his 64-bit steam ID, to byte number that specifies his permission in ASF instance. Currently available bot permissions in ASF are defined as:

In short, this property allows you to handle permissions for given users. Permissions are important mainly for access to ASF commands, but also for enabling many ASF features, such as accepting trades. For example you may want to set your own account as Master, and give Operator access to 2-3 of your friends so they can easily redeem keys for your bot with ASF, while not being eligible e.g. for stopping it. Thanks to that you can easily assign permissions to given users and let them use your bot to some specified by you degree.

We recommend to set exactly one user as Master, and any amount you wish as Operators and below. While it's technically possible to set multiple Masters and ASF will work correctly with them, for example by accepting all of their trades sent to the bot, ASF will use only one of them (with lowest steam ID) for every action that requires a single target, for example a loot request, so also properties like SendOnFarmingFinished or SendTradePeriod. If you perfectly understand those limitations, especially the fact that loot request will always send items to the Master with lowest steam ID, regardless of the Master that actually executed the command, then you can define multiple users with Master permission here, but we still recommend a single master scheme.

It's nice to note that there is one more extra Owner permission, which is declared as SteamOwnerID global config property. You can't assign Owner permission to anybody here, as SteamUserPermissions property defines only permissions that are related to the bot instance, and not ASF as a process. For bot-related tasks, SteamOwnerID is treated the same as Master, so defining your SteamOwnerID here is not necessary.

byte​型別，預設值為​60​。 Normally ASF handles incoming trade offers right after receiving notification about one, but sometimes because of Steam glitches it can't do it at that time, and such trade offers remain ignored until next trade notification or bot restart occurs, which may lead to trades being cancelled or items not available at that later time. If this parameter is set to a non-zero value, ASF will additionally check for such outstanding trades every TradeCheckPeriod minutes. Default value is selected with balance between additional requests to steam servers and losing incoming trades in mind. However, if you are just using ASF to farm cards, and don't plan to automatically process any incoming trades, you may set it to 0 to disable this feature completely. On the other hand, if your bot participates in public ASF's STM listing or provides other automated services as a trade bot, you may want to decrease this parameter to 15 minutes or so, to process all trades in a timely manner.

byte flags​型別，預設值為​0​。 This property defines ASF behaviour when in trading, and is defined as below:

請注意，本屬性為​flags​欄位，因此可以使用所有可用值任意組合。 若您想了解更多，請參閱​旗標映射​。 不啟用任何旗標即為​None​選項。

For further explanation of ASF trading logic, and description of every available flag, please visit trading section.

ImmutableHashSet<byte>​型別，預設值為​1, 3, 5​的Steam物品類型。 This property defines which Steam item types will be considered for transfering between bots, during transfer command. ASF will ensure that only items from TransferableTypes will be included in a trade offer, therefore this property allows you to choose what you want to receive in a trade offer that is being sent to one of your bots.

請注意，不論上述如何設定，ASF都只會處理Steam分類（​appID​為753）中的社群物品（​contextID​為6），因此依據定義所有遊戲物品、禮物等物品都會被排除在交易提案之外。

Default ASF setting is based on the most common usage of the bot, with transfering only booster packs, and trading cards (including foils). 本處定義的屬性使您能夠依自己所需自訂該行為。 請注意，上述所有未定義的類型都會顯示成​Unknown​類型，特別是在Valve發布一些新的Steam物品時，ASF也會將它們標示成​Unknown​，直到它們（在未來的版本中）被加入於本表格中。 That's why in general it's not recommended to include Unknown type in your TransferableTypes, unless you know what you're doing, and you also understand that ASF will send your entire inventory in a trade offer if Steam Network gets broken again and reports all your items as Unknown. My strong suggestion is to not include Unknown type in the TransferableTypes, even if you expect to transfer everything.

bool​型別，預設值為​true​。 This property defines if ASF should use login keys mechanism for this Steam account. Login keys mechanism works very similar to official Steam client's "remember me" option, which makes it possible for ASF to store and use temporary one-time use login key for next logon attempt, effectively skipping a need of providing password, Steam Guard or 2FA code as long as our login key is valid. Login key is stored in BotName.db file and updated automatically. This is why you don't need to provide password/SteamGuard/2FA code after logging in successfully with ASF just once.

Login keys are used by default for your convenience, so you don't need to input SteamPassword, SteamGuard or 2FA code (when not using ASF 2FA) on each login. It's also superior alternative since login key can be used only for a single time and does not reveal your original password in any way. Exactly the same method is being used by your original Steam client, which saves your account name and login key for your next logon attempt, effectively being the same as using SteamLogin with UseLoginKeys and empty SteamPassword in ASF.

However, some people could be concerned even about this little detail, therefore this option is available here for you if you'd like to ensure that ASF won't store any kind of token that would allow resuming previous session after being closed, which will result in full authentication being mandatory on each login attempt. Disabling this option will work exactly the same as not checking "remember me" in official Steam client. Unless you know what you're doing, you should keep it with default value of true.

byte​型別，預設值為​0​。 This property specifies user interface mode that the bot will be announced with after logging in to Steam network. Currently you can choose one of below modes:

若您不確定如何設定本屬性，請保留預設值​0​。

ASF is using quite simple file structure.

├── config
│     ├── ASF.json
│     ├── ASF.db
│     ├── Bot1.json
│     ├── Bot1.db
│     ├── Bot1.bin
│     ├── Bot2.json
│     ├── Bot2.db
│     ├── Bot2.bin
│     └── ...
├── ArchiSteamFarm.dll
├── log.txt
└── ...

In order to move ASF to new location, for example another PC, it's enough to move/copy config directory alone, and that's the recommended way of doing any form of "ASF backups", since you can always download the remaining (program) part from the GitHub, while not risking corrupting internal ASF files, e.g. through a faulty backup.

log.txt file holds the log generated by your last ASF run. This file doesn't contain any sensitive information, and is extremely useful when it comes to issues, crashes or simply as an information to you what happened in last ASF run. We will very often ask about this file if you run into issues or bugs. ASF automatically manages this file for you, but you can further tweak ASF logging module if you're advanced user.

config directory is the place that holds configuration for ASF, including all of its bots.

ASF.json is a global ASF configuration file. This config is used for specifying how ASF behaves as a process, which affects all of the bots and program itself. You can find global properties there, such as ASF process owner, auto-updates or debugging.

BotName.json is a config of given bot instance. This config is used for specifying how given bot instance behaves, therefore those settings are specific to that bot only and not shared across other ones. This allows you to configure bots with various different settings and not necessarily all of them working in exactly the same way. Every bot is named using unique identifier, chosen by you in place of BotName.

Apart from config files, ASF also uses config directory for storing databases.

ASF.db is a global ASF database file. It acts as a global persistent storage and is used for saving various information related to ASF process, such as IPs of local Steam servers. You should not edit this file.

BotName.db is a database of given bot instance. This file is used for storing crucial data about given bot instance in persistent storage, such as login keys or ASF 2FA. You should not edit this file.

BotName.bin is a special file of given bot instance, which holds information about Steam sentry hash. Sentry hash is used for authenticating using SteamGuard mechanism, very similar to Steam ssfn file. You should not edit this file.

BotName.keys is a special file that can be used for importing keys into background games redeemer. It's not mandatory and not generated, but recognized by ASF. This file is automatically deleted after keys are successfully imported.

BotName.maFile is a special file that can be used for importing ASF 2FA. It's not mandatory and not generated, but recognized by ASF if your BotName does not use ASF 2FA yet. This file is automatically deleted after ASF 2FA is successfully imported.

Every configuration property has its type. Type of the property defines values that are valid for it. You can only use values that are valid for given type - if you use invalid value, then ASF won't be able to parse your config.

We strongly recommend to use ConfigGenerator for generating configs - it handles most of the low-level stuff (such as types validation) for you, so you only need to input proper values, and you also don't need to understand variable types specified below. This section is mainly for people generating/editing configs manually, so they know what values they can use.

Types used by ASF are native C# types, which are specified below:

bool - Boolean type accepting only true and false values.

Example: "Enabled": true

byte - Unsigned byte type, accepting only integers from 0 to 255 (inclusive).

Example: "ConnectionTimeout": 90

ushort - Unsigned short type, accepting only integers from 0 to 65535 (inclusive).

Example: "WebLimiterDelay": 300

uint - Unsigned integer type, accepting only integers from 0 to 4294967295 (inclusive).

ulong - Unsigned long integer type, accepting only integers from 0 to 18446744073709551615 (inclusive).

Example: "SteamMasterClanID": 103582791440160998

string - String type, accepting any sequence of characters, including empty sequence "" and null. Empty sequence and null value are treated the same by ASF, so it's up to your preference which one you want to use (we stick with null).

Examples: "SteamLogin": null, "SteamLogin": "", "SteamLogin": "MyAccountName"

Guid? - Nullable UUID type, in JSON encoded as string. UUID is made out of 32 hexadecimal characters, in range from 0 to 9 and a to f. ASF accepts variety of valid formats - lowercase, uppercase, with and without dashes. In addition to valid UUID, since this property is nullable, a special value of null is accepted to indicate lack of UUID to provide.

Examples: "LicenseID": null, "LicenseID": "f6a0529813f74d119982eb4fe43a9a24"

ImmutableList<valueType> - Immutable collection (list) of values in given valueType. In JSON, it's defined as array of elements in given valueType. ASF uses List to indicate that given property supports multiple values and that their order might be relevant.

Example for ImmutableList<byte>: "FarmingOrders": [15, 11, 7]

ImmutableHashSet<valueType> - Immutable collection (set) of unique values in given valueType. In JSON, it's defined as array of elements in given valueType. ASF uses HashSet to indicate that given property makes sense only for unique values and that their order doesn't matter, therefore it'll intentionally ignore any potential duplicates during parsing (if you happened to supply them anyway).

Example for ImmutableHashSet<uint>: "Blacklist": [267420, 303700, 335590]

ImmutableDictionary<keyType, valueType> - Immutable dictionary (map) that maps a unique key specified in its keyType, to value specified in its valueType. In JSON, it's defined as an object with key-value pairs. Keep in mind that keyType is always quoted in this case, even if it's value type such as ulong. There is also a strict requirement of the key being unique across the map, this time enforced by JSON as well.

Example for ImmutableDictionary<ulong, byte>: "SteamUserPermissions": { "76561198174813138": 3, "76561198174813137": 1 }

flags - Flags attribute combines several different properties into one final value by applying bitwise operations. This allows you to choose any possible combination of various different allowed values at the same time. The final value is constructed as a sum of values of all enabled options.

For example, given following values:

Using B + C would result in value of 6, using A + C would result in value of 5, using C would result in value of 4 and so on. This allows you to create any possible combination of enabled values - if you decided to enable all of them, making None + A + B + C, you'd get value of 7. Also notice that flag with value of 0 is enabled by definition in all other available combinations, therefore very often it's a flag that doesn't enable anything specifically (such as None).

So as you can see, in above example we have 3 available flags to switch on/off (A, B, C), and 8 possible values overall:

• None -> 0
• A -> 1
• B -> 2
• A + B -> 3
• C -> 4
• A + C -> 5
• B + C -> 6
• A + B + C -> 7

Example: "SteamProtocols": 7

Due to JavaScript limitations of being unable to properly serialize simple ulong fields in JSON when using web-based ConfigGenerator, ulong fields will be rendered as strings with s_ prefix in the resulting config. This includes for example "SteamOwnerID": 76561198006963719 that will be written by our ConfigGenerator as "s_SteamOwnerID": "76561198006963719". ASF includes proper logic for handling this string mapping automatically, so s_ entries in your configs are actually valid and correctly generated. If you're generating configs yourself, we recommend to stick with original ulong fields if possible, but if you're unable to do so, you can also follow this scheme and encode them as strings with s_ prefix added to their names. We hope to resolve this JavaScript limitation eventually.

It's top priority for ASF to remain compatible with older configs. As you should already know, missing config properties are treated the same as they would be defined with their default values. Therefore, if new config property gets introduced in new version of ASF, all your configs will remain compatible with new version, and ASF will treat that new config property as it'd be defined with its default value. You can always add, remove or edit config properties according to your needs.

We recommend to limit defined config properties only to those that you want to change, since this way you automatically inherit default values for all other ones, not only keeping your config clean but also increasing compatibility in case we decide to change a default value for property that you don't want to explicitly set yourself (e.g. WebLimiterDelay).

Due to above, ASF will automatically migrate/optimize your configs by reformatting them and removing fields that hold default value. You can disable this behaviour with --no-config-migrate command-line argument if you have a specific reason, for example you're providing read-only config files and you don't want ASF to modify them.

Starting with ASF V2.1.6.2+, the program is now aware of configs being modified "on-the-fly" - thanks to that, ASF will automatically:

• Create (and start, if needed) new bot instance, when you create its config
• Stop (if needed) and remove old bot instance, when you delete its config
• Stop (and start, if needed) any bot instance, when you edit its config
• Restart (if needed) the bot under new name, when you rename its config

All of the above is transparent and will be done automatically without a need of restarting the program, or killing other (unaffected) bot instances.

In addition to that, ASF will also restart itself (if AutoRestart permits) if you modify core ASF ASF.json config. Likewise, program will quit if you delete or rename it.

You can disable this behaviour with --no-config-watch command-line argument if you have a specific reason, for example you don't want from ASF to react to file changes in config folder.