<![CDATA[Faldon Forums - ^session_flags no longer correctly reset]]>2026-02-02T13:44:59ZPunBBhttps://www.faldon.org/topic/7780/<![CDATA[Re: ^session_flags no longer correctly reset]]>Turns out it was worse than this. Since October 2024, all in-memory flags had been saving to disk instead. Probably not the greatest given the limited rewrite cycles of SSDs. Anyway, it's fixed now. Thanks for reporting this bug ]]>https://www.faldon.org/user/2/2026-02-02T13:44:59Zhttps://www.faldon.org/post/73966/#p73966<![CDATA[Re: ^session_flags no longer correctly reset]]>I've had two instances where I had to reset a particular ^flag on a player to get some feature working again. I don't think I've ever used the same flag names without the ^ so those should be 0. Then again it has been over a decade since I last really worked on any of the scripts.
The most recent example was the ^active_storm flag on ~pr0phet~. Had to manually set that to 0.
]]>https://www.faldon.org/user/431/2026-01-30T09:36:19Zhttps://www.faldon.org/post/73965/#p73965<![CDATA[Re: ^session_flags no longer correctly reset]]>Are you sure this is what you are seeing? The one non-obvious behavior right now is that ^flag, if not set, gets its value from the stored flag (without the ^), though it caches that value for the session (setting the permanent flag later does not change the ^flag). But I'd thought it has always been that way. I will look into this though.]]>https://www.faldon.org/user/2/2026-01-29T19:37:19Zhttps://www.faldon.org/post/73964/#p73964<![CDATA[^session_flags no longer correctly reset]]>The previous behavior of flags prefixed with ^ was that they would reset when a player logged off.
Currently it does not appear to always do this, leading to subtle bugs.
]]>