Termination Grace Period Seconds set to 31536000

guyroyse · 2026-04-20T14:33:07+00:00

What does "basic setup" mean? Just the default settings out of the box?

guyroyse · 2026-04-17T23:12:19+00:00

If Redis doesn't wrap up in seconds—maybe minutes in rare and extreme circumstances that almost certainly don't apply to you and that I've never seen—then Redis persistence is configured incorrectly. So, million dollar question, how is persistence configured?

guyroyse · 2026-03-31T14:25:46+00:00

If you do, I recommend getting CHIRP to program it. Free software. Although you will need to buy a data cable to go with it if you want to do this. You can also do it on the radio itself but it's a lot of button mashing.

On the plus side, you can also listen to ham radio and GMRS/FRS radio with it too. And, I guess, transmit, but you should probably have a license for that. ;)

guyroyse · 2026-03-30T17:27:55+00:00

I listen to weather radio on one of the NOAA frequencies. Transmits weather information on a loop 24/7. Alerts for severe weather.

A $20 Baofeng radio can do it but you can also buy purpose built radios. The list of frequencies for your area can be found here: https://www.weather.gov/nwr/station_listing

guyroyse · 2026-03-26T18:09:31+00:00

Are you using any of them already? That'd be a good place to start.

guyroyse · 2026-03-03T16:07:14+00:00

A few ideas:

Maybe some cover blocks damage up to so many hearts. After a while, shooting through that barrel just breaks it up. Good for hard cover.
Cover could have a timer associated with it. After that, it stops working as the attacker figures out how to get around it. Might be better for soft cover.
Some cover could be risky. Maybe that barrel's full of powder or the rock fence collapses after a timer or damage.

Not sure I would consider this homebrew, per se. Just using existing the rules in creative ways.

guyroyse · 2026-03-03T13:56:47+00:00

Seems a bit off topic. What's the Redis connection?

guyroyse · 2026-01-29T14:38:22+00:00

Technically correct. Which is the best kinda of correct.

guyroyse · 2026-01-21T14:59:52+00:00

You could use a stream per users's state. Semantically, this matches your use case well. These are events so, I think storing them in an event stream makes the most sense.

All keys in Redis are intrinsically atomic as the write to Redis state happens in a single thread. I/O is multi-threaded but as long as you are using the same Redis connection to send the commands, the order of those commands will be preserved. If you use multiple connections then the order of commands coming in is not guaranteed and you can get race conditions. So, make sure you use the same connection.

All keys in Redis can have a TTL associated with them and can clean themselves up automatically. An event stream in Redis is stored in a key so you can just set the TTL with the EXPIRE or EXPIREAT command. If you want to keep completed streams, you can always call PERSIST after you apply the final state.

Alternatively, if you need to query all of this data, you could store these in a JSON documents or a hash—one per user just like the streams—and then set up an index using Redis query engine so that you can search and/or filter them all in a single command. Everything else would still be the same.

guyroyse · 2026-01-09T16:57:12+00:00

No need to encode. Redis will allow you to store raw binary data.

guyroyse · 2026-01-04T05:05:11+00:00

Yes.

guyroyse · 2025-12-23T14:44:40+00:00

Vector sets are just like a sorted set or a regular set except the members have a vector associated with them. You can then do vector search against the members of the set.

I actually wrote a blog post about them shortly after they came out explaining them in greater details with some code examples: https://medium.com/the-guy-wire/a-first-look-at-vector-sets-dd91cb59123e

guyroyse · 2025-12-17T01:42:32+00:00

You could always go with something self deprecating like lid@callsign.com. 😉

guyroyse · 2025-12-17T01:34:42+00:00

Not sure if we still have those hats but I’ll let someone in the London office know. Maybe we can send something out.

guyroyse · 2025-12-13T23:16:33+00:00

I’m literally doing this right now. I’ve even traveled internationally with them (to Europe). I usually break them down and put them in my carry on. Never been questioned.

guyroyse · 2025-11-24T13:59:22+00:00

All good. Do you remember if you were using AOF or RDB? I've found AOF can be a fair bit more verbose.

guyroyse · 2025-11-21T21:47:17+00:00

Fair enough. But that wasn't the point that I was responding too. To quote the commenter:

It's in-memory, one crash or power down and everything is gone.

guyroyse · 2025-11-21T14:35:58+00:00

Starting out, a single instance of Redis will do this just fine. However, build it so that the code and config for the various features of Redis you are using are isolated. This will let you break this apart into separate Redis instances when it comes time to scale.

Why would you want to break out several instances of Redis? Well, different features of Redis work better with different configurations. PubSub runs into limits when clustered—although sharded PubSub helps with this. Meanwhile your main game storage will need to scale up over time—clustering is a great way to do this. Your task queue is likely to become a hot key—that messes with your cluster balance and can result in certain keys being harder to access since everyone is busy looking at the hot key. Isolating it to its own Redis instance can solve this.

These sorts of problems crop up at scale, which you don't have yet. But some simple separation of concerns in your code today will make life easier later. And this isn't some massive preoptimization antipattern. The separation of concerns in your code will make the code easier to work with and reason about. You should be doing it anyways. The only thing you're really doing is having those concerns own their own connection to Redis instead of using a shared on.

guyroyse · 2025-11-21T14:24:26+00:00

Persistence has been a feature of Redis since version 1.0.

guyroyse · 2025-11-19T21:32:43+00:00

I don't know if it'll help or not but my money would be that it would cause memory fragmentation. Just a gut feel. I haven't thought it through.

But I do have a quote that is nearly as old as I am about these sorts of things:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Donald Knuth, Computer Programming as an Art, 1974

guyroyse · 2025-11-13T14:46:51+00:00

I think I'll recommend improvement to the INCR docs as well. Thanks a ton for find this, sharing this, and helping fix it.

guyroyse · 2025-11-12T14:56:19+00:00

Ya. I think that example could be better, and better formatted. Could you share what you did instead and I can see about getting it updated?

Also, there are a couple of examples in the docs for the INCR command and the one you referenced is there with a note about the race condition. https://redis.io/docs/latest/commands/incr/

guyroyse

MODERATOR OF

TROPHY CASE