Greasy Fork is available in English.
Twitch 自动领取 (掉宝/Drops) , 窗口标签显示进度 , 直播结束时还没领完 , 会自动寻找任意掉宝直播 , 并开启后继续挂机 , 代码自定义设置
目前有多個配置項目, 要保存到存儲空間, 考慮設置方便, 可能需要要另外寫菜單, 但目前沒有寫菜單的打算, 暫時不會提供該功能
嗯，其實并不需要寫菜單。只需要在脚本中加入檢測是否存在已保存的設置的邏輯，並在沒有檢測到時初始化（生成）儲存空間内容的代碼即可。這個時候用戶就可以采用與目前相同的設置方式在儲存空間中調整相應的設置而無需修改脚本自身，這樣用戶也可以更容易地重置到初始設置（只要清空儲存内容即可）。
另外 True 和 False 可以考慮改成 0 和 1，這樣尺寸更小也更方便修改。
你的提議我在下次需要更新時, 再看看是否有更好的處理方式加入吧, 目前我的考量覺得這不是很好的方式
該腳本最初設計的目的就是 "簡單的操作" 畢竟不是每個人都會, 手動操作儲存空間 且 不同的腳本管理器, 不同的平台, 操作差異也很大, 有些你沒特別設置, 或是他原本的 UI 設計, 你就很難直接這樣修改, 所以如果要多配置存儲, 我會傾向寫菜單, 這樣能避免有人不知道怎麼用
目前集成於上方 Config 直接修改, 這樣只是要更新時, 會比較麻煩, 但是他的操作相對簡單
這個也只是提供可自定, 但其實你什麼都不改也能使用
至於你說的改成 0 和 1, 你自己設置其實就可以直接這樣打, 他會自動被轉型, 但這也是考量到, 不是每個人都有計算機思維
知道 0 可以代表 false, 1 可以代表 true, 我直接寫單字, 更能明確表示
我的認知是不能把開發者思維, 帶到項目中 認為一般使用者都會進行各種操作, 盡可能以最低操作成本來發佈, 是更好的選擇
項目中操作成本越低, 簡單精美的 UI, 或是小範圍集成配置, 比起複雜強大的功能交互 和 極度優化的底層算法, 對於小項目來說還更加重要
另外如果你有什麼思路, 可以提供看看, 你要的這個功能實現很簡單, 在不考慮某些使用者不會用的情況, 我想看看你的想法
1. 怎麼判斷什麼時候以 代碼設置為主, 什麼時候又以存儲為主
2. 如果使用者修改時, 打錯了 (格式錯誤/Key值錯誤/變數類型錯誤) 我直接 getValue, 怎麼處理這可能的錯誤
3. 當我更新之後, 我的預設 Config 刪除了某些 key, 或添加了某些 key, 此時如果我直接以存儲為主, 那他就有可能出錯, 此時又怎麼處理
雖然三個解決方法也不難, 但我想知道你希望遇到這狀況怎麼處理
目前剛好需要修復, 我臨時加入了保存的功能
我的認知是不能把開發者思維, 帶到項目中
我同意，但這樣開發成本可能會大幅增加。
1.怎麼判斷什麼時候以 代碼設置為主, 什麼時候又以存儲為主
2.如果使用者修改時, 打錯了 (格式錯誤/Key值錯誤/變數類型錯誤) 我直接 getValue, 怎麼處理這可能的錯誤
上面問題1的方案中已經包含，如果校驗時發現不一致，則保留有效的條目，並移除無效條目，然後使用默認設置補充缺失條目，最後進行完整讀取。
3.當我更新之後, 我的預設 Config 刪除了某些 key, 或添加了某些 key, 此時如果我直接以存儲為主, 那他就有可能出錯, 此時又怎麼處理
參考問題2即可。
嗯 你說的解決方式, 雖然是能成功處理大部份狀況, 但這些更像是 存在先前版本數據結構, 與當前結構不同時, 要進行版本轉移時才需要做的操作 這對於只是要使用先前存儲內容, 過度複雜化
另外判斷存儲值類型這點, 是因為你想要直接修改, 這通常不是預設行為, 所以我實際上不會考慮檢測 如果真要檢測, 存儲是否是有效值, 通常只能做類型判斷, 假設 UpdateInterval, 我將他的單位 更新成分鐘, 或其他不能直接類型判斷的 我要怎麼知道哪些是有效值, 如果我直接根據版本, 不管有效值全部覆蓋, 那又回到預設, 這樣存儲不就多此一舉
這不是一個單純判斷兩邊是否不同, 就能夠決定要以哪邊為主的狀況
另外我說的 不能把開發者思維帶到項目中, 指的是不能預設使用者都有開發者的思維, 知道怎麼操作, 或將一些需要計算機知識, 才知道的事情作為預設操作
存在先前版本數據結構, 與當前結構不同時, 要進行版本轉移時才需要做的操作
這對於只是要使用先前存儲內容, 過度複雜化
嗯，可能是我沒描述清楚。
這個數據檢測是運行時確保配置内容完全正確以保障脚本能預期正常執行的必要步驟。既然你非常重視一般使用者的體驗，那就不能省略這項保障措施。因爲只有這樣才能保證讓沒有相應知識的人也能在任何時候都能繼續使用，而無須想辦法自行修理。（只需要重新設定修復后的設置即可）
它就像文檔複製時進行 CRC 校驗一樣，平時我們看起來不是必須的，但當注重數據安全性時那它就是一個不可省略的步驟。
另外判斷存儲值類型這點, 是因為你想要直接修改, 這通常不是預設行為, 所以我實際上不會考慮檢測
如果真要檢測, 存儲是否是有效值, 通常只能做類型判斷, 假設 UpdateInterval, 我將他的單位 更新成分鐘, 或其他不能直接類型判斷的
我要怎麼知道哪些是有效值, 如果我直接根據版本, 不管有效值全部覆蓋, 那又回到預設, 這樣存儲不就多此一舉這不是一個單純判斷兩邊是否不同, 就能夠決定要以哪邊為主的狀況
嗯，這裏涉及到如何進行檢測的問題。
在這裏的話通常是采用“模擬執行”來進行判定，先不實際進行操作，但嘗試讀取存儲内容並模擬執行一次看看是否會出錯，而出錯的都是哪些。通過這樣的方式就能確定哪些有問題，哪些條目缺失等情況。
另外我說的 不能把開發者思維帶到項目中, 指的是不能預設使用者都有開發者的思維, 知道怎麼操作, 或將一些需要計算機知識, 才知道的事情作為預設操作
所以我們要在存儲中也包含注釋。比如説明 0=関，1=開。
同時在脚本的説明頁面注明脚本的特性。比如如何操作，遇到問題時會發生什麽。
所以說一旦考慮到要兼容無知識使用者的時候，開發成本就會大幅增加，因爲要把除錯和説明的代碼也放進去。
你提到的許多處理機制, 比如校驗與模擬執行等, 都是在高度自訂或開發環境下才會需要考慮的事情
這個腳本面向的是一般使用者, 且預期行為是透過界面或設定面板操作, 而不是讓使用者手動去編輯存儲值, 這不是正常流程的一部分, 因此我不會特地為此增加額外處理, 這跟「使用體驗」無關, 而是開發與維護成本的取捨
至於你提到模擬執行的方式, 實際上會造成大量開銷, 也違反這個腳本設計上的原則, 更不用說每個配置影響的是行為邏輯, 模擬的可行性與覆蓋率幾乎不具實際操作意義
還是想確認一下, 你提出的這些建議, 是基於你實際有開發與長期維護過大型項目的經驗？還是純粹就概念討論出發？
我並不是反對深入討論設計問題, 而是想釐清我們討論的基準線, 因為在我目前的理解裡, 你提出的很多做法在實務上是過度設計, 不利於專案的可維護性與擴展性
請問是否可以將設定項目移到儲存空間裏面？這樣就能避免修改了設置后影響自動更新了。