lakwsh

可以在群里发送“添加违禁词 xxx”，“查看违禁词”，“删除违禁词 xxx”来进行最简单的违禁词管理 目前的话没有想好怎么细化指令操作违禁词 建议是编辑违禁词.txt手动管理违禁词，例子的话： - 加(群|君\S?羊|羣)\S*\d{6,} $撤回$禁言$仅限123456789,987654321 - 狗群主 $禁言$排除987654321 可以这样理解，第一个规则匹配“加群123456”、“加群888888888”、“加君 羊12345678”等等，执行的操作是撤回＋禁言，生效群聊仅987654321和123456789两个 第二个规则只执行禁言操作，生效群聊为排除987654321以外的所有群聊 不对违禁词操作（右边那些）做定义的话，默认禁言＋撤回，所有群生效

> > 可以在群里发送“添加违禁词 xxx”，“查看违禁词”，“删除违禁词 xxx”来进行最简单的违禁词管理 目前的话没有想好怎么细化指令操作违禁词 建议是编辑违禁词.txt手动管理违禁词，例子的话： > > > > * 加(群|君\S?羊|羣)\S*\d{6,} 撤回撤回禁言$仅限123456789,987654321 > > * 狗群主 禁言禁言排除987654321 > > > > 可以这样理解，第一个规则匹配“加群123456”、“加群888888888”、“加君 羊12345678”等等，执行的操作是撤回＋禁言，生效群聊仅987654321和123456789两个 第二个规则只执行禁言操作，生效群聊为排除987654321以外的所有群聊 不对违禁词操作（右边那些）做定义的话，默认禁言＋撤回，所有群生效 > > 请问能设置禁言时间吗...

toolz是框架，rmc是多人功能的具体实现。rmc的设计思路就是完全由插件管理sv_setmax和sv_maxplayers，不应该在其他地方进行设置。至于你说的中途加入玩家，正常来讲如果是换章节后第一次进服不应该死亡昨天，可能跟你手动修改那两个参数有关系。这个插件我也是用在服务器的，在我服务器是默认4人，玩家如果有多人游戏需要，通过插件自带的投票功能更改人数上限。

建议先排查下是不是有其他插件影响，因为这功能我是测试过的，我服务器群也没有类似的反馈

该版本的l4dtoolz包含多人解锁及Tick解锁功能，建议删除其他版本l4dtoolz及tickrate_enabler。 另外，使用tick解锁功能时出现问题的具体现象是什么？

....? 有必要这么针对性吗，感觉没有使用场景

最近没什么搞求生的欲望。。。有需要建议直接改源码，下次更新我看看怎么加

因爲tickrate解鎖功能部分設定需要在伺服器啓動之初進行，因此通過指令方式控制tickrate解鎖功能開關在技術上會存在一定困難（需要引入額外偏移/簽名）。較爲便捷的實現方式為添加額外啓動項，在檢測到該啓動項時不啓用tickrate解鎖相關功能，但爲了不啓用tickrate解鎖而引入額外啓動項有點奇怪...，對於這個需求我需要額外時間考慮是否及如何實施。如有需要，我建議你fork倉庫並自行修改源代碼，將代碼中[`g_tickrate`](https://github.com/lakwsh/l4dtoolz/blob/main/l4dtoolz.cpp#L241)的值固定為30。

這也是一種處理方法，但代價有點大，應該不會採用… 至於100+（如128）tick時的客戶端＆伺服器不同步問題，當初我對伺服器二進制文件進行反向工程時其實有關注到：起源引擎有對客戶端tick值上限有做限制（如CGameClient::SetUpdateRate函數，限制值為100）。由於未能確認其他位置是否也有相似限制，且為減少使用的偏移/簽名數量，故未有做適配，如有需要可以補上。

要話關聯性，其實係兩者實現的功能上並不大，but係功能實現個方式上很相似（本質都是對伺服器內存打patch…） 促使我將l4dtoolz和tickrate_enabler二合一的根本原因在於，tickrate_enabler本身實現解鎖tickrate功能個代碼邏輯過於複雜，而l4dtoolz對內存進行補丁的代碼亦完全可以復用與tickrate上。 （btw，繁體字也是我母語之一）