Send message from gridworld on behalf of agent, e.g. from an action

[thaije]

What is your question?
Is it possible from the gridworld, e.g. from an action, to send a message?

I thought of using the get_messages_func, adding the new message, and then adding it to the agent using the set_messages_func. However, that does not work, as the set_messages_func puts every message as the content of a new message (???). Why do we want that?

To what is your question related?

• I am not sure if I should use MATRX.
• I have a question about the idea behind MATRX.
• I don't know how to do something with MATRX.
• I don't know where to find something.
• I think I found a bug, but I am not sure.
• I want to contribute, but don't know where to start.
• Something else.

[thaije]

@jwaa help

[jwaa]

Help is on the way!
And the answer is... no.

This functionality is currently missing. This will probably be part of the next version that revolves around events/scenario-management. The idea then is to have a kind of event system nested in the GridWorld that could (among others) send messages to agents. I will create an issue for it, can you tell me why you need this feature now?

Your second question is about why the _set_messages unwraps the received Message list. However, I cannot see anything that the received messages get unpacked to be later packed into a new Message instance in that function. Could you clarify where the rewrapping in a Message object occurs?

However, you did found a bug. Previously we decided to enforce all messages to be of type Message. This to allow users to extend on that class to help build agent communication languages (e.g. HATCL). It would make no sense if any meta-data would be thrown away if only the content of each message would be made user accessible. If you concur, we can make a bug report out this and fix it.

[thaije]

AIMS was in need of this feature, but I fixed it in a different manner, so for now there is no hurry. In AIMS, agents have a memory in which they memorize things they have seen. Agents exchanged memory items through messages, which needed to be done in an action now: Agent A performs action IdentifyBuildingStatus, which in the mutate identifies the building status, updates the memory of Agent A, and was suppossed to sent a message to Agent B with the new info. The latter part was thus not possible, so I fixed this by directly changing the memory of Agent B in the action's mutate function. So for now, no high priority for this feature, but it is something we do indeed need in the long term for the event system, and overal is a handy feature to have.

As for the second question, I refer to this line of code: https://github.com/matrx-software/matrx/blob/dev/matrx/agents/agent_brain.py#L517

# Since each message is secretly wrapped inside a Message (as its content), we unpack its content and
# set that as the actual received message.
received_message = mssg.content

Why is the message (assumed to be) packed as the content of a message? I can't wrap my head around the logic behind this, so I can't determine if it is a bug or not, but I would say so.

By the way, I remember we talked about that messages should not be deleted anymore, but only set to read?
Thus deleting this line:
https://github.com/matrx-software/matrx/blob/dev/matrx/agents/agent_brain.py#L491

[jwaa]

It seems there still some bugs out there regarding Message. I gues it originates when we transitioned from a more 'closed' message system ("just provide the content, MATRX does the rest"), to a more open system ("create your own message [type], en MATRX does the sending").

In this specific case the inline comment is misleading: received_message never actually gets initialized as an actual Message object. This would indeed make no sense, though it doesn't make much sense now either.

Since it seems messaging is littered with bugs and unclarity, I made a single bug report to encapsulate all of these: #112
I invite everyone to add to it until we have the time to fix them.

Finally, I added a feature request to include an action with which an message can be send: #113