代码文件字段解释

1) primary_set

主系列名(字符串)。
在函数里会先把你输入的系列名“纠正/补全”,比如你输“阿努比斯”会尝试匹配到“阿努比斯收藏品”。
它的作用主要有三块:

  • 决定产出池:产出皮肤必须属于主/副系列之一
  • 决定材料池:材料皮肤必须属于主/副系列之一且稀有度匹配
  • 在 CP-SAT 时,用它来强制主系列材料数量等于 main_count

2) secondary_set

副系列名(字符串)。
逻辑和 primary_set 一样,只是它对应的材料数量是 10 - main_count(代码里叫 sub_count),并且 CP-SAT 里会被固定为这个数量。


3) input_rarity

输入材料稀有度(字符串)。
它会用 _next_rarity(input_rarity) 推出“产出稀有度”(trade-up 的下一档)。所以:

  • input_rarity 决定材料池怎么筛
  • 同时决定产出池要找哪一档稀有度的皮肤

如果传了脚本不认识的稀有度,或者已经是最高档,会直接报错/返回。


4) main_count

主系列材料数量(整数,0~10)。
trade-up 固定 10 个材料,所以:

  • main_count 给主系列
  • 剩下的 sub_count = 10 - main_count 给副系列

代码里会检查 main_count 必须在 0~10,否则抛异常。


5) global_cap

全局磨损上限 cap(浮点数)。这是这个函数里最关键的“约束参数”之一。

它不是简单地“材料磨损 ≤ cap”,而是:

  • 先根据产出池 outputs_list 计算一个“全局可行的平均归一化磨损上限”(avg_norm_max / norm_sum_max
  • CP-SAT 在选 10 个材料时,会限制 10 个材料的归一化磨损和不超过这个上限
  • 这样可以保证:对产出池里最不利的那一个皮肤,预测产出磨损也不会超过 global_cap

另外它还影响 产出价格查询:算 EV 时会按预测磨损去查该磨损下的最低价。


6) mode

系列归属模式(字符串,默认 "collection")。
它决定“皮肤属于哪个系列”的来源:

  • "collection":用 sk.collections
  • "crate":用 sk.crates

所以它会同时影响:系列名列表、材料池筛选、产出池筛选、概率/EV 计算里“同系列”判断。


7) topn

输出/处理前 N 个方案(整数,默认 1)。

它有两层用途:

  1. 结果展示:只打印 filtered[:topn]
  2. 自动购买模式:最多只“询问/处理”topn 个候选方案(避免一直问下去)

8) min_roi

ROI 过滤阈值(百分比)(浮点数)。
脚本会先算每个方案的 EV 利润 profit = EV - cost,然后算:

roi = profit / total_cost * 100

只保留 roi >= min_roi 的方案进入 filtered,后续展示/自动购买都基于这个过滤后的列表。


9) out_txt

导出日志开关 + 导出目录(字符串路径或 None)。

它在代码里的语义不是“输出到这个具体文件名”,而是:

  • 只要 out_txt 非空,就触发导出
  • out_txt 当作“目录提示”:out_dir = dirname(out_txt) or "."
  • 最终文件名会自动生成:主系列+副系列+cap+时间戳.txt

另外:如果你开了 auto_buy 但没传 out_txt,脚本会给一个默认值(比如 autobuy_logs/run.txt)来确保会落盘。


10) stattrak

是否只做暗金(StatTrak)材料(布尔)。

材料池筛选时有一条“暗金一致性”:

  • is_stattrak(sk.name) != stattrak 的皮肤会被排除

也就是说:

  • stattrak=True → 只允许暗金材料
  • stattrak=False → 排除暗金材料

11) auto_buy

是否启用自动购买流程(布尔)。

  • 关:只做规划 + 计算 + 打印/导出
  • 开:在 filtered 里按顺序挑方案,进入“组装购买清单 → 二次检查 →(可选)下单 →(可选)追踪订单”的流程

注意:开启后如果没给 trade_url,会提示并跳过购买。


12) trade_url

Steam 交易链接(字符串)。
DT 的购买接口需要这个字段;auto_buy=True 但不传会直接无法购买(只会提示)。


13) plan_index

在自动购买里它的语义是:从第几个方案开始问/处理(1-based)

  • plan_index=1:从第一名方案开始
  • plan_index=3:从第三名方案开始(仍然最多处理 topn 个)

代码里会把它转成 start_idx = plan_index - 1,并做越界保护。


14) confirm_buy

“真的下单”的确认开关(布尔)。

这是一个“保险栓”:

  • confirm_buy=False:跑完整流程到“打印最终 payload”为止,但不会调用购买接口(不花钱)
  • confirm_buy=True:才会真正调用 batch_buy(...) 下单

(你的代码里即使不下单,也可能会把“预览清单”同步到网站记录,用于测试。)


15) track_orders

买完是否追踪订单状态(布尔)。

  • True:对每个成功订单循环查 order_detail(...),直到完成/失败/超时
  • False:下单后就不再轮询订单状态

你这里传的是 track_orders=(not args.no_track),也就是命令行 --no-track 会反转它。


16) poll_interval

追踪订单时的轮询间隔(秒)(浮点)。
追踪循环里每次查询后会 sleep(max(1.0, poll_interval)),避免刷接口太频繁。


17) max_wait_sec

每个订单最多追踪多久(秒)(整数)。
追踪循环里如果超过这个时间就停止追踪,并记录“超时停止”。


已发布

分类

来自

标签:

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注