For now, the text compression feature is beyond what I can reliably implement, so I’m putting it on hold and taking a break before continuing. The current version should be stable, but if you run into any issues or have any suggestions, please let me know.

目前文本压缩功能超出了我能稳定实现的范围，所以暂时决定搁置这一部分，先休息一段时间。当前版本应当是非常稳定的，如果遇到任何问题或有任何建议，随时在评论区/讨论区留言。

這種情況確實很難辦...其實我這邊也一直在想要怎麼盡量避免這類狀況，目前說實話還沒有找到一個既穩定又通用的做法。不過之後只要有比較好的點子，我這邊還是會持續更新，盡量減少這種狀況。

我懂了，謝謝大佬。所以其實是維持到威脅消失(但遊戲本身沒辦法判斷威脅來自特定事件)，上限是至多0.6天。
我當時的情況是：發生了被激怒之後剛好又來了一個墜落事件(白信封)掉的是敵對派系，導致威脅狀態持續，這確實感覺沒辦法。

另外補充一下：你看到的 0.6 天其實比較像是一個「保險機制」。並不是說事件相關的內容會在 RimTalk 裡被強調 0.6 天那麼久，而是「在有威脅存在的情況下，這個模組查詢資料時，只會去讀取過去 0.6 天內發生的威脅事件」。

換句話說，它的作用比較像是幫忙把太久以前的威脅自動切掉，理論上反而不太會出現你說的那種情況。

這個MOD的邏輯是，一旦威脅（比如這裡的美洲獅被激怒）在遊戲裡被判定為解除，模組就會立刻停止往 LLM 填入相關的威脅資訊。

至於會出現「討論半天美洲獅」的情況，一方面是受 RimTalk 本身的上下文視窗影響。比如說，如果前 6 則對話裡都有提到美洲獅，那後面的對話很高機率也會一直帶到美洲獅相關的內容，就會需要在提示詞那邊自己多加一些限制，讓 LLM 盡量不要重複同一件事講太久。

另外也有可能是因為同時裝了其他記憶類的模組，比方說 Expand Memory。我自己覺得它的想法是好的，不過目前看起來整體實作還不算很穩定，有時候就比較容易出現這種「一直圍繞同一件事討論很久」的狀況。

@benny30912 主要是因為 Rimworld 實際上並沒有一個可以判定「特定某個威脅」是否已經解除，或者現在這個威脅到底是跟哪一次最近的威脅事件綁在一起的機制；遊戲基本上只知道「現在是危險狀態」或「現在是安全的」

而且再加上很多威脅事件的持續時間差異很大，沒辦法很籠統地下結論說，比如「動物被激怒」就一定只會持續一小段時間。這一點是目前最棘手的地方。就算真的把威脅事件的持續時間全部暴露在XML，也還是得先做大量的審視和思考

大佬，請問設計上為什麼將威脅事件的持續時間設成固定而不是持續到威脅解除(或解除後一小段時間)？
因為襲擊持續0.6天合理，但美洲獅被激怒一槌打死了，小人卻討論半天
或是可以基於不同事件設定持續時間/把威脅事件的持續時間暴露在xml中？

Source is now available on github: https://github.com/SaltGin/RimTalkEventPlus/

@OCEAN 修好了，现在所有隐藏的事件一律不会显示

@OCEAN 我看一下 应该很好解决

大佬，我在rimtalk调试界面看到了重复很多个隐形魔的报告
就是隐形魔尖啸事件后，地图上隐形魔没有现身时，在ongoing下面会列出一堆[隐形魔]
也许可以优化一下？

神一品

@sapphire star 嗯...最好还是开一个讨论帖或者找外链发我一下全部内容，因为理论上即使是卡在任务列表里，当前地图上没有相对应的触发物体（pawn或者物件）是不会加入到evetn list里的，我需要看他的整个def里有没有LookTargets或者其他脏东西导致现在的代码把他加进去了

事实上已经有好几层过滤器了（不然大量垃圾quest都会塞到event list里），所以他就算不能达成success也没关系

