Trouble understanding variable update

[zeyus]

I've made some progress, but there's an odd issue which probably means I've done something silly. I have an agent status (which might be better to set as an agent state?), and it does successfully update based on some conditions, but I've outlined the flow here with the initial status of 0, and if there's any messages, it means there's a neighbouring agent, and if not, then it might be possible to move. For some reason, all agents end up with the playing status (hardcoded to 1 in the example below).

I actually think spatial 2D messaging could be better for this code as well, but I don't think that is the issue here?

# ...
agent.newVariableUInt("agent_status", 0)
# ...

FLAMEGPU_AGENT_FUNCTION(search, flamegpu::MessageNone, flamegpu::MessageArray2D) {
    FLAMEGPU->message_out.setVariable<flamegpu::id_t>("id", FLAMEGPU->getID());
    FLAMEGPU->message_out.setIndex(FLAMEGPU->getVariable<unsigned int>("x_a"), FLAMEGPU->getVariable<unsigned int>("y_a"));

    return flamegpu::ALIVE;
}

FLAMEGPU_AGENT_FUNCTION(interact, flamegpu::MessageArray2D, flamegpu::MessageNone) {
    const unsigned int my_x = FLAMEGPU->getVariable<unsigned int>("x_a");
    const unsigned int my_y = FLAMEGPU->getVariable<unsigned int>("y_a");

    unsigned int num_neighbours = 0;
    for (auto &message : FLAMEGPU->message_in.wrap(my_x, my_y, 1)) {
        ++num_neighbours;
    }
    if (num_neighbours == 0) {
        FLAMEGPU->setVariable<unsigned int>("agent_status", 0);
    } else {
        FLAMEGPU->setVariable<unsigned int>("agent_status", 1);
    }
    return flamegpu::ALIVE;
}

class step_fn(pyflamegpu.HostFunctionCallback):
  def __init__(self):
    super().__init__()

  def run(self, FLAMEGPU: pyflamegpu.HostAPI):
    prisoner: pyflamegpu.HostAgentAPI = FLAMEGPU.agent("prisoner")
    n_ready = prisoner.countUInt("agent_status", 0)
    n_playing = prisoner.countUInt("agent_status", 1)
    print(f"step: {FLAMEGPU.getStepCounter()}, n_ready: {n_ready}, n_playing: {n_playing}")

Output:

Processing Simulation Step 0
step: 0, n_ready: 0, n_playing: 256
Processing Simulation Step 1
step: 1, n_ready: 0, n_playing: 256

I tried with a small grid and low number of agents to investigate, and there are agents with zero other agents around them:

minimal reproducible working example:
https://gist.github.com/zeyus/fcf451d4d2ea9f891adfbd26e13c4d1c

[Robadob]

I actually think spatial 2D messaging could be better for this code as well, but I don't think that is the issue here?

Spatial 2D is intended for continuous space agents (e.g. float coords, rather than int). It's generally alot more expensive in terms of performance.

I think your problem is misunderstanding array messages. They are literally an array, any element which does not have a message output to it, still exists, it just contains zero for every variable. So retrieve variable "id" and check that it's none-zero (0 is only used as an ID for agents who's ID has not yet been set).

[zeyus]

Yep, fundamental misunderstanding, that makes perfect sense now, I was under the assumption that messages would only be retrieved if there was something output to them! Thanks :)

[Robadob]

Yeah it's a bit awkward. I can't remember the exact reason for doing it that way (probably my fault though).

[Robadob]

You could implement your own discrete messaging data structure via MsgBucket if it really bothers you. Just need to implement a hash function to convert the 2D grid coord to a single int.

[zeyus]

I can imagine there are use cases for retrieving empty message locations (even just in terms of checking if communication has occurred in that position), and there's probably a cost in terms of extra checks if the entire array is expected and only a subset is passed to the function.

For what I'm doing it will be perfectly fine as is, and funnily enough (not sure I'll use it in the end) I just used x + y * grid_width to convert the grid position to a sequential int for giving agents a transient ID based on where they were at the time, I thought I could store the energy balance for each agent during the game phase in a 1D array, but it still faces the race conditions we'd discussed in the other thread anyway.

[Robadob]

It's probably more a case of maximising performance. If we did checks, it would add an extra redundant branch for the assumed most common use-case, whereby someone is doing a cellular automata with 1 agent in every cell.

Probably not the largest overhead in the world (as with R=1, you're only accessing 2/8/26 messages), but avoiding redundant code is normally a large part of our design philosophy (e.g. spatial messages, we have users perform the distance check, to avoid doubly loading location vars).