Actors intended to be used by players should be loaded always

Roboticy3 commented

2026-10-30 23:01:12 +00:00

Owner

In the crpg example, a bug arose where Benjamin could "spoke rule" one of Geno's dialogue choices simply because Geno wasn't there. This can be fixed by loading the Geno "actor", even though the agent playing Geno is not present.

This is sort of an esoteric issue and something that's easy to run into when setting up the engine. Generally, it might be good for this example to be paired with a setup guide for using the engine with Godot, though that's a problem for another day. Anyway, the fix is to load all actors intended to be used by player-characters beforehand, then go from there.

In the crpg example, a bug arose where Benjamin could "spoke rule" one of Geno's dialogue choices simply because Geno wasn't there. This can be fixed by loading the Geno "actor", even though the agent playing Geno is not present. This is sort of an esoteric issue and something that's easy to run into when setting up the engine. Generally, it might be good for this example to be paired with a setup guide for using the engine with Godot, though that's a problem for another day. Anyway, the fix is to load all actors intended to be used by player-characters beforehand, then go from there.

Roboticy3 added the

documentation

examples

labels

2026-10-30 23:01:12 +00:00

Roboticy3 referenced this issue

2026-10-30 23:13:17 +00:00

Make explicit boolean support for variants #89

Roboticy3 commented

2026-10-30 23:31:33 +00:00

Author

Owner

Well, I can't believe this, but I'm doubting myself again on my conclusion that flags for "ownable" speakers are a bad idea. Here's the problem:

Currently, an actor being connected and a UI being connected are the same thing. That's just how my implementation works. Actors belong to a conversation, and the game uses the signal of an actor being created/destroyed to manage the UI. This is a sensible approach because actors "below" conversations don't have to worry about their positions across conversations, leading to more complex data structures. And, for my usage at least, there's no reason one user would want to connect to two conversations at the same time. If they did, they would just make two actors in the same way a linux dude would make two terminals.

Changing how the UI behaves is an option: on top of making actors all added statically, the UI doesn't reveal itself by adding an actor. Instead, it simply opens.

Another option is to make speakers ownable again, and add a counter-spoke rule at the engine level for ownable speakers that make them behave as if they are actors.

...

Second approach is still worse because it assumes two things: 1, that actors map to single speakers, which is not always true, and 2, that who the playable characters are can even be known by the config file.

Alright, my doubt is cleared.

Well, I can't believe this, but I'm doubting myself *again* on my conclusion that flags for "ownable" speakers are a bad idea. Here's the problem: Currently, an actor being connected and a UI being connected are the same thing. That's just how my implementation works. Actors belong to a conversation, and the game uses the signal of an actor being created/destroyed to manage the UI. This is a sensible approach because actors "below" conversations don't have to worry about their positions across conversations, leading to more complex data structures. And, for my usage at least, there's no reason one user would want to connect to two conversations at the same time. If they did, they would just make two actors in the same way a linux dude would make two terminals. Changing how the UI behaves is an option: on top of making actors all added statically, the UI doesn't reveal itself by adding an actor. Instead, it simply opens. Another option is to make speakers ownable again, and add a counter-spoke rule at the engine level for ownable speakers that make them behave as if they are actors. ... Second approach is still worse because it assumes two things: 1, that actors map to single speakers, which is not always true, and 2, that who the playable characters are can even be known by the config file. Alright, my doubt is cleared.

Roboticy3 commented

2026-10-30 23:36:53 +00:00

Author

Owner

I will adjust the engine so that speakers can be tagged. That's a good way to filter for player speakers since #90 is still a good ways off.

Rows
Columns

Actors intended to be used by players should be loaded always #88