虽然我很想发给你但是steam回复有字符数限制，我只能截取一部分，实际上这个任务是作者只写了任务失败的Fail而没写任务完成的Success判定导致卡在进行中任务列表里的，我说这个只是举例一下
<li Class="QuestPart_DropPods">
<inSignal>Quest1.pickupShipThing.SentSatisfied</inSignal>
<dropSpot>(-1000, -1000, -1000)</dropSpot>
<customLetterLabel>回报已送达</customLetterLabel>
<importantLookTarget>null</importantLookTarget>
<thingsToExcludeFromHyperlinks />
<destroyItemsOnCleanup>True</destroyItemsOnCleanup>
<faction>Faction_35</faction>
</li>
<li Class="QuestPart_Pass">
<state>Enabled</state>
<inSignal>Quest1.pickupShipThing.SentSatisfied</inSignal>
<outSignal>Quest1.OuterNodeCompleted4</outSignal>
</li>
<li Class="QuestPart_QuestEnd">
<inSignal>Quest1.OuterNodeCompleted5</inSignal>
<outcome>Fail</outcome>
</li>

@sapphire star 绮罗商户信息一直保留是正常的，这样子处理的话有个好处是无论如何AI都会了解这只绮罗是借住的商户+她的背景故事，唯一缺点就是看起来比较费token；后续我会把这部分内容也加入压缩功能里进行一部分筛除，不然可以想象到如果有好几只绮罗商户的话event list里会全是猫儿，会直接把别的事件也顶掉...

堕天使的话因为我没有玩所以不知道他def结构和判定是什么样子的 如果可以进开发者模式把任务列表里的debug信息复制一份就帮大忙了

非常好的mod，对话生动多了。不过有一点小瑕疵，某些永远不会结束（或者说作者没设置结束条件）的任务，例如绮罗商户和更好的堕天使里的通讯器任务因为任务不会结束导致rimtalk反复提起，还好放到整个游戏过程中大概也就二三十次调用才会触发一次

好家伙，你这个更好理解，我马上着手做个简单攻略教程。

我喜欢你

強啊，支持

Also planning to add a mod settings screen with a toggle so you can choose whether to compress quest description text or not. The compressed version should only lose a minimal amount of detail, but if token usage isn’t a concern, the full uncompressed text will always give the most accurate and vivid results.

同时我也会加入一个模组设置界面和压缩功能开关，可以自行选择是否压缩任务文本。压缩后的文本理论上只会损失极少量细节，但在不在意token消耗的情况下，给AI模型直接喂完整未压缩的文本，返回的对话效果无论如何都是最理想的。

As of 11/27/2025

I'm currently working on a lightweight event description compressor/formatter. Since most quest descriptions are already naturally split into modular blocks, it's easy to re-use them efficiently. Once this is in, it should cut the tokens used for quest text by more than half compared to the current version.

这两天正在制作一个事件描述压缩的功能；考虑到rimworld大部分任务描述本身是由大量高度模块化的小部分组成，所以实际可以相当高效的直接引用+删减这部分内容。功能上线后预计能把任务文本的token消耗减少一半以上

以后得给rimtalk充AI月卡了

Whoo, now I just need something that will pick up on in-game conversations and rimtalk can actually replace rimdialogue, I really don't know why they thought a paywall was a smart idea.

cy，到时候试试

回来环也成月付游戏了

笑死我了ahhh

@萌声主播风信子 诶你这小孩

有中文吗

@HeLLDaN That was actually my first idea too! The only problem is that as soon as you start touching the “memory” side, everything has to go through several extra layers of processing, which adds a lot of hidden complexity and failure points.

You might have noticed the packageId is actually rimtalkeventmemory ; I originally wanted to do something closer to that weekly/monthly story summary, but it felt like it would get too bloated.

I think the core idea behind Expand Memory is excellent, but its implementation naturally needs an extra LLM layer, memory saving, and lots of moving parts that can break. I haven’t figured out a cleaner way to do that yet, so for now I settled on a lightweight addon that just helps conversations stay aware of ongoing events.

Maybe in the future I’ll find a good way to do the story summary approach...

That's a great idea! You know, it would be awesome to have a story generated from the colony's history. But instead of constant updates, maybe a neural network could create a short summary every week or month, like in the "RimTalk - Expand Memory" mod, just without all the minor details it adds.

Will upload the source code to github when it’s a bit more cleaned